Part II free software

3. The Movement

Part II of Two Bits describes what Free Software is and where it came from, with each of its five chapters detailing the historical narrative of a particular kind of practice: creating a movement, sharing source code, conceptualizing openness or open systems, writing copyright (and copyleft) licenses, and coordinating collaborations. Taken together, the stories describe Free Software. The stories have their endpoint (or starting point, genealogically speaking) in the years 1998-99, when Free Software burst onto the scene: on the cover of Forbes magazine, as part of the dotcom boom, and in the boardrooms of venture-capital firms and corporations like IBM and Netscape. While the chapters that make up part II can be read discretely to understand the practices that are the sine qua non of Free Software, they can also be read continuously, as a meandering story of the history of software and networks stretching from the late 1950s to the present.

Rather than define what makes Free Software free or Open Source open, Two Bits treats the five practices as parts of a collective technical experimental system: each component has its own history, development, and temporality, but they come together as a package and emerge as a recognizable thing around 1998-99. As with any experimental system, changing the components changes the operation and outcomes of the whole. Free Software so conceived is a kind of experimental system: its practices can be adopted, adapted, and modulated in new contexts and new places, but it is one whose rules are collectively determined and frequently modified. It is possible to see in each of the five practices where choices about how to do Free Software reached, or surpassed, certain limits, but nonetheless remained part of a system whose identity finally firmed up in the period 1998-99 and after.

The first of these practices—the making of Free Software into a movement—is both the most immediately obvious and the most difficult to grasp. By the term movement I refer to the practice, among geeks, of arguing about and discussing the structure and meaning of Free Software: what it consists of, what it is for, and whether or not it is a movement. Some geeks call Free Software a movement, and some don’t; some talk about the ideology and goals of Free Software, and some don’t; some call it Free Software, while others call it Open Source. Amid all this argument, however, Free Software geeks recognize that they are all doing the same thing: the practice of creating a movement is the practice of talking about the meaning and necessity of the other four practices. It was in 1998-99 that geeks came to recognize that they were all doing the same thing and, almost immediately, to argue about why. ⁸⁸

One way to understand the movement is through the story of Netscape and the Mozilla Web browser (now known as Firefox). Not only does this story provide some context for the stories of geeks presented in part I—and I move here from direct participant observation to historical and archival research on a phenomenon that was occurring at roughly the same time—but it also contains all the elements necessary to understand Free Software. It is full of discussion and argument about the practices that make up Free Software: sharing source code, conceiving of openness, writing licenses, and coordinating collaborations.

Forking Free Software, 1997-2000

Free Software forked in 1998 when the term Open Source suddenly appeared (a term previously used only by the CIA to refer to unclassified sources of intelligence). The two terms resulted in two separate kinds of narratives: the first, regarding Free Software, stretched back into the 1980s, promoting software freedom and resistance to proprietary software “hoarding,” as Richard Stallman, the head of the Free Software Foundation, refers to it; the second, regarding Open Source, was associated with the dotcom boom and the evangelism of the libertarian pro-business hacker Eric Raymond, who focused on the economic value and cost savings that Open Source Software represented, including the pragmatic (and polymathic) approach that governed the everyday use of Free Software in some of the largest online start-ups (Amazon, Yahoo!, HotWired, and others all “promoted” Free Software by using it to run their shops).

A critical point in the emergence of Free Software occurred in 1998-99: new names, new narratives, but also new wealth and new stakes. “Open Source” was premised on dotcom promises of cost-cutting and “disintermediation” and various other schemes to make money on it (Cygnus Solutions, an early Free Software company, playfully tagged itself as “Making Free Software More Affordable”). VA Linux, for instance, which sold personal-computer systems pre-installed with Open Source operating systems, had the largest single initial public offering (IPO) of the stock-market bubble, seeing a 700 percent share-price increase in one day. “Free Software” by contrast fanned kindling flames of worry over intellectual-property expansionism and hitched itself to a nascent legal resistance to the 1998 Digital Millennium Copyright Act and Sonny Bono Copyright Term Extension Act. Prior to 1998, Free Software referred either to the Free Software Foundation (and the watchful, micromanaging eye of Stallman) or to one of thousands of different commercial, avocational, or university-research projects, processes, licenses, and ideologies that had a variety of names: sourceware, freeware, shareware, open software, public domain software, and so on. The term Open Source, by contrast, sought to encompass them all in one movement.

