OpenStack, Meritocracy and Diversity

These days, any time I reach for the word “meritocracy” when I want to explain something about OpenStack’s technical community and its governance, I give pause.

Clearly, in some circles, the concept of “meritocracy” has been seriously discredited and represents a system whereby elites perpetuate their power by tilting the rules in favour of themselves.

I’m not much of a political thinker and my understanding of internal American politics is pretty limited (think watching The West Wing and vaguely following the spectacle of a presidential election) so the first time I really encountered the term was in the context of the GNOME project. From the GNOME Foundation Charter:

GNOME is a Meritocracy

A corporation, organization or individual should not be granted a place in the foundation unless its presence is justified by the merits of its contribution. Money cannot buy influence in the GNOME project: show us the code (or documentation, or translations, or leadership, or webmastering…).

and, subsequently, other projects like the ASF. From How The ASF Works:

When the group felt that the person had “earned” the merit to be part of the development community, they granted direct access to the code repository, thus increasing the group and increasing the ability of the group to develop the program, and to maintain and develop it more effectively.

We call this basic principle “meritocracy”: literally, government by merit.

What is interesting to note is that the process scaled very well without creating friction, because unlike in other situations where power is a scarce and conservative resource, in the apache group newcomers were seen as volunteers that wanted to help, rather than people that wanted to steal a position.

Being no conservative resource at stake (money, energy, time), the group was happy to have new people coming in and help, they were only filtering the people that they believed committed enough for the task and matched the human attitudes required to work well with others, especially in disagreement.

To me, the “power” we’re talking about here is the ability, permission or empowerment to get stuff done which advances the project. In some projects that means commit access, but ultimately it means building up the respect and trust of the other contributors to the project such that you can more easily influence and drive the direction of the project. You achieve that “power” by getting useful stuff done (defined broadly – code, documentation, translations, leadership, marketing, advocacy, etc.) and all it grants you is the ability to get more useful stuff done. In a healthy project, we want to give that power to more and more people rather than concentrating it in a small elite.

This is what we mean when we say “OpenStack is a technical meritocracy”. I hate to think of those well-meaning principles of project governance being sullied by “meritocracy” being used to explain away the social inequities in U.S. politics. I also don’t like to think of us seeing these principles as some sort of platonic ideal that don’t require us to constantly evaluate how we empower people to help advance OpenStack.

One hint that all is not perfect is the level of diversity within the project. Yes, we have diversity of opinions and a diversity of sponsoring organizations, but we don’t have an impressive level of gender, race or cultural geography.

My good friend from GNOME days, Daniel Veillard, asked this question of the Technical Committee in Hong Kong:

We are in China. There is no Asian on the podium. What can you do to actually try to improve the situation?

Yes, we have a meritocracy and anyone can advance to leadership positions within the project, but we need to recognize that there are extremely difficult language and cultural hurdles in front of many.

An example of these barriers is how we often conduct our Design Summit sessions. Quite regularly – especially when you get a large number of the more established contributors in the room together, folks who are good friends who understand each other well – the discussion can often devolve into a punchy flow of casual in-joke ridden sound-bites. I’m as much to blame for that as anyone, but sometimes I think back and shudder at how hard it must be for someone outside of the “in group” to join that discussion.

I’ve seen a number of examples where a new non-native English speaker has paired with an existing contributor to lead a design summit session about their work. What can work really well is that the existing contributor can help to engage the attendees, slow down the conversation and ensure the new contributor understands the feedback being given … without attempting to take credit for the work of the new contributor. This is just one technique we could use to empower new contributors.

Anyway, in summary – I think OpenStack’s “meritocracy” is a well-meaning model for empowering contributors (and celebrating their contributions) but we should all be on the lookout for ways that we can make a special effort to empower contributors from groups which are not already well represented in the leadership of the project.