How to Attract New Contributors

One of the biggest challenges that free and open source communities face is attracting new contributors to their project. It's a frustrating problem... after all, your community has built The Greatest Software Ever, why aren't people beating down the metaphorical doors to join in on all the fun?

The barriers to entry for any project can be subtle and numerous, and even those of us who do this every day face this challenge all of this time. Recently, Stormy Peters put the question to members of our team: What's the single best tip you've gotten for attracting new contributors? Or, alternatively, what's the single thing that's made the most impact on attracting new contributors to your project?

Recently the Community Leads team within OSAS decided to dedicate part of its weekly meeting to exploring topics that affect team members in their interactions with projects. When it came to asking about how best to bring on contributors, the answers were certainly interesting.

Build Good On-Ramps

A common theme among the replies was making contributions as easy as possible. "Make it easy to contribute—and this is a broad definition of contribution, including not just code, but also documentation, design, and even issue reports," answered Garrett LeSage of our Design and Access team. "When people file issues, make them feel like a vital a part of the process in solving the problem or adding the new feature. If possible, assist everyone, from newcomers to seasoned project participants alike, through additions by talking with them in IRC channels, 1:1, and other means of communication."

Josh Berkus, Project Atomic Community Lead, echoed these comments: "[The] best advice I can give is 'Make it obvious how to contribute.' For example, if you're on Github, accept pull requests, and document clearly where your test suite is."

My personal bias about ease of discovery showed up in my own reply. For me, pushing the standards of onboarding in a consistent way on a project's website is key. We need to make sure project software is easy to understand, easy to find, and easy to start using. That's the three core principles of community onboarding a lot of us in OSAS try to follow, and building good websites is a great way to implement those principles.

Leslie Hinson, Community Lead for PatternFly, agreed with the sentiments about onboarding and added: "PatternFly has recently put a ton of effort in trying to provide a good onboarding experience for designers (especially since they are not accustomed to GitHub). We created a wiki with instructions/workflow/infographics on how to use github. Also, when someone does join the community, try to make sure we make that the best experience possible. Welcoming them and making sure they have the proper channels of communication to reach out for questions. Right now, in PatternFly, for the most part, contributions are limited to design and development, there is other areas that people can be contributing but don't."

"We are working hard to understand this question better," chimed in Brian Exelbierd, Fedora Community Action and Impact Coordinator. "The best thing we've done so far is to really emphasize on-boarding and to try to get newer contributors looking at how to make being a new contributor easier. Our most successful groups, as far as we can estimate, have a mentoring process in place. We are hoping to build on that and make it easier to create these onboarding programs for different subprojects."

Have Tasks Ready

Another line of suggestion was ensuring that new community members have tasks readily available. Providing "a list of easy-to-get-started-with-tasks combined with personal invitations" was Peters' own contribution to her question. Rich Bowen, Community Liaison for the RDO Project, concurred: "Specific tasks that beginners can work on. It tells them that they are empowered to participate, and it shows them where to get started. Also, each task probably has someone associated with it who thought it needed to get done, and that person is the one who will coach the beginner along as they work on it. A lot of people want to be involved, but are just waiting to be asked. Also, exhaustive step-by-step 'first patch' tutorial, particularly for projects (like OpenStack!), where that process is convoluted."

Infrastructure Manager Karsten Wade also agreed: "Making sure there are small tasks that are obvious, and that even the people who sweep the floor are acknowledged and shown a pathway toward more... when they are ready, so people can grow expertise at their own pace. So this means not doing all the things when there is a professional staff."

"...Improving our contributor experience is one of our biggest focus areas in Gluster," responded Gluster Community Liaison Amye Scavarda. "We're currently working on improving our test suite so that a patch doesn't languish in manual testing. I'm mindful that testing is one of the areas where new contributors can get involved, so I'm trying to balance between 'automate all the things' and 'automate just enough to get out of your own way.' When Drupal implemented testbot, we noticed a drop in contributors—because testing a patch was a way to contribute to the project that ended up being a gateway to other contributions. This lesson's stuck with me."

See The Individuals

Finally, recognizing newcomers for their individuality was key. CentOS' Jim Perrin replied, "Remember that no one is a small fish in the community. Even if you're chasing larger groups of users/contributors, be sure to take the time to talk to everyone and make them feel that they matter."

SDN/NFV Community Strategist Dave Neary put in a great conclusion: "Newcomers look for 'people like me' to approach when in an unfamiliar environment—the more diverse the welcoming committee, the more welcome people will feel."

(Image courtesy of Nicholas A. Tonelli, under CC by 2.0.)