Questioning the merit of meritocracy.
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.
Page 2 of 2 | Previous page
Robbie Mackay:
November 29th, 2009 at 4:33 pm
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..
Melissa:
November 29th, 2009 at 5:13 pm
THIS.
Mary:
November 29th, 2009 at 7:03 pm
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.
Dorothea:
November 29th, 2009 at 7:45 pm
Could this be transplanted to the wiki? It sure does come up a lot IME.
Arjen Lentz:
November 29th, 2009 at 7:46 pm
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.
Leigh Honeywell:
November 30th, 2009 at 12:21 am
I’ll do what I can tomorrow. This is an important essay, methinks.
Erigami:
November 30th, 2009 at 10:34 am
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.
Skud:
November 30th, 2009 at 11:22 am
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.
Evan Prodromou:
November 30th, 2009 at 12:14 pm
@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
jemimah ruhala:
December 1st, 2009 at 8:23 am
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.
Erigami:
December 3rd, 2009 at 2:18 pm
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
spz:
December 5th, 2009 at 3:02 pm
“Well, most of the people who currently run open source projects *have* a great deal of privilege”
I don’t understand. Care to expand?
Skud:
December 6th, 2009 at 1:01 am
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.
spz:
December 6th, 2009 at 6:51 am
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?
Skud:
December 6th, 2009 at 11:30 am
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.
Mary:
December 6th, 2009 at 12:42 pm
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.
S.P.Zeidler:
December 7th, 2009 at 8:20 am
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.
Mackenzie:
December 8th, 2009 at 10:34 pm
…or have already attempted to contribute and been run off by arses.
Erigami:
December 9th, 2009 at 6:46 am
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.
Skud:
December 9th, 2009 at 7:25 am
Oh, well, I guess we should all just give up then. Thanks for letting us know!
James Westby:
December 9th, 2009 at 4:53 pm
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
Erigami:
December 10th, 2009 at 6:25 pm
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.
Thursday (Night) Link Love « The Feminist Texican:
December 10th, 2009 at 6:43 pm
[...] Geek Feminism Blog: Questioning the merit of meritocracy [...]
Leigh Honeywell:
December 11th, 2009 at 1:30 pm
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.