The event that precipitated this attempted semantic coup d’état was the release of the source code for Netscape’s Communicator _{[pg 100]} Web browser. It’s tough to overestimate the importance of Netscape to the fortunes of Free Software. Netscape is justly famous for its 1995 IPO and its decision to offer its core product, Netscape Navigator, for free (meaning a compiled, binary version could be downloaded and installed “for zero dollars”). But Netscape is far more famous among geeks for giving away something else, in 1998: the source code to Netscape Communicator (née Navigator). Giving away the Navigator application endeared Netscape to customers and confused investors. Giving away the Communicator source code in 1998 endeared Netscape to geeks and confused investors; it was ignored by customers.

Netscape is important from a number of perspectives. Businesspeople and investors knew Netscape as the pet project of the successful businessman Jim Clarke, who had founded the specialty computer manufacturer, Silicon Graphics Incorporated (SGI). To computer scientists and engineers, especially in the small university town of Champaign-Urbana, Illinois, Netscape was known as the highest bidder for the WWW team at the National Center for Supercomputing Applications (NCSA) at the University of Illinois. That team—Marc Andreessen, Rob McCool, Eric Bina, Jon Mittelhauser, Aleks Totic, and Chris Houck—had created Mosaic, the first and most fondly remembered “graphical browser” for surfing the World Wide Web. Netscape was thus first known as Mosaic Communications Corporation and switched its name only after legal threats from NCSA and a rival firm, Spyglass. Among geeks, Netscape was known as home to a number of Free Software hackers and advocates, most notably Jamie Zawinski, who had rather flamboyantly broken rank with the Free Software Foundation by forking the GNU EMACS code to create what was first known as Lucid Emacs and later as XEmacs. Zawinski would go on to lead the newly free Netscape browser project, now known as Mozilla.

Meanwhile, most regular computer users remember Netscape both as an emblem of the dotcom boom’s venture-fed insanity and as yet another of Microsoft’s victims. Although Netscape exploded onto the scene in 1995, offering a feature-rich browser that was an alternative to the bare-bones Mosaic browser, it soon began to lose ground to Microsoft, which relatively quickly adopted the strategy of giving away its browser, Internet Explorer, as if it were part of the Windows operating system; this was a practice that the U.S. Department of Justice eventually found to be in violation of _{[pg 101]} antitrust laws and for which Microsoft was convicted, but never punished.

The nature of Netscape’s decision to release the source code differs based on which perspective it is seen from. It could appear to be a business plan modeled on the original success: give away your product and make money in the stock market. It could appear to be a strategic, last-gasp effort to outcompete Microsoft. It could also appear, and did appear to many geeks, to be an attempt to regain some of that “hacker-cred” it once had acquired by poaching the NCSA team, or even to be an attempt to “do the right thing” by making one of the world’s most useful tools into Free Software. But why would Netscape reach such a conclusion? By what reasoning would such a decision seem to be correct? The reasons for Netscape’s decision to “free the source” recapitulate the five core practices of Free Software—and provided key momentum for the new movement.

Sharing Source Code Netscape’s decision to share its source code could only seem surprising in the context of the widespread practice of keeping source code secret; secrecy was a practice followed largely in order to prevent competitors from copying a program and competing with it, but also as a means to control the market itself. The World Wide Web that Andreessen’s team at NCSA had cut their teeth on was itself designed to be “platform independent” and accessible by any device on the network. In practice, however, this meant that someone needed to create “browsers” for each different computer or device. Mosaic was initially created for UNIX, using the Motif library of the X11 Window System—in short, a very specific kind of access. Netscape, by contrast, prided itself on “porting” Netscape Navigator to nearly all available computer architectures. Indeed, by 1997, plans were under way to create a version of the browser—written in Java, the programming language created by Sun Microsystems to “write once, run anywhere”—that would be completely platform independent.

The Java-based Navigator (called Javagator, of course) created a problem, however, with respect to the practice of keeping source code secret. Whenever a program in Java was run, it created a set of “bytecodes” that were easy to reverse-engineer because they had to be transmitted from the server to the machine that ran the program and were thus visible to anyone who might know how and where to look. Netscape engineers flirted with the idea of deliberately _{[pg 102]} obfuscating these bytecodes to deter competitors from copying them. How can one compete, the logic goes, if anyone can copy your program and make their own ersatz version?

Zawinski, among others, suggested that this was a bad idea: why not just share the source code and get people to help make it better? As a longtime participant in Free Software, Zawinski understood the potential benefits of receiving help from a huge pool of potential contributors. He urged his peers at Netscape to see the light. However, although he told them stories and showed them successes, he could never make the case that this was an intelligent business plan, only that it was an efficient software-engineering plan. From the perspective of management and investors, such a move seemed tantamount to simply giving away the intellectual property of the company itself.

