【"Free' vs. "Open Source' Software】
In 1995, three years before its acquisition by AOL, Netscape Communications marked its initial public offering with a plan to distribute its browser, Netscape Communicator (formerly Navigator), at no cost. Netscape would have gone forward with the free distribution of its software application if its financial backers (in the mid-1990s) hadn't stipulated that the product generate revenue. Netscape acquiesced, while at the same time distributing the browser free of charge to students, educators, and researchers. It would be three years before Netscape would give the browser away to everyone, "no strings attached.'[3]
It was also in 1998, following the precedent set by Linus Torvalds when he developed Linux, a Unix-like operating system, with input from unaffiliated programmers from around the world, that Netscape published the source code for Netscape Communicator under an open source license. This meant that anyone with enough programming expertise and enthusiasm could modify and redistribute the source code.
Colloquially known as "hackers,' members of MIT's Tech Model Railroad Club (TMRC) and the MIT Artificial Intelligence Laboratory had championed such rights since the 1960s. Richard Stallman further galvanized the hacker subculture in 1983 by creating the GNU Project—GNU stands for "GNU's Not Unix'—and founding the Free Software Movement (FSM). In announcing the GNU Project, Stallman declared the development of "a sufficient body of free software... to get along without any software that is not free.'[4]While for Stallman "free' also means "free of charge,' his adherents emphasize liberty over cost: as they are wont to say, "free as in speech, not as in beer.' Today, the organization born out of the FSM, the Free Software Foundation (FSF), defines free software on the basis of the following tenets, as published in the GNU manifesto:[5]
The freedom to run the program, for any purpose (freedom 0).
The freedom to study how the program works, and adapt it to your needs (freedom 1). Access to the source code is a precondition for this.
The freedom to redistribute copies so you can help your neighbor (freedom 2).
The freedom to improve the program, and release your improvements (and modified versions in general) to the public, so that the whole community benefits (freedom 3). Access to the source code is a precondition for this.
The proliferation of manifestos by contemporary technologists—The Hacker's Manifesto (1986) by Lloyd Blankenship and The Cathedral and the Bazaar (1997) by Eric S. Raymond, to name two—echoes a history of credos in political life from the United States Declaration of Independence to the Republican Party's 1994 Contract with America; and in the arts, including Walt Whitman's 1885 preface to Leaves of Grass and Frank O'Hara's Personism: A Manifesto, from the world of poetry, suggesting hackers deploy a self-conscious political and social activism. And certainly the FSF was (and is) activist. What it was not conceived as, though, was a business model. Instead, the FSF articulated a philosophy, one predicated on the ideal that software, morally speaking, should not be proprietary.
By 1992, having formulated and executed the GNU Project under the guiding principles of the FSF, Stallman combined his community-developed operating system components with the Linux kernel—code that manages communications between software and hardware in an operating system—to create an operating system comprised of entirely free software. Though this accomplishment was not the first of its kind, it aids our deion of a seemingly natural transition from free software as primarily a manifesto to open source software, based on a similarly altruistic ideology, with real product and commercial potential. (Anticipating the software industry as we know it today, it's worth noting that in the early 1990s the availability of the Linux kernel gave rise to several Linux distributions when developers of Unix-like operating systems built on top of the Linux kernal. Early examples of Linux distributions include MCC Interim Linux and TAMU. Founded in mid-1992, Softlanding Linux System[SLS] was the first Linux distribution to include more than the kernel and basic utilities.[6]Announced in November 1992, Yggdrasil Linux/GNU/X purportedly was the first Linux distribution widely available to the public.[7]Linux distributions that are well known today include Fedora, Debian, Gentoo Linux, and Red Hat.)
In early 1997, in anticipation of Netscape's release of its source code, Bruce Perens and Eric S. Raymond founded the Open Source Initiative (OSI), an organization committed to the advocacy of software with freely available source code. The OSI definition of open software shares core values with the FSF definition of free software; namely, the software user enjoys the right to use, modify, and redistribute source code under the terms of one of a number of sanctioned licensing agreements.[8]Those agreements all grant users these core freedoms and license many of the rights that copyright owners legally possess. Famously, the General Public License (GPL) "infects' any modification to code licensed under it with the same open source requirements. Nevertheless, the founding of the OSI inaugurated a public debate about the ethical contrasts between "free' and "open' in software development.
Whereas the FSF maintained that open-source software development as an organizational strategy for increasing market share threatened to blur the distinctions between free and proprietary software, the OSI held that "it was time to dump the moralizing and confrontational attitude that had been associated with ‘free software' in the past and sell the idea strictly on the same pragmatic, business-case grounds that had motivated Netscape.'[9]When on March 31, 1998, Netscape released the source code for the Communicator suite, it did so to compete with Microsoft's Internet Explorer browser. Netscape's intention was to make up in advertising what it lost from the sale of software licenses.
【Some Pros and Cons of Open Source】
The benefits of open source software typically cited focus on business rationales. They include the argument that open source is often (but not always) less expensive than proprietary software. Another advantage of open source software is that it can be more customized by the end-user. As such, open source is arguably more educational than proprietary software, in that the user is invited to learn or practice coding or both. He does so for his own benefit and, when customizations are profound and implemented into new versions of widely distributed software, for the benefit of the community at large. (As we will soon discuss at length, Mozilla is somewhat atypical in that it uses the open source practice not only as a way of deepening its pool of talented programmers, but also as a mechanism for increasing public participation in the maintenance of the Internet as "a global public resource that must remain open and accessible.'[10]Ideological in nature, this tenet is fundamental to our understanding of the Mozilla business model as relevant to participatory governance at large.)
Because open source software can be copied and shared without a fee and without violating intellectual property laws, users can operate software essential to their jobs at home, and teachers can send their students home with the software in use in the classroom. Because the licensee in open source development is free to modify and redistribute software, license management is simplified. Licensors dedicate fewer resources to the problem of piracy. As a safeguard against commercial exploitation of the source code, the GPL obliges those who modify the code to share their improvements with the community. The specifics of open source licensing will be explored in a later section of this report.
Open source software also creates networks between an organization's in-house developers and unaffiliated developers. Apache, a program that hosts nearly half of the Web sites on the Internet, facilitates a network comprising itself, Web designers, and Web site proprietors. A company like Apple can build its latest operating system on the source code of BSD, an open source operating system, as a way of keeping pace with community-based innovations in this product category. If a software company goes out of business, the community still has the source code and can interface with other vendors and developers. Even if a vendor remains solvent, the community may avoid being locked into doing business with that vendor.
There are counterfactuals to these assertions. Open source is not always cheaper. The opportunity costs of open source software can be significant if a program does not include a tool the user needs. Furthermore, proprietary software such as Microsoft Office has been improved over the course of many years and may offer more features than do customizable counterparts.
Many users are simply more familiar with proprietary software. Microsoft Word is a clear example of this, as many users learned word processing with this program. Furthermore, since its first release in 1983, Microsoft Word has been written for the most popular platforms in personal computing, including the IBM PC, Apple's Macintosh, and Microsoft Windows.
What is undeniable and of central interest here is the way that an open source project like Mozilla—and specifically one of Mozilla's scope and longevity—fosters civic engagement and participation. For Mozilla, participation is the goal. Open source is a tool to engender that participation.
【Recursive Publics】
Netscape's premise in publishing its source code and making it available for enhancement (under the terms of an open source license) by qualified individuals was that such an arrangement would solicit the expertise of an effectively unlimited pool of programmers in the development of future releases of the Netscape browser.[11]Individuals would qualify themselves to revise the source code on the basis of their enthusiasm, their ability to identify an aspect of the code base that needed improvement, their ability to execute that improvement, and their willingness to submit their work to a vetting process that can be described as distributed peer review. On one hand, Netscape's use of crowdsourcing gave it the ability to recruit individual talent, and on the other hand to create an online—and thus geographically unlimited—network of programmers. Volunteers who were professionally or by avocation skilled software developers were invited not only to contribute their expertise, but also to publicly or anonymously affiliate themselves with what Christopher M. Kelty terms a "recursive public':
A recursive public is a public that is vitally concerned with the material and practical maintenance and modification of the technical, legal, practical, and conceptual means of its own existence as a public; it is a collective independent of other forms of constituted power and is capable of speaking to existing forms of power through the production of actually existing alternatives. Free Software is one instance of this concept.... Recursive publics, and publics generally, differ from interest groups, corporations, unions, professions, churches, and other forms of organization because of their focus on the radical technological modifiability of their own terms of existence.[12]
In seeking to identify its public by offering a sense of itself as a community, Netscape was engendering a movement dedicated to the common cause of software use and development. The delineation of this public required source code visibility, a quality comparable in political theory to transparency, and a shared sense of mission. Participants needed to believe that they were more than free labor and to trust that their contributions were not pro forma, but would be taken seriously. Netscape needed to avoid creating a project that only seemed to invite collaboration. Again, Kelty:
In any public there inevitably arises a moment when the question of how things are said, who controls the means of communication, or whether each and everyone is being properly heard becomes an issue. A legitimate public sphere is one that gives outsiders a way in: they may or may not be heard, but they do not have to appeal to any authority (inside or outside the organization) in order to have a voice. Such publics are not inherently modifiable, but are made so—and maintained—through the practices of participants.[13]
How Mozilla governs volunteer participation toward the end of creating a "legitimate public sphere... that gives outsiders a way in' will be explored in some detail in upcoming sections. But first we start by explaining the initial online structure—the tools and the governance—that makes participation possible in the first place.
As of March 31, 1998, developers from around the world could download and modify the nearly eight megabytes of Communicator 5.0 code from mozilla.org, the Web site for the Mozilla Organization. Founded largely by Netscape employees who were working independently of Netscape, the Mozilla Organization was created as an open source enterprise to coordinate testing of the first Mozilla browser. (Then synonymous with the Web site, mozilla.org, the Mozilla Organization became the Mozilla Foundation in 2003 under the same URL. In accordance with the nomenclature currently published at mozilla.org, we may refer collectively to the ongoing open source projects facilitated at the Web site as the Mozilla Project. Established with financial assistance from Netscape's parent company, AOL, the Mozilla Foundation is the independent, nonprofit organization that oversees the open source Mozilla Project. Since the Mozilla Project's inception as the Mozilla Organization in 1998, the Web browser known today as Firefox has gone through several incarnations—iterations, generations, releases—each of them developed as open source projects.)
To this day, the Mozilla Project hosts the process for facilitating input from volunteer programmers in the maintenance and improvement of the Firefox browser at mozilla.org. Based on a system of distributed decision making, this Web site manages the interactions between developers and Mozilla principals. It also houses the Mozilla Concurrent Versions System (CVS) source repository. Known more generically as a Version Control System, CVS is a free software control system released under the GNU GPL that, by keeping track of all work underway in the development of the code base, enables remote, asynchronous collaboration among developers. As with a lending library, developers "check out' files and ultimately publish their revisions—"check-ins'—in the repository. The CVS source repository is a public resource.[14]Other Version Control Systems that are applied to collaboration in nonprogramming enterprises at Mozilla are also treated as public resources.
While the Internet enables geographically distributed communities to cohere around a common cause or interest, structure is necessary for people working across a distance to become a community. Mozilla.org facilitates such a community. As one of many tools available to the general public at Mozilla.org, the Mozilla Version Control Systems provide the necessary technological architecture to support the community in its distributed work. Having a well-designed system by which individuals can contribute to the shared work of the group is essential to forging a recursive public. Without the ability to manage volunteer contributions quickly and cheaply, the sponsor organization can ill afford to support public participation. Experts and enthusiasts can ill afford to join a community without the mechanism to take effective action together. In addition to the tools, the organization has to be committed to the notion of crowdsourced participation. Without that, it will not publicize its needs, invite engagement, and ultimately communicate the ways in which those outside its boundaries can help. Mozilla's beginnings are rooted in both the culture and practices of open and collaborative work.
【The Scope of Participation】
Most software users are not programmers and do not seek software the way hobbyists from earlier generations purchased Heathkits to build their own shortwave radios. Software users want their browser to work. They want bug-free software that offers them the tools they need to maximize their personal-computing capabilities. If the number of people willing to volunteer their time and expertise to open-source software development is miniscule compared to the total number of people who use the software, the population willing to work together as a part of a group is even more limited, calling into question the scope of a community required to develop code and the tradeoffs implicit in this style of participation.
In a 2008 interview at Stanford University, the chairman of the Mozilla Foundation, Mitchell Baker, talked about participation rates in any given project:
The number of people who participate may be small. The important thing is that when there is an issue you care about—and there may be only one or two issues that matter to you. The important thing is that you have the opportunity to participate. You have the option to be more than a consumer. You can create something when you need it. Most of the time, most of us won't want to participate. Not everyone is involved all the time. But the option to get involved is fundamental. What's important to us is that we have enough people getting involved when something is wrong.[15]
Despite the unquestionable success of Mozilla at crowdsourcing experts from around the world, in a public dedicated to any one project under the Mozilla banner, recursive means rarified. As with Wikipedia, where a far smaller number than the actual visitor count writes the encyclopedia entries, Mozilla attracts a small number of volunteer developers relative to the overall number of people using its software. Ohloh.com, a Web site designed as a directory of open source projects, lists 152 developers who have contributed nearly 7,000 "commits' to the Firefox browser under the GNU General Public License 2.0, GNU Lesser General Public License 2.1, and Mozilla Public License 1.1.[16]This is not quite an accurate headcount, however, as this figure accounts only for "front-end' coders—programmers who design the user interface. Ohloh.com identifies an additional 824 programmers who work on the "back end'—software that performs the final stage of a process and may not be apparent to the user. A short list of additional Firefox-related projects—Mozilla Chrome, SpiderMonkey, Fennec, and Firebug—accounts for a couple of hundred more programmers. Taking into consideration that many programmers work on more than one project, we estimate that one thousand individual programmers help to develop and maintain the Firefox browser, now used by an estimated 270 million people.[17]These numbers may not be historically accurate, but they probably reflect the general ratio of programmers to end-users.
When in the late 1990s Netscape published the Communicator source code, one of the more compelling critiques of open source centered on the administrative challenge of incorporating what could become too much input (from too many participants) in decision-making processes that traditionally turn on the decisions of an individual or a relatively small group of managers. In his book The Success of Open Source, Steven Weber recalls the idiom of "having too many cooks in the kitchen':[18]
The dilemmas are familiar. Monitoring and evaluating the performance of a complex task like writing code is expensive and imperfect. Proxy measures of achievement are hard to come by. Quality is as important (often more important) than quantity, and simple measures are likely to be as misleading as informative (someone who produces a large number of lines of code may be demonstrating poor implementation skills, not productivity). Shirking within teams and free riding on the efforts of others is hard to isolate. One person's good efforts can be rendered ineffective by another person's failure to produce.
With this passage, Weber is introducing a well-known principle-cum-proverb from the literature of software engineering known as Brook's Law: "Adding manpower to a late software project makes it later.'[19]In other words, the overall productivity of a team is diminished while added experts come up to speed on a project. Fred Brooks, a manager of IBM's OS/360 project, called this the "ramp up' time. He argued that the number of bugs created increases exponentially with the number of people added to a team.
Weber and other writers like Eric S. Raymond point out that Brook's Law is not applicable to open-source software development because participants self-select to work on a specific project.[20]As Weber further explains, the concept of self-selection invites individuals to nominate themselves for participation in a project of their own choosing:
The key element of the open source process, as an ideal type, is voluntary participation and voluntary selection of tasks. Anyone can join an open source project, and anyone can leave at any time. That is not just a free market in labor. What makes it different from the theoretical option of exit from a corporate organization is this: Each person is free to choose what he wishes to work on or to contribute. There is no consciously organized or enforced division of labor. In fact the underlying notion of a division of labor doesn't fit the open source process at all. Labor is distributed, certainly—it could hardly be otherwise in projects that involve large numbers of contributors. But it is not really divided in the industrial sense of the term.[21]
Thus, the volunteer open-source code developer completes her selected task on her own time, prior to review, without the guarantee that her contribution will be implemented. She works on spec. The only guarantee granted the volunteer is that her proposed contribution, submitted via a clear and public protocol, will be taken seriously. It is also significant that Weber is describing the open source process as "an ideal type.'
Because the utility of the volunteer developer's code modification—known colloquially as a patch—determines the applicability of her patch to the project at hand, the proliferation of bugs that Brooks associates with the increase in personnel is checked. As we will see in the case of Mozilla, volunteers submit their patches to a system of distributed peer review. Self-selection is the starting point of that process. As such, the peer review of patches from volunteer developers serves to initiate individuals new to the Mozilla community on the basis of their technical knowledge.
Self-selection engenders another aspect of quality control in open-source software development, one based not on the expertise of the individual developer, but on the collective ability of developers to scrutinize code, as summarized in Raymond's articulation of Linus's Law: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone.' Raymond also states the same idea less formally: "Given enough eyeballs, all bugs are shallow.'[22]
Of course, all programmers are not looking at the same piece of code. An open source process works best if the overall project or objective of the organization is modular; each module can benefit from specialization on the part of the individuals who comprise the recursive public.
A key characteristic of the Firefox browser is that source code is often modular. Modularity promotes specialization and the concept of comparative advantage between individuals in a recursive public. Modularity arguably is part of the open source definition because the organization of source files into chunks within a software program isolates tasks on the basis of functionality. A volunteer developer dedicates himself to the specific fix he deems necessary within the parameters set by the module. He chooses a topic he is most qualified to work on. Because modularity dedicates the programmer to a single component of the code base, it is the basis for specifying, soliciting, and organizing contributions from volunteers.
Finally, it is noteworthy that the ideal open source process that includes such concepts and practices as self-selection, peer review, and modularity may or may not identify an open source operation's management style as top-down or by degrees more bottom-up. As we will describe in subsequent sections, the Mozilla model relies on leadership to steer the process. Asa Dotzler, Director of Community Development at the Mozilla Corporation, a taxable subsidiary of the Mozilla Foundation, explains that programmers are encouraged to submit patches for possible implementation, "but management often decides what it wants. Management may recruit programmers from the community to work on specific, underrepresented projects.'[23]As such—and as we will explore in greater detail—Mozilla is an example of an open source project that is mediated by managers—a mix of Mozilla employees and prominent volunteers.
In sum, self-selection is the first step in a system of peer review. Self-selection also makes possible the formation of a large group of individuals qualified to work on a specific problem. Regardless of any one developer's standing in the community, a group of self-selected individuals is better suited to track down bugs more efficiently than an individual or a static team of individuals employed by a company dedicated to the development of proprietary software. It is also important to recall Mitchell Baker's observation that not everyone is involved all the time. Participants choose the levels of their involvement. Furthermore, they may vary their involvement as they become familiar with the community. In addition to periodically writing code, a volunteer may also report bugs and propose "check-ins' to the code repository that he is not capable of addressing with a patch. As such, meaningful distinctions between users and developers begin to diminish, especially when, later in this report, we consider the contributions of users who are not programmers, but who nonetheless contribute to quality assurance and the promotion of the software.
These are several "take-away' lessons of Mozilla's crowdsourcing technique that can be applied more generally to other forms of shared work:
The ratio of active participants to the total population of a community may be small.
Individuals must know they have the option to participate.
Not everyone needs to be involved all the time.
Participants choose their tasks.
Participants may discover new roles as they acclimate to the community.
Leadership may steer participation toward select projects.
【Why Software Developers Participate in Open Source】
To question why software developers participate in open source foreshadows our inquiry into what would inspire private citizens with technical and nontechnical expertise to contribute to the work of government agencies. In a study conducted by Paul A. David and Joseph S. Shapiro, 1,459 software developers were asked what motivated them to volunteer their time and expertise to open source projects.[24]In the spirit of the ideology of the earliest proponents of the Free Software Movement, nearly 80 percent responded that users "should be free to modify software[they] use.' To couple this motivation with the next most often-cited reason for participation, the desire to "give back to community,' is to combine a sense of individual rights with the importance of exercising those rights to enhance the prosperity of that community. Pairings of other motivations create similar dichotomies: open-source software development is the "best way for software to be developed,' and also a good "way for[the developer] to become a better programmer.' Other motivations for participation (in decreasing order of importance) include to:[25]
Provide alternatives to proprietary software.
Interact with like-minded programmers.
Modify existing software as needed.
Fix bugs in existing software.
Learn how a particular program works.
Fulfill an employer's stipulation for the programmer to collaborate in open source projects.
David and Shapiro also compare developers' motivations for choosing their first open source projects with those for participating in subsequent projects. Here, the predominant rationale centered on individual enrichment: the software being developed was technically interesting and would be useful to that particular developer. Still, the importance and visibility of the project itself was a major factor in developers' decisions to join open source projects.
The Mozilla Project confirms these findings. Among software developers and (as we will see) less technically inclined individuals, there is a desire to participate, if given the opportunity. Where participation is mutually beneficial to the organization, the volunteer, and the volunteer's community, there is a greater likelihood of engagement.
【The Mozilla Manifesto】
In light of the advantages and disadvantages of open source, community-based coding involves a set of practices, both ideological and commercial, that has quickly become a permanent aspect of the software industry. With the example of the Firefox browser, the input of a proportionately small, self-selected group of programmers must address the needs of a user base outside the technically savvy core of users if the Mozilla Foundation is to build market share while simultaneously educating the general public about its core mission. This mission, which we quote at length here, was published as "The Mozilla Manifesto' in 2007, and illustrates the intersection of individual rights with the antiproprietary activism of open source in the maintenance of the Internet as a social sphere, where the Internet itself is a public resource:
1. The Internet is an integral part of modern life—a key component in education, communication, collaboration, business, entertainment, and society as a whole.
2. The Internet is a global public resource that must remain open and accessible.
3. The Internet should enrich the lives of individual human beings.
4. Individuals' security on the Internet is fundamental and cannot be treated as optional.
5. Individuals must have the ability to shape their own experiences on the Internet.
6. The effectiveness of the Internet as a public resource depends upon interoperability (protocols, data formats, content), innovation, and decentralized participation worldwide.
7. Free and open source software promotes the development of the Internet as a public resource.
8. Transparent community-based processes promote participation, accountability, and trust.
9. Commercial involvement in the development of the Internet brings many benefits; a balance between commercial goals and public benefit is critical.
10. Magnifying the public-benefit aspects of the Internet is an important goal, worthy of time, attention, and commitment.[26]
