Coraline Ada Ehmke

Meritocracy in Theory and Practice

Coraline Ada Ehmke | September 19, 2018

Meritocracy is one of the four pillars of open source (along with the free exchange of ideas, success through collaboration, and shared ownership). But in our current day and age it’s become a subject of increasing debate.

I would like to share some thoughts on the meritocracy, its origin, its value as a governing system, and its relationship to the utilitarian philosophy, and how all these factors shape the field we know and love.

The Origins of Meritocracy

The term “meritocracy” was coined by British sociologist Michael Young in his 1958 satirical essay “The Rise of the Meritocracy.” In this essay, an unnamed narrator in the distant future describes the contemporary society of the United Kingdom. The narrator observes that the greatest contributor to society is not the majority but rather a creative minority, members of what he describes as a “restless intellectual elite”. In terms of open source, this group looks like “people with technical skills combined with the free time (or paid time, if they work for certain corporations) to devote to creating open source code”. I don’t think that anyone would argue that this criteria alone leaves a lot of technically talented people in a position where they cannot devote their time to pursuing open source.

The Restless Elite

And in practice, this restless intellectual elite is largely comprised of white males. Because of the traditional organization of Western society, white men have considerably more free time than white women do, and both groups have more free time than people of color. So immediately gender, racial, and class issues limit the level of participation that different kinds of people can bring to open source.

And with the intellectual elite making decisions about the types of problems that they identify need to be solved, it’s logical that they are going to focus on solving the kinds of problems that apply to themselves-- often at the expense of the needs of marginalized people.

The Myth of Free Participation

Women make up about 30% of all software developers, but only an estimated 2-5% of women participate in open source. And of those women who do participate, they generally participate less than their male counterparts and have fewer open source repositories. Only people like James Damore would postulate that there is some innate biological cause for this disparity; the most likely causes are social, political, and economical.

But even among those with the privilege of free time or jobs that allow them to contribute to open source, there’s still not a level playing field. Open source was, in part, a reaction against corporate giants defining the parameters for successful software. It was a rebellion against the hierarchical structure of software development, centralization of power, and the conservative approach to risk-taking inherent in systems that concentrate power in the hands of the few.

But these self-same structures have come to be the de facto standard for major open source projects. These projects tend to be governed either by a single charismatic individual (the benevolent dictator model) or a small cadre of individuals (the corporate mirror model), and decision-making and risk-taking is once again concentrated in the hands of the few. An argument could be made for these people rising to positions of power through merit, but how is that really different from the rise to positions of power of people in traditional software companies?

Gatekeeping

So we have a ruling class in open source, and this ruling class enjoys a concentration of decision-making power. One of the most important uses of this power is determining who else in an open source community is allowed to participate. The ruling class are gatekeepers: they are the arbiters of the ill-defined concept of merit, they set the tone for participation in the community, and they establish and normalize standards of behavior that are acceptable in a given community. In doing so, they are managing the most important barrier to free and full participation: access.

Intelligence as Merit

In technological meritocracies, intelligence is held up as the predominant ideal. It is commonly said that your race, gender, ethnicity, gender, sex, and sexual orientation are irrelevant, only your code contributions matter. But meritocracy is a system of power, and like all systems of power, that power is not evenly distributed. A queer Black woman is at a distinct disadvantage in a system governed by straight white men. Whether that is the result of blatant homophobia and racism or the more subtle implicit bias is beside the point; in either case, she is not as free to participate as her white, straight-passing male counterparts.

What’s more, elevating intelligence above all other traits is a form of erasure. Intelligence is notoriously hard to measure-- ask any psychometrician. Intelligence in fact does not have a formal definition that people in the field of measuring intelligence can even agree on. So even calculating how intelligent someone is comes down to a subjective value judgement. As a result, the whole process of the assignment of merit becomes an exercise in self-recognition: “I believe you are intelligent or capable or a talented coder because you believe the same things that I believe, and you meet the standards that I hold myself to.” What could be more subjective than that?

But What About the White Male Coders?

What’s more, boiling down the many facets of what makes someone an individual to a single, unmeasurable trait is dehumanizing. If a marginalized person can’t draw on their own experiences and value systems, they can’t contribute fully as their whole selves. Consider an open source project that aims to improve facial recognition software. If we consider merit alone, in the form of “good code” that advances the system, there is no room for a Black technologist to bring their experience of the weaponization of facial recognition software-- the abuses of which are well-documented and a mere google search away-- to bear on the project. That’s even assuming that there is a Black developer on the team, which is statistically unlikely to begin with. That developer’s observation has nothing to do with their ability to write good code, and will in fact cause them to write less code, or withdraw from the project altogether. By the meritocratic principle of being judged on the code that you create, this developer would not be awarded any merit at all. In fact, they would become irrelevant.

Asking people to ignore who they are in the service of producing code is asking them to not bring all of their tools and experience to bear on solving a problem. This is like asking someone to code without using the letter ‘x’ more frequently than ‘y’, because the people at the top of the meritocracy power structure believe that “all consonants matter”.

The Utilitarian Connection

Meritocracy draws on many of the principles of the utilitarian philosophy. Utilitarianism defines its own moral system and provides tools for measuring the morality of a given action in terms of its impact on the larger society. Actions which benefit the majority of people are deemed to be moral actions. The trick here is that this moral calculus benefits the majority at the expense of the minority. By this calculus the slavery of a minority (Black people) is a perfectly moral practice, as long as it is contributes to the overall benefit of the majority (white people).

