The long-tail means that for “every Wikipedia, there are a thousand other wikis that never managed to get a second contributor.” The same applies to open source projects, and it’s something you need to think about if you want to ensure the longevity of your project. If it’s just you, handling all those pull requests and tickets by yourself, you stand a good chance of running out of steam unless you can attract additional contributors to help you with the workload.

The First Real Milestone

It’s easy to think of the first milestone as being the first git push to your repository. Or perhaps the first time it gets popular on Hacker News or Reddit. But these are just distractions. Really, the first and most important milestone is attracting the second contributor. Someone who is not you. Someone who can fill in when you are busy. Someone who brings a second perspective to the project. The start of your community.

This is your real first milestone because of the work it takes to get to this point, and because of what it means for your project. Attracting that second contributor should be your primary focus. (And indeed, attracting additional contributors should be one of your highest priorities too.)

There are three steps involved:

1. Make the project attractive to potential contributors
2. Make it easy to start contributing
3. Recognise contribution and commitment to the project

I’ll cover each step, and share some of the things I commonly recommend at the Apache Software Foundation, where this sort of community building is a central component to graduation from the Incubator.

Attracting Potential Contributors

Your first task is to market your project. Now, I know that “marketing” is something that a lot of open source people are suspicious of, because it seems very corporate. But it’s a crucial part of any project—just as crucial as product management, quality assurance, community building, etc. More and more, we’re seeing that successful open source projects have to replicate processes and activities that make business successful if they wish to succeed in the marketplace. And for open source, succeeding in the marketplace means attracting contributors who donate time and attention to the project.

What do I mean by marketing? I mean things like:

• Design a nice website. Describe the project. Provide screenshots. Make it obvious what the product does and who it’s for.
• Set up a mailing list, or some other sort of forum. Be helpful and supportive. Answer people’s questions. Monitor tags on StackOverflow. Listen for mentions on Twitter. Pay close attention to your community.
• Set up a Twitter account. Consider setting up additional social media accounts as appropriate. Each account is an opportunity to reach a new segment of your community. Make sure that important news about your project is shared across all of your social media profiles.
• Make regular releases. Release often, even if they’re just bugfix releases, or alpha versions. Each new release is an excuse to spread the news about your project, and communicates that the project is alive. Post links to your social media and other popular link sharing sites.
• Set up a project blog. Don’t think too hard about it. It doesn’t have to be perfect, and the theme doesn’t matter. Just start blogging. Talk about the project. How is development going? What sort of features do you have planned? What’s a solution to a common problem people have? Each new blog post is an opportunity to get the word out about your project. Don’t forget to post links to your social media and link sharing sites.

When we talk about marketing in this sense, what we’re really talking about is communication. Communicate news and information about your project as far and as wide as you can. Listen to people when they talk back.

Make It Easy To Get Started

So you’ve started to attract people to your project by communicating news and information about it far and wide. Your next step is to make your project an attractive place to contribute.

Surprisingly, the first thing you should do is tell people that you’re interested in receiving contributions. This is not a default, so you have to make it explicit. Most projects are run by one person, and a lot of people may have had negative experiences contributing patches or pull requests. So your first job is to make people feel welcome and actually encourage contribution. Putting a welcoming statement on your homepage, and in your README file, is one good way to accomplish this.

The second thing you can do is write a contribution guide. What is obvious to you may not be obvious to others. What sort of issues are you interested in? What branching model are you using? Are there are any tests that must be run before something will be merged? Do you require changes to the docs with every pull request? Document it all. And while you’re documenting that, document the source. Make it easy to hack on features. Point people to the correct modules and files for various things. People shouldn’t have to do archaeology to contribute a patch.

Taking It Further

Add a “starter” tag to your issue tracking system. Add this to issues that are good for new contributors. It’s a way of communicating that this is good to go; no permission required to start work on this. And while you’re at it, you might also consider adding “easy”, “medium”, and “hard” tags for people looking to contribute a second patch. Anything to help get some of that context out of your head and into a place where others can use it.

Consider providing resources aimed specifically at new contributors. These might be developer docs, say, or developer blog posts. Pick a module and do a post about it. What is it? Why is it necessary? How would you extend it? Not only is this a great marketing activity, but it makes it as easy as possible for someone to get started with the code. Also consider doing group videos calls where people can ask questions or pair with you.

These are exactly the sorts of things you might expect to do with co-workers at a private organisation. But you need to purposefully replicate these things for your open source project if you want to enjoy the same benefits.

Keep an eagle eye on things. Keep a look out for anyone who looks like they might want to contribute. Reach out to them, help them, prod them in the right direction. Do everything you can to get them over that first hump. All first-time contributors have an “activation energy” and it’s your job to either lower that, or give them the boost they need.

Recognise Contribution And Commitment

Once people are contributing, you’ll obviously want to keep tabs on the situation. Set up weekly or monthly reminders for yourself. Take notes if you have to. But whatever you do, don’t get complacent. People who are regularly contributing to your project need encouragement, nurturing, and recognition.

Contribution comes in all shapes and sizes. You don’t have to code to contribute to open source. The idea that code is primary, or indeed the only thing that counts, is actively harmful to open source as a whole. People with a lot of valuable time and expertise are being ignored, sidelined, or driven away from contribution. You can do your part to combat this by making it explicit that you will recognise diverse forms of contribution.

If you’re going to prioritise anything, prioritise social skills over technical skills. They will be more useful to you in the long term, if you care about the community and people that comprise it. What would you rather have: a large community of helpful and cooperative people who have decent technical skills, or a small community of unhelpful and uncooperative people who have excellent technical skills?

If someone makes a number of positive contributions to the project, you should make them a committer. For many people, “committer” means someone with a commit bit. But I think that a more useful definition is someone who is committed to the project. Reward this commitment with official recognition by adding them to the project, giving them write access to the project infrastructure, and announcing the news.

Whatever you require from people before making them a committer is, in effect, a barrier to entry. Lower this as much as possible. Remember that Git is a time machine. Bad changes are easy to back out. Take that leap of faith.

Conclusion

People matter. As we say at the Apache Software Foundation: community over code. Make this a priority from day one. Recognise people who contribute in a positive way to the project and the community.

The first major milestone in any open source project is attracting a second contributor. This is more important than any feature or any release, and adding a second contributor means you are doing better than most on your way to building a sustainable project.

Are you struggling to add a second contributor to your project? Have you had success with your community building efforts? Got a tip to share that I didn’t cover in this post? Throw us a comment below.