Growing the community around your open-source project

Does your project have an active community, but there’s still way more work than it can handle? This is the final part of the Marketing for open-source projects series and this time we’ll focus on how to keep your community growing.

Catch up

If you haven’t yet, check out the previous parts in the series:

The why

If you kickstarted your community successfully but it isn’t growing as well as you’d expected, there might be about a gazillion reasons behind it. And you need to figure out what they are and be realistic about them.

They will fall into one of the following categories:

things that you can do something about
and things that you can’t.

Is your issue tracker getting cluttered up again as the number of people working with it rises? Isn’t your response time to newcomers getting longer as you spend more time discussing things with people from within the community? Do you keep the documentation up to date? Has it been two years already since you last published a blog post about this project?

It’s not difficult to let these little things slip as the community around your project becomes an unstoppable machine that requires your constant attention. But forgetting about them entirely can stop your project’s growth in the future. The bigger the project gets, the more complex it becomes with many processes and conventions that newcomers must familiarise themselves with, making it harder to become a contributor again.

The second category of issues is just unfortunate. Particularly for smaller and niche projects, the audiences may not be as big to yield enough contributors. Maybe there are only ten people on the planet who are both interested and capable of contributing. Five of them already do, three have ridiculously limiting contracts with their employers and the other two prefer spending time with their kids. You might be battling the windmills here.

The world of tech moves forward at an insane pace. Have you not noticed much activity on your COBOL library in the past few years? You may be doing everything right, but people are just moving to the shiny new thing. When you started, you were replacing and old, rusty piece of tech and a day will come when this happens to your library as well. It’s up to you whether you’re willing to work with what you’ve got or jump ship like everybody else is doing.

Now that we’ve laid out the possible issues, how to go about solving them?

Rinse and repeat

The simple answer is: keep at it! Revisit your project’s friendliness towards newcomers every now and then. Experiment with new things and approaches to see what works for you.

Keeping your community running and growing it further requires at least as much effort, if not more, as it took to build it. But at least this time you’re not on your own.

Make these community management good practices a part of the workflow. Is someone breaking the interface? Then they should fix the documentation as well. Encourage people who complete large new features to blog about them. It’s their work and they should be proud of it!

Explain everything you do in a series of posts on your project’s page so other people can jump in and help you. Open up the decision process and give trusted members full access to the repo. That way, you’ll create a self-sustaining machine that can live without consuming all of your free time and energy.

Take it to a conference

There are many conferences focused on different areas of computing all over the world. If you want to get your project some extra exposure, sign up to give a talk about it at a conference. If it’s not a commercial product, there are so many opportunities to talk about it. Meet-ups, hacker spaces and other focus groups are also a great place to presenting your project to people that might find it useful.

One of the biggest out there is FOSDEM in Brussels. Sign up your project next year, even if it’s a lighting talk only.

Work with less experienced devs

Most of the advice given throughout this series is focused at people that know their way around pretty well. This means mid-level to senior devs that have been programming for a while. The problem with this audience is that they have a full time job and maybe a family and other side projects going on.

Taking a little extra time to make your project friendly for less experienced contributors may give you access to large groups of highly motivated people who would like to gain experience by working with you. This includes students, people switching stacks and industries. They won’t be inexperienced forever and building relationships with them might get you some great community members down the road.

I published a post about working with students on this site few months ago. Check it out!

Pay people to contribute

This is a pretty unrealistic option for individuals, but might be well worth it for companies. Using websites like BountySource.com, you can set a price for features you’d like to see implemented and someone might pick it up.

Another option is to organise contests and hackatons where people work on your project for a price or some form of recognition.

Many companies also choose to sponsor key people from the community and pay them full-time salary to work on their project. Another great example that open-source doesn’t mean that no money is involved.

The end

Open sourcing your project is a great start, but it’s even more fun when people start using it and getting involved. Even though we’re mostly programmers, open-source is much more of a social enterprise than it seems.

This was the last post in the Marketing for open-source projects series. Thanks for sticking out with me till the end, I hope you found it useful!

If you have any questions by posting a comment below or tweeting at @radekpazdera.

Cheers!