Exploring why people contribute to OpenStack
No doubt that OpenStack is one of the largest open source development efforts existing at the moment, with Linux, Debian and few others. What can be improved to make the OpenStack community grow faster? How can we help new contributors become productive more rapidly?
Whatever dimension you look at, the growth of the OpenStack developers community is astonishing. I’ve looked at the reasons for this growth and I’ve identified four main causes summarized in my presentation at Linux Conf North America and Open World Forum in Paris last year:
- One clear mission to solve a hard problem
- One initial core team with strong motivation to solve that problem
- One team dedicated to recruiting new team members
- One clear path to onboard new members in the team
The first two points are pretty clear already and don’t seem to need much tweaking: those ain’t broken, so no need to fix’em. The other two are not broken either but they’re the kind of stuff you want to stay on top of because once you notice they’re broken, the cost to fix them will be higher. Recently I started to ask myself what margins of improvements there are in recruiting and onboarding new members in our communities.
I quickly realized that while we know a lot about the top contributors to OpenStack, we don’t know much about the ‘long tail’ of contributors. It’s fairly easy to understand why the people responsible for 80% of OpenStack code and documentation work on the project. But who are the occasional contributors and what are their motivations to join the community? I embarked on a quest to get to know this long tail in an effort to understand how we can improve recruiting and onboarding new developers.
After a conversation with Asheesh Laroia, of OpenHatch fame, I selected 55 random developers from the list of those who submitted a single change to the integrated OpenStack programs during the past 12 months. These people went through quite a huge chunk of trouble only to submit one single patch: besides learning enough of the quite complex OpenStack code, they had to sign the Individual CLA (maybe the Corporate CLA, too), learn about git review and the other tools, go through the code review process. I would expect that whoever goes through that process, does it with the intention to stick around. So I asked the sample two simple questions:
- What made you decide to submit a patch to OpenStack?
- What prevented you to submit more patches?
I’ll wait a few days for their answers and share more details. Feel free to answer the questions leaving a comment here, too.