Tagged with Open Source

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.

Tagged ,

If Knowledge is Power ...

If knowledge is power, then sharing your knowledge empowers others.

"Illumination"{.aligncenter width="395" height="500"}

Illumination by Mr. Skinner

In the open-source world, each of us endeavours to strengthen the communities to which we contribute. There is no better way to strengthen a community than empowering your fellow contributors with your knowledge.

There are no excuses in the open-source world for not sharing your knowledge. Our tools and processes are designed to make this happen naturally.

Having discussions on a mailing list allows other contributors to benefit from the information being shared in the discussion. It also ensures that information is archived for future contributors.

Detailed commit messages ensures that current and future developers can fully understand your reasoning for a given change. Pushing your in-progress work to a public branch allows others to take the work on and finish it, even if you don't have time.

Thinking out loud in bugzilla means that even if your work is not complete on the problem, others can run with your initial ideas or analysis.

Using a public wiki for note taking and giving others access to your jumbled up thoughts, ideas, hints and tips is a great way to open your brain to the world.

A nice side-effect of all this is that if your knowledge is shared openly and archived, you don't need to have such a good memory! :-)

RISE UP &
SHARE{width="386" height="500"}

RISE UP & SHARE by alyceobvious

In other contexts, it might be good practice to jealously guard your knowledge. If you're the guy that everyone has to come to because you're the one guy who knows how to do something, that's good for your job security, right? Surely, if you share your knowledge freely, that means anyone can do your job?

This is the exact opposite to what should motivate you as you contribute to a community. You absolutely do want to make it possible for others to come along and kick your ass. If somebody appears out of nowhere and starts doing your job better than you could ever have done, then that is an absolutely awesome outcome!

Tagged

The OpenSSL License

At least twice previously I've gone off and figured out what this whole
OpenSSL GPL incompatibility thing is all about and, in pretty short
order, completely forgotten the details again. Well, this time I've
written
it down
so I won't forget.

Tagged