Unintended Consequences

Under traditional economic analysis, this model lacks incentives for creators and capitalists, yet under certain conditions it motivates a swarm of self-directed volunteers to cooperate, create and assemble working computer code. Weber attempts to identify and analyze those conditions using the principles of political economy with frequent reference to writings of Eric Raymond. See, e.g. Eric S. Raymond, “The Cathedral and the Bazaar,” (O’Reilly, 2001) and the original essay of the same name at http://www.firstmonday.org/issues/issue3_3/raymond/ .

Weber focuses on three component questions posed by open source models:

He also addresses four broader subjects illuminated by the open source models:

Early History of Open Source

A joint project at MIT, Bell Labs and GE to develop an improved time-sharing OS led to frustration and Bell’s withdrawal. A Bell researcher, Ken Thompson, working alone over a period of four weeks, built the central core of Unix and its philosophy:

AT&T feared that it would breach the 1956 antitrust consent decree if it sold Unix, so licensed it free, “as is,” and included the source code. It first went to research centers and was used as a research and learning tool. Lacking AT&T support, a community of early users made and freely shared their own bug fixes, enhancements and extensions, with Berkeley taking a leading role. In 1983, at the urging of DARPA (which feared ‘lock-in’ from dependency on a proprietary system), Berkeley’s Bill Joy integrated TCP/IP into Berkeley Unix, fostering its role as a foundation of the Internet.

In the 1970’s, Microsoft pressed for broader recognition of proprietary rights in software about the same time as AT&T was broken up on antitrust grounds. Free of the 1956 consent decree that limited its role in commercial software sales, AT&T jacked up license fees for the popular Unix system. Berkeley organized a network that developed an alternative that was free of code owned by AT&T and distributed it under liberal terms. Tensions grew between those supporting the proprietary versions of Unix and those behind the “free” version, eventually leading to years of disruptive litigation as AT&T fought to protect its interests.

A philosophical backlash was led by Richard Stallman, founder of the Free Software Foundation and developer of GNU (“Gnu’s Not Unix”) as an alternative to Unix. Stallman saw software as an expression of human creativity, not just a tool to run computers, and saw traditional property rights as constraints on a cooperative community. The FSF supported the elements of four freedoms essential to Stallman’s vision, including the freedom to charge a fee for the distribution of the free software. Stallman’s views and the meaning of “copyleft” are explained and supported at the GNU/FSF website, www.gnu.org.

He developed the General Public License (“GPL”) to protect what he called “copyleft,” an inversion of copyright concepts to ensure that free software and its derivatives remain free. A “viral” provision in the GPL bars use of GPL code in another program unless the combination is also GPL-licensed. These self-imposed philosophical restrictions limited the potential applications of Gnu and other GPL-licensed products as alternatives to the proprietary systems defended by AT&T.

What Is Open Source and How Does It Work?

Frederick P. Brooks, a scholar of the software development process, separated two kinds of problems in software engineering: essence (what is inherent in the structure) and accident (what happens in the process). Weber writes that in "The Mythical Man-Month" (Addison-Wesley Professional, 1995), Brooks takes the position that the complex nature of software is an essential property rather than an accidental property. Resolving this complexity calls for the creative work of an individual or a small, close-knit group of individuals. Adding programmers, according to “Brooks’ Law,” multiplies the vulnerability to bugs faster than it multiplies the work done, as the number of pathways between workers and operations (and the necessary coordination effort) increases geometrically. As software systems and their desired uses become more complex, Brooks Law presents escalating challenges for proprietary and open source software alike.

The ideal form of open source process, according to Weber, relies upon voluntary participation and voluntary selection of tasks. The process relies upon suggestions, requests and contributions of solutions from ordinary users as well as developers, but remains ordered and methodical, with vigorous debate over alternatives. Despite sometimes heated differences, the resulting system is stable, even though an essential freedom of all users is to take the source code and a sub-set of followers in another direction (“fork the code base”).

Weber writes of open source labor as being distributed, but not divided in the industrial sense of that term. As an example, statistical studies of Linux indicate hundreds of central members do most of the coding, with thousands of others making some contribution. All are volunteers, with no formal distinction between the role of user or consumer and that of producer or developer.

Weber suggests eight principles to capture the essence of the open source process:

The Internet has facilitated collaboration among open source participants. The formal licensing schemes, such as the GPL, explicitly shift property rights away from protection of the author to protection of users, expanding the commons. These schemes manifest the social structure underlying the process. The social structure of the open source community influences the structure of the code it writes, resulting in modular code adaptable to voluntary parallel processing. Different coding projects resolve conflict differently, but none have a central authority to enforce rules and all are free to “fork,” or leave the system with the code.

