Eugen is also a polymath (and an autodidact to boot), but in the conventional sense. Eugen's polymathy is an avocational necessity: transhumanists need to keep up with all advances in technology and science in order to better a.s.sess what kinds of human-augmenting or human-obsolescing technologies are out there. It is not for work in this world that the transhumanist expands his or her knowledge, nor quite for the next, but for a "this world" yet to arrive.

Eugen and I were introduced during the Napster debates of 2001, which seemed at the time to be a knock-down, drag-out conflagration, but Eugen has been involved in so many online flame wars that he probably experienced it as a mere blip in an otherwise constant struggle with less-evolved intelligences like mine. Nonetheless, it was one of the more clarifying examples of how geeks think, and think differently, about technology, infrastructure, networks, and software. Transhumanism has no truck with old-fashioned humanism.

> >From: Ramu Narayan . . .

> >I don't like the

> >notion of technology as an unstoppable force with a will of its own that

> >has nothing to do with the needs of real people.

[Eugen Leitl:] Emergent large-scale behaviour is nothing new. How do you intend to control individual behaviour of a large population of only partially rational agents? They don't come with too many convenient behaviour-modifying hooks (pheromones as in social insects, but notice menarche-synch in females sharing quarters), and for a good reason. The few hooks we have (mob, war, politics, religion) have been notoriously abused, already. a.n.a.logous to apoptosis, metaindividuals may function using processes deletorious[sic] to its components (us).31

Eugen's understanding of what "technological progress" means is sufficiently complex to confound most of his interlocutors. For one surprising thing, it is not exactly inevitable. The manner in which Leitl argues with people is usually a kind of machine-gun prattle of coevolutionary, game-theoretic, cryptographic sorites. Eugen piles on the scientific and transhumanist reasoning, and his interlocutors slowly peel away from the discussion. But it isn't craziness, hype, or half-digested popular science-Eugen generally knows his stuff-it just fits together in a way that almost no one else can quite grasp. Eugen sees the large-scale adoption and proliferation of technologies (particularly self-replicating molecular devices and evolutionary software algorithms) as a danger that transcends all possibility of control at the individual or state level. Billions of individual decisions do not "average" into one will, but instead produce complex dynamics and hang perilously on initial conditions. In discussing the possibility of the singularity, Eugen suggests, "It could literally be a science-fair project [that causes the singularity]." If Francis Bacon's understanding of the relation between Man and Nature was that of master and possessor, Eugen's is its radicalization: Man is a powerful but ultimately arbitrary force in the progress of Life-Intelligence. Man is fully incorporated into Nature in this story, so much so that he dissolves into it. Eugen writes, when "life crosses over into this petri dish which is getting readied, things will become a lot more lively. . . . I hope we'll make it."

For Eugen, the arguments about technology that the polymaths involve themselves in couldn't be more parochial. They are important only insofar as they will set the "initial conditions" for the grand coevolutionary adventure of technology ahead of us. For the transhumanist, technology does not dissolve. Instead, it is the solution within which humans are dissolved. Suffering, allocation, decision making-all these are inessential to the ultimate outcome of technological progress; they are worldly affairs, even if they concern life and death, and as such, they can be either denounced or supported, but only with respect to fine-tuning the acceleration toward the singularity. For the transhumanist, one can't fight the inevitability of technical evolution, but one certainly can contribute to it. Technical progress is thus both law-like and subject to intelligent manipulation; technical progress is inevitable, but only because of the power of ma.s.sively parallel human curiosity.

Considered as one of the modes of thought present in this-worldly political discussion, the transhumanist (like the polymath) turns technology into a rhetorical argument. Technology is the more powerful political argument because "it works." It is pointless to argue "about" technology, but not pointless to argue through and with it. It is pointless to talk about whether stopping technology is good or bad, because someone will simply build a technology that will invalidate your argument.