Frank Hecker, a sales manager, made the link between the developers and management: “It was obvious to [developers] why it was important. It wasn’t really clear from a senior management level why releasing the source code could be of use because nobody ever made the business case.” ⁸⁹ Hecker penned a document called “Netscape Source Code as Netscape Product” and circulated it to various people, including Andreessen and Netscape CEO Jim Barksdale. As the title suggests, the business case was that the source code could also be a product, and in the context of Netscape, whose business model was “give it away and make it up on the stock market,” such a proposal seemed less insane than it otherwise might have: “When Netscape first made Navigator available for unrestricted download over the Internet, many saw this as flying in the face of conventional wisdom for the commercial software business, and questioned how we could possibly make money ‘giving our software away.’ Now of course this strategy is seen in retrospect as a successful innovation that was a key factor in Netscape’s rapid growth, and rare is the software company today that does not emulate our strategy in one way or another. Among other things, this provokes the following question: What if we were to repeat this scenario, only this time with source code?” ⁹⁰

Under the influence of Hecker, Zawinski, and CTO Eric Hahn (who had also written various internal “heresy documents” suggesting similar approaches), Netscape eventually made the decision to share their source code with the outside world, a decision that resulted in a famous January 1998 press release describing the aims _{[pg 103]} and benefits of doing so. The decision, at that particular point in Netscape’s life, and in the midst of the dotcom boom, was certainly momentous, but it did not lead either to a financial windfall or to a suddenly superior product. ⁹¹

Conceptualizing Open Systems Releasing the source code was, in a way, an attempt to regain the trust of the people who had first imagined the www. Tim Berners-Lee, the initial architect of the www, was always adamant that the protocol and all its implementations should be freely available (meaning either “in the public domain” or “released as Free Software”). Indeed, Berners-Lee had done just that with his first bare-bones implementations of the www, proudly declaring them to be in the public domain.

Over the course of the 1990s, the “browser wars” caused both Netscape and Microsoft to stray far from this vision: each had implemented its own extensions and “features” to the browsers and servers, extensions not present in the protocol that Berners-Lee had created or in the subsequent standards created by the World Wide Web Consortium (W3C). Included in the implementations were various kinds of “evil” that could make browsers fail to work on certain operating systems or with certain kinds of servers. The “browser wars” repeated an open-systems battle from the 1980s, one in which the attempt to standardize a network operating system (UNIX) was stymied by competition and secrecy, at the same time that consortiums devoted to “openness” were forming in order to try to prevent the spread of evil. Despite the fact that both Microsoft and Netscape were members of the W3C, the noncompatibility of their browsers clearly represented the manipulation of the standards process in the name of competitive advantage.

Releasing the source code for Communicator was thus widely seen as perhaps the only way to bypass the poisoned well of competitively tangled, nonstandard browser implementations. An Open Source browser could be made to comply with the standards—if not by the immediate members involved with its creation, then by creating a “fork” of the program that was standards compliant—because of the rights of redistribution associated with an Open Source license. Open Source would be the solution to an open-systems problem that had never been solved because it had never confronted the issue of intellectual property directly. Free Software, by contrast, had a well-developed solution in the GNU General Public License, _{[pg 104]} also known as copyleft license, that would allow the software to remain free and revive hope for maintaining open standards.

Writing Licenses Herein lies the rub, however: Netscape was immediately embroiled in controversy among Free Software hackers because it chose to write its own bespoke licenses for distributing the source code. Rather than rely on one of the existing licenses, such as the GNU GPL or the Berkeley Systems Distribution (BSD) or MIT licenses, they created their own: the Netscape Public License (NPL) and the Mozilla Public License. The immediate concerns of Netscape had to do with their existing network of contracts and agreements with other, third-party developers—both those who had in the past contributed parts of the existing source code that Netscape might not have the rights to redistribute as Free Software, and those who were expecting in the future to buy and redistribute a commercial version. Existing Free Software licenses were either too permissive, giving to third parties rights that Netscape itself might not have, or too restrictive, binding Netscape to make source code freely available (the GPL) when it had already signed contracts with buyers of the nonfree code.

It was a complex and specific business situation—a network of existing contracts and licensed code—that created the need for Netscape to write its own license. The NPL thus contained a clause that allowed Netscape special permission to relicense any particular contribution to the source code as a proprietary product in order to appease its third-party contracts; it essentially gave Netscape special rights that no other licensee would have. While this did not necessarily undermine the Free Software licenses—and it was certainly Netscape’s prerogative—it was contrary to the spirit of Free Software: it broke the “recursive public” into two halves. In order to appease Free Software geeks, Netscape wrote one license for existing code (the NPL) and a different license for new contributions: the Mozilla Public License.

