Ever published an open-source project and didn’t see a frenzied crowd of people storm by, taking down the servers on the first night after the release? Well, most communities don’t form overnight and with so many different projects that are available today, it’s difficult to attract contributors without doing a little marketing.

But that isn’t what most of us programmers are used to or comfortable doing. And so our code lays abandoned in repositories that nobody cares about. How can you change that? This post series will go through a number of things you could do to help your project be discovered and make it easier for others to get involved.

The series

This is a first post in a 5-piece long series. Here’s the rest:

Your community starts with users

The question people usually start with is “how do I get people contributing to my project?” Too often though, it is to early to ask. Before even thinking about contributors, you should consider your users.

Without a reasonable user base, it will be tricky to attract any contributors at all. Do you contribute to projects you’ve never used yourself? Probably not. And so doesn’t everyone else.

I assume you built your project to solve a problem you had and chances are, that other people have it too. You just need to find them.

Figure out what your target audience is

Even the smallest pet project is a product, something that solves a problem or fills a particular need. What problem does yours solve? And who might find it helpful? Thinking along these lines will help you target your efforts and make sure you don’t bother people who really don’t care.

Making a vim plugin for pbcopy/pbpaste ? You’re probably looking for people using vim on OS X and posting it to the emacs subreddit might not be the smartest thing to do. For an open source app for hobby beer brewers you might want to target computer savvy craft beer enthusiasts.

Find out where these people hang out and join them. Certain groups of people gravitate towards specific places and communication channels, have their subredits and local meetups.

While the vim example is ridiculous, it’s not always this obvious and with as passionate crowd as programmers are, you can get yourself into some pretty heavy flame wars. Sometimes, the negative response to won’t be just ignorance. People will go out of their way to hate on it. Targeting the right people also means that you won’t upset people who don’t share your opinion.

Set up a landing page

Before telling people about your project, you need a place to send them to that has all the information they’ll need to get started. This can be a README on Github, blog post or dedicated website.

It should summarise what your project does, where to get it, how to make it work and optionally end with a quick, high-level reference of the most common tasks or problems. People need to know about the various edge cases, but presenting them too early may be too much to grasp. Focus on the things your app is great at and leave edge cases for the documentation.

If your app produces some sort of visual output or has graphic interface, don’t forget to include screenshots. If not, then take snaps or make gifs of the terminal as you use it. People will understand your project much faster from seeing it rather than just reading about it.

Lastly, your landing page should give people means of contacting you or the community around your project for support. Set up a mailing list, IRC channel or Gitter and put them in. For smaller projects, your email is fine too. Be mindful of your target audience’s habits. A bunch of info-sec experts might not be very keen on hanging out in your Facebook group.

When your page is ready, you can post it to various places where all sorts of programmers hang out like Hacker News and r/programming. However, these efforts aren’t targeted and your success there depends on luck a great deal. I’ll be talking about the better ways to spread the word in a future instalment of this series. Stay tuned!

When you get down to making your page, remember that it’s not as much about the form as it is about the content. In fact, you should spend more time thinking about the content than the rest. Are you a ninja front-end dev that can whip up a beautifully designed website from scratch in two hours? Go for it! But spending three months fiddling with margins isn’t time well spent. README on Github is just fine.

Coming up next

Next time, we’ll take a look at making your project more accessible for users. What’s worse than not being able to understand what a project really does? Having to spend three hours trying to make it work.

Next post: 2/5: Making your project accessible