Project outline

Final report

Press coverage

related research




Open Source Software as a Meritocracy
Anca Metiu, INSEAD, Paris, France

In order to better understand how open source organizes the efforts of distributed developers, I propose we compare its work processes and organization with those of closed-source projects, particularly with those that are also distributed and modular. Modularity has been held as key to understanding the ability of open source projects to hold down complexity in the absence of management and international travel budgets. Their development has been described as a complex adaptation of modules written by interacting agents (Baldwin and Clark, 2000; Axelrod and Cohen, 2000). In many ways, modularity and being distributed are of the essence in open source projects.

They are also important in closed source software development (Cusumano, 1991). Companies have adopted the principle of modularity aggressively and consistently, and are nevertheless facing tenacious problems in coordinating efforts among dispersed developers. Part of the problem lies with the fact that modularity implies more than a splitting of the work across individuals and groups to achieve speed and efficiency. Distributed software development largely relies on a mental division of labor that is hierarchical: intelligent work is specialized to the design group, code writing is given to a less skilled group, and debugging and maintenance to an even less skilled (and lowly paid) group. In reality, this practice superimposes a hierarchy of labor tasks over a political hierarchy of the world whereby Silicon Valley does the innovative work and places like India does the coding and maintenance part (Kogut and Metiu, 2001).

Consequently, closed-source models of software development that attempt to exploit distributed intelligence confront numerous difficulties. Based on a 7-month ethnography of a team of software developers who were working on a digital property rights suite between the US and India, I concluded that the geographical distance was far less problematic than the social distance separating the two groups. Geographical distance creates opacity (lack of knowledge about developments, about worker identity) about the remote site. However, the most recalcitrant problems stemmed from the huge status differential between the two sites, whereby the high-status site did not want to share work with the low-status group. In closed-source there is reluctance to spread development to locations that have highly skilled and low-cost workers: older centers of software development are jealously keeping code ownership over innovative work for themselves (Metiu, 2001). The combined effect of opacity and status differentials amounted to an absence of problem resolution within the team, and led to the lower-status group’s disengagement from the work.

Open source dissolves this hierarchy by creating a community of developers organized as a meritocracy in which decisions (technical and non-technical) are made by experts. We can posit open source as an ideal type of organization, one based on the principles of merit-based membership (Metiu, 2002). This premise has two important and inter-related consequences. At the level of inter-group cooperation, it solves many of the recurring and tenacious problems arisen in distant coordination. At the level of the division of labor among various regions, it opens up the possibility of doing innovative work in locations known for routine tasks. I’ll discuss briefly each of these consequences.

Because entry in the meritocracy is gained upon one’s quality of contribution, open source solves the opacity that plagues closed source projects. The regime of visibility instituted at all levels – infrastructure, process, product advances, problem resolution – functions as an effective coordination mechanism. Hence the progress made, the glitches identified and solved or still standing, the identity of the developers (in terms of their competence and dedication) are known. Importantly, code ownership is not a matter of contention as it is clearly recognized to contributors who self-select into the tasks they want to perform.

Also, because technical ability is the main criterion for belongingness in the community, the social distance that is so problematic in closed-source becomes irrelevant. Hence the in-group/out-group phenomena of categorization and stereotyping are avoided, as well as the negative effects of categorization whereby individuals are perceived as group members and judged by group traits. For example, one particular mechanism that allows for ethnic markers that are irrelevant for work purposes to recede in the background is the ease of hiding one’s ethnic identity in an email address (Dempsey et al., 1999).

Apart from the implications of the meritocracy for project organization, there are important implications for developing countries that have been so far only marginally participating in the creation of innovative products. First, developers from around the world have a chance to contribute to open source projects (see Dempsey et al., 1999). A second important development is the attempt by several countries to adopt open source instead of Microsoft products. In this realm, we need to better understand how open source software can penetrate in various countries when it relies on knowledgeable users.

My intervention is also a call for studies that would detect and examine the social psychological processes by which people relate to these communities, the modalities of belonging, and of positioning towards other members. Lakhani and von Hippel (2000) have started to offer an answer to the question as to why people contribute their non-trivial effort and time. We need to understand more about the motivations of developers: as anyone who has attended an open source conference can testify, they can be very varied. Ethnographic studies are ideally positioned to capture the basic processes in the communities of developers: how the software is made, the identity of the developers involved, and what this activity means to developers themselves. A larger question is: how much is the feasibility and sheer existence of open source software based on task dimensions (modularity in particular) and how much is behaviourally-based (no status differentials, coordination by means of visibility)?

The means of maintaining, governing, and growing the meritocracy are also key. The elaborate ways of accepting new members (for example, Apache’s ‘step-by-step’ approach), as well as the governance mechanisms that prevent forking deserve close examination. Finally, the cornerstone of the open source ideology – that the code is a commons that needs to be protected from enclosure – is an often overlooked glue that holds most of these communities together. Is this essential element of open source under threat nowadays by the cooperation with large companies?


Axelrod, R. and M. Cohen. Harnessing Complexity: Organizational Implications of a Scientific Frontier. New York: Free Press, 2000.

Baldwin, Carliss, and Kim Clark. Design Rules. Vol. 1: The Power of Modularity. Cambridge, MA: MIT Press, 2000.

Cusumano, Michael A. Japan’s Software Factories. New York: Oxford University Press, 1991.

Dempsey, B. J., D. Weiss, P. Jones, and J Greenberg (1999). A Quantitative Profile of a Community of Open Source Linux Developers. Report, UNC Open Source Research Team, School of Information and Library Science, University of North Carolina at Chapel Hill.

Kogut, B. and A. Metiu (2001). “Open-source software development and distributed innovation,” Oxford Review of Economic Policy, 17)2): 248-264.

Lakhani, K. and E. von Hippel (2000). “How Open Source Software Works: ‘Free’ user-to-user assistance,” Working paper #4117, MIT Sloan School of Management, Cambridge, MA.

Metiu, A. “Faraway, So Close: Code Ownership over Innovative in the Global Software Industry.” Unpublished dissertation, The Wharton School, 2001.

Metiu, A. (2002). “Open Source Software Development as a Meritocracy,” Working paper, INSEAD.