In certain communities (I’m looking at you, open source), it’s common to describe the way the community functions as a “meritocracy”. The idea is that the community is led by those who demonstrate ability and skill, and in software projects, that usually means the people who write the code. Meritocracy is often espoused as being fair, in that anyone is theoretically able to rise to the top: all they have to do is demonstrate their ability.
For instance, in Jono Bacon’s recent book The Art of Community, he says:
The magic of meritocracies is that the playing field is level for everyone. Those who work hard and show a recurring commitment to the community are rewarded. Those who think that driving a car with a blue neon light underneath it will impress us are going to be sadly disappointed.
Few would argue that a meritocracy is a bad thing. Its fundamental basis is in rewarding hard work. This concept largely maps to the general life lessons that we are all raised with: work hard and you reap the rewards of your efforts.
I don’t mean to pick on Jono here, because his is only one description of meritocracy that I’ve seen. Others include PHP, Apache, and Eclipse.
But something about Jono’s description of meritocracy really jumped out for me: “the life lessons that we are all raised with.” I was lucky — let’s call it what it is and say privileged — because I did receive that message, largely through my schooling at a private, girls-only school. But it came long with other messages, from my family and society at large, like “people won’t like it if you’re too clever” and “ambition is so unattractive” and “don’t put yourself forward, dear.”
Noirin Shirley describes the situation in a blog post from 2006, FLOSSPOLS, Sexism, and Why Meritocracy Really Isn’t:
On the surface, [meritocracy is] a completely fair, non-sexist, open concept. Anyone can get in, anyone can progress, as long as theyâ€™re good enough.
Thatâ€™s very, very rarely true. Generally, at best, a meritocracy turns very quickly into a merit-and-confidence/pushiness-ocracy. Good work doesnâ€™t win you influence â€” good work thatâ€™s pushed in othersâ€™ faces, or at the very least, good work of which others are regularly reminded â€” wins you influence. And thatâ€™s where women fall down.
In short: meritocracy benefits not only those with skill and ability, but with the self-confidence to demonstrate their skill publicly and demand recognition for it. And self-confidence is highly gendered.
Noirin also writes about unconscious bias in judging merit:
The final problem with meritocracy is that even after all the noises of â€œitâ€™s all about the quality of contributionsâ€, women very often arenâ€™t judged on the same basis as men. This is one of the few areas that FLOSSPOLS have looked at where both men and women perceive there to be a problem. People listen or pay attention to women, or donâ€™t, based on the fact that theyâ€™re female â€” not based on the merit or otherwise of their contributions.
This reminds me of the practice of blind auditions, where it was found that women have greater success rates in auditioning for orchestral roles when they are placed behind a screen that prevents the listener from perceiving the musician’s gender. We know that unconscious sexism plays a part in how merit is judged in other “meritocracies”; it would be naive to think that the situation is different in software development.
So when I hear someone say that their project is a meritocracy (especially if they say it as if it’s necessarily a good thing), I tend to assume that they are 1) naive, and 2) probably have a bunch of unexamined, unconscious sexism going on.
So I guess this is the part where I offer suggestions for improvement.
First up, I’d like to see projects expand the definition of merit. A pure “meritocracy” based on coding skill will lead to crappy documentation, ugly UIs, and poor community dynamics. Watch How Open Source Projects Survive Poisonous People and consider whether a poisonous person who writes good code has merit or not. Then consider any steps to seniority or leadership that are based on “merit”. Do you judge nothing but code, or do you also include other skills, including “plays well with others”, in your reviews of people’s merit?
Accept that some of your contributors will have lower “merit”, but may still be valuable, perhaps by taking on easy tasks so that more senior contributors have time to work on harder ones, or perhaps as senior contributors in training. Don’t expect people to come in with a high level of skill and ability from day one, and be prepared to accept contributions that are less than perfect. Denise Paolucci’s Teaching People to Fish is a good read on this subject for project leaders, and Angie Byron’s A diary of two developers describes a similar situation from the contributor’s perspective, showing how imperfect contributions quickly iterated can lead to a more active, collaborative community than a single perfect patch.
Finally, don’t require pushiness along with ability. To what extent do people need to put themselves forward to progress in seniority? Could you offer commit bits or leadership roles to people who haven’t asked for them, if you think they’ll do a good job? And consider “pulling” instead: ask people how their patch is progressing, and offer to review it privately. Make yourself available via a back-channel such as instant messenger and ping contributors from time to time to give them an opportunity to talk without appearing pushy.