Jeremy Bentham, one of the key philosophers who developed utilitarianism, even wrote “If pains must come, let them extend to the few”. And in the case of open source, this “few” is the population of developers from marginalized or underrepresented populations.

The Utility Monster

One of the most prominent critics of utilitarianism as an ethical system is the philosopher Robert Nozick. In 1974 he wrote about something called The Utility Monster as a way of demonstrating the shortcomings of a meritocratic, utilitarian form of governance. This thought experiment shows that utilitarianism is not egalitarian, even if it might appear so at first glance. To keep things approachable, I will adapt and simplify his ideas to the realm of open source.

Imagine an open source community in which the average developer consumes one resource-- access to the project, or the attention of a maintainer, or an hour of free time to devote to the project. From this resource the developer produces one unit of “value”.

Distribution of resources would be egalitarian, because as the community grows the stockpile of resources also grows (e.g. the total amount of time available to work on the code, the number of code reviewers available, etc.), and would result in greater and greater value for the project.

But consider a developer who fills the role that Nozick calls “The Utility Monster”. This developer is hungry for resources, and in fact is able to produce two units of “value” for every resource consumed. They do not contribute extra to the stockpile of resources, since they are not materially affecting the total amount of time available to work on the code, but they are thought of as more productive-- they’re making more with less.

In an open source community without a Utility Monster, it is beneficial to the overall system for resources to be distributed evenly. Everyone has about the same amount of time to code, gets the same amount of time and attention from project maintainers, and has the same level of access to the other resources available through the project.

In the hedonistic calculus of the utilitarian philosophy, a community of ten equally talented developers, each consuming one resource (the attention of project maintainers, with a total of ten such resources for the entire community) produce one unit of value each, for a total of 10 across the system.

A community with a Utility Monster changes this dynamic. For every resource consumed, the Utility Monster produces two units of value. With an equal distribution of resources this raises the value of the total system to 11.

The Utility Monster gets identified by project maintainers as a high performer, earning merit. So the maintainers decide that the Utility Monster now gets 3 resources, which means that 7 developers get 1 resource each, and 2 developers get 0 resources, effectively being removed from the community. The total value produced by the system is now 13. The increase in value produced by the system comes at the cost of two developers being excluded from participating.

Taken to the extreme, if the Utility Monster is given access to 100% of the available resources, the total value delivered by the system rises to 20 and excludes 9 developers. (And since a Utility Monster benefits materially by reducing competition for resources, he is actually rewarded for pushing people out of the community, and normalizes exclusion and antisocial behavior.)

What is lost in this scenario? For one, the opportunity for a group of developers to participate in the project. No one can argue that the attention of project maintainers, who must respond to bug reports and perform code reviews, is not finite. Attention is a fixed resource. Defining merit as a material contribution to the overall value of a system not only encourages leaving a large population of potential contributors out, but rewards projects that do so.

To restate that point: projects that actively exclude developers from broad participation by linking output and merit are, on the surface, producing more merit. But the quality of that code is not as good as it would be otherwise.

In reality the quality of software goes up when more people are participating in its creation. This is the whole premise of open source: more hands make better software. And especially if you draw on a rich and diverse population: a quick google search will lead to you study after study that prove that diverse teams outperform homogenous teams by a significant margin. Not to mention the studies by Esch et al that quantify the effect of groupthink on cognitive performance and problem solving.

So who are the utility monsters in open source? They are the ones who demand more attention from project maintainers. They are the ones who have a stake in reducing competition for this attention by keeping certain people out of the community. They are the aggressive developers, the developers with a stake in maintaining a status quo that grants them more privileges. They are the restless elite whose happiness, according to the utilitarian moral calculus, matters more than fairness or the happiness of the minority. In our current culture, they are the cisgender, straight-passing white men.

Final Thoughts

If open source is truly based on a genuine and sincere meritocracy, where people rise to positions of influence and power based solely on their intellectual contributions, the only rational explanation for the dominance of cisgender straight-passing white men in our field is that these people somehow have constitutional or biological advantages that make them better coders than transgender and nonbinary people, white women, women of color, and men of color.

Is that what you really believe?

Or do you believe that everyone should have the opportunity to change the world through software, not just the white male majority?

Do you believe that everyone deserves the chance to change their lives for the better by participating in our field and enjoying the salary and privilege that comes with that, or just the white male majority?

Do you admit the possibility that there are social and societal factors at play here that are pressuring certain privileged people to embrace the status quo, because it benefits them the most?

If these questions leave you feeling a pang of discomfort or guilt, ask yourself: what good reason is there for opposing the adoption of tools and techniques and policies that seek to level out the playing field and make room for a more diverse population in our field? Things like deliberate and effective outreach, inclusive recruiting and hiring practices, STEM programs designed for women and people of color, and adopting codes of conduct? The very causes that lead to disparaging remarks about “social justice warriors” destroying open source?

Our mission is not destruction. It’s inclusion. By bringing more people to the table, the conversation gets richer. The value of our software goes up. The changes we enable to our society get better. The world becomes a more fair and equitable place.

Why would you want to stand in the way of that kind of progress?

Further Reading

There are a number of resources for understanding the shortcomings of meritocracy. Here are some suggested sources for further reading:

And, if you're convinced, you can sign the Post-Meritocracy Manifesto.