How to recruit open-source contributors

As avid followers of my work may know, I’ve been contributing to a Linux distribution called Gentoo Linux for about 10 years now. One of the things I do is lead Gentoo’s involvement with the Google Summer of Code, an excellent program in which Google pays college students $5000 to work on open-source projects for the summer.

Since I took over Gentoo’s involvement in GSoC a few years back, I’ve made a series of improvements that enabled us to increase our student-to-developer recruitment rate from about 20% of students (roughly the average across all of GSoC) to about 65%. I gave a talk a couple of months ago on what we did to accomplish this at the extremely popular local BarCamp called MinneBar, which had more than 900 attendees this year. The videos were just posted online so I wanted to share this one, as well as a summary of my talk. (For the observant viewer, the tables in view are mostly empty because everyone’s sitting in back and around the sides.)

Step 0: Set goals and measure progress

Before you can start improving anything, you need to figure out what improvement actually means to you. This means setting goals for success, and knowing what metrics are important. In the context of GSoC, most open-source projects have one or both of these two options as their primary metrics:

1. Recruit new developers
2. Merge new code

Getting new people and more usable code tend to be correlated to some extent but there’s definitely not a perfect mapping between them. It’s easy to take on interns for a summer who have no clear ties to your project and are likely to move on after taking your money, but who have outstanding résumés and contribute some great code. It’s more challenging to figure out in advance which people are most likely to stick around after the end of an internship, but in many ways it’s a higher return on your investment of time and money.

In my experience, the 5 hours/week that typical mentors spend working with new contributors is sufficient for them to have completed the project themselves, so there’s a net-zero benefit after a summer of effort. And that’s assuming that the new contributor’s code is well-designed, well-written and well-documented so it’s instantly mergeable (a major assumption).

Therefore, the true benefits tend to come after you successfully recruit new contributors who stay involved in the project for a year, two, or longer down the road. They’re much more productive after that initial experience and have a much better understanding of how the open-source project works. In my view (and therefore Gentoo’s view), the code produced during someone’s initial summer of work tends to serve its best purpose as inculcation to a community and its standards, rather than as useful code in itself. We regard that code as potentially throwaway work that is more of an experimentation than something on Gentoo’s critical path.

Now for the second half of this step, actually measuring progress toward your goals. In Gentoo’s case, we scale our methodology based on the scale of our GSoC during any given year; if there’s 5 or even 10 students, we keep things pretty informal because it’s hard to fall through the cracks. But if there are 15 or 20 new contributors, more process is required to prevent failures to the greatest extent possible. On the high end, we maintain a spreadsheet to track weekly updates from students, any notes from their mentors, and (most importantly) progress toward becoming a developer. We try to determine early on whether they’re interested, later open a ticket to track their recruitment, and continue communicating our interest until we get them on board. We track every step of the funnel to ensure that we’re minimizing our losses throughout the pathway.

Step 1: Establish the expectation that most contributors become long-term developers

At the start of our funnel is the simple concept of communicating our expectations at the very earliest point in the process. On our webpage about what it takes to join Gentoo in GSoC, we explicitly tell people in the very first paragraph that most of our students become developers at the end of the summer. This puts the idea into people’s minds before they even get started that this is how things work, so they’re chewing on that thought throughout their projects.

Step 2: Make them interact as true community members, not through a mentor’s conduit

The data show that communicating like every other contributor and participating in the community, particularly in a realtime fashion, is a major component in ensuring a successful project:

And our experience further shows that it’s critical to recruiting students after the summer’s over by building social ties with people, not just experience working on a codebase. While the code may draw people in, it’s the social network that gets them to stay. We work very hard to make sure new contributors are behaving as typical members of the community, not just talking with mentors via private emails. Before they even begin their projects, we require that they post to one of our public mailing lists — in fact, we won’t even consider their application unless they do so. (The same holds true for proving experience with the necessary tools like git, but that’s a different story.)

Step 3: Don’t let them slip away. Sometimes, all you have to do is ask.

To people new to the open-source world, it can all seem pretty intimidating, and everyone seems to have vast amounts more experience than the new folks do. That’s why it’s so important to reach out to them at every opportunity. Don’t wait for them to ask you, go and ask them — whether it’s regularly checking in to see if they’ve hit roadblocks to periodically asking them whether they’d like to join your project after their internship ends. We’ve found that oftentimes, students are extremely excited about joining Gentoo at the end of the summer, but they didn’t make a peep about it all summer long. They thought they were being judged unworthy because we didn’t ask them, while we may have thought they weren’t enthusiastic because they didn’t bring it up. Frequent, clear communication is almost never a problem in this type of virtual environment, and it serves the additional purpose of continuing to build social ties.

Conclusion

If you wish you could recruit more people to your project, give these steps a try. To get in-depth help or more details about how to apply this to your project specifically, let me know and I’d be happy to work with you.

By the way, here are the slides from my talk in case you’d like to browse through them. But you’ll find that the video is much more useful since I don’t put much text on my slides, and there was a great deal of discussion during my talk.

Disclosure: Google and the Gentoo Foundation are not clients. I am an active Gentoo Linux developer.