Questioning the merit of meritocracy.

http://geekfeminism.org/2009/11/29/questioning-the-merit-of-meritocracy/
In certain communities (Im looking at you, open source), its common to describe th
e 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 u
sually means the people who write the code. Meritocracy is often espoused as bei
ng 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 Bacons 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 rewarde
d. 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 th
at we are all raised with: work hard and you reap the rewards of your efforts.
I dont mean to pick on Jono here, because his is only one description of meritocr
acy that Ive seen. Others include PHP, Apache, and Eclipse.
But something about Jonos description of meritocracy really jumped out for me: the
life lessons that we are all raised with. I was lucky lets 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 wont like it if youre too clever and ambitio
n is so unattractive and dont put yourself forward, dear.
Noirin Shirley describes the situation in a blog post from 2006, FLOSSPOLS, Sexi
sm, and Why Meritocracy Really Isnt:
On the surface, [meritocracy is] a completely fair, non-sexist, open concept
. Anyone can get in, anyone can progress, as long as theyre good enough.

Thats very, very rarely true. Generally, at best, a meritocracy turns very quic
kly into a merit-and-confidence/pushiness-ocracy. Good work doesnt win you influenc
e good work thats pushed in others faces, or at the very least, good work of whic
s are regularly reminded wins you influence. And thats where women fall down.
In short: meritocracy benefits not only those with skill and ability, but with t
he self-confidence to demonstrate their skill publicly and demand recognition fo
r 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 its all a
out the quality of contributions, women very often arent judged on the same basis as
men. This is one of the few areas that FLOSSPOLS have looked at where both men a
nd women perceive there to be a problem. People listen or pay attention to women
, or dont, based on the fact that theyre female not based on the merit or otherwi
heir contributions.
This reminds me of the practice of blind auditions, where it was found that wome
n have greater success rates in auditioning for orchestral roles when they are p
laced behind a screen that prevents the listener from perceiving the musicians ge
nder. We know that unconscious sexism plays a part in how merit is judged in oth

er meritocracies; it would be naive to think that the situation is different in so

ftware development.
So when I hear someone say that their project is a meritocracy (especially if th
ey say it as if its 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, Id like to see projects expand the definition of merit. A pure meritocra
cy based on coding skill will lead to crappy documentation, ugly UIs, and poor co
mmunity dynamics. Watch How Open Source Projects Survive Poisonous People and co
nsider whether a poisonous person who writes good code has merit or not. Then co
nsider 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 peoples merit?
Accept that some of your contributors will have lower merit, but may still be valu
able, 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. Dont expe
ct 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 Paoluccis Te
aching People to Fish is a good read on this subject for project leaders, and An
gie Byrons A diary of two developers describes a similar situation from the contr
ibutors perspective, showing how imperfect contributions quickly iterated can lea
d to a more active, collaborative community than a single perfect patch.
Finally, dont 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 havent asked for them, if you think theyll 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 s
uch as instant messenger and ping contributors from time to time to give them an
opportunity to talk without appearing pushy