“This is not a democracy, it’s a meritocracy.”
The statement comes from the Ubuntu Governance page, but you can find similar statements in the Fedora Release Notes, the Why Debian For Developers page, and just about anywhere else were free and open source software (FOSS) projects discuss their core values.
Clearly, meritocracy is one of the myths that the FOSS community tells itself. By “myth,” I do not mean that the claim is a lie, but that meritocracy is part of the story that community members tell themselves to establish and maintain a common identity.
In other words, the idea that FOSS is a meritocracy is equivalent to the idea that America is the land of opportunity, or that scientists are objective. For members of the FOSS community, the idea that hard work is rewarded with recognition and the opportunity for more responsibility is central to their belief system and their sense of who they are.
For people to continue to believe such myths, they must have enough truth in them that no one calls them into question, and exceptions to the myth can be explained, or even denied.
Yet if a community’s myths are not a lie, they are not necessarily the whole truth, either. Often, they are over-simplifications of a much more complex situation.
That, I believe, is the situation with FOSS and meritocracy today. If you have the right background, and contribute in the right area in the right way, FOSS actually can act as a meritocracy, and frequently does.
However, the idea that the community runs on merit alone does not completely describe the vastly more complex situation in which merit is only part of the reason for recognition and responsibility. Instead, many other considerations come into play, often unrecognized.
Questionable assumptions
One of the problems with any claim of meritocracy is that it can become a circular argument justifying how power is already distributed. How do you know that the people in power deserve their position? Because they are in a meritocracy, and they are in power. If their actions had not merited their positions, they would not hold those positions.
Yet you do not have to search too far to see that merit is not the only reason for holding power in the FOSS community. In particular, project founders tend to hold influence regardless of the value of their recent contributions — or whether they continue to contribute.
For instance, when Ian Murdock founded Progeny Linux Systems (a company I used to work for) in 2000, he had not been active in the Debian Project for several years. Yet when the company started to become active in Debian affairs, his status remained undiminished within the project. Despite the increasingly evidence that he would not actively involved in the project personally, he was even offered the chance to skip the usual process for becoming a Debian Maintainer, although he turned it down.
More recently, Mark Shuttleworth became benevolent dictator-for-life of Ubuntu and Canonical — not because of his contributions to free software, but because he had the energy and money to create the position for himself. Few people in Ubuntu or Canonical begrudge him his position, but the fact remains that it was not obtained through merit (as the community defines it) so much as the exercise of existing power.
Nor are leaders the only ones who gain influence through means other than pure merit. In projects in which some contributors are paid and some are volunteers, paid contributors almost always have more influence than any volunteers. In some cases, like OpenOffice.org, the paid contributors can almost shut out the volunteers entirely.
In others, like the Fedora project, power is more equably distributed, but the paid contributors often step into positions of responsibility. For instance, seven out of ten of the current Fedora board members are Red Hat employees. In much the same way, three of the five members of the openSUSE board are employees of Novell, the project’s main sponsor, and another is a consultant specializing in Novell products. The situation is much the same in most projects.
Of course, you could argue that paid staff has more time to devote to responsibilities. Yet, while true, that is irrelevant. The point is that paid staff tend to hold responsible positions in projects more often than volunteers. What matters is that the assumption that a level playing field exists in which effort alone determines status within a project does not hold up to even the most casual scrutiny.
Other means to merit
Meritocracy sounds idealistic in the abstract. But the trouble is, it is very rarely abstract. Merit has to be defined before it is recognized, and the FOSS community is no exception.
Founded around code, the FOSS community continues to place the most value on writing code, even though many large projects now involve testing, documentation writing, translation, art, and technical support as well. Although efforts to change this orientation exist in many projects, such as Fedora and Drupal, the bias remains — in most projects, you are still more likely to learn the names of developers or hear them speak at conferences than anyone else.
To a certain extent, this bias is justified. After all, without the code, FOSS projects wouldn’t exist. Yet the success of the project as a whole can be determined as much by other contributions as by the code itself.
Moreover, as Kirrily Robert, blogging as Skud, points out, even if some contributions are considered more important than others, that does not mean that they should be ignored altogether.
For instance, the best person to write documentation might be a project head, but having them add documentation to their duties is not the best use of their time. Instead, having a less knowledgeable person write documentation is probably a better use of everyone’s time. In such a case, the documentation writer deserves credit both for providing documentation and for freeing the project head for other concerns. Yet such contributions frequently go unacknowledged in many FOSS projects.
Similarly, the idea that merit is noticed and rewarded is a comforting idea in modern industrial culture. I suspect, though, that it is especially comforting in FOSS circles, where many identify themselves as introverts, if not self-diagnosed cases of Asperger syndrome.
Yet is merit is always recognized in FOSS? Talking about some of the barriers to women’s participation in FOSS, Noirin Shirley writes:
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.
What Shirley is suggesting is that, the ability to make yourself visible on discussion lists and chat channels and at conferences, is at least as important as the quality and frequency of your contributions. Since women tend to be culturally conditioned not to push themselves forward, many are at a disadvantage in a FOSS project (and so, too, by extension, are diffident men). If they cannot learn at least a degree of self-promotion, then their ideas may be unheard, under-valued, or dismissed.
Conversely, by the same logic, some people in FOSS projects may become prominent less because of what they do than because they are outgoing or aggressive (I can think of some examples, but giving them would amount to a personal attack).
Just as demagogues may subvert democracy, so self-promotion may subvert meritocracy. If a project is not careful, it could easily find itself accepting contributions based less on quality than on contributors’ visibility or ability to push themselves forward.
Social gravity and how to escape it
In The Meritocracy Myth, Stephen J. McNamee and Robert K. Miller, Jr. suggest that meritocracy in the United States is influenced by what they call “social gravity” — factors such as class and education that can help or prevent people being recognized for their contributions.
I suggest that social gravity is also at work in the FOSS community — not just because it is a product of modern industrial society, but because of factors unique to the community. Acknowledging this social gravity may not be pleasant, but doing so does not suggest that FOSS meritocracy is unworkable or applied hypocritically. Nor does it denigrate the work of FOSS’s contributors.
Instead, recognizing that social gravity exists can be the first step towards making FOSS’s meritocracy work better.
One suggestion that might help comes from Kirrily Robert. Noting that female musicians are more likely to be hired in blind auditions, when the gender of applicants is unknown, Robert suggests that blind submissions might remove the biases in the judging of contributions. She is talking specifically about increasing the contributions of women, but blind submissions might also assure that only merit was applied to all contributions.
Of course, this is only one suggestion. If you want FOSS to be completely meritocratic, then the community needs to ask itself some hard questions.
For instance, what other means might reduce the influence of self-promotion? To ensure that paid workers do not start from a more privileged position than volunteers? Can merit be redefined so that it no longer refers simply to code, but to the overall success of the project?
Addressing issues like these will not dilute the principle of merit. Instead, answering them can strengthen the main principle of FOSS, making sure that it is more evenly applied. And that, surely, is something that any supporter of FOSS should want to see.