Neither Stallman nor any other Free Software hacker was entirely happy with this situation. Stallman pointed out three flaws: “One flaw sends a bad philosophical message, another puts the free software community in a weak position, while the third creates a major practical problem within the free software community. Two of the flaws apply to the Mozilla Public License as well.” He urged people _{[pg 105]} not to use the NPL. Similarly, Bruce Perens suggested, “Many companies have adopted a variation of the MPL [sic] for their own programs. This is unfortunate, because the NPL was designed for the specific business situation that Netscape was in at the time it was written, and is not necessarily appropriate for others to use. It should remain the license of Netscape and Mozilla, and others should use the GPL or the BSD or X licenses.” ⁹²

Arguments about the fine details of licenses may seem scholastic, but the decision had a huge impact on the structure of the new product. As Steven Weber has pointed out, the choice of license tracks the organization of a product and can determine who and what kinds of contributions can be made to a project. ⁹³ It is not an idle choice; every new license is scrutinized with the same intensity or denounced with the same urgency.

Coordinating Collaborations One of the selling points of Free Software, and especially of its marketing as Open Source, is that it leverages the work of thousands or hundreds of thousands of volunteer contributors across the Internet. Such a claim almost inevitably leads to spurious talk of “self-organizing” systems and emergent properties of distributed collaboration. The Netscape press release promised to “harness the creative power of thousands of programmers on the Internet by incorporating their best enhancements,” and it quoted CEO Jim Barksdale as saying, “By giving away the source code for future versions, we can ignite the creative energies of the entire Net community and fuel unprecedented levels of innovation in the browser market.” ⁹⁴ But as anyone who has ever tried to start or run a Free Software project knows, it never works out that way.

Software engineering is a notoriously hard problem. ⁹⁵ The halls of the software industry are lined with the warning corpses of dead software methodologies. Developing software in the dotcom boom was no different, except that the speed of release cycles and the velocity of funding (the “burn rate”) was faster than ever before. Netscape’s in-house development methodologies were designed to meet these pressures, and as many who work in this field will attest, that method is some version of a semistructured, deadline-driven, caffeine- and smart-drink-fueled race to “ship.” ⁹⁶

Releasing the Mozilla code, therefore, required a system of coordination that would differ from the normal practice of in-house _{[pg 106]} software development by paid programmers. It needed to incorporate the contributions of outsiders—developers who didn’t work for Netscape. It also needed to entice people to contribute, since that was the bargain on which the decision to free the source was based, and to allow them to track their contributions, so they could verify that their contributions were included or rejected for legitimate reasons. In short, if any magical Open Source self-organization were to take place, it would require a thoroughly transparent, Internet-based coordination system.

At the outset, this meant practical things: obtaining the domain name mozilla.org; setting up (and in turn releasing the source code for) the version-control system (the Free Software standard cvs), the version-control interface (Bonsai), the “build system” that managed and displayed the various trees and (broken) branches of a complex software project (Tinderbox), and a bug-reporting system for tracking bugs submitted by users and developers (Bugzilla). It required an organizational system within the Mozilla project, in which paid developers would be assigned to check submissions from inside and outside, and maintainers or editors would be designated to look at and verify that these contributions should be used.

In the end, the release of the Mozilla source code was both a success and a failure. Its success was long in coming: by 2004, the Firefox Web browser, based on Mozilla, had started to creep up the charts of most popular browsers, and it has become one of the most visible and widely used Free Software applications. The failure, however, was more immediate: Mozilla failed to reap the massive benefits for Netscape that the 1995 give-away of Netscape Navigator had. Zawinski, in a public letter of resignation in April 1999 (one year after the release), expressed this sense of failure. He attributed Netscape’s decline after 1996 to the fact that it had “stopped innovating” and become too large to be creative, and described the decision to free the Mozilla source code as a return to this innovation: “[The announcement] was a beacon of hope to me. . . . [I]t was so crazy, it just might work. I took my cue and ran with it, registering the domain that night, designing the structure of the organization, writing the first version of the web site, and, along with my co-conspirators, explaining to room after room of Netscape employees and managers how free software worked, and what we had to do to make it work.” ⁹⁷ For Zawinski, the decision was both a chance for Netscape to return to its glory and an opportunity _{[pg 107]} to prove the power of Free Software: “I saw it as a chance for the code to actually prosper. By making it not be a Netscape project, but rather, be a public project to which Netscape was merely a contributor, the fact that Netscape was no longer capable of building products wouldn’t matter: the outsiders would show Netscape how it’s done. By putting control of the web browser into the hands of anyone who cared to step up to the task, we would ensure that those people would keep it going, out of their own self-interest.” ⁹⁸

But this promise didn’t come true—or, at least, it didn’t come true at the speed that Zawinski and others in the software world were used to. Zawinski offered various reasons: the project was primarily made up of Netscape employees and thus still appeared to be a Netscape thing; it was too large a project for outsiders to dive into and make small changes to; the code was too “crufty,” that is, too complicated, overwritten, and unclean. Perhaps most important, though, the source code was not actually working: “We never distributed the source code to a working web browser, more importantly, to the web browser that people were actually using.” ⁹⁹

Netscape failed to entice. As Zawinski put it, “If someone were running a web browser, then stopped, added a simple new command to the source, recompiled, and had that same web browser plus their addition, they would be motivated to do this again, and possibly to tackle even larger projects.” ¹⁰⁰ For Zawinski, the failure to “ship” a working browser was the biggest failure, and he took pains to suggest that this failure was not an indictment of Free Software as such: “Let me assure you that whatever problems the Mozilla project is having are not because open source doesn’t work. Open source does work, but it is most definitely not a panacea. If there’s a cautionary tale here, it is that you can’t take a dying project, sprinkle it with the magic pixie dust of ‘open source,’ and have everything magically work out. Software is hard. The issues aren’t that simple.” ¹⁰¹

Fomenting Movements The period from 1 April 1998, when the Mozilla source code was first released, to 1 April 1999, when Zawinski announced its failure, couldn’t have been a headier, more exciting time for participants in Free Software. Netscape’s decision to release the source code was a tremendous opportunity for geeks involved in Free Software. It came in the midst of the rollicking dotcom bubble. It also came in the midst of the widespread adoption of _{[pg 108]} key Free Software tools: the Linux operating system for servers, the Apache Web server for Web pages, the perl and python scripting languages for building quick Internet applications, and a number of other lower-level tools like Bind (an implementation of the DNS protocol) or sendmail for e-mail.

Perhaps most important, Netscape’s decision came in a period of fevered and intense self-reflection among people who had been involved in Free Software in some way, stretching back to the mid-1980s. Eric Raymond’s article “The Cathedral and The Bazaar,” delivered at the Linux Kongress in 1997 and the O’Reilly Perl Conference the same year, had started a buzz among Free Software hackers. It was cited by Frank Hecker and Eric Hahn at Netscape as one of the sources for their thinking about the decision to free Mozilla; Raymond and Bruce Perens had both been asked to consult with Netscape on Free Software strategy. In April of the same year Tim O’Reilly, a publisher of handbooks for Free Software, organized a conference called the Freeware Summit.

The Freeware Summit’s very name indicated some of the concern about definition and direction. Stallman, despite his obvious centrality, but also because of it, was not invited to the Freeware Summit, and the Free Software Foundation was not held up as the core philosophical guide of this event. Rather, according to the press release distributed after the meeting, “The meeting’s purpose was to facilitate a high-level discussion of the successes and challenges facing the developers. While this type of software has often been called ‘freeware’ or ‘free software’ in the past, the developers agreed that commercial development of the software is part of the picture, and that the terms ‘open source’ or ‘sourceware’ best describe the development method they support.” ¹⁰²

It was at this summit that Raymond’s suggestion of “Open Source” as an alternative name was first publicly debated. ¹⁰³ Shortly thereafter, Raymond and Perens created the Open Source Initiative and penned “The Open Source Definition.” All of this self-reflection was intended to capitalize on the waves of attention being directed at Free Software in the wake of Netscape’s announcement.

The motivations for these changes came from a variety of sources—ranging from a desire to be included in the dotcom boom to a powerful (ideological) resistance to being ideological. Linus Torvalds loudly proclaimed that the reason to do Free Software was because it was “fun”; others insisted that it made better business _{[pg 109]} sense or that the stability of infrastructures like the Internet depended on a robust ability to improve them from any direction. But none of them questioned how Free Software got done or proposed to change it.

Raymond’s paper “The Cathedral and the Bazaar” quickly became the most widely told story of how Open Source works and why it is important; it emphasizes the centrality of novel forms of coordination over the role of novel copyright licenses or practices of sharing source code. “The Cathedral and the Bazaar” reports Raymond’s experiments with Free Software (the bazaar model) and reflects on the difference between it and methodologies adopted by industry (the cathedral model). The paper does not truck with talk of freedom and has no denunciations of software hoarding à la Stallman. Significantly, it also has no discussion of issues of licensing. Being a hacker, however, Raymond did give his paper a “revision-history,” which proudly displays revision 1.29, 9 February 1998: “Changed ‘free software’ to ‘open source.’” ¹⁰⁴

Raymond was determined to reject the philosophy of liberty that Stallman and the Free Software Foundation represented, but not in order to create a political movement of his own. Rather, Raymond (and the others at the Freeware Summit) sought to cash in on the rising tide of the Internet economy by turning the creation of Free Software into something that made more sense to investors, venture capitalists, and the stock-buying public. To Raymond, Stallman and the Free Software Foundation represented not freedom or liberty, but a kind of dogmatic, impossible communism. As Raymond was a committed libertarian, one might expect his core beliefs in the necessity of strong property rights to conflict with the strange communalism of Free Software—and, indeed, his rhetoric was focused on pragmatic, business-minded, profit-driven, and market-oriented uses of Free Software. For Raymond, the essentially interesting component of Free Software was not its enhancement of human liberty, but the innovation in software production that it represented (the “development model”). It was clear that Free Software achieved something amazing through a clever inversion of strong property rights, an inversion which could be expected to bring massive revenue in some other form, either through cost-cutting or, Netscape-style, through the stock market.

Raymond wanted the business world and the mainstream industry to recognize Free Software’s potential, but he felt that Stallman’s _{[pg 110]} rhetoric was getting in the way. Stallman’s insistence, for example, on calling corporate intellectual-property protection of software “hoarding” was doing more damage than good in terms of Free Software’s acceptance among businesses, as a practice, if not exactly a product.

Raymond’s papers channeled the frustration of an entire generation of Free Software hackers who may or may not have shared Stallman’s dogmatic philosophical stance, but who nonetheless wanted to participate in the creation of Free Software. Raymond’s paper, the Netscape announcement, and the Freeware Summit all played into a palpable anxiety: that in the midst of the single largest creation of paper wealth in U.S. history, those being enriched through Free Software and the Internet were not those who built it, who maintained it, or who got it.

The Internet giveaway was a conflict of propriety: hackers and geeks who had built the software that made it work, under the sign of making it free for all, were seeing that software generate untold wealth for people who had not built it (and furthermore, who had no intention of keeping it free for all). Underlying the creation of wealth was a commitment to a kind of permanent technical freedom—a moral order—not shared by those who were reaping the most profit. This anxiety regarding the expropriation of work (even if it had been a labor of love) was ramified by Netscape’s announcement.

All through 1998 and 1999, buzz around Open Source built. Little-known companies such as Red Hat, VA Linux, Cygnus, Slackware, and SuSe, which had been providing Free Software support and services to customers, suddenly entered media and business consciousness. Articles in the mainstream press circulated throughout the spring and summer of 1998, often attempting to make sense of the name change and whether it meant a corresponding change in practice. A front-cover article in Forbes, which featured photos of Stallman, Larry Wall, Brian Behlendorf, and Torvalds (figure 2), was noncommittal, cycling between Free Software, Open Source, and Freeware. ¹⁰⁵

~[* “Peace, Love and Software,” cover of Forbes, 10 August 1998. Used with permission of Forbes and Nathaniel Welch. ]~

By early 1999, O’Reilly Press published Open Sources: Voices from the Open Source Revolution, a hastily written but widely read book. It included a number of articles—this time including one by Stallman—that cobbled together the first widely available public history of Free Software, both the practice and the technologies _{[pg 111]} involved. Kirk McKusick’s article detailed the history of important technologies like the BSD version of UNIX, while an article by Brian Behlendorf, of Apache, detailed the practical challenges of running Free Software projects. Raymond provided a history of hackers and a self-aggrandizing article about his own importance in creating the movement, while Stallman’s contribution told his own version of the rise of Free Software.

By December 1999, the buzz had reached a fever pitch. When VA Linux, a legitimate company which actually made something real—computers with Linux installed on them—went public, its shares’ value gained 700 percent in one day and was the single _{[pg 112]} most valuable initial public offering of the era. VA Linux took the unconventional step of allowing contributors to the Linux kernel to buy into the stock before the IPO, thus bringing at least a partial set of these contributors into the mainstream Ponzi scheme of the Internet dotcom economy. Those who managed to sell their stock ended up benefiting from the boom, whether or not their contributions to Free Software truly merited it. In a roundabout way, Raymond, O’Reilly, Perens, and others behind the name change had achieved recognition for the central role of Free Software in the success of the Internet—and now its true name could be known: Open Source.

Yet nothing much changed in terms of the way things actually got done. Sharing source code, conceiving openness, writing licenses, coordinating projects—all these continued as before with no significant differences between those flashing the heroic mantle of freedom and those donning the pragmatic tunic of methodology. Now, however, stories proliferated; definitions, distinctions, details, and detractions filled the ether of the Internet, ranging from the philosophical commitments of Free Software to the parables of science as the “original open source” software. Free Software proponents refined their message concerning rights, while Open Source advocates refined their claims of political agnosticism or nonideological commitments to “fun.” All these stories served to create movements, to evangelize and advocate and, as Eugen Leitl would say, to “corrupt young minds” and convert them to the cause. The fact that there are different narratives for identical practices is an advantageous fact: regardless of why people think they are doing what they are doing, they are all nonetheless contributing to the same mysterious thing.

A Movement?

To most onlookers, Free Software and Open Source seem to be overwhelmed with frenzied argument; the flame wars and disputes, online and off, seem to dominate everything. To attend a conference where geeks—especially high-profile geeks like Raymond, Stallman, and Torvalds—are present, one might suspect that the very detailed practices of Free Software are overseen by the brow-beating, histrionic antics of a few charismatic leaders and that ideological commitments result in divergent, incompatible, and affect-laden _{[pg 113]} opposition which must of necessity take specific and incompatible forms. Strangely, this is far from the case: all this sound and fury doesn’t much change what people do, even if it is a requirement of apprenticeship. It truly is all over but for the shouting.

According to most of the scholarly literature, the function of a movement is to narrate the shared goals and to recruit new members. But is this what happens in Free Software or Open Source? ¹⁰⁶ To begin with, movement is an awkward word; not all participants would define their participation this way. Richard Stallman suggests that Free Software is social movement, while Open Source is a development methodology. Similarly some Open Source proponents see it as a pragmatic methodology and Free Software as a dogmatic philosophy. While there are specific entities like the Free Software Foundation and the Open Source Initiative, they do not comprise all Free Software or Open Source. Free Software and Open Source are neither corporations nor organizations nor consortia (for there are no organizations to consort); they are neither national, subnational, nor international; they are not “collectives” because no membership is required or assumed—indeed to hear someone assert “I belong” to Free Software or Open Source would sound absurd to anyone who does. Neither are they shady bands of hackers, crackers, or thieves meeting in the dead of night, which is to say that they are not an “informal” organization, because there is no formal equivalent to mimic or annul. Nor are they quite a crowd, for a crowd can attract participants who have no idea what the goal of the crowd is; also, crowds are temporary, while movements extend over time. It may be that movement is the best term of the lot, but unlike social movements, whose organization and momentum are fueled by shared causes or broken by ideological dispute, Free Software and Open Source share practices first, and ideologies second. It is this fact that is the strongest confirmation that they are a recursive public, a form of public that is as concerned with the material practical means of becoming public as it is with any given public debate.

The movement, as a practice of argument and discussion, is thus centered around core agreements about the other four kinds of practices. The discussion and argument have a specific function: to tie together divergent practices according to a wide consensus which tries to capture the why of Free Software. Why is it different from normal software development? Why is it necessary? Why now? _{[pg 114]} Why do people do it? Why do people use it? Can it be preserved and enhanced? None of these questions address the how: how should source code circulate? How should a license be written? Who should be in charge? All of these “hows” change slowly and experimentally through the careful modulation of the practices, but the “whys” are turbulent and often distracting. Nonetheless, people engaged in Free Software—users, developers, supporters, and observers—could hardly remain silent on this point, despite the frequent demand to just “shut up and show me the code.” “Figuring out” Free Software also requires a practice of reflecting on what is central to it and what is outside of it.

The movement, as a practice of discussion and argument, is made up of stories. It is a practice of storytelling: affect- and intellect-laden lore that orients existing participants toward a particular problem, contests other histories, parries attacks from outside, and draws in new recruits. ¹⁰⁷ This includes proselytism and evangelism (and the usable pasts of protestant reformations, singularities, rebellion and iconoclasm are often salient here), whether for the reform of intellectual-property law or for the adoption of Linux in the trenches of corporate America. It includes both heartfelt allegiance in the name of social justice as well as political agnosticism stripped of all ideology. ¹⁰⁸ Every time Free Software is introduced to someone, discussed in the media, analyzed in a scholarly work, or installed in a workplace, a story of either Free Software or Open Source is used to explain its purpose, its momentum, and its temporality. At the extremes are the prophets and proselytes themselves: Eric Raymond describes Open Source as an evolutionarily necessary outcome of the natural tendency of human societies toward economies of abundance, while Richard Stallman describes it as a defense of the fundamental freedoms of creativity and speech, using a variety of philosophical theories of liberty, justice, and the defense of freedom. ¹⁰⁹ Even scholarly analyses must begin with a potted history drawn from the self-narration of geeks who make or advocate free software. ¹¹⁰ Indeed, as a methodological aside, one reason it is so easy to track such stories and narratives is because geeks like to tell and, more important, like to archive such stories—to create Web pages, definitions, encyclopedia entries, dictionaries, and mini-histories and to save every scrap of correspondence, every fight, and every resolution related to their activities. This “archival hubris” yields a very peculiar and specific kind of fieldsite: one in which a kind _{[pg 115]} of “as-it-happens” ethnographic observation is possible not only through “being there” in the moment but also by being there in the massive, proliferating archives of moments past. Understanding the movement as a changing entity requires constantly glancing back at its future promises and the conditions of their making.