A Maturing Model of Production

Disagreements over paths for development of proprietary Unix extensions led to competing forks with higher costs, incompatibilities and fragmented development efforts. Linus Torvalds created Linux as an alternative to Unix, which many developers believed to be “dying.”

Torvalds elected to create a large, “monolithic” kernel, despite recent trends toward less complex “microkernels.” Weber attributes Torvald’s decision to a belief that the open source process would allow management of a monolithic kernel’s complexity. Asked to allow distributors to charge fees for distribution, Torvalds adopted the GPL as the standard license for Linux, with its “viral” clause that required derivative code to be similarly licensed. Both decisions were responses to open debate over the best path for the process. As the Linux code writers publicly battled over the best technical solutions, AT&T and BSD battled over ownership of the Unix code, mostly in private without involvement of the code writers.

As an alternative to the basic command prompt, Linux users wanted a GUI. Orest Zborowski ported X, a public domain GUI application to Linux. Torvald encouraged the initiative by reworking the Linux kernel to better work with X. The “lieutenant” organization of Linux development evolved as Torvalds chose between the products of rival code projects and thereafter routed new code submissions to the “winning” leader.

Linux evolved further as it was ported to architectures other than Intel’s x86 line, was distributed as part of packages with business goals and as its release numbering matured to distinguish between “stable” and “experimental” releases.

As Linux 2.0 was released and Torvalds took a position with Transmeta in 1996, participants in the process began to articulate a self-consciousness, of which Eric Raymond’s “The Cathedral and the Bazaar” (1997, 2001) was an example. With that self-awareness came the realization that the label “free software” and the rigid moral stance of Richard Stallman’s Free Software Foundation were limiting and problematic. The label “open source” and its accompanying Open Source Definition clarified its agnostic goal of meeting the needs of users rather than serving any particular moral ideal.

As Linux and its community grew, the load on Torvalds increased. By summer of 1998, the system was stretched to its limit and heated disputes broke out in the open discussion boards, threatening a fork. To the community, Eric Raymond styled the problem in technical terms and proposed a new code management system. The principals agreed to a pyramidal structure to better manage work flow and the crisis passed, the dispute resolved through open public debate in archived Linux email lists. See “Linus tries to make himself scale,” Linux World, February 11, 2002, http://www.linuxworld.com/story/32722.htm

Linux demonstrated its value to commercial enterprise platforms in 2000 as developers ported high-end database systems to work on it. Netscape attempted to counter Microsoft’s free browser tactic by contributing its browser code as open source, but Mozilla never caught on with the community due to problems with the code and the licensing scheme. IBM was more successful in opening its hardware to Linux and announcing a corporate bet on open source as a core IBM strategy.

Microsoft’s Vinod Valloppillil analyzed the threat of open source to commercial business models in an August 1998 “Halloween Memo” that was later leaked. It presented for Microsoft’s management the challenge of competing with the open source process. “The intrinsic parallelism and free idea exchange in OSS has benefits that are not replicable with our current licensing model and therefore present a long term developer mindshare threat,” wrote Vallopillil, and “the ability of the OSS process to collect and harness the collective IQ of thousands of individuals across the Internet is simply amazing. More importantly, OSS evangelization scales with the size of the Internet much faster than our own evangelization efforts appear to scale.” The memo addressed the serious challenges for a hierarchical organization that must competitively target a process rather than a company.

Explaining Open Source: Microfoundations

Weber opens an examination of why and how individuals contribute to open source projects by dispelling “myths” that open source is the product of like minded individuals acting out of altruism, and that it can be explained by merely labeling it “self-organized.” He finds a variety of individual motivations that do not rely upon the traditional monetary rewards. For the economic logic, he suggests that software is not just “nonrival,” but actually “anti-rival” and subject to positive network externalities, whereby the value of a system increases with the number of users, even benefiting from free riders, as long as some fraction of the users make a contribution. The highly diverse population of the Internet, combined with low connectivity costs, increases the impact of the small percentage of “outlier” users who actually contribute to code solutions.

Weber recognizes the views of Mancur Olsen that the larger the group size, the lower the benefit to any marginal contributor, and the less the likelihood that a social good will be produced. See Mancur Olsen, “The Logic of Collective Action; Public Goods and the Theory of Groups,” (Harvard Univ. Press, 1971). As an alternative Weber proposes that: “Under conditions of antirivalness, as the size of the Internet-connected group increases, and there is a heterogenous distribution of motivations with people who have a high level of interest and some resources to invest, then the large group is more likely, all things being equal, to provide the good than is a small group.” Weber, p. 155.