There is still a role for technical invention, but it is strongly distinguished from political, legal, cultural, or social interventions. For most transhumanists, there is no rhetoric here, no sophistry, just the pure truth of "it works": the pure, undeniable, unstoppable, and undeconstructable reality of technology. For the transhumanist att.i.tude, the reality of "working code" has a reality that other a.s.sertions about the world do not. Extreme transhumanism replaces the life-world with the world of the computer, where bad (ethically bad) ideas won't compile. Less-staunch versions of transhumanism simply allow the confusion to operate opportunistically: the progress of technology is unquestionable (omniscient), and only its effects on humans are worth investigating.

The pure transhumanist, then, is a countermodern. The transhumanist despises the present for its intolerably slow descent into the future of immortality and superhuman self-improvement, and fears destruction because of too much turbulent (and ignorant) human resistance. One need have no individual conception of the present, no reflection on or synthetic understanding of it. One only need contribute to it correctly. One might even go so far as to suggest that forms of reflection on the present that do not contribute to technical progress endanger the very future of life-intelligence. Curiosity and technical innovation are not historical features of Western science, but natural features of a human animal that has created its own conditions for development. Thus, the transhumanists' historical consciousness consists largely of a timeline that makes ordered sense of our place on the progress toward the Singularity.

The moral of the story is not just that technology determines history, however. Transhumanism is a radically antihumanist position in which human agency or will-if it even exists-is not ontologically distinct from the agency of machines and animals and life itself. Even if it is necessary to organize, do things, make choices, partic.i.p.ate, build, hack, innovate, this does not amount to a belief in the ability of humans to control their destiny, individually or collectively. In the end, the transhumanist cannot quite pinpoint exactly what part of this story is inevitable-except perhaps the story itself. Technology does not develop without millions of distributed humans contributing to it; humans cannot evolve without the explicit human adoption of life-altering and ident.i.ty-altering technologies; evolution cannot become inevitable without the manipulation of environments and struggles for fitness. As in the dilemma of Calvinism (wherein one cannot know if one is saved by one's good works), the transhumanist must still create technology according to the particular and parochial demands of the day, but this by no means determines the eventual outcome of technological progress. It is a sentiment well articulated by Adam Ferguson and highlighted repeatedly by Friederich Hayek with respect to human society: "the result of human action, but not the execution of any human design."32

Conclusion.

To many observers, geeks exhibit a perhaps bewildering mix of liberalism, libertarianism, anarchism, idealism, and pragmatism, yet tend to fall firmly into one or another const.i.tuted political category (liberal, conservative, socialist, capitalist, neoliberal, etc.). By showing how geeks make use of the Protestant Reformation as a usable past and how they occupy a spectrum of beliefs about progress, liberty, and intervention, I hope to resist this urge to cla.s.sify. Geeks are an interesting case precisely because they are involved in the creation of new things that change the meaning of our const.i.tuted political categories. Their politics are mixed up and combined with the technical details of the Internet, Free Software, and the various and sundry organizations, laws, people, and practices that they deal with on a regular basis: operating systems and social systems. But such mixing does not make Geeks merely technoliberals or technoconservatives. Rather, it reveals how they think through the specific, historically unique situation of the Internet to the general problems of knowledge and power, liberty and enlightenment, progress and intervention.

Geeks are not a kind of person: geeks are geeks only insofar as they come together in new, technically mediated forms of their own creation and in ways that are not easy to identify (not language, not culture, not markets, not nations, not telephone books or databases). While their affinity is very clearly const.i.tuted through the Internet, the Internet is not the only reason for that affinity. It is this collective affinity that I refer to as a recursive public. Because it is impossible to understand this affinity by trying to identify particular types of people, it is necessary to turn to historically specific sets of practices that form the substance of their affinity. Free Software is an exemplary case-perhaps the exemplar-of a recursive public. To understand Free Software through its changing practices not only gives better access to the life-world of the geek but also reveals how the structure of a recursive public comes into being and manages to persist and transform, how it can become a powerful form of life that extends its affinities beyond technophile geeks into the realms of ordinary life.

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 199899, 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 199899. 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 surpa.s.sed, certain limits, but nonetheless remained part of a system whose ident.i.ty finally firmed up in the period 199899 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 199899 that geeks came to recognize that they were all doing the same thing and, almost immediately, to argue about why.1 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 partic.i.p.ant 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, 19972000.

Free Software forked in 1998 when the term Open Source suddenly appeared (a term previously used only by the CIA to refer to uncla.s.sified 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 "h.o.a.rding," as Richard Stallman, the head of the Free Software Foundation, refers to it; the second, regarding Open Source, was a.s.sociated 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 199899: 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 encompa.s.s them all in one movement.

The event that precipitated this attempted semantic coup d'etat was the release of the source code for Netscape's Communicator 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 (nee 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, Spygla.s.s. 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 ant.i.trust 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 compet.i.tors 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 obfuscating these bytecodes to deter compet.i.tors 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 partic.i.p.ant 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 n.o.body ever made the business case."2 Hecker penned a doc.u.ment called "Netscape Source Code as Netscape Product" and circulated it to various people, including Andreessen and Netscape CEO Jim Barksdale. As the t.i.tle 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?"3 Under the influence of Hecker, Zawinski, and CTO Eric Hahn (who had also written various internal "heresy doc.u.ments" 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 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.4 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 compet.i.tion 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 compet.i.tive advantage.

Releasing the source code for Communicator was thus widely seen as perhaps the only way to bypa.s.s the poisoned well of compet.i.tively 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 a.s.sociated 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, 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 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."5 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.6 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."7 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.8 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-drinkfueled race to "ship."9 Releasing the Mozilla code, therefore, required a system of coordination that would differ from the normal practice of in-house 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 a.s.signed 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 ma.s.sive 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."10 For Zawinski, the decision was both a chance for Netscape to return to its glory and an opportunity 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."11 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."12 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."13 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 a.s.sure 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."14 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 partic.i.p.ants 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 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."15 It was at this summit that Raymond's suggestion of "Open Source" as an alternative name was first publicly debated.16 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 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 h.o.a.rding a 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.'"17 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 ma.s.sive 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 rhetoric was getting in the way. Stallman's insistence, for example, on calling corporate intellectual-property protection of software "h.o.a.rding" 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 partic.i.p.ate 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.18

2. "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 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 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 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?19 To begin with, movement is an awkward word; not all partic.i.p.ants would define their partic.i.p.ation 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 ent.i.ties 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 a.s.sumed-indeed to hear someone a.s.sert "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 partic.i.p.ants 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? 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 partic.i.p.ants toward a particular problem, contests other histories, parries attacks from outside, and draws in new recruits.20 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.21 Every time Free Software is introduced to someone, discussed in the media, a.n.a.lyzed 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.22 Even scholarly a.n.a.lyses must begin with a potted history drawn from the self-narration of geeks who make or advocate free software.23 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 sc.r.a.p 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 of "as-it-happens" ethnographic observation is possible not only through "being there" in the moment but also by being there in the ma.s.sive, proliferating archives of moments past. Understanding the movement as a changing ent.i.ty 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 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-princ.i.p.ally 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 partic.i.p.ation and sharing that existed before 1998 into meaningful, goal-directed practices in the present, turning a cla.s.s-in-itself into a cla.s.s-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 s.p.a.ce 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 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.

4. Sharing Source Code.

Free Software would be nothing without shared source code. The idea is built into the very name "Open Source," and it is a requirement of all Free Software licenses that source code be open to view, not "welded shut." Perhaps ironically, source code is the most material of the five components of Free Software; it is both an expressive medium, like writing or speech, and a tool that performs concrete actions. It is a mnemonic that translates between the illegible electron-speed doings of our machines and our lingering ability to partially understand and control them as human agents. Many Free Software programmers and advocates suggest that "information wants to be free" and that sharing is a natural condition of human life, but I argue something contrary: sharing produces its own kind of moral and technical order, that is, "information makes people want freedom" and how they want it is related to how that information is created and circulated. In this chapter I explore the twisted and contingent history of how source code and its sharing have come to take the technical, legal, and pedagogical forms they have today, and how the norms of sharing have come to seem so natural to geeks.

Source code is essential to Free Software because of the historically specific ways in which it has come to be shared, "ported," and "forked." Nothing about the nature of source code requires that it be shared, either by corporations for whom secrecy and jealous protection are the norm or by academics and geeks for whom source code is usually only one expression, or implementation, of a greater idea worth sharing. However, in the last thirty years, norms of sharing source code-technical, legal, and pedagogical norms-have developed into a seemingly natural practice. They emerged through attempts to make software into a product, such as IBM's 1968 "unbundling" of software and hardware, through attempts to define and control it legally through trade secret, copyright, and patent law, and through attempts to teach engineers how to understand and to create more software.

The story of the norms of sharing source code is, not by accident, also the history of the UNIX operating system.1 The UNIX operating system is a monstrous academic-corporate hybrid, an experiment in portability and sharing whose impact is widely and reverently acknowledged by geeks, but underappreciated more generally. The story of UNIX demonstrates the details of how source code has come to be shared, technically, legally, and pedagogically. In technical terms UNIX and the programming language C in which it was written demonstrated several key ideas in operating-systems theory and practice, and they led to the widespread "porting" of UNIX to virtually every kind of hardware available in the 1970s, all around the world. In legal terms UNIX's owner, AT&T, licensed it widely and liberally, in both binary and source-code form; the legal definition of UNIX as a product, however, was not the same as the technical definition of UNIX as an evolving experiment in portable operating systems-a tension that has continued throughout its lifetime. In pedagogical terms UNIX became the very paradigm of an "operating system" and was thereby ported not only in the technical sense from one machine to another, but from machines to minds, as computer-science students learning the meaning of "operating system" studied the details of the quasi-legally shared UNIX source code.2 The proliferation of UNIX was also a hybrid commercial-academic undertaking: it was neither a "public domain" object shared solely among academics, nor was it a conventional commercial product. Proliferation occurred through novel forms of academic sharing as well as through licensing schemes constrained by the peculiar status of AT&T, a regulated monopoly forbidden to enter the computer and software industry before 1984. Thus proliferation was not mere replication: it was not the sale of copies of UNIX, but a complex web of shared and re-shared chunks of source code, and the reimplementation of an elegant and simple conceptual scheme. As UNIX proliferated, it was stabilized in multiple ways: by academics seeking to keep it whole and self-compatible through contributions of source code; by lawyers at AT&T seeking to define boundaries that mapped onto laws, licenses, versions, and regulations; and by professors seeking to define it as an exemplar of the core concepts of operating-system theory. In all these ways, UNIX was a kind of primal recursive public, drawing together people for whom the meaning of their affiliation was the use, modification, and stabilization of UNIX.

The obverse of proliferation is differentiation: forking. UNIX is admired for its integrity as a conceptual thing and despised (or marveled at) for its truly tangled genealogical tree of ports and forks: new versions of UNIX, some based directly on the source code, some not, some licensed directly from AT&T, some sublicensed or completely independent.

Forking, like random mutation, has had both good and bad effects; on the one hand, it ultimately created versions of UNIX that were not compatible with themselves (a kind of autoimmune response), but it also allowed the merger of UNIX and the Arpanet, creating a situation wherein UNIX operating systems came to be not only the paradigm of operating systems but also the paradigm of networked computers, through its intersection with the development of the TCP/IP protocols that are at the core of the Internet.3 By the mid-1980s, UNIX was a kind of obligatory pa.s.sage point for anyone interested in networking, operating systems, the Internet, and especially, modes of creating, sharing, and modifying source code-so much so that UNIX has become known among geeks not just as an operating system but as a philosophy, an answer to a very old question in new garb: how shall we live, among a new world of machines, software, and networks?