[openstack-dev] The Evolution of core developer to maintainer?

Joe Gordon joe.gordon0 at gmail.com
Tue Mar 31 22:30:05 UTC 2015

I am starting this thread based on Thierry's feedback on [0].  Instead of
writing the same thing twice, you can look at the rendered html from that
patch [1]. Neutron tried to go from core to maintainer but after input from
the TC and others, they are keeping the term 'core' but are clarifying what
it means to be a neutron core [2]. [2] does a very good job of showing how
what it means to be core is evolving.  From

"everyone is a dev and everyone is a reviewer. No committers or repo
owners, no aristocracy. Some people just commit to do a lot of reviewing
and keep current with the code, and have votes that matter more (+2)."

To a system where cores are more then people who have votes that matter
more. Neutron's proposal tries to align that document with what is already

1. They share responsibility in the project's success.
2. They have made a long-term, recurring time investment to improve the
3. They spend their time doing what needs to be done to ensure the projects
success, not necessarily what is the most interesting or fun.

I think there are a few issues at the heart of this debate:

1. Our current concept of a core team has never been able to grow past 20
or so people, even for really big projects like nova and cinder. Why is
that?  How do we delegate responsibility for subsystems? How do we keep
2. If everyone is just developers and reviewers who is actually responsible
for the projects success? How does that mesh with the ideal of no
'aristocracy'? Do are early goals still make sense today?

Do you feel like a core deveper/reviewer (we initially called them core
developers) [1]:

In OpenStack a core developer is a developer who has submitted enough high
quality code and done enough code reviews that we trust their code reviews
for merging into the base source tree. It is important that we have a
process for active developers to be added to the core developer team.

Or a maintainer [1]:

1. They share responsibility in the project’s success.
2. They have made a long-term, recurring time investment to improve the
3. They spend that time doing whatever needs to be done, not necessarily
what is the most interesting or fun.

Maintainers are often under-appreciated, because their work is harder to
appreciate. It’s easy to appreciate a really cool and technically advanced
feature. It’s harder to appreciate the absence of bugs, the slow but steady
improvement in stability, or the reliability of a release process. But
those things distinguish a good project from a great one.

[0] https://review.openstack.org/#/c/163660/
[2] https://review.openstack.org/#/c/164208/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150331/128ea08b/attachment.html>

More information about the OpenStack-dev mailing list