Open Stack

> 
> Over the last year we have seen some contraction in the number of
> companies and individuals contributing to OpenStack. At the same
> time we have started seeing contributions from other companies and
> individuals. To some degree this contraction and shift in contributor
> base is a natural outcome of changes in OpenStack itself along with
> the rest of the technology industry, but as with any change it
> raises questions about how and whether we can ensure a smooth
> transition to a new steady state.
> 
> What aspects of our policies or culture make contributing to OpenStack
> more difficult than contributing to other open source projects?
> 
> Which of those would you change, and how?
> 

Comparing OpenStack contribution to other open source projects, the biggest and
most obvious thing coming in to it is our use of gerrit vs GitHub pull
requests. For those used to contributing to other current large scale projects,
this can be a non-intuitive thing for them to learn. Luckily, I think we have a
lot of guidance documented on how our workflow works. And having worked with
both types of projects, I definitely would not propose or support moving away
from Gerrit, even with it's warts.

One of the bigger challenges I see for new or casual contributors is the
tendency for a lot of projects to only accept perfection. I don't know if this
is a side effect of the explosive growth years, something we have indirectly
encouraged with the way we do code reviews, or some other factor, but I have
seen plenty of patches proposed that are clear improvements, but get downvoted
for comment spelling, preferred variable naming, or other minor things that
either are not ultimately too important or would be easy to clean up with a
later patch.

I do think it's important we have high standards for new code accepted into our
projects. We need to make sure we are delivering high quality services and
tools. But for things that do not end up changing the end user or operator
experience of using OpenStack, I feel we need to be more relaxed. This can
easily change things for a new or casual contributor. They might get excited to
find something they can quickly change in the code to improve things, but then
get discouraged and leave and never come back if we make it look like we are
more concerned about grammatically correct code comments than functioning code.

I would also love to see more of our existing members spend time helping new
contributors. But I don't know how we can really change any policies to make
this more likely to happen. Speaking from experience, even for full time
contributors (or maybe especially for full time contributors?) we are usually
already busy with several other things that make it hard to carve out the time
to work with someone new. But I do feel it is an important way to welcome new
contributors and make sure it is not always the same folks overloaded on trying
to address several issues at the same time.

We do have some great work done with our onboarding documentation and our
regular events with the Upstream Institute. We just need to make some effort to
help consumers of those resources move on past that point.

Which makes me think of some of the discussion we've had about getting people
to core. I am actually not sure if this is the right focus. I do think it would
be great to have a lot of core members or potential candidates, but I think
there are plenty of contributors that would like to be involved and would be
able really help out projects without necessarily wanting or needing to be
cores to do so. I would like to see more focus on helping people contribute
without needing to commit to taking on more responsibilities.

> Where else should we be looking for contributors?
> 

Universities are a good one. And being an open source project in a relatively
easy to learn programming language, I think we could do more to encourage
formal programs with CS schools as something students could do. I've brought up
the idea of "internships" in the past. It would be great if we could work with
schools to set up some sort of program where we are able to help someone new
through accomplishing a discrete set up tasks that can benefit all involved.

I do think the majority of our resources will be through commercial interests
though, with vendors using or benefitting from OpenStack contributing
development, infrastructure, or testing to help the project continue to meet
their customers' needs. NFV is a big area now where I think there are some
resistant to changes being driven to meet their use cases, but I think it's
important that we are open to those types of changes in order for OpenStack to
be able to meet their needs.

Sean