«Richard N. Langlois The University of Connecticut U63 Storrs, CT 06269-1063 USA (860) 486-3472 (phone) Richard.Langlois Giampaolo ...»
Of Hackers and Hairdressers:
Modularity and the Organizational Economics
of Open-source Collaboration
Richard N. Langlois
The University of Connecticut
U63 Storrs, CT 06269-1063 USA
(860) 486-3472 (phone)
Università degli Studi di Roma, “La Sapienza”
Dipartimento di Teoria Economica
e Metodi Quantitativi per le Scelte Politiche
Piazzale Aldo Moro, 5
00185, Rome, Italy
firstname.lastname@example.org Draft: April 15, 2005 Special thanks to Roberto Galoppini and Martin Michlmayr.
We tend to think of decentralized intellectual collaboration as a phenomenon of open-source software, the Internet, and the New Economy.1 But consider the plight of a certain Monsieur Prony, as recounted by Charles Babbage (1835, §243). Gaspard Riche de Prony (1755-1839) was a French civil engineer whom the Revolutionary government of 1790 had charged with an unenviable assignment: construct the largest and most accurate set of trigonometric and logarithmic tables ever produced. One day while pondering this seemingly impossible task, Prony wandered into a bookseller’s shop and absent-mindedly thumbed through a copy of Adam Smith’s Wealth of Nations. Suddenly it struck him. He could enlist the division of labor to construct the tables – in effect, he could manufacture logarithms like pins. Driven by this insight, Prony set up a collaborative project along the following lines. He would begin by enlisting four or five of the most eminent mathematicians in France to devise formulas well suited for numerical calculation. The results would then pass to a small team of run-of-the-mill mathematicians who would turn the formulas into simple algorithms. The actual calculations would be performed by a large team of 60 to 80, most of whom knew no math beyond simple addition and subtraction.
Indeed, in the event the calculators came largely from the ranks of unemployed hairdressers, a group who had lost their once elaborately coiffed clients to the In the context of software, our use of the term “open-source” follows von Hippel and von 1 Krogh (2003). We adopt an even more expansive meaning below.
-1- same Revolutionary taste for austerity and reason that had inspired Prony’s commission. “By 1794, 700 results were being produced each day” (Grattan- Guinness 1990, p. 180).
Obviously, this example differs from present-day open-source software projects in a number of respects. For one thing, Prony’s calculators were not volunteers, and were presumably paid either as employees or on a per- calculation basis.2Moreover, the entire process was “fordist” (to use an anachronistic term) rather than collegial: the design was top down, with no communication among the calculators or feedback from them to the mathematicians above. And the calculators were not creative programmers but deskilled automatons whom Babbage had every hope of replacing with his planned difference engine.3 Nonetheless, like present-day open-source efforts, the Prony Project was an attempt to share-out a complex creative task. Both are examples of what Babbage called the “mental division of labor.” This paper seeks to understand the phenomenon of open-source collaboration by placing it within this larger context of the intellectual division of labor. Our primary focus here will not be on the problem of incentives to Unfortunately, no information seems to have survived about the actual organization of the 2 work (Grattan-Guinness 1990, p. 179).
There is at least one recent analogue to the Prony Project: NASA’s Clickworkers study, 3 which enlisted volunteers to engage in well-specified and relatively menial astrometric tasks. See: http://clickworkers.arc.nasa.gov/top. Of course, Babbage’s dream of handing off the most menial calculations to computers has long since come true, and today Google will help you donate free time on your Internet-connected computer to solving a small piece of a large scientific problem. See: http://toolbar.google.com/dc/offerdc.html.
indirectly. Much of the existing literature, especially that created by economists (Lerner and Tirole 2002), has seen incentives as central: why would so many people contribute time and effort without pecuniary compensation or the promise of returns from intellectual property?4 The answer seems to be that sources of motivation are abundant and adequate. We concentrate instead on
collaboration coordinate the mental division of labor? In Prony’s case, the answer was top-down design and control. But the hallmark of many present-day opensource efforts is bottom-up coordination. The Prony Project was a fordist cathedral; but the paradigmatic open-source software project of today is a spontaneous bazaar (Raymond 2001). Under which circumstances, and in what quantities, is central design necessary? When can genuinely decentralized design lead to a well-ordered and effective structure?
In effect, this paper seeks to ask for open-source collaborations the question Coase (1937) originally asked about firms: why do they exist? Although “open-source” has its original technical meanings in software design and law, we will appropriate the term here to refer to the general phenomenon of a spontaneously coordinated mental division of labor. Examples include the phenomenon of “collective invention” (Osteloh and Rota 2004) within industrial One exception is Benkler (2002), to which we return.
the business of journal editing and refereeing familiar to academics (Bergstrom 2001); online open bibliographic databases, such as Research Papers in Economics (RePEc) (Krichel and Zimmermann 2005); cases of “open-source” collaboration for literary and hobbyist ends rather than for software production (like the online encyclopedia Wikipedia and the photography site photo.net);
and even the modern practice of “open science” (David 1998).
We redirect the Coasean question toward open-source collaboration by adding an additional dimension to Coase’s spectrum between market and firm.
In Coase and the Post-Coasean literature, markets are about the exchange of products or outputs; such exchange is coordinated spontaneously, in the sense that relative prices rather than fiat direct resources. A firm stands in contrast to both of these aspects of markets: it replaces contracts for products with employment contracts, effectively substituting a factor market for a product market (Cheung 1983); at the same time, it replaces spontaneous coordination with some kind of central design or direction. Notice that this leaves two unexamined alternatives: product markets governed by central direction and factor markets coordinated spontaneously. Inside contracting and outsourcing are examples of the former. Open-source collaboration is an example of the latter. That is, open-source collaboration is an organizational form that permits the exchange of effort rather than the exchange of products, and it does so under a regime in
accepting assignment like employees in a firm.
Like Coase and the present-day economics of organization, we attempt to answer the “why” question by isolating the economic circumstances that favor one form of organization over another. As we have already hinted, however, we do not think that the lens of incentives, which focuses most of the present-day economics of organization, is the appropriate glass through which to see the phenomenon of open-source collaboration. We turn instead to what we may loosely call the modularity theory of the firm (Langlois 2002; Baldwin and Clark 2003), since, as we will argue, open-source collaboration ultimately relies on the institutions of modularity. Here the issue hinges on a tradeoff between the benefits (and costs) of modularity and the benefits (and costs) of its opposite, integrality. This tradeoff determines the extent to which central coordination is preferable to spontaneous or decentralized coordination. In this respect we are attempting to make more precise an idea that is already implicit in many discussions of the open-source phenomenon. In addition, however, we suggest that the nature and intensity of demand – especially the extent to which demand is quality or time sensitive – can shift the margin between modularity and integrality. Moreover, we argue, the existence of this tradeoff between modularity and integrality can constitute an incentive and “focal point” for technological or organizational change (Rosenberg 1976) – change that sometimes, and perhaps typically, shifts the margin in favor of modularity.
360 series of computers, Frederick Brooks (1975) paints a depressing portrait of the intellectual division of labor. Like Prony, Brooks parceled out the tasks of mental labor to a large number of workers. Unlike Prony, however, Brooks found himself faced with a daunting problem of coordination. An operating system is an immensely complicated tangle of interconnections, and every piece potentially depends on every other piece. Brooks took this to mean that every programmer ought to know what every other programmer is doing.5 Unfortunately, however, since the number of connections in a network rises exponentially with the number of nodes, so must the costs of coordination rise exponentially as more workers are added to a project.6 The implication, he reasoned, is that coordination costs quickly vitiate any benefits from the intellectual division of labor.
At about the same time, however, David Parnas (1972) and other researchers were looking at software systems in a different light. Solving the problem of interdependency, they argued, is not a matter of maximizing communication among the parts but rather of minimizing communication. In this approach, which laid the foundations for object-oriented programming, one As open-source guru Eric Raymond observes, Brooks’s dire conclusion rested on the implicit 5 “assumption that the communication structure of [a] project is necessarily a complete graph” (Raymond 2001, p. 35).
communicate richly with one another but are actually forbidden from communicating with one another. The basic idea is that “system details that are likely to change independently should be the secrets of separate modules; the only assumptions that should appear in the interfaces between modules are those that are considered unlikely to change” (Parnas et al. 1985, p. 260). This is the notion of information hiding or encapsulation.
Software design reveals the logic of modularity with particular clarity.
But the basic ideas were long ago articulated by Herbert Simon (1962) in a more general context. Simon contrasted systems that are non-decomposable with systems that are (or are nearly) decomposable. Brooks’s conception of the 360 operating system created a non-decomposable system: every part communicates with virtually every other part.8 By contrast, a decomposable system is one in which all (or most) communication takes place within the subsystems and little or none among the subsystems. As Simon put it more recently, a decomposable system “can be thought of as a boxes-within-boxes hierarchy with an arbitrary number of levels. Its special characteristic is that equilibrating interactions Brooks (1975) actually suggested that costs should rise as the square of the number of 6 workers, an idea now sometimes called Brooks’s Law.
To put it in a different technical language, Brooks’s dire conclusion rested on the implicit 7 “assumption that the communication structure of [a] project is necessarily a complete graph” (Raymond 2001, p. 35).
As Baldwin and Clark (2003) rightly insist, the notion of “communication” should involve 8 more than information, and can include the transmission of energy and materials as well as symbols.
The term modular system takes on many meanings in the literature; but one important candidate definition, which we adopt here, is that a modular system is a nearly decomposable system that preserves the possibility of cooperation by adopting a common interface. The common interface enables, but also governs and disciplines, the communication among subsystems.9 In terms of Figure 1, an interface would be a set of elements that communicates with most or all the other elements. In Matrix 3, element a1 is the common interface: a1 communicates with all the aij and all the aij communicate with a1.10 In other respects, however, Matrix 3 remains sparse off the diagonal.
Let us refer to a common interface as lean if it enables communication among the subsystems without creating a non-decomposable system, that is, if it enables communication without filling up the off-diagonal. As we will see, an interface may become standardized; it may also be “open” as against “closed.” But it is the leanness of the interface, not its standardization or openness, that makes a system modular. Baldwin and Clark (2000) suggest thinking about modularity in terms of a partitioning of information into visible design rules and hidden design parameters. The visible design rules (or visible information) consist This depiction of an interface is only meant to be suggestive. For one thing, cooperation 9 may not require that communication be completely bidirectional in all cases, that is, it may not require that row 1 and column 1 be fully populated. Moreover, many different kinds of interface configurations are possible. On this point see Ulrich (1995).
Think of a1 as M. Prony’s assistant, who must have had to scurry among the calculators, 10 each one working in isolation, to gather up the results and arrange them for typesetting.
system and what their functions will be. (2) Interfaces describe in detail how the modules will interact, including how they fit together and communicate. And (3) standards test a module’s conformity to design rules and measure the module’s performance relative to other modules. Notice that “standards” in this sense doesn’t necessarily imply that the architecture or interfaces are standard in the sense of being publicly shared or common to many similar artifacts or systems.