open source marketer and community manager

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.

Giving back patches to the community as a small payment for receiving so much.
Getting recognition for the patches we are using internally in our lab.
Upstreaming of our patches so we do not have to port them on every updated release.

I have not contributed yet, or was prevented from writing a few other patches due to the CLA really not fitting our situation. Our organization has, after years of effort, figured out how to release software open source. The org has not ever ran into a project that needed a CLA though, and it may take several more years for it to come to grips with them. The OpenStack project itself does not have a CLA that fits the situation either. The legal team is reviewing the issue and is working on it, but it is very slow going.

IMO, the CLA has been a very high hurtle that projects like the Linux Kernel have very successfully gotten away without.