Explaining Open Source: Macro-Organization

The coordination of an open source effort can be explained by several mechanisms, suggests Weber. Individual disincentives to fork are inherent in a system that has positive network externalities, because segmenting the user population reduces the value of the forked product. A variety of cultural norms common to open source participants govern control of distribution and successful decision-making. Leadership practices reflect the system’s dependency upon participants by emphasizing responsiveness to that group’s followers, the reliance on rational explanation and the focus on technical justification. Weber recognizes the potential for such an emergent system to get stuck in a local maximum (as do ecological systems), and that the systems are testing the balance between the power to fork (that supports creativity) and the disincentives to fork (that support stability).

Open source efforts manage the complexity of software development in part by modular design of the code, which reduces organizational demands on the social and political structures. Sanctions upon violators of community norms take the form of public expressions of disapproval (“flaming”), and denial of cooperation and access to the community’s support (“shunning”). The variety of open source licenses seen in the environment also demonstrate the norms and standards of the particular process and reflect the common realization that participants expect to be on both sides (licensor and licensee) of the bargain at different times. Early examples of formal governance structures reflect the need to accommodate asynchronous, “bursty” communication and the lack of a hierarchy for division of labor (although a hierarchy for decision making may exist).

Business Models and the Law

An open source process not only releases control of source code but also assures that no one can control the source code, complicating the search for business models that accommodate the increased customer control. Weber suggests approaching the problem by focusing on protectible rights other than the source code (e.g. brands and trademarks), and on accumulation of valuable knowledge necessary to implement the source code. He describes several early experiments with such business models attempted in the initial years of open source.

Open source licenses rely upon copyright law to enforce requirements for control of source code, but few “copyleft” controversies have been resolved by the courts. Weber poses the question whether or not the Digital Millennium Copyright Act’s bar on anti-circumvention tools could be used to prevent creation of systems that provide the functionality of proprietary systems using open source code. Open source uses non-negotiated, “click-wrap” licenses with untested provisions that purport to disclaim warranties and that bind downstream users much like a restrictive land covenant.

Recent decisions allowing patenting of algorithms and business methods have intensified an ongoing controversy over patentability of software. See State Street Bank & Trust v. Signature Financial Group, 149 F.3d 1368 (Fed.Cir. 1998). Weber asks what might be the impact of a threat of patent litigation against users of open source software when there is no license warranty binding a “deep pocket” to defend against such challenges?

The Code That Changed the World?

Open source is a process with elements that can work in fields other than software development, suggests Weber. Traditional notions of intellectual property focus on rewarding creativity by limiting distribution, making the producer more powerful than consumers. Open source systems protect distribution, shifting power to the consumer. Yet under proper conditions, creativity is sufficiently rewarded in an open source environment that it continues. The open source process shifts innovation to the edges of the network, taking away the role of central authority that architects and make labor assignments and in its place leaves a system of distributed innovation.

Weber suggests four organizational principles that enable distributed innovation:

Weber also cautions that without a central authority, distributed innovation systems can get stuck in a sub-optimal equilibrium, falling into the trap explained by Clayton Christensen in "The Innovator’s Dilemma," (Harvard Business School Press 1977). Distributed innovation may also be unequally responsive to all segments of a diverse international community. It is unclear what effects open source processes will have on standards setting. Open source may also accelerate the rate of performance improvement for projects such as cluster and grid computing.

Open source processes transcend national boundaries and may shift decision-making toward people in the developing world, and enables users in the developing world to drive technology development to serve their needs, suggests Weber. Open source may serve nationalist desires to avoid lock-in and dependency on a particular vendor or on products of a particular nation’s industry. The changes in power relationships and property rights may have more impact than the lowering of transaction costs, and may “destabilize the foundations of existing cooperative arrangements and institutions … .” Weber p. 257.

Yet to be explored are the political and economic phenomena resulting when open source communities interact with traditional hierarchies. Weber suggests some examples in the interaction between Microsoft and the open source software movement and between the United States and terror networks as described by John Arquilla and David Ronfeldt.

Weber closes by suggesting avenues for possible generalization of the open source process beyond software development, such as to develop engineering techniques common to players in an industry, sharing of knowledge in the medical field, and in the study of genomics. Weber suggests characteristics of tasks that may be suited to open source solutions:

He also suggests the most suitable motives and capabilities of the involved agents:

Weber’s “The Success of Open Source” (Harvard, 2004) includes numerous footnotes and a bibliography. It provides a thoughtful perspective on an emergent phenomenon of creative development that tests the frontiers of intellectual property law and policy.

DougSimpson.com/blog