A few days ago, I asked 55 OpenStack developers why they decided to submit one patch to OpenStack and what prevented them from contributing more. The sample polled people who contributed only once in the past 12 months, looking for anecdotal evidence for what we can do to improve the life of the occasional contributor. To me, occasional contributors are as important as the core contributors to sustain the growth of OpenStack in the medium/long term. Since it’s possible that the community has already already hired the best candidates among Python developers and system operators, to sustain the growth of OpenStack we need to tap into the wider Python community and experts of large distributed systems coming from other languages (Java, for starters). Knowing what hurdles new contributors face when they first join OpenStack is a first step to make onboarding easier and multiple contributions more frequent.
People who replied are for the most parts users of OpenStack, that is developers and dev-ops people working on deployments of OpenStack for internal usage and system integrators who develop and deploy OpenStack for their customers. A third group of occasional contributors are developers of projects that use or are used by OpenStack, like Docker or Ceph.
The top reasons to submit a patch went from the practical convenience of having patches maintained upstream, to fixing bugs (discovered during a proof of concept or in more advanced phases of a deployment) or to add/fix funcionalities to better integrate OpenStack with other projects. Finally, people contribute patches for personal growth and to enrich resumes.
Why don’t they submit more? There are three main stumbling blocks. Legal hurdles delayed contributions, and even prevented (at least) one. The reasons for the delays range from NDAs with customers to incompatibility with corporate policies to release software under open source license and sign a Corporate Contributor License Agreement. Another group of reasons for the delay is the long time it takes for contributions to travel the review queue. The time it takes for patches to get in OpenStack repositories was mentioned more than once. Finally, the lack of simple issues to fix in the spare time: apparently the community fixes simple bugs too rapidly.
The results cannot be considered representative but they seem to confirm that legal hurdles and speed of the reviews are preventing more casual contributions. While there are already many discussions on how to improve reviewing times, changing the way we handle contributions legally requires a massive endeavour to change OpenStack Foundation’s bylaws. The fact that simple issues to fix are hard to find is new to me: it may indicate that there are lots of people joining the community fixing these ‘low hanging fruits’ or something else. I think more analysis is needed in this area.