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.
Geek Feminism Blog 
Another element that occurs to me is that most meritocracies are partially based on hard work. Thats a very different criteria from technical skill. For an open source project thats often a good thing – you don’t give someone much authority unless they’ve put in the work to become familiar with the project, and contribute regularly.
But it could also result in useful contributions being ignored simply because the contributor doesn’t put in as many hours as others. I’m not talking about a totally fresh new contributor here, but simply someone with experience who’s voice may be drowned out by those with more time.
Similar to the corporate cultures where staff need to work long hours to gain respect, even if they’re more efficient than their colleagues or doing a great job anyway..
THIS.
I saw some partially private discussion on Twitter along the lines of “I think my project is already on top of this, but we’re not exactly drowning in women committers”. It’s probably worth noting that no, indeed this is no guarantee of gender or other diversity in a project. It does remove a particularly pervasive and subtlety damaging form of mythology though.
Could this be transplanted to the wiki? It sure does come up a lot IME.
I’ll do what I can tomorrow. This is an important essay, methinks.
Reciprocity is important. Where people accept the gift of free software and do something in return, it’s vital that that return work also gets acknowledged in some way.
If a project has one or more people who identify contributions and make sure they get noted (by blogging about them, etc) this reduces/eliminates the perceived need for ‘pushiness’. A contribution will get noted.
Also, it addresses another key issue, namely that different contributions are perceived to be different in value. Over recent years documentation too has received specific attention, and rightfully so. But bug triage/fixing, build engineering are traditionally lower valued, while actually critically important.
The more time goes on, the more I realize that open source projects aren’t meritocracies, they’re oligopolies run by people with available time and energy. I’d call them “petty fiefdoms” but that (a) makes me sound like a weenie, and (b) has too strong of a negative connotation.
I’ve produced patches for open source projects that were completely ignored. Conversely, I’ve completely ignored patches submitted to me because they didn’t do anything that I cared about. Why? Because reviewing, integrating, and maintaining code takes time and effort. Since open source developers are rarely paid for their work, they are unlikely to use up valuable time with other people’s stuff.
The solution you propose involves folks in OS projects spending even more time helping out others, which requires a great deal of privilege. Bringing others into a project may be good in the long run, but it has huge up front costs for the team. On small projects, the cost could be prohibitive.
Well, most of the people who currently run open source projects *have* a great deal of privilege, so that works out quite nicely!
Re: up-front costs and long-term payoffs, yes, that’s covered in detail in the linked article Teaching People to Fish.
In my experience, open source projects aren’t designed with users in mind – the developer wants an app that meets their needs. Vetting patches and other contributions tasks are secondary to the developer, since the app already does what they want.
Instead of asking hobbyist developers to do more work, what can be done to change open source to encourage the acceptance of contributions?
1. Make open source projects money-making ventures. If a developer is making cash on an app, then they’re more likely to put time and effort into it. It’s in their interest to groom contributors so that the app gains more users, more features, and thereby generates more cash.
2. Make the control of the project’s lifecycle easier. Systems like Launchpad that make the secondary tasks more interesting and more fun for the dev. Another example is the WordPress dev site is awesome for developers, since it makes releasing versions and pushing them out to users a snap, which leaves more time for the grooming you suggest.
3. Make it easier for contributors to contribute. Remove the developer’s involvement in the cycle entirely. Distributed source control and wikis should make this easier, but they don’t seem to be used much.
e
“Well, most of the people who currently run open source projects *have* a great deal of privilege”
I don’t understand. Care to expand?
No really, no. This is not the place for 101-level discussions. However, some of the links from http://geekfeminism.wikia.com/wiki/Privilege might help.
I’ve read that (previously, and again), but it does not exactly help me understand what kind of privilege you are hitting on.
Having free time that they (can) spend on their open source project?
Having access to a computer and the Internet?
Having the necessary education and mental capacity?
All of the above?
I’m sort of hard put imagining how to contribute to an OS project without all of the above, so yes, anybody contributing to open source is probably rather privileged compared to the average of mankind, but how is that a helpful distinction?
All of the above. Then add in the fact that 95% or more of open source project leaders are men, and you have everything that came from the male privilege checklist; and the 90% or more that are white also have everything that came from the white privilege checklist. Most are also straight, cisgendered, temporarily able-bodied, speak English as their first language and have a university degree, though those are probably not in the high 90% range. In other words, most open source project leaders are fortunate to have almost every privilege that exists in our society. Things are, on average, easier for them than for people who don’t have those privileges.
Erigami, up-thread, said:
and implied that “asking hobbyist developers to do more work” was unreasonable.
My take is, if someone has almost every privilege that society can give them, then it’s not unreasonable to ask them to take a little time out of their privileged lives to think of others. In fact, they are the very people who have the most time and resources to do it.
I see.
A privilege I’m missing sorely is more than 24 hours in a day :7 (Don’t we all?)
For those people in volunteer-based open source project leadership positions I know, ‘more work’ is infeasible, the best they could do would be to spend the time they are spending differently, and since they tend to be in leadership positions because they do the tedious stuff that Needs Doing ™, I doubt that would be helpful.
You don’t necessarily need the leaders to mentor either, other senior contributors can (and IME do) very well pick up newbies that want to work on their area of interest and foster them. But pushing too hard for volunteers to take on additional jobs has its dangers: either they see the point and add the load, then overtax themselves and burn out, or it stops being rewarding for them, and you lose them as well.
It’s a fragile balance between enough encouragement and driving them away.
@Skud Loved this blog post. One niggling bit: I’ve always liked the term “Do-ocracy” for how most FLOSS projects work:
http://www.communitywiki.org/en/DoOcracy
I recently decided to come out of my shell and contribute to an open source project. I chose to work on Puppy Linux because of the unstructured community, and chaotic development model, and because Puppy is just awesome. I made no effort to hide the fact that I’m female, nor to call an unnecessary amount of attention to that fact. I do pretty good work (if I do say so myself), and have had no trouble attracting beta testers and users, and I’ve always been treated with complete respect and gratitude.
I don’t think the concept of meritocracy is flawed. However, it is obvious to me that many of the people that end up in “leadership” positions are not the type of people who are good at community building. Strong programming ability seems not to be frequently paired with empathy and social skills, especially in men, but even I have to make a conscious effort to compensate for my relatively low EQ. As far as I can tell, people with the right temperament for social leadership, and technical skills for project management, are a really rare occurrence in open source, (and in corporate environments too).
Perhaps one of the reasons I am successful is because I am not trying to immediately integrate with existing developers. As I build my reputation though, they start coming to me. I’m learning as much about social engineering as I am about programming.
It seems pointless to me to try make demands for equal or preferential treatment in an environment that is essentially anarchy. If you are trying to work on a project that has a jerk in leadership, find something better, or start your own project. You can’t learn and grow in a socially hostile environment.
In some ways this is a restatement of the OP, but one thing that has always bothered me about the meritocratic assumption in Open Source projects is the following line of reasoning:
Premise: Open Source development has incredibly low barriers to entry[1]
Premise: Open Source development is a meritocracy
Conclusion: Open Source already has the best possible pool of contributors, because anyone who doesn’t contribute already can’t have been deterred by the non-existent barriers to entry, so they must not have sufficient merit.
Some of the comments thread (see Skud in reply to spz) has already touched on the fallacy of the first premise and in fact as per Skud’s post the failure of the two premises is in fact related: the false assumption of a meritocracy is in fact one of the barriers to entry.
I think the largely unstated assumption that all of the smart people who have anything to contribute to Open Source are already contributing, or at least will spontaneously involve themselves from a young age, is pervasive and harmful and very closely connected to this post. I’m reminded also of the point from If you thought Physics was misogynistic, try open source software!:
Which is not to say that I believe even the extreme tail of ‘intelligence’ (yeah, problematic construct already) has signed itself up for Open Source development, but the meritocratic myth interacts with this “only extreme talent need apply” myth too.
[1] For coding the barriers to entry are usually cited as “just” a computer to which you have access for extended periods of time, on which you have the ability to install compilers, interpreters and/or libraries, plus access to reference materials of some kind. Even without reference to privilege I could add a bunch of others, but it’s not the point of this comment.
…or have already attempted to contribute and been run off by arses.
Hey Skud,
I didn’t say it was unreasonable. But I think the proposal is unlikely to succeed: it seems that coders contribute to open source projects for the fun of programming or because they want to have a specific app. And they do it in their spare time. What you’re proposing involves things that aren’t fun – which are usually the first things to fall off the table when time constraints kick in.
Oh, well, I guess we should all just give up then. Thanks for letting us know!
That’s not what I’m suggesting at all.
As S.P.Zeidler noted, piling more work onto project admins doesn’t sound very attractive to an already busy admin. I listed some ideas on technical supports to make it easier for OS projects to get moving, and to make it easier for other contributors to get involved without the say-so of people already on the project. I bet there are plenty of other ones that don’t make admins’ lives more stressful.
Um, it’s going to take some work to fix the diversity problems FOSS has. Is this really that surprising? There’s no Fred Brooks-ish Silver Bullet in diversity any more than there is in software engineering in general.
Aren’t fun for some people. Are everything to others.
It doesn’t just have to be something you naturally prefer to coding though. Helping others can be very rewarding in itself, even without the longer-term payoffs. If you don’t find it that way then maybe you are doing it wrong.
Thanks,
James