Stories of the movement are also stories of a recursive public. The fact that movement isn’t quite the right word is evidence of a kind of grasping, a figuring out of why these practices make sense to all these geeks, in this place and time; it is a practice that is not so different from my own ethnographic engagement with it. Note that both Free Software and Open Source tell stories of movement(s): they are not divided by a commercial-noncommercial line, even if they are divided by ill-defined and hazy notions of their ultimate goals. The problem of a recursive public (or, in an alternate language, a recursive market) as a social imaginary of moral and technical order is common to both of them as part of their practices. Thus, stories about “the movement” are detailed stories about the technical and moral order that geeks inhabit, and they are bound up with the functions and fates of the Internet. Often these stories are themselves practices of inclusion and exclusion (e.g., “this license is not a Free Software license” or “that software is not an open system”); sometimes the stories are normative definitions about how Free Software should look. But they are, always, stories that reveal the shared moral and technical imaginations that make up Free Software as a recursive public.

Conclusion

Before 1998, there was no movement. There was the Free Software Foundation, with its peculiar goals, and a very wide array of other projects, people, software, and ideas. Then, all of a sudden, in the heat of the dotcom boom, Free Software was a movement. Suddenly, it was a problem, a danger, a job, a calling, a dogma, a solution, a philosophy, a liberation, a methodology, a business plan, a success, and an alternative. Suddenly, it was Open Source or Free Software, and it became necessary to choose sides. After 1998, debates about definition exploded; denunciations and manifestos and journalistic hagiography proliferated. Ironically, the creation of two names allowed people to identify one thing, for _{[pg 116]} these two names referred to identical practices, licenses, tools, and organizations. Free Software and Open Source shared everything “material,” but differed vocally and at great length with respect to ideology. Stallman was denounced as a kook, a communist, an idealist, and a dogmatic holding back the successful adoption of Open Source by business; Raymond and users of “open source” were charged with selling out the ideals of freedom and autonomy, with the dilution of the principles and the promise of Free Software, as well as with being stooges of capitalist domination. Meanwhile, both groups proceeded to create objects—principally software—using tools that they agreed on, concepts of openness that they agreed on, licenses that they agreed on, and organizational schemes that they agreed on. Yet never was there fiercer debate about the definition of Free Software.

On the one hand, the Free Software Foundation privileges the liberty and creativity of individual geeks, geeks engaged in practices of self-fashioning through the creation of software. It gives precedence to the liberal claim that without freedom of expression, individuals are robbed of their ability to self-determine. On the other hand, Open Source privileges organizations and processes, that is, geeks who are engaged in building businesses, nonprofit organizations, or governmental and public organizations of some form or another. It gives precedence to the pragmatist (or polymathic) view that getting things done requires flexible principles and negotiation, and that the public practice of building and running things should be separate from the private practice of ethical and political beliefs. Both narratives give geeks ways of making sense of a practice that they share in almost all of its details; both narratives give geeks a way to understand how Free Software or Open Source Software is different from the mainstream, proprietary software development that dominates their horizons. The narratives turn the haphazard participation and sharing that existed before 1998 into meaningful, goal-directed practices in the present, turning a class-in-itself into a class-for-itself, to use a terminology for the most part unwelcome among geeks.

If two radically opposed ideologies can support people engaged in identical practices, then it seems obvious that the real space of politics and contestation is at the level of these practices and their emergence. These practices emerge as a response to a reorientation of power and knowledge, a reorientation somewhat impervious to _{[pg 117]} conventional narratives of freedom and liberty, or to pragmatic claims of methodological necessity or market-driven innovation. Were these conventional narratives sufficient, the practices would be merely bureaucratic affairs, rather than the radical transformations they are.