Coding commons: fun and the Ubuntu labor process

PDF

Download

Open document

Flip pages

Download a page range

Download transcript

Copy asset link

Request this asset

Transcript (if available)

Content CODING COMMONS: FUN AND THE UBUNTU LABOR PROCESS by Jacob J. Peters A Dissertation Presented to the FACULTY OF THE USC GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In Partial Fulfillment of the Requirements for the Degree DOCTOR OF PHILOSOPHY (GEOGRAPHY) August 2012 Copyright 2012 Jacob J. Peters Dedication dedicated to my parents, to whom i owe everything. to my mom, who is still teaching me how to live a life that prioritizes music and beauty; to my papa, who has signed every email for twelve years KHF ... ... keep having fun. ii Acknowledgements I have been privileged to meet and learn from many amazing and generous folk in the course of graduate school, and I owe a great debt to those who made some fun possible in all conditions. Towards the end of my first year I was lucky enough to find two co-advisors, Carolyn Cartier and Ruthie Gilmore, who were willing to work with a kid who had no research project. I was so excited and relieved I went out and got a new pair of Converse to celebrate. Through Carolyn's hard work and guidance I received support from the National Science Foundation to conduct the international research that ended up giving form to this dissertation. Through many semesters of Geography 100, a few great seminars, and a good bit of nerding out, I learned from Ruthie how to teach and think and to approach the best and the worst with generosity and a demanding inquisitiveness. As my dissertation chair, Ruthie has always pushed me to answer odd and tough question that have led down surprising paths to discovery. Thank you Ruthie, for your friendship and your guidance. My dissertation committee is fantastic. I met Greg Hise just before starting at USC, and over eight years he helped me through draft proposals from robots to waterways before I came to code and fun. I am always inspired by and indebted to his intellectual generosity and wonderful scholarship. Francois Bar welcomed me to the world over at the Annenberg School at a time when I needed another academic home at USC. Thank you for that and for pushing me on the international and empirical. Thank you, Rod McKenzie, for having my back several times in conditions not of our choosing. iii Paul Adler was a ghost member of my committee in the past three years, and those years and this dissertation were made far better and more rewarding through good conversations about Marxism and writing. Thank you, Laura Pulido, for always asking the best questions and providing excellent advice and mentorship. Dorinne Kondo’s encouragement and advice on dealing with ethnographic work and representing complexity has been invaluable. When there was a Geography department, I would have never been able to negotiate its and the university’s idiosyncrasies without Billie Shotlow—she was there for all students, encouraging us and making sure we got paid. Many, many thanks to USC staff Maria Muratalla, Onita Morgan-Edwards, Sandra Hopwood, Jujuana Preston, Kitty Lai, Sonia Rodriguez, and Kate Kelsey. This dissertation was possible through funding by a National Science Foundation Doctoral Dissertation Improvement Grant (BCS-0928777, P.I. Dr. Carolyn Cartier). Like Tom Waits croons, I am so thankful for these friends I do receive. Thank you, Swan Club and ketchup, Triple J and Tuggy; thank you, Wendy Cheng, Jason Goldman, Jesus Hernandez, Todd Honma, Peter Holderness, Nisha Kunte, Sharon Luk, David Stein, and Luz Vazquez. Each of you has believed in me a little more than I did at some time, thank you for that gift. And thank you to all the guests and iterations of the Ardmore, my home of eight years in this city I love. It has been strange being a zombie geographer, but it was a good sort of strange thanks to a few friends I had the privilege of meeting in the process. Ryan Frisberger has been a good friend and source of inspiration from spatial theory to furniture design. iv Thank you, April Ruth Peck, for your excited insights, your dreams of a (think) TANK, and for teaching me how to roast a chicken. Laura Harjo and I struggled through the last stages of writing and defending together—doctors! Dang. If Andrew Burridge had not shown up at USC the same day I did, my life would be far less interesting and I would not have made it through graduate school without him. Along the way of this project I worked out ideas with friends and colleagues Sasha Costanza-Chock, Laura Fujikawa, Emily Hobson, Julie Hua, Peter Marolt, Veronica Paredes, and Nate Sessoms; thank you all, and to others I am forgetting to mention. Special thanks to Jenna Loyd and other geography compadre who made conferences and this professional life fun. Chris Kelty, Lilly Nguyen, and Luis Felipe Rosado Murillo at UCLA and I worked together on an unpublished FLOSS review article, which was a great help for my literature review. Thank you to folk at ephemera journal’s Work, Play and Boredom conference for helping me figure out what I cared about and reminding me what intellectual generosity looks like at a time when I dearly needed it. The greatest gift I received in this work was the time, generosity, and openness of the twenty-six Ubuntu contributors who each sat down with a stranger for several hours to talk about their work. I was always amazed by the kindness of FLOSS and Ubuntu folk, even those rightfully wary of academics. Many people who I did not formally interview helped me figure out how Ubuntu works, and I am in the debt of many whose names or IRC nick I do not remember. Thank you, California LoCo team members, I am forever in debt to your warm welcome and friendship. Thank you, Benjamin Mako Hill, v for introductions to Ubuntu contributors that got research rolling. I learned much more from Ubuntu folk than is in the dissertation; it was a privilege to get to do such work. Thank you to my only favorite place on the USC campus, USC Physical Therapy Associates, and especially Erin Hayden, without whom I would have suffered much more with the physical trials and pain of this work of sitting and typing. More than half of this dissertation was written between Stories LA and Cafecito Organico. Thank you to the folk who work and frequent those places and others where I have had the pleasure of writing and reading. Thank you to Susan Harris for providing a place to retreat to the desert for the last push of writing. And another thank you to my parents and Madeline Island, Wisconsin, for some good summers of writing. Special thanks goes to Kim Ryan and the Angeles National Forest, co-sponsers of fun and my sanity in the past year. Last, it is essential to note my indebtedness to Fred Moten. Fred’s readings of Hortense Spillers’ and Samuel Delany’s work are always stuck in my head and changed how I think in ways I am only beginning to recognize. Also, I once told Fred that I could not stop thinking about the form for holding things in common, and he said something like, “Of course. Those are the two things, the form, and the held-in-common.” Those are the words that influenced this dissertation the most. Thank you, Fred, for those words and others. vi Table of Contents Dedication ii Acknowledgements iii List of Figures ix Abstract x Introduction: Raising the Dead: Gifts and Things Left Behind 1 “This is a Gift” 11 Questions Left Behind 15 Chapter Zero: Breathing Life into 0s and 1s: Origins and Value 23 I. Who is Ubuntu? 24 Community or Canonical? 29 Community Management 32 Ubuntu Practices, FLOSS Law 37 Computer Mode and IRC 42 II. FLOSS, it is Good to Think With 48 Practitioner Histories and Journalistic Accounts 51 A Challenge to Assumptions: FLOSS Enters the Academy 53 Studies of FLOSS that are not Necessarily about FLOSS 55 III. Some of the Usual Stories 58 Usual Story #1, “Linus Torvalds in his bedroom” 60 Usual Story #2: “Richard Stallman and the Proprietary Printer” 66 Usual Story #3, “A Millionaire Founder from Outer-Space” 72 Interlude: How Software Melts into Hardware 85 Chapter One: The Material Worlds of Code 88 I. The Relationship Between Code and Software 93 Code as Media or Text 95 The Dual Nature of Code 106 On Becoming Software 113 Movement and Speed 117 II. Services, Informational Goods, and Cultural Products 129 How Ideology Works: the Case of Services 136 Informational and Cultural Goods: Is that what Code is? 150 Extramedial: A Necessary Addition to Informational 156 Interlude: Bug Jam 164 Chapter Two: Fun at Work 168 vii I. Why This Fun Now? 178 Fun and Meaningfulness 186 Fun and the Management of (Machine) Time 192 II. Why We Do Versus What We Do 200 Where Motivation Leads 202 That Which is Hidden Behind Motivation 205 How Fun Helps Create Surplus Value When There is None to be Found 207 From Autonomy to Dependency 213 Fun and Subjectivity 221 III. Fun at Work: Eyeglasses and Laundry 227 Reproducing Fun, or, A Few of Fun’s Externalities 234 Stepping Back from Fun: Context and Recap 238 Interlude: Conferences Hold the Allure of Possible Magic 243 Chapter Three: A Spatial Fix and Ubuntu Economics 245 I. What is it that Makes the Commons a Good Fix? 249 Rethinking “Knowledge Commons” 255 Canonical and Control, or, How the Wage Relation becomes Absurd 265 Immaterial is Poor Word Choice for Something so Full of Matter 282 II. A Spatial Fix, or, Devaluing Capital with Dreams of More Surplus 291 Productive Labor: A way through this Mess 294 What is in a Spatial Fix? (Labor’s own Fix, the Grip of Dead Labor, Time) 304 III. How a Cloud Strategy Hits the Ground 312 Gift to Capital and Back Again (a Return to the Dual Nature of Code) 318 Epilogue: We Simply Do Not Know What Our Work Does 334 Glossary 336 Bibliography 349 Appendix A: The Ubuntu Code of Conduct 372 Appendix B: Open Week Announcement of Jaunty 374 Appendix C: Mirror List 377 Appendix D: Manifesto for Fun 384 Appendix E: Global Bug Jam Guide 2008 386 Appendix F: List of Interviews 387 viii List of Figures Figure 1: Some Examples Collected From Wikipedia that Represent How Operating Systems and Kernels Relate to Other Aspects of Computing Devices 8 Figure 2: Sample Ubuntu Development Cycle (Six Months) 79 Figure 3: Microscope Images of the Surface of a Hard Drive Platter and the Surface of a CD 115 Figure 4: Images Taken at the California LoCo Global Bug Jam Posted on the Ubuntu Community Manager’s Blog (with me, second from the right, looking like a dork) 166 Figure 5: Model of Extractive Strategies 212 Figure 6: Medibuntu Karma Ranking and Canonical’s Explanation of how Karma Works 218 Figure 7: "Google Women" Mugs at Session in the "Women in Open Source" Track at SCaLE 232 Figure 8: Freenode Acknowledgments for Groups that have not given Direct Financial support, but “Provided Significant Resources.” 275 Figure 9: Location of Amazon Data Centers (very likely not inclusive) 316 ix Abstract Coding Commons: Fun and the Ubuntu Labor Process explores what is at stake in how we understand “digital work” and builds a theory of code that exposes the dependencies and externalities of code production. This labor geography uses ethnographic research methods to analyze the labor process of Ubuntu, an international software project emblematic of emerging conditions of work and new organizations of productive resources. Ubuntu is a free software project—meaning that the collaborative practices of creating Ubuntu are dedicated to making it freely available to be used and changed by anyone—and it is built by the labor of a few hundred paid contributors and tens of thousands of volunteers. Ubuntu is made via an on-going uneasy negotiation between the capitalist mode of production and a non-capitalist mode of production organized by something coders themselves call “fun.” My research has revealed that fun is more than an individual motivation or experience: it is a means through which labor is organized. As firms seek to capitalize on our desire for fun—via processes such as “crowd-sourcing” or the creation of “fun” workplaces—knowing what our fun produces is as important as knowing what our work produces. So, why this fun now? What does our work produce when it becomes part of the commons? What is the nature of the relationship between capitalism and the commons when code is held in common? What is code? Or, to sum all these questions up, how is life breathed into 0s and 1s? I answer these questions though the words and experiences of Ubuntu contributors, all the while working to build a theory of the material life of code. This theory rests on my argument that code is the material with which all things digital are made. Code is metal, plastics, x and other material that has a dual nature: it is both something akin to a set of instructions, and in it its use, code is movement and machine. I demonstrate how focusing on this material life allows for tracing the movement of value into the commons and though moments of being put to use for capital—in other words, how it works that capital can seek a spatial fix in a commons of computer code. Capital is dependent upon the commons, and making sense of the form and outcomes of this dependency is crucial to understanding capitalism and its extractive strategies. Dealing with the material life of code and coders leaves us with the challenge of connecting distant people, machines, and labor processes that are all part of creating the computing environment we have before us. Making these connections is a basis for making it common sense to ask: is a more just way of distributing resources is possible? And how can any work—from coding to hand soldering circuit boards—be organized so that it is fun? And how might this fun work to create humane and sustainable ways for producing what we need and for more justly allocating the surpluses we produce? xi Introduction: Raising the Dead: Gifts and Things Left Behind [Labour] raises the means of production from the dead merely by entering into contact with them, infuses them with life so that they become factors of the labour process, and combines with them to form new products. (Marx 1993, 308) The raising of the dead is always on my mind, especially concerning software. Os and 1s, resting in the form of charged pieces of some metal alloy that can be read as either closer to on or off, are the primary material form taken by the dead labor of coders past and present that must be brought to life again and again to make software, and all things digital. 1 Code is part of the means of production, in some capacity, for most labor processes, and is raised from the dead and put to work as all sorts of means with all sorts of ends. One of the foundational myths of the digital is that when the means of production are digital, they can be put to work unendingly; that digital things can be copied again and again, without meaningful cost or loss. Like all machines, digital machines have a life span of usefulness. Determining the length of this lifespan is complicated; some code may be raised from the dead for centuries. Code is not quite like anything that proceeded it—but how it is put to work is often quite like the analog machines, human computers and switch operators it augmented or replaced. It is important to remember that the first computers were humans performing calculations and 1 Please see the glossary at the end of this document for definitions of some technical terms, such as digital. 1 that the machinery for executing binary code once involved humans, mostly women, sorting, ordering, moving, and running code. Thinking back for a moment about these emergent forms of using code can help shed light on another foundational myth of the digital: digital workers own the means of production. The myth goes as follows, those who work to produce digital goods do so by combining their mental faculties with their own low-cost personal computing devices, and thus own their very own means of producing digital things. The machines, people, and legions of infrastructure required to create the first computing machines and to produce the workers who would build and program such machines make clear that from the inception of computing, doing “digital work” has always relied upon vast infrastructure and is necessarily a social endeavor. Today, the machines, people, and infrastructure that make networked digital computing possible can no longer all be contained in a single site such as Bletchley Park, UK (where one of the first digital computers was assembled in 1943), or in a mid-twentieth century firm’s computing room. Yet, simply because the people and infrastructure that create and support the means of production are abstracted, distanced, or beneath the ground and the oceans should not allow us to forget to include them in our thoughts, concepts, and theories of digital things. In particular, for at least the last twenty years, bringing code to life to produce a digital good has usually required a packet-switched network, most often the internet. Those working upon digital things are likely several significant struggles away from ownership of the means of production—the cables, switches, buildings, land, servers, electricity, and 2 more that come together with millions of people’s labor to form the internet and other infrastructure that create the means of producing digital things. My dissertation takes one labor process of making some digital things and asks, “how does it work?” The reason for this sort of primary research question is encapsulated in media theorist Friedrich Kittler’s seminal article “There is no Software,” and Kittler’s conclusion about the nature of software: “we simply do not understand what our writing does” (Kittler 1995, 2). However, my work is not about identifying the linguistic practices or ontological effects of writing code; instead I locate the writing of code in a broad context of its production. As I hope will become clear, this context is an on-going uneasy negotiation between the capitalist mode of production and a non- capitalist mode of production. Although not entirely reducible to these terms, this negotiation (not antagonism or contradiction) is also one between capitalism and the commons. 2 Such abstract relationships take the form of people organizing and being organized to work on code with others—that is, the abstract concept of a negotiation between capitalism and the commons refers to the whole and complicated lives and relationships between people laboring and the means and object of their labor. As digital things almost always require digital tools for their creation, any labor process of making something like software is immediately part of a larger “ecosystem” of dependencies between pieces of software and hardware. Any moment in such a labor process quickly becomes full of what Peter J. Taylor calls unruly complexity: “situations 2 I will return to the commons in detail in Chapter Three, but for now I want to propose thinking about commons in a very general sense—for the commons are general. The commons, or a common, refers to a resource that is in some way rendered un-ownable, that humans somehow make valuable (use to meet a need). Of course, the value of a common may be put to any number of ends that do not reproduce the common. How we come to forge relationships between our work and the things of value we make and use will be a good part of the story that follows. 3 that do not have clearly defined boundaries, coherent internal dynamics, or simply mediated relations with their external context” (Taylor 2005, xiii). Following Taylor, who argues that framing a new idea “as a hypothesis to be tested is not necessarily the quickest route to better generative representations,” I focus on asking a primary research question and telling stories toward a generative representation of the relationships that bring a labor process into being. What makes these relationships particularly difficult to sort out is that code is both the means and object of labor, and the means and object of labor are often indistinguishable (i.e., coders often put the software to which they contribute to work to create more code for that very same software). Working through this nigh indistinguishable blurring between object of labor and means of labor is not simply an interesting intellectual exercise, it is rooted in the very material problem that drives Kittler to provocatively argue that we do not know what our writing does. We do not know what writing code does because code operates beyond human perception at millions of operations per second and in its operation becomes indistinguishable from hardware on a material level (more on this in further detail in Chapter One). Without a grounded, material framework for thinking about code, such blurring makes it easy to argue that workers creating code own their own means of production (e.g. Chiao 2003; Chopra and Dexter 2008); that the value produced by the labor of coding is nigh impossible to measure (e.g. Dyer-Witheford 1999, 27; Hardt and Negri 2009, 356); or that digital goods are reproducible at a cost approaching zero (e.g. Castells 2001; Weber 2004). Locating code in the context of its production is about 4 understanding how code creates the conditions in which we work and the capacities and methods by which capital is able to (and not able to) organize labor and extract value. The stakes of this study emerge from trying to build theory for understanding the qualities and conditions of work in the context of capital’s extractive capacities. The argument I put forward for explaining these qualities and conditions is based in an exploration of fun. Fun is key to the dominant ideology of digital work. A key part of my concern with fun is to figure out how this ideology takes on material force in a labor process, and to show how this fun comes into being and where this fun comes from. There are many needs and desires caught up in what software developers and I both call fun. 3 One of the primary tasks of this project is to sort out fun from related concepts, as well as understanding how fun functions ideologically. To accomplish these goals, I must keep fun located in its context—acts of laboring, of transforming something from one state to another, that are fun. Quite simply, I find hope and beauty in a labor process organized to make work fun and to reproduce the capacity for fun for future workers. Meeting dozens of contributors who light up when talking about coding or creating something with Ubuntu is beautiful, and the possibilities of a labor process organized to make this fun and joy possible gives me hope that such fun is possible in all labor. In an unsurprising twist, it turns out that fun is also key to capital’s strategies for organizing labor and extracting value from the goods, knowledge, or other things of value that are 3 What I am calling fun is tied up with experiences, processes, and emotional states that could also easily be explored with the concepts of joy, meaningfulness, happiness, play, etc. I follow fun because I was struck by its appearance in FLOSS discourse—I could not stop wondering if there was something to Linus Torvalds’s (the creator of the Linux kernel) autobiography, Just for Fun—and later fun kept popping up, unprompted, in conversations with FLOSS folk I interviewed, drank with, worked with, and observed. A larger explanation of the choice of this term will be developed in detail in Chapter Two. 5 produced by such a labor process and held in common. As firms seek to capitalize on our desire for fun—via processes such as “crowd-sourcing” or the creation of “fun” workplaces—knowing what our fun produces is as important as knowing what our work produces. To understand what code does and what our fun produces I focus on the labor process of a large, privately funded international Free, Libre, and Open Source Software (FLOSS) project, the Ubuntu GNU/Linux operating system (hereafter, Ubuntu). All of these terms matter in the FLOSS world—their utterance is significant and my choices in the acronym and jargon-filled sentence that introduces this paragraph are indicative of how belonging works in FLOSS and the politics of FLOSS. First, FLOSS needs to be quickly broken down: “free,” “libre,” and “open source” all refer to important histories and places in FLOSS. 4 In very short form, “free” refers to the free software movement and the Free Software Foundation (FSF), founded in 1985 and still headquartered in Cambridge, Massachusetts. As oft repeated by free software supporters, free software is about software being “free as in freedom, not free as in beer,” and often serves as a marker for the “political” side of FLOSS. Open Source emerged as a term out of a meeting in VA Linux System’s office in Mountain View, California in 1998 (one year before VA would have a record-setting Initial Public Offering (IPO)). Open Source was specifically designed to be more palpable to investors and the “business world” than 4 Using FLOSS, instead of “free software” or “open source software” is also a choice to set aside the ethical, political, and practical differences between free software and open source software in favor of a focus on the systems of exchange and social relations that emerge through labor processes of making software (for a good discussion of the difference see Coleman and Hill 2004; Chopra and Dexter 2008; and especiallly Bejamin Mako Hill's 2008 review of Chopra and Dexter). 6 “freeware” or “free software” (Raymond 2001, 175; Weber 2004, 114). Libre 5 is important as a reminder that although founded and developed in the US, FLOSS code, practices, and sociality were very quickly, if not immediately, a transnational affair and the work of transnational collaboration has shaped FLOSS from the very beginning. GNU/Linux matters as well, it represents a choice to acknowledge that although Ubuntu is commonly referred to as a version of Linux, it is better described as GNU/Linux. A very significant portion of what is usually called Linux was built and is maintained by the GNU Project. A recursive acronym for “GNU’s Not UNIX,” GNU is a FSF attempt that began in 1983 to create a non-proprietary operating system. The project remained unfinished until 1991 with the creation of the Linux kernel, which used GNU Project tools to create a functional operating system (a “kernel” is the core of an operating system, the layer that connects applications to the processing capacity of a computing device). The figures below help explain what an “operating system” is and show some of the ways in which the functions of operating systems and/or kernels are represented—the important thing to take away is the relation between operating system and “hardware,” and that Microsoft Windows, Apple’s Mac OS, GNU/Linux, or another operating system could be placed in the box for “operating system” (See Figure 1). As we shall see, in their material lives, operating systems and hardware are not so easily separated into discrete boxes. 5 In Spanish, French and close approximations in other romance languages libre clearly refers to free as in freedom (libre) as opposed to free as in no cost (gratis). 7 This brings us to the object, labor process, and “community” that is the focus of much of my dissertation: Ubuntu. Ubuntu is located in the totality of inter-related FLOSS projects (commonly referred to as the “ecosystem”) as a Linux “distribution” that packages thousands of other FLOSS projects in a particular manner, with particular features along with branding and aesthetics that differentiates it from hundreds of other “distributions.” 6 Ubuntu provides an operating system in several “flavors:” three official editions, the Desktop Edition, focused on providing a user-friendly desktop experience to 6 Only a few distributions account for the majority of Linux users; Ubuntu is currently the most popular. And like most popular Linux distributions backed by a firm, Ubuntu is much discussed in the FLOSS world, with love as well as distrust—and in the past few years with perhaps slightly increasing distrust. 8 Figure 1: Some Examples Collected From Wikipedia that Represent How Operating Systems and Kernels Relate to Other Aspects of Computing Devices compete with other consumer interfaces (i.e. Windows and Mac OS); the Server Edition, designed primarily for large “enterprise-level” server applications, targeted at large firms (not small office or home servers server use); and, until it was rolled into the Desktop Edition in April 2011, the Netbook Edition, designed with an interface for small screens and low power consumption. There are also five other officially recognized derivatives with specific interfaces, applications or intended users, as well as many unsupported derivatives, from “localized” versions such as Arabian Linux to versions for specialized hardware such as Easy Peasy. Last, but not least, I use “labor process” to refer to “a way making things,” in its most simple and straightforward definition. Yet, such a “way” always references a set of complex relationships between people and things. Karl Marx defines “the simple elements of the labour process” as “(1) purposeful activity, that is work itself, (2) the object on which that work is performed, and (3) the instrument of that work” (Marx 1993, 284). Building on this definition with the help of scholars who have sought to make us understand that the reproduction of workers is internal to production, and thus part of the labor process (from Althusser 1970 to Fortunati 1995 to Ehrenreich 2008), I add (4) how people’s whole lives (including the reproduction of their capacity to work) and the times and locations of laboring are made to fit around each other. There is a lot of talk about time in the following pages, but it always rooted in an understanding that time and place are mutually produced. Machine time—the compulsory movement of human bodies in accordance with the rhythms of machines (see Marx 1993, 469)—only becomes a meaningful material force through the orchestration of people’s movements to the 9 rhythms of machines in place (see Pred 1981, 1984). To talk about time and place together is a good way to start to think about how space is produced; for instance, in considering how machine time becomes part of the dominant practices that form capitalist space. 7 Different modes of production create different sorts of space, and this space is a very real thing—there is an organization of time, and of how things are valued in capitalism that can be very viscerally felt and known, with effects that we can see and experience in the landscape. Non-capitalist ways of producing and exchanging things create palpably different sorts of space. Ubuntu exists in the juncture of two different modes of production and two different sorts of space; one is capitalist space, the other could be called many things, but I will talk about it primarily in terms of the commons and in terms of the methods of exchanging and circulated things of value in the Ubuntu mode of production: the gift. 7 This approach is somewhat similar to Labor Process Theory, which was developed primarily by UK management studies and the International Labor Process Conference and related book series (i.e. Braverman 1998; Thompson 2010). However, my focus on management is limited and is concerned not with the production of consent or control, but rather management’s role in orchestrating the movement of value and labor between modes of production—and, in the case of Ubuntu, how managers have commitments to Ubuntu and FLOSS and are also whole and complex persons. 10 “This is a Gift” The other thing we need to be conscious of is that we’re a gift economy. This might sound a little social sciency bullshity here, but we must remember that everything that happens in open source is a gift. (Jono Bacon, SCaLE 2009) Labor, freed from private property, simultaneously engages all our senses and capacities, in short, all our ‘human relations to the world—seeing, hearing, smelling, tasting, feeling, thinking, contemplating, sensing, wanting, acting, loving.’ (Marx 1964, 351) All of the thinking through code, fun, and the Ubuntu labor process that follows is work towards finding a place from which to comprehend capital’s dynamic relationship with the commons. Each of these first three topics has merit onto itself, but the puzzle that following fun, code, and the labor process led me towards is this particular relationship between capitalism and the commons, although that was not where I began. What is the nature of the relationship between capitalism and the commons? Is it different when digital things are held in common? This was not my research question, it is where research led, toward a theory for thinking about an un-named relationship between capitalism and the commons. The chapters that follow are likely the not best framework, or provide the most revealing concepts, or the cleanest names for what is at stake. But this dynamic seems essential for unraveling capitalism, and I am convinced that contending with the materiality of code is essential in doing such work. 11 I hope that this project reveals how fun and code come together to create commons upon which capital depends and how the commons and gift exchange might offer a path towards organizing a more just economy. Along the way I came to the conclusion that code is the material with which all digital things are made; a conclusion that has important repercussions for thinking about economies and digital things. Somewhat oddly I was led to this conclusion by thinking through the proposition that fun is possible in any kind of work, when working in accordance with the material at hand. Fun turns out to be great method for understanding “how we do what we do,” and it required engaging with the material at hand, which led me to ask over and over, what is the material of digital work? My answers to this questions and others about the nature of code are very different than where I began. Code is without analogy, it is singular, like the written word; as different from the written word as writing is from speech. Code eats energy whenever it moves and takes up space when it rests. Paying attention to how fun shapes the movement of code and organization of the Ubuntu labor process also led me to the commons and back to the gift, eventually making clear that Ubuntu has its origins in capital seeking a new geography to both keep capital in motion and to fix capital to the environment in some manner; in other words, in capital seeking a spatial fix. This dissertation is also sometimes about Ubuntu itself, and hopefully offers a glimpse into how Ubuntu contributors’ whole and complex lives bring this labor process, this spatial fix, this commons, and all else that Ubuntu is and means, into the world. Through all of this, time matters dearly, as Ubuntu contributors make a different sort of time with their work and fun, in concert with the sorts of time enabled by code and the 12 structuring of work by the experiences of working with people across many time zones. There is an intense and palpable feeling of possibility sometimes found in the fun of this work. Fun unbinds us from machine time, it insists on a temporal rhythm based on the material at hand. Yet the temporal relations of fun also create conditions that obscure how our labor is immanently productive while we are having fun; for when our fun produces something of value that enters the commons, and it happens to be digital, it is especially susceptible to being put to work by capital (how this works is discussed in detail in Chapter Three). Fun obscures its effects in our economic lives by appearing to somehow be outside of capitalism, or outside of economic matters all together. In the moment of having fun, say listing to or making music, having fun might also mean using our bodies to move value created by someone else’s labor into the realm of labor that is productive for capital. This happens because the fun of music can reproduce out capacity to work. This is hard to comprehend and sometimes disheartening to me because the act of making this connection through our bodies is often full of fun and joy, and the temporal relations of this act (caught up in some fun) is antithetical to capitalist temporal relations. This means that fun, in a very emotional, bodily manner, obscures how labor becomes productive though other workers’ bodies. Simply, we often want and need our fun to be about something other than the drudgery and meaninglessness of many the forms of work we face. And, contradictorily, it is precisely because fun is outside the temporality of capital that our fun is such an effective conduit for the movement of value into productive labor (that labor which is made productive for capital and produces surplus value). Fun is a 13 method for understanding these relations, and combined with thinking about productive labor, it helped me make some sense of the Ubuntu labor process. That is, although this dissertation focuses on fun, fun is often on the sidelines, as I use fun as method to understand what is at stake in our work of making and exchanging things of value. What follows is a story about the Ubuntu labor process, and thus is and is not about technology. It is about technology in the sense that it is a story about the development of information and communication technology and thus I seek to always have a grounded, material understanding of the infrastructure, labor, and knowledges required for this technology to operate. Yet, it is not about technology in the sense that it is a story of people and relationships, and I tell this story in order to develop a way to understand the context and significance of these relationships. I have been inspired by ethnographies of FLOSS (Kelty 2005, 2008; Coleman 2005; Ratto 2005; Lloyd 2007; Coleman and Golub 2008), but this project is not exactly an ethnography, although I deploy ethnographic methods. This is not to undermine my work, but rather to recognize the difference between using ethnographic methods and being ethnographic. 8 The work of trying to be an ethnographer was as not fun as it was fun. Very often it felt terrible, trying to figure out how to follow something that seemed important and missing it and failing on repeat. There was much more that was to be accomplished with this project, and much that got left behind. The questions and topics below that got left behind are largely the result of an ethnographic research project that was open-ended by 8 The term that I secretly use for my type of ethnographic work is “half-ass-nography.” This is not to insult my work or other similar work that may be well described by this term. Rather, in moments of inhabiting ethnographer—for instance, while working to promote Ubuntu as part of a team at a FLOSS convention—I developed an immense respect for the hard and emotionally draining work of ethnographic research which requires that I not call my work an ethnography. Or, more simply, I use some ethnographic methods, but this is not a thorough and deeply embedded ethnographic work. 14 design—my goal was always to try to “think from FLOSS”—and as with any research project, this meant making choices as the research unfolded in unexpected directions. Questions Left Behind As Ernest Mandel points out in his introduction to the popular Penguin edition of Capital Volume I, “the content of the economic institution of private capital is therefore the independent firm (whether a small manufacturer or a giant multi-national corporation),” (Marx 1993, 58). While this is still true, in the context of Ubuntu, what other economic institutions are at play, or are in formation and what are their relationships to capital? I ignored questions like these, questions that would have required naming things. In large part, this was to resist letting naming something stand in for analysis, to not give myself any more crutches to stand with, to force explanation. But also, because the firm, even as it has changed, is still as Mandel describes. As different as Canonical may seem—I heard dozens of times “there are really not any corporations like us”—Canonical is still bound by the force of the legal and social apparatuses of the firm. Yet I did not develop any categories or names that provide take- away bits to describe or represent what is different about Canonical, about Ubuntu, about FLOSS, or even about this negotiation between capitalism and the commons. Some other important questions that never quite found their way into the finished work are worth mentioning from the outset. This question from Adrian MacKenzie moved around a lot, and never quite found a home: 15 ... given the many ways, sites and levels at which performativity works, and the problems of class, race, gender and sexuality for which the concepts of performativity have been most often used, how does an object like Linux participate in power (MacKenzie 2006, 75)? The “problems” of class, race, gender, and sexuality stand in all too well for a logic of the problem of difference, a logic that common-place understandings of code are constantly referencing. Mackenzie positions Linux as being “unable to overcome limitations in regard to gender” as evidenced by nearly all of the Linux kernel coders being male (Mackenzie 2006: 90). What, exactly, does it mean to “overcome limitations” here? Is the problem solved simply when others, in this case women, are included in discourse? Or, reading Mackenzie more generously, is this a call for an understanding of how FLOSS projects, which are by most estimates 91-97% male, produce masculinist work environments or imagine certain problems to be outside of the realm of software—a problem which might not be overcome by inclusion? Wendy Hui Kyong Chun offers some insights into how the “problem” of difference has worked in relation to software: in the 1990s the internet was almost always represented as some sort of online “market” that would eradicate markers of difference and thus discrimination, as if discrimination emerged from markers of difference. The internet was a place that “supposedly relieves them of their problem, of their flesh that races, genders, ages and handicaps them, of their body from which they usually cannot escape” (Chun 2006, 133). This understanding of difference as a problem to be solved by “free-markets” rests upon the belief that certain people—different bodies for different times and fears—are not allowed to, cannot, or will not, properly submit themselves to the disciplining of the internet, this “technology of freedom” (as it is called 16 by Manuel Castells and Lawrence Lessig (Castells 2001b; Lessig 2004)). It is also these very race and gender differences that are used to justify exploitative “flexible” labor relationships for code and hardware production around the globe (Chun 2006, 73; Schiller 1999; Brenner 2002). We thus have a “cybernetic dream based on a technology [the internet] that perpetuates master-and-slave relations, that reduces freedom to control, language to programs and commands” (Chun 2006, 297). This is part of how Linux “participates in power:” dominant ideologies in FLOSS, such as a pervasive belief that FLOSS is a meritocracy, align with beliefs in the liberatory power technology that naturalize inequality. It is thus crucial to address what Chun calls the extramedial work of code, not to get to a further truth of code, but to understand how both hopes and fears of what will be wrought by the increased use of software may be caught up in the same system of representing and (re)producing difference. The question that must follow (and must wait for later work) is what possible relationship to code does not fall into this logic of difference, and might it be located in some practice or condition of FLOSS production? Herman Gray asks questions about the racial logic of technologies, which informed this work in a far more minor manner than the question deserves, especially as such questions has been stuck in my head for quite some time. At a conference, after listening to Gray speak, I had the chance to participate in a small group discussion with academics and technologists and to ask what folk thought those logics might be, and how they work. The first answer was that if you use a technology, you might see a picture of a white person on the screen, instead of black person. Someone responded, arguing that 17 no, it is more about how different people code differently, like how Japanese people code differently and how aboriginal folk code differently. Another person said no, this logic is about western-, euro-, bourgeoisie- centricism, and that this is what is prioritized and written through digital technologies. These were not the answers I expected, for these responses each seemed as if they might be representative of the racial logics of the digital age, rather than analyzing or explicating such logics—yet I do not have a ready answer either. There might be a racial logic that is part of how the technologies we use produce the assertion that only certain folk can properly submit themselves to the workings of digital technology and the corresponding rules and laws of using or making things with technology. That is, there is a way that digital technologies are created, exchanged, and used that is about producing proper citizens, and delimiting not just who has access to technology, but what people should become via the use of technology. Several times, I wrote something akin to: I take seriously Tara McPherson’s call for “understanding race as key to parsing the politics of the digital, as a root structure, a ghost in the machine, that cannot be added after the fact of analysis.” 9 Perhaps because this project was not about the politics of the digital, or because it did not directly engage with the consumption and “end user” use of technologies, all three of these questions left behind—What is the racial logic of the digital age? How do the politics of inclusion inform the organization of digital labor processes? How does race shape the politics of the digital age?—are underdeveloped in what follows. My hope is that the analysis that follows of code, the digital, work, fun, and capitalism will enable me to seriously 9 McPherson, Tara. August 25, 2006. “Conversation with Guillermo Gomez Pena” at SECT III: TechnoSpheres/FutureS of Thinking. Irvine, CA. 18 consider these question in future work, and that this project might provide a small part of a framework for others interested in related questions and issues. My initial research focused on gender in Ubuntu and FLOSS, but that focus and analysis never found a meaningful chapter-based home in the dissertation. I found most discussions of gender to be framed in terms of the inclusion / exclusion of women as above, but there were also significant critiques of the inclusion thesis from FLOSS folk— arguments that decried “whinging” about the the underrepresentation of women in FLOSS instead of focusing on “winning” (i.e. “FLOSS domination”). Such arguments focused on thinking about organizing women to be part of FLOSS as being essential to winning and seeing an end to a masculinist culture of computing and FLOSS domination as being one and the same goal. Nonetheless, any significant analysis of the different ways that the underrepresentation of women is addressed in FLOSS and Ubuntu or a detailed analysis of gender formation got left out. In the middle of the writing process I was struck by what a mistake it was not to talk to more with people who support the office. This means not only the administrative assistants at Canonical’s offices, but also those who support home offices. I could have learned a great deal talking to spouses, parents, partners, roommates, and others who end up supporting the home office. The form of labor that is most absent from this study (in terms of who I spoke with, whose voices I listened to) is the labor of those who support home offices. My project is about coders and those who produce Ubuntu, but for how I am thinking about the labor process, it is essential to acknowledge that I made choices that meant not meaningfully including the labor of household reproduction, of the 19 subcontracted janitorial staff in the offices, of assembly line workers making circuit boards, of support staff in data centers, and certainly more people and their work who play important roles in the Ubuntu labor process. This was in part an unintended side-affect of not getting as much access to Ubuntu contributors homes as I would have liked. In hindsight this was because of the way I selected interviewees—getting to know folk via the California LoCo who were happy to talk with me at LoCo events, meeting people at conferences who were willing to sit down for an interview at or near the conference, and visiting people at Canonical’s office who were happy to be interviewed in the office. Otherwise I ended up meeting somewhat skeptical Ubuntu contributors at bars and coffee shops, and I only ending up actually conducting interviews in two Ubuntu contributor’s home work spaces. As might be obvious, permission to watch someone work at their home is a significantly larger ask than an interview in a public place. Another side-affect of this interviewee collection method is that aside from the California LoCo members, most of my interviewees were either current or former Canonical employees, and my dissertation ended up being more about Canonical than I originally intended. This means the voices on non-Canonical Ubuntu contributors are quieter in this work than they likely should be. This was also a process of understanding a firm—Canonical turned out to be far more complex of an entity than I imagined. Canonical may appear, in many instances, to act in a manner that would alienate FLOSS supporters—it develops un-free software, and has many employees who work on projects that do not directly benefit Ubuntu development. Ubuntu community members have faith that Canonical will act well and in 20 their interest—this faith is both tenuous and strong. Aside from the reasoning that Canonical is, after all, a firm, and must do what it can to try to be profitable, there is a larger faith based in a very solid infrastructural backbone: if Canonical ever acted in a manner deemed unacceptable by large numbers, all code could be forked, the community could direct its efforts elsewhere and fully outside of Canonical’s interests. It is this knowledge that caused Ubuntu contributors (Canonical and not) to laugh at my question: “is there anything Canonical could do that would make you not want to contribute to Ubuntu?” This is the wrong question, even if Ubuntu fails at everything, what is produced by FLOSS production—people who believe in FLOSS—will pick up the dead labor, fork the code, and try again. A better question would have been a more open: “what would cause you not to contribute to Ubuntu anymore?” This is a small example of a larger issue that led to many things getting left out—especially in the beginning of my interviews I asked questions that were too focused and not open enough (or open in the right directions), even though open ended questions were my goal. There is much more that got left out because of this and other more practical reasons—for instance, the siting of Canonical offices never made it in, I ended up with a “cast of characters” much smaller than I imagined, and many interviews that I was once certain were essential are not mentioned at all—but this is the nature of research and making choices. In what follows, I begin with Chapter Zero, “Breathing Life into 0s and 1s,” with a short literature review of scholarship on FLOSS in order to provide a bit of history about FLOSS, computing, and the internet, and then I examine a few of the stories told about FLOSS in both this literature and in FLOSS social worlds, with an eye out for 21 relationships of dependency that might be obscured by the usual telling of these stories. Next, I turn my focus back to code in Chapter One, “The Material World of Code,” in order to establish the “dual nature” of code; as code is both something like instructions, and also as a moving, material, and machine-like thing. Chapter Two, “Fun at Work,” develops a theory of fun as method for bringing focus to how work proceeds how qualitative experiences shape the organization of work. Chapter Three, “A Spatial Fix and Ubuntu Economics” takes the theory developed in the previous two chapters and returns to gifts, the commons, and capitalism in order to develop an understanding of how the particular form of working with code in Ubuntu makes for an appealing, yet fraught and uneasy, “spatial fix” for capital. Finally, I conclude with a short statement about the broader stakes of the work. But first, a little bit about how I came to know about some aspects of the Ubuntu labor process and the lives of a few of the tens of thousands of people involved with Ubuntu. 22 Chapter Zero: Breathing Life into 0s and 1s: Origins and Value I came here this early for a panel called “politics of open source” at 8 a.m. There is no such panel, nothing even starts until 9 a.m. So tired. And now my laptop won’t boot to Ubuntu. I just had to boot to Windows and I’m trying to hide my screen. (field notes, 7:50 a.m., 3/8/08) On the first day of fieldwork at my first FLOSS convention waiting in line for a free lunch sponsored by Google I met David, 10 a member of the California Local Community Team (LoCo Team). 11 David was wearing a semi-official looking Ubuntu badge, so we started chatting about Ubuntu and why we were spending a Friday in a hotel conference center near Los Angeles International Airport. As a member of the LoCo team, David’s primarily contribution to Ubuntu is promotion and public speaking, although he does write some code. He seemed as excited to be there as I was nervous. We told stories of how we first encountered free software—I explained that I wanted to build a Tivo-like device in 2002 and failed miserably trying to get MythTV (a FLOSS digital video recorder) to run on Debian. 12 I then tried other Linux distributions such as Mandrake and Knoppix, only getting the machine I had built to work years later with 10 A pseudonym. Surprisingly, almost every contributor gave me permission to use their real names, however, I have changed all Ubuntu contributors’ names, except for those who gave express permission to use their real name and who have very public roles in the Ubuntu community that made changing their names moot. 11 At this time, the team was primarily Southern California based (like David, who lives in Orange County) and the team was only a year old. Its geography and member ship would change in coming years. 23 Ubuntu. My utter failure provided a surprising amount of credibility and a half dozen times it established me as some sort of an insider; or at the least, someone who had a sincere interest in the technology. David struck me as a very sincere true-believer in Ubuntu and he turned out to be an invaluable key informant who had a great impact on my research process. Being able to use his technical knowledge and enthusiasm to give what he refers to as “the gift of Ubuntu” to his family, friends, and strangers means a great deal to David and it is evident in his voice and visible excitement with which he talks about Ubuntu and free software. I. Who is Ubuntu? Several months later David and I met in Culver City (a western Los Angeles county city home to many movie studies) for an interview at a coffee shop near a technology firm where he had a temporary contract setting up new computers and installing software. He occasionally uses Ubuntu or other FLOSS tools in his work on his own initiative, but has never been paid to work with or develop FLOSS in any capacity. Nonetheless he has a set of relationships with Ubuntu, mediated through Ubuntu’s relationship to Canonical, the private firm that sponsors Ubuntu’s development: I’m a member of the Ubuntu community, of the Ubuntu project ... so, my formal relationship with Canonical is that I’ve signed a code of conduct saying that whenever I’m a representative of Ubuntu I’m going to act a certain way and be excellent to everyone. And that more or less sums it up. 12 Ubuntu is an off-shoot (or in proper terms, a derivative) of the Debian Project (another GNU/Linux distribution) and depends heavily upon past and future labor by Debian developers. How the Ubuntu community does and should “give back” to Debian and other projects upon which its successes depend has been a source of conflict and debate with the Ubuntu community and the wider FLOSS ecosystem. 24 David identifies that his formal relationship to Ubuntu, initiated by signing Ubuntu’s primary governance document the “Ubuntu Code of Conduct,” links him to Canonical in some manner (See Appendix A for the full Ubuntu Code of Conduct). Canonical is a private firm incorporated on the tax haven of the Isle of Man, although its “headquarters” are located in London, which a “Corporate Services” office in Montreal, and hardware integration offices in Lexington, Massachusetts and Taipei (with two other offices opening during the course of my writing in Shanghai, China, and São Paulo, Brazil). “Headquarters” remains in quotes because the vast majority of Canonical’s approximately four hundred employees work from home, while the London office primarily houses human resources, system administration, and managerial staff. The nature of this relationship between Ubuntu and Canonical—especially what constitutes an “official” Ubuntu policy, such as “official” communications channels or other sorts of policies—is a topic of ongoing confusion and uncertainty amongst many Ubuntu contributors. This is primarily due to the fact that, for instance, there is no “official” policy or procedure for creating an Ubuntu communication channel, even when using a service hosted or supported by Canonical. 13 People who want to contribute to Ubuntu, myself included, often end up looking for formal policies that simply do not exist. I eventually signed the Code of Conduct, created a profile for myself in the collaborative development platform hosted by Canonical and joined the California LoCo Team. Becoming part of the team meant “showing up” at online meetings, going to “bug jams” and other in-person events in Southern California, and attending FLOSS conventions and working at an Ubuntu booth 13 Although Canonical can and has shut down some channels at management’s discretion. 25 as a representative of the Ubuntu community. David helped me navigate much of this process and his advice on how to join the LoCo team was a refrain I would hear dozens of times at conferences, in online meetings and in email list serves: “if you want to become part of Ubuntu, just do something … no one gives you permission.” This mantra is based in a belief in meritocracy that is pervasive in Ubuntu and in FLOSS in general—although there are varying barriers to entry in FLOSS projects, some of which have very explicit sets of permissions, and some of which, like Ubuntu, have sets of permissions that are informal or only exist for certain types of contributions. David identifies himself as part of the Ubuntu community, which comprises various overlapping and coexisting forms of social and technical relationships (full of friendships, temporary collaborations, bosses, feuds, celebrities, leaders, camaraderie, antagonisms, etc.). A good part of the challenge of this dissertation is how to represent this complexity. I am interested in how anthropology scholars such as Dorinne Kondo represent complexity—Kondo uses “vignettes” throughout her book Crafting Selves to insist upon experience and theory as part of the same process of understanding; complicating the “setting trope” that usually renders the author (and also the reader) in a world once strange, and then, comprehensible and knowable. In order to deal with the technical world of Ubuntu, there is a fair amount exactly this sort of explanatory narrative in what follows, but I hope to also convey the unknowable and complex nature of the interplay between people’s lives and their work with Ubuntu. To do so, I occasionally use detailed description of places, events, and daily rhythms to insist upon their complexity, rather than the mastery of knowledge through observation (see also, Traweek 26 1988; Martin 1994). I feel more overwhelmed by the scope of Ubuntu then when I began this project and recognize that I know only small portions of the labor process—three years of following email list serves, online meetings, and monitoring Ubuntu news and public web discourse; attending and participating in six FLOSS conferences (working at two) and attending a week-long Ubuntu Developer Summit; conducting twenty-four informal interviews with various Ubuntu contributors; observing work at Canonical offices in Taiwan, Montreal and London; learning to use Ubuntu, submit bug reports, and learning the basics of the Java and Python programming languages; and along the way almost accidentally becoming an Ubuntu advocate and installing or helping install Ubuntu on about fifteen different friends’ or acquaintances’ computers all confirmed the overwhelming complexity of this project, especially as I got to know more about how people’s whole lives, including mine, are affected and shaped by working with Ubuntu. Anthropology and anthropology-inspired scholars have well explored how identities are formed via work—as Kondo argues “work and personhood are inextricable from each other” (Kondo 1990, 45; Kelty 2005; G. Coleman 2005; Shields 1996; Plant 1997; Wakeford 1999b; Nakamura 2002; Chun 2006). While the above scholarship focuses on the personhood side, my dissertation privileges the work side of things, and does not talk much about personhood or subjectivity. The story of work I tell is also a story of a set of struggles to figure out what to do with surplus. Capital itself is the primary surplus at hand, but there are also surpluses of code and coders—all of which develop in the context of computer hardware and software production which is consistently, and I believe accurately, described as being in a state of frequent “crisis” and 27 “revolution” by trade and technology press and media. These often hyperbolic discussions of the computing devices such as phones, tablets, netbooks, or platforms such as “cloud computing” represent actual crisis and instability in the organization of labor and infrastructure. Such crisis and struggle, as Ruth Wilson Gilmore reminds us, are neither objectively good or bad or with any particular political implications, but rather part of the reality that “we make places, things, and selves, but not under conditions of our own choosing” (Gilmore 2007, 54, 242). Thus I am interested in how the “worker- consumer who has to work to buy and buy to work is central to this drama,” (Gilmore 2007, 56) and my research is driven and organized to understand the nexus between the particular organization of work in Ubuntu and capitalist space. The ways in which I am “insider” and “outsider” to the Ubuntu labor process was both an asset and a challenge in my research—it opened up conversations but occasionally I had to remind myself to get back in researcher mode and stop geeking out, or had to fight the depressing feeling of being a useless researcher surrounded by people actually struggling to make the world as they dreamed it could be. Nonetheless, these experiences of disjointedness, uncertainty, depression, and being unable to express why or what I was doing turned out to be enlightening and key moments in research. Conveniently, these moments turn out to have a name: “visceral learning.” Emily Martin argues that “most of what anthropologists learn is gained precisely through these kinds of nonlinguistic, felt experiences, not through the answers to verbal questions put directly to people” (Martin 1994, xv). Thus even in the moment of learning something from David about how the relationship between Ubuntu and Canonical functions, I learned as much 28 from how he appeared to feel about what he was talking about, from the tenor of his voice, or from the quality of a shared laugh. Obviously all of this is filtered through my own emotional state and perceptions (and certainly some misconceptions), but as the experience of work is primary in my research, I choose to often focus on this sort of knowledge and put some trust in it. Community or Canonical? “Community” is used by David and others who contribute to Ubuntu to describe themselves—and it is a heartfelt term for many. Community is often defined against Canonical, in many contexts “Canonical or community?” is a question used to ascertain the genesis of an idea, some code, or another form of good or knowledge. Community certainly means many things in Ubuntu, but when used as a descriptor it also means “not of or from Canonical.” So although Ubuntu is described as a “community distribution” and people involved use community to describe themselves, it is not easy to describe the organization of Ubuntu as a community or as a firm, movement, or volunteer organization. Ubuntu has grown from a group of twelve high-profile FLOSS coders working on an unnamed project into a highly complex network of tens of thousands of professional and semi-professional programmers and other Ubuntu enthusiasts—only a tiny fraction of whom are directly paid for their work. The difficulty in describing Ubuntu extends out of this complicated relationship between paid Canonical employees who work on Ubuntu and the wide variety of volunteer contributors—as David describes it “Ubuntu is sort of independent.” 29 The “sort of independent” nature of Ubuntu is indicative of a general form of organization of groups that come into being via internet-based communication technologies. In a comparative study of a variety of such groups Adam Fish et al point out there is always a relationship between some sort of “formal social enterprise” (FSE) and an “organized public” (OP) (Fish et al. 2011). What David calls “community” is an organized public—not “the public,” but with a relatively open boundary with the public, while Canonical is a formal social enterprise—there are significant barriers to becoming part of Canonical and members are bound by a set of legal and extralegal contractual obligations that constitute employment. The FSE/OP concept does an excellent job at providing inter-disciplinary language for talking about the formation of groups and their actions. For instance, looking to the history of Ubuntu, an OP existed prior to Canonical. All founding members of Canonical were contributors to the Debian Project, and with the funding and guidance of Mark Shuttleworth, the multi-millionaire founder of Ubuntu, Canonical became a FSE and sought explicitly to organize a public, which became the Ubuntu “community.” Unfortunately the FSE/OP concepts takes capitalism as a natural and unspoken feature of the FSE/OP relationship and fails to notice that the FSE/OP relationship could perhaps be best described as an emerging form of capitalism in which capital is increasingly dependent upon the value produced by organized publics (the commons). This is not to say that capital determines organized publics or that organized publics are always commons, but that the conditions of organizing to do something useful (of value) is constrained by conditions in which capital owns the means of producing the public (the internet). At the same time capital(ists) are well aware that they cannot 30 control a public that is not dependent upon the wage relation to make something of value, especially when the way of organizing to make that thing erodes the natural-ness of private property. Making Ubuntu a “true community distribution,” as it is often described, where the vectors of development are supposed to be led by the community, depends upon the labor of people like David who believe in FLOSS: I do have a copy [of Windows] for free, my laptop came with it and I don’t use it, basically, it’s worthless to me. There is no value in that for me. Because with free software when I contribute to free software whether through advocacy, or any bug fixes or bug reports, that makes that software better for everyone in the world who wants to use that software. And so that’s something where I can be very proud to tell my kids that I’ve been working on something that is a gift to all of humanity, to the world. There is a common belief and pride amongst Ubuntu contributors that Ubuntu, or FLOSS in general, is going to make the world better. Imaginaries of how this will happen vary, from improving elementary education to enabling technological independence in developing countries to helping keep money in local economies. Interestingly, none of the Ubuntu contributors I talked to said that Ubuntu or FLOSS would make the world better because either is better technology. Thus making world better, whatever that may mean to individual contributors, is not just about FLOSS being used to do something, but about the process by which things of value are produced exchanged in FLOSS development and FLOSS use. 31 Community Management Jono 14 , who works for Canonical as Ubuntu’s “Community Manager,” describes one way in which labor is organized by fun. Jono discusses how it feels to make the transition from volunteering his time to paid laborer: Yeah, there’s a lot in there … balance that you have, defining your own balance … the big thing for a lot of people is when your hobby becomes your job. That’s weird. Canonical is much more in line with what I do as a hobby. What I do as the Ubuntu community manager is exactly what I did in my spare time, but it wasn’t for Ubuntu. FLOSS coder and advocate Stormy Peters describes the transition in Jono’s life as part of the invention of an “old new job:” a job that people have been doing as long as FLOSS has been around, interfacing between firms and other entities that nominally “control” a code base and a group of “users” who want to contribute patches or other changes to improve that code base. But now this old job has become a paid position in a firm. The community manager has become the official interface between a firm and contributors, sometimes playing a role akin to a Public Relations representative, other times serving as an advocate for those outside the firm. Many FLOSS projects backed by a firm (for profit or not) have community managers, and as Stormy points out, around 50% are women, while only 2%-7% of FLOSS contributors are women. 15 Like Jono, Stormy 14 Jono gave express permission to use his real name, in part because of his very public role in the Ubuntu community as “Community Manager” makes anonymity nigh impossible, and also because he understands his role in the Ubuntu community to require a great deal of transparency about his work and ethos. 15 Peters and other participants in the Southern California Linux Expo’s (SCaLE) Women in Open Source track attribute this over-representation to women getting promoted out of “tech” centered jobs and into “people” centered jobs. 32 discusses her work—in this case in a presentation at a FLOSS convention—as existing in a blurry zone wherein “I might be online for 22 hours a day and I don’t know if I’m really working or having fun.” FLOSS managers like Jono and Stormy spend a lot of time thinking and talking about why some FLOSS communities work and others do not—and the theme of fun pops up again and again. Stormy defines a major part of her job as “explaining to managers that there are a bunch of people who write software because it’s fun,” while Jono, who has developed many metrics to measure community contributions to Ubuntu, talks about the challenge of creating “rules to control the fun” that do not feel like control or bureaucracy. I first heard of Jono and position of community manager at a party with some former Canonical employees and a handful of various FLOSS coders and advocates. Jono was chided for being a “cheerleader” and his frequent blog posts, emails, and other announcements that end with “lets make Ubuntu rock!” Later I met Jono via an email introduction and interacted with him briefly via IRC. 16 This interaction was the moment I first switched from being a “lurker” 17 in an IRC channel and participated by asking a 16 Internet Relay Chat (IRC) is a text-based real time collaboration tool used as a “meeting room” for almost all Ubuntu meetings, as a “classroom” for teaching and a “chat room” for daily collaboration within teams. It was a challenge for me to learn how to use IRC software, leading to many awkward moments lurking in an IRC channel unsure about the meaning of abbreviations or how to ask a question or make a comment. Even in face-to-face events, IRC is nearly always present on laptops, for instance, connecting participants at a convention to each other and to those who could not attend. 17 Lurking is key to learning, such as in the below when “Kangarooo” is scolded in an Ubuntu IRC channel for not following proper etiquette: (10:09:55 AM) tgm4883: Kangarooo, you should prefix your question with QUESTION: (10:11:07 AM) Kangarooo: and then what’s gonna happen? im guesing bot gonna log it somewhere? ok did understand.. - I’ve read all wiki page aobut ubuntu open week what’s wrong again? 33 question during “Open Week,” a week-long online event aimed at new or curious contributors during which various Ubuntu folk talked about how Ubuntu works and answered questions (see Appendix B for the announcement and schedule). About 300 people were logged into two IRC channels, one for discussion and asking questions and the other for the “speaker.” A moderator copied questions from the discussion channel into the “speaker” channel for the presenter to see and respond to. Reading back over my notes from that day my intense discomfort with an unfamiliar mode of communication comes reeling back: I actually asked a question, it freaked me out to do so, my heartrate went up, I was all nervous. It was not a good question, but someone did try to follow it up with a question about what I actually cared about: how will canonical support conventions? ... but it was unanswered. Someone else following up made me feel better (field notes, 4/30/2008). The actual question I asked is embarrassingly academic, and reflects my primary curiosity at the time: [17:46] <jcastro> < jake_peters> QUESTION: Jono, seems like you attend many conventions, how do these off-line events matter for the community and as the community grows, do you think the role face-to-face interaction will change? [17:47] <jono> jake_peters: I think face-to-face conferences have their place - much of it for me is being there to speak face-to-face with specific groups, but naturally confs are very time consuming and expensive, so I try to limit them where possible (and still end up travelling all the time!) (10:11:54 AM) zaidka: Kangaroo you’re killing me (10:12:00 AM) tgm4883: Kangarooo, when you do that, the presenter (or presenters helper) can post relevant questions in the other channel for answeringand here is the "who to" that came out after insulting Kangaroo’s mother for drinking while he was unborn (10:19:49 AM) zaidka: Kangaroo, well that explains it then (10:24:48 AM) gregknicholson: howto: join in with a conversation (Kangarooo take note): Step 1: Lurk. Figure out what’s going on. Step 2: *Then* join in with something insightful, using what you’ve learnt by lurking. Step 3: Don’t attract too much attention. Never do more than ⅔ of the talking. 34 [17:47] <jono> I think as the community grows the number of confs will grow, and we will see less of the same people visiting every conf (#ubuntu-classroom, 8/03/08 logged by author) Fittingly, after these first meetings I ran into Jono in person at two conferences before scheduling an interview and sitting down with him for two hours at a third. Today, three yeas later, Jono has actually cut back from running “the conference circuit” as many call it—and as Jono mentioned above, after my third FLOSS conference I started running into the same people, seeing familiar faces, and hearing familiar conversations. Back at SCaLE 2008, my first “field site,” Jono appears in my field notes before I understood his job: 8:50 p.m. The Westin is full of Linux folk—Jono Bacon has been hanging out at the hotel bar with various groups of folk for the last two hours ... I don’t quite know how to approach social life here, if I should have stayed with the Open Source Politics birds-of-a-feather (BoF) group and get involved because I do care; but that wouldn’t help my research. I’d like to be at the bar, talking shit with these folk, but I’m not very comfortable in this researcher role. People are drifting in and out in small groups, twos and threes for the most part. Up to rooms or out of front door as I sit in the lobby. There is something shared here. You can feel it by the bar, in the BoF session, in the informal group of ten or so that sat in the couches by the escalators with five OLPC laptops, talking about who knows what. Many transactions reek of business deals—after all this an Expo. (field notes, 3/09/08) A year later, back at SCaLE, after having interviewed Jono and talked to him about fun a bit, at the beginning of a presentation he says that he frequently asks himself “how do we keep Ubuntu fun?” Right as I am scribbling down notes, I hear “where’s my friend who is writing a paper about how open source is fun?” Outed and pulled from the background of a group of fifty or so, Jono made me stand up and quickly introduce myself. Aside from freaking me out, it was heartening and validating to hear Ubuntu’s community manager talk about fun, but all this really told me was something that I was already pretty 35 sure about: FLOSS managers, leaders, advocates, and organizers talk a fair deal about fun and are convinced that fun is somehow key to how FLOSS works. At the same conference while working at the California LoCo Team’s booth— mostly just answering questions about Ubuntu—I ran into another community manger I had met at the previous SCaLE and in Portland at the Open Source Convention (OSCON). Aside from being a community manager, Cindy is also an organizer involved in many FLOSS and FLOSS-adjacent projects. We talked for a moment on the expo floor and after a pause in conversation she said “I’ve been using some of your ideas, you know.” No, I did not know and I could not really imagine what ideas I had that could be put to use: “No, what ideas?” “Fun, I’ve been using fun.” She had been telling folk that “hey, the reason we do this is because it’s fun, so let’s get together.” This has taken form through hacking events, weekly planning meet-ups that bring together coders with folk doing other (non-coding) work and seating people doing different tasks next to each other. Although this interaction might appear as a sort of dream test or proof for what I want to say about fun, it is not. These stories tell us how important it can be to talk about fun—like a coach before a game. Cindy and Jono’s work points towards the discursive power of fun, the story Cindy tells of trying to organize work in a manner that makes for more fun, that calls fun into being as something so much more than a motivation, makes clear that fun is used to organize work. Fun, when talked about in this manner—as something to be put to work—sidesteps motivation in favor of focusing on what is to be done. It was this small comment, “I’ve been using some of your ideas, you know,” that 36 made me realize that my discussion of fun should be framed by a phrase I jotted down that day: “fun is about how we do, not why we do.” This started to come together the next day of the conference, sitting in a session led by a community manager who never mentioned anything near fun, focusing instead of the structures of belonging and membership. This lack, of course, is no indication of whether or not people who contribute to that project were having fun. Ubuntu Practices, FLOSS Law I have seen Thierry, who has a management role on the Ubuntu Server Team, work in a wide variety of public capacities. Some of these are dictated by Canonical, such as giving talks at conferences, working at a Canonical booth on a conference floor, leading meetings, running public online meetings on IRC (i.e. “open week” and “developer week;” the latter is like “open week,” but for coders), and attending and leading discussions at the Ubuntu Developer Summit. Other work is closer to being “on his time,” such as working with the France LoCo team, writing some code that he finds interesting, or going out to pizza with the California LoCo team after a convention— although I find it difficult to sort out work done for Ubuntu from work done as part of his job for Canonical. But this public life is only a small part of Thierry’s work; he primarily works from home. Working from home without an office or the institutional and infrastructural support that comes with an office is not an easy adjustment—I found that Ubuntu contributors descriptions of this challenge resonated with my struggles to create work 37 space after I lost my office at my University and piled all my books into my bedroom. Canonical has an internal wiki with detailed suggestions and guidelines for working at home, as Tierry describes: ... dress up, take your shower before you work. That will put you in the working mindset. Actually I don’t follow this advice completely as I like to have my coffee before my shower while reading my email, so I do read my emails in pajamas, then go back, take my shower, and come back dressed to go to work. But that’s very important, a little ritual, little things like that. You need to educate your family. If you’ve got a wife and kids, you tell them, well, I’m working from home. Just because I’m home doesn’t mean I’ll be able to go bring you the shoes you’ve forgotten for your sport lesson, or go buy the little thing you forgot to buy the day before. It’s not as if you are unemployed at home, you’ve still got stuff to do. When I close the door on my office, that doesn’t mean I don’t want to see you, that just means that I’m doing something that requires enough concentration that I cannot afford being interrupted. The first few, ah, weeks, it’s some kind of adjustment. I know of a few people who never adjusted and actually decided to leave Canonical because they just realized that they were just not meant to be working from home. For me it worked out. This common set of practices of working from home for Canonical employees, loosely codified in a “best practices” wiki, ties workers together. Every Canonical employee I talked to who works or worked from home discussed a number of difficulties, ranging from finding office space within the physical constraints of their living space to long term conflicts with spouses and partners. But like Thierry, for most it works out, and the time and space of working from home becomes a key part in enabling the fun that Ubuntu contributors have working with code. Teams like Thierry’s consist of employees in France, Germany, the US, Canada, and elsewhere and part of the daily ritual is checking with the group over IRC as each member’s core hours begin and meeting as a group when core hours overlap. 38 Thierry has come to enjoy this mode of working, and some of the freedom it affords his home life, but he locates his reasons for doing this work elsewhere: I always wanted to do good for people. I don’t believe in any god, I believe in humans. If I can participate in our enhancement in anyway, that would be nice. That is what brought me to computer science, I thought that was one of the coolest tools that was given to humanity to enhance itself. I wanted to participate in that. Unfortunately, as I developed my business knowledge, I realized that most of the work that I was doing was, ah, not really doing much good to people, but doing a lot of good to capital. And with open source I was like, ‘Hey! There is a light!’ What is “the light” of FLOSS and how is it different from “making the world better?” FLOSS is most often defined by the rights or freedoms offered by the various licensing and legal frameworks deployed by FLOSS coders over the years as the legal and computing landscape changed and different material and organizational contexts created needs for different types of licenses. So what is “the light?” For some, such as Free Software Foundation founder Richard Stallman, the light is a glimpse at a different world: “in the long run, making programs free is a step toward the post-scarcity world, where nobody will have to work very hard just to make a living” (Stallman et al 2002, 39). For Thierry, the light is a dream of a more humane capitalism through which Thierry believes it is possible to produce an order that “puts the needs of people before the needs of capital.” For others the light is akin to a form of common sense that extends from technology—that FLOSS is the most sensible way of making software and thus software production should be organized in this manner in order to facilitate the creation of more and better software. In all of these visions, the terms of “the light” are manifest in the licenses by which FLOSS code is distributed, for these licenses enable things of value to go out into the world and meet people’s needs. 39 The politics of FLOSS licensing are very well discussed in existing literature, especially by computer scientists Samir Chopra and Scott D. Dexter in their aptly titled book Decoding Liberation: the Promise of Free and Open Source Software (see also Weber 2000; Coleman 2004; Kelty 2008). Nearly every article or book on FLOSS introduces the topic by framing FLOSS in terms of licenses that “combat” or “cleverly hack” intellectual propriety laws, for unlike property software, free software is licensed in a manner that guarantees certain freedoms for everyone, for the life of the software; namely, the freedom to reuse, re-purpose, redistribute, change, use, and share the software as anyone sees fit, as long as doing so does not encumber future access to the above freedoms. Exemplary of this framing of FLOSS, political scientist Steven Weber argues that FLOSS licenses are useful social contracts because they are appropriately skeptical of human nature—such licenses “force you to be free” (Weber 2006). In this vision of FLOSS licenses, the point of the license is to protect code against human nature, which, if left to its own devices, would mean that individuals would attempt to control code as private property. This common reading of licenses violently misplaces the nature of capitalism as extending naturally from the minds and actions of individuals. To reduce a human being to the imperatives of capitalism is a violent act and such a misplacement excuses the violence of capital as if it is an extension of human nature rather than a set of relations given the force of law via particular forms of the state. FLOSS licenses exist to require the refusal of private property, and to keep code in circulation in a manner that is useful for FLOSS coders. The imperative of property does not extend from human nature, but a set of rules codified in all aspects of the modern 40 state, and a system of production, exchange, and consumption through which the state as we know it came into being. Certainly the legal frameworks that enable FLOSS code to circulate in a system of exchange that moves in and out of the temporal rhythms and organization structures of capitalist exchange are essential to understanding FLOSS. These legal frameworks have specific histories and emerge out of varying needs of individuals, firms, and other organizational forms: the many different FLOSS licenses devised in the past twenty-seven years can be read to support a variety of arguments about the nature of FLOSS. I chose to set these histories aside, in part because they are well discussed, in part because I wish to frame FLOSS slightly differently and follow anthropologist Chris Kelty who defines FLOSS as a practice, rather than as a type of object or legal framework: “free software is a practice of working through the promises of equality, fairness, justice, reason, and argument in a domain of technically complex software and networks, and in a context of powerful, lopsided laws about intellectual property” (Kelty 2008, xi). Thus, I understand FLOSS licenses as a set of property relations (a form of practice) that displaces private ownership’s hold on access, sharing, and distribution with the public provision of access, sharing, and attribution rights that are enforced by various US-based licenses (a reminder that FLOSS is often entrenched within US law and narratives of US and/or Western exceptionalism). I am more concerned with how FLOSS practices work though these promises—or how “the light” that Tierry discusses takes form—in relatively mundane ways: First of all we are an atypically distributed company … there are not a lot of companies working on the same level of distribution that we are. All the time people are asking us, do you have offices here, do you have offices there, how many employees do you have in France, how many in the US. This doesn’t make 41 any sense for us. I’m the project manager, I work on the server. I work out of France, from my home. The technical lead for the Server Team works out of St. Louis [Missouri, US]. The guys working on the Server Team work in Canada, Germany, and many other countries. And we meet every day virtually. It’s a rule that instead of entering the office and saying hello to everyone, we join the IRC channel and we say hello to people. And our work hours, we don’t have actually very finite work hours, but we have what are called our core hours, which are the time at which people know that they can reach us. And during these core hours, if we are available, not at a conference for example [laughing, as we are at conference], we should be logged into IRC, the way that you would be sitting your desk if you were in a company. This is a part of the light for Thierry. The capacity to do this work, with people he likes and cares about—people who, as Canonical employees frequently mention, are the “most excellent” in their area of specialization. Such a working environ is not without its troubles, but it is the repetition of these mundane practices, such as saying hello to people via particular FLOSS technologies, that the Ubuntu labor process comes into being. It is this mundaneness, and the fun of such mundane practices, that is the focus of the following chapters. Computer Mode and IRC Defining FLOSS as a practice is a move to take FLOSS out of a narrative of progress. For in nearly all academic and popular literature, FLOSS is understood as a corrective that can somehow work to solve the problems of a flawed system—from copyright to capitalism—“the light!” FLOSS often becomes evidence of an emergent society based in openness, freedom, user innovation, transparency, and “mix,” “mash-up” or “make” culture (e.g. Castells 2001; Weber 2004; Benkler and Nissenbaum 2006). I focus on the practices of producing Ubuntu, and do not explicitly address Ubuntu’s use to 42 solve technical or social problems. However, because of the nature of code, it is impossible to analyze software production without talking about its use to solve social and technical problems. The production of software is, of course, itself a social and technical problem solved through the use of software. Ubuntu coders use Ubuntu to create Ubuntu and what they create offers a particular set of possibilities for solving the social and technical problems Ubuntu coders face in meeting their goals. The particular configurations of computing devices and software that Ubuntu coders use are highly personalized environments that coders modify to create an workplace that works for them. In the only academic study of Ubuntu, anthropologist Andreas Lloyd argues in his Anthropology masters thesis that hackers become part of a shared history and social world through the customization and use of Ubuntu (Lloyd 2007). However, this environment is not just the configuration of the operating system, but the hardware, office space, and the social world in which people and their computing devices are located. In Canonical’s Taipei office on the 46th floor of the Taipei 101 tower three kernel engineers share a pod, with their desk spaces separated by short dividers so that they can just see the tops of each other’s heads. While interviewing Nick, one of the three developers, in a conference room next door, he mentioned how he could never work with his deskmate’s setup. After the interview we walked over to look at the differences and as each developer explained his setup to me, the others laughed. These are not simply different hardware setups, but a mash of tweaked hardware and customized software that creates particular ways of managing self and altering time and space (even if it just is a 43 stack of books to raise a monitor or a “desktop” on a laptop full of files to help organize thoughts). The management of self via technical tools by coders is a hobby-like activity onto itself (for instance, see lifehacker.com). All three of these developers are “present” in around twenty IRC channels and have to manage and respond in a timely manner an incredibly high volume of IRC pings (whenever someone’s IRC nick(name) is entered in an IRC that user is notified in some manner) from fellow Canonical employees, their bosses, Ubuntu community members, folk who work on FLOSS hardware enablement, users looking for support or bug fixes, and more. Notably, Canonical’s clients who are seeking to enable their hardware on Ubuntu do not often communicate with Canonical employees via IRC, as the hardware companies are “outside” the FLOSS ecosystem and their employees are not often socialized in this particular FLOSS way of communicating. Different channels get priority at certain times and folk get to know each other’s availability—Canonical employees are highly encouraged to be in certain relevant internal (private) and external (public) IRC channels during their core hours (prioritizing the internal channel); outside of core hours each of these three reside in channels related to FLOSS (both in Ubuntu channels and channels for other FLOSS projects); and after or before their core hours they will prioritize or catch up with pings from those channels. Reside is not an accidental word above, for it is in these channels, during particular times, that each coder is known to not just be present, but to take up residence, in any one of numerous roles. IRC allows other parts of life to go on during meetings, and moments such as the following are not uncommon: “[16:34] <ScottK> Groceries 44 have arrived, so I need to run off for a bit.” Bots—independent programs that perform automated duties—control much of IRC, as in below where the topic of the channel is changed, reminding folk that another meeting is about to start: [16:58] <yann2> right, I am glad someone put the topic up before me :) where could I contact them? === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Kernel Team Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 06 Jan 21:00: Community Council | 07 Jan 03:00: America’s Council | 07 Jan 16:00: Foundation Team | 07 Jan 17:00: QA Team [16:58] <mathiaz> yann2: right. So I’ll defer this discussion to the next meeting as we’re running out of time [16:58] <yann2> np And this volume of communication is not necessarily a subject of complaint or inconvenience, but simply something that must be managed effectively to get the work at hand accomplished and to maintain meaningful relationships with friends, colleagues, and strangers. Ed, the engineer with the setup that Nick could “never work with,” works on his large-ish laptop with an external keyboard and manages IRC with a graphical user interface (GUI). This is very rare amongst coders, who usually prefer the “power,” speed, and customizing possibilities of an application run in a text-based terminal (think the fast typing and cryptic commands following by a blinking cursor in nearly every hacking scene in a movie, such as Tron: Lecacy, in which the protagonist used a Linux- like operating system to take down a corporation and its proprietary evils). Ed’s explanation of his choices elicited friendly snickers from his co-workers, but he continued, explaining how he likes the desktop integration of the GUI and how it notifies him graphically in the corner of his monitor of any ping. The moment a ping appears, he 45 typically uses a keyboard command to bring up the IRC client and responds immediately and quickly, even if he is in the middle of coding. Ed might move back and forth between IRC and coding dozens of times in an hour, which works for him as he develops no IRC backlog. In contrast, next to him Dan has one monitor hooked up to a small laptop. The laptop’s built-in-monitor is dedicated to running “GNU Screen,” a highly customizable text based interface for managing multiple programs on different computers. GNU Screen connects Dan to his IRC server at home which he uses to log all of the IRC channels in which he participates. This way he is logged in all the time and can search for a missed thread of conversation someone references later, take a look at any pings he missed, or read discussions that took place while he was asleep or otherwise occupied. The external monitor hooked up to his laptop is for coding and other work and he moves between the two in discrete, but often short, blocks of time. Nick uses hardware to develop even more discrete work spaces and to create the sort of time in which he likes to work. He has four monitors on his desk, each with a specific task, all working together to be able to create was he calls “computer mode:” I prefer most of the time to work by myself, because I have to … well, you know, computer language is not a language for humans [laughing]. I have to turn myself into “computer mode.” I prefer to be here [the office] and have headphones and listen to music and things like that … [in] computer mode you only know the logic of the coding in the “C” language and you think 1 goes to 1 goes to 1 and when I have this function, I will have some change in the memory, or I will have something happen in my computer and I have to think about all that at once. (Me:) What do you have to do to get in that mode? A lot of coffee. [laughs] A lot of coffee … And I enter this mode and I can do 46 work for about two hours or three hours, maybe longer. But longer than that, it’s not efficient. In order to get in this mode Nick has a small laptop slightly to his left dedicated to IRC, other chat applications, and web browsing. Another laptop is solely for coding, which is hooked up to a large external monitor directly in front of his chair that runs a terminal at full screen so that all he can see is the text of the code he is working on and the blinking cursor. This is the monitor through which he enters “computer mode.” Off to his right side are a few other laptops and some diagnostic equipment. These laptops are the hardware that he is making sure work with the Linux kernel (and all three developers remind me that I cannot reveal which model or brand they are working on, thus no pictures). Nick clearly takes joy in being in “computer mode,” although he never calls it fun. This mode is about a relationship with time as well as code. Although Nick’s explanation of “computer mode” is very specific to his way of working, the need to remake time in order work on code is a shared by many, and somewhat surprisingly, is a key condition for making work fun. As Nick articulates, and as I return to in Chapter Two, “Fun at Work,” this capacity for fun is and is not about FLOSS—the essence of fun is in the material at hand, code, but FLOSS creates social relations and organizations of living and dead labor that enable a certain sort of fun in the mundane work of coding. When I commented that the way Nick was talking about making something work in Linux sounded like it made him want to work with open source software, he paused and corrected me: 47 Well, no, not actually, for open source software, the difference between closed is, ah, how can I say this? If I worked on open source or closed source, it doesn’t matter, I can still look at examples and make things work. If I work on open source, it might be easier to make it to my goal. Coding is coding, and when I make it work, I am happy, but open source will make the way shorter. II. FLOSS, it is Good to Think With FLOSS is good to think with because it challenges numerous assumptions about how people come to work together and make something of value as well as how that thing of value circulates and is controlled. And, as with most complex social worlds, it is easy to find whatever you want in FLOSS. I am writing this dissertation because six years ago I was staring out a window on a familiar Greyhound bus ride between Minneapolis and Duluth, Minnesota and open source software made sense as a concrete example of some ideas I was grappling with at the time. This turned out only to make sense because my ignorance allowed me to use FLOSS to think about ownership. I had been using Linux for a few years, most of the time only using FLOSS to find the limits of my technical knowledge and skills, not actually using it successfully to any purpose or end (although years later I would be quick to point out anyone who uses the internet uses FLOSS quite successfully). These failures at “open source,” the term of choice of the friend who introduced me to FLOSS, ended up becoming the same stories of my failures with FLOSS cited above that would give me entry into FLOSS communities. At the time, however, FLOSS was just a tool I did not have the skill to use which happened to provide a good example of un-ownership for a graduate seminar paper. 48 Later, trying to figure out how to write a dissertation proposal that critiqued Manuel Castell’s concept of the “network society” by using FLOSS, I was looking for case studies that captured different modes of FLOSS organization—particularly large and “mature” projects such as OpenOffice.org, Firefox, and Ubuntu that had gone through changes in types of governance, had different relationships to private or publicly help firms and non-profits, and had struggles with membership or belonging. 18 Many typologies of FLOSS are used by scholars, each with its own purpose. Indicative of computer scientists and other scholars who focus on the software development process itself (including its social worlds and enabling conditions), Warren Scacchi has identified common traits of FLOSS organizations and then studied topic groupings, such as “internet/Web Infrastructure” (Scacchi 2002, 2006). Social scientists concerned with motivation, group formation, decision making and authority, such as the work of Didier Demazière et al tend to create groupings based on some understanding of organization modes. Demazière et al propose four typologies based in how a FLOSS project is formed: 1) projects in which there is “monopolization of the decision-making process by one person;” 2) projects founded by “a group characterized by personal relations of people that share common experience;” 3) an organization around a “central institution … that initiates the project, allocates capital, manages its development;” and 4) the “case of larger, more widespread and heterogeneous groups that have modified their 18 It is important to note that the vast majority of FLOSS projects are short lived and only have one or two contributors even though scholars, understandably, tend to focus on mature, large projects. Yet, taken as a total ecosystem, FLOSS would constitute the largest software company in the world, outselling the top three companies combined and having the largest workforce (O’Gara 2008, citing figures from the Standish Groups “Trends in Open Sourrce Report” which costs $1000). This is not the reason FLOSS is interesting, but scholars frequently note both the small-ness of FLOSS projects and the large-ness of the FLOSS ecosystem. 49 organizational rules … to include members that are dispersed geographically” (Demazière et al 2006). Other modes scholars use to divide up FLOSS projects include revenue model, type of license, size of project (in terms of lines of code or number of contributors), or governance structure. Others simply choose an exemplar project based on popularity, cultural significance (to either the FLOSS world or computing generally), or, like me in the end, go with personal familiarity and interest. The more I learned about the FLOSS world, the more complicated it seemed and the more I wanted to know about how things actually worked. Ubuntu also has an appealing mix of the four “origin types” that Demazière et al discuss above. Much decision making in Ubuntu is monopolized by Shuttleworth who calls himself the “Self Appointed Benevolent Dictator for Life” (his IRC nickname is SABDFL, as he is often referred to in text-based Ubuntu communication), a variation on a term used to describe the leadership structure of many popular FLOSS projects. At the same time, Ubuntu came into being through the work of a group of twelve Debian Developers, all of whom cared about making a better, more regularly updated, free (in terms of both libre and gratis) operating system that took the best of Debian’s practices. As Canonical took form, the project that is Ubuntu today (and related software projects developed by Canonical) are very much so driven by a central organization that allocates capital and resources. Yet, like Debian, Ubuntu is a widespread and heterogeneous group and faces ongoing issues of how to maintain a sense of cohesiveness. Ubuntu and Canonical are such a jumble of the most commonly used FLOSS typologies that I eventually decided just Ubuntu was probably more than I could handle 50 —and I had been using Ubuntu for a few years and thought it would be interesting to know to dig deeply into the production of something that I enjoyed using and gives me some hope for a different, more just economy. Perhaps most importantly, this process of thinking with and about FLOSS moved me away from using FLOSS as a test for some particular theory and provided me the privilege of spending over two years with my head down, focused on Ubuntu, having no idea what I was going to write about other than fun and the work of making Ubuntu. Yet my strugle of trying to “think from” Ubuntu is far from an isolated process. In addition to the voices and thoughts of advisors, friends, theorists, and Ubuntu contributors, my frustrations and joys with existing scholarship on FLOSS played a large role in my particular focus on work, fun, the nature of digital things, and the relationship between capitalism and the commons. Practitioner Histories and Journalistic Accounts As with many studies of emerging technologies and social movements, social science and humanities informed FLOSS scholarship got its start outside or on the periphery of the academy. Deploying popular anthropological and sociological tropes, it was FLOSS practitioners that published the first accounts of FLOSS practices, initially presented at conferences and then distributed on various internet-based communication mediums, sometimes later in print media. For instance, Eric Raymond’s The Cathedral and the Bazaar was first a presentation at a Linux conference in 1997, then shared on the internet, then published as a book by O’Reilly Media (Raymond 2001). O’Reilly also published Open Sources: Voices from the Open Source Revolution in 1999, when very 51 little scholarship about FLOSS was available (DiBona and Ockman 1999a; shortly followed by Rosenberg 2000). 19 Richard Stallman’s GNU Manifesto, first published in 1985, served as a key account of what free software means, and was included in this collection (and in other anthologies). Stallman’s essays were distributed on the internet, at conferences, are cited in much FLOSS scholarship, and were eventually published as a book by GNU Press in 2002 as Free Software Free Society: Selected Essays of Richard M. Stallman (Stallman et al 2002). Trade press monographs such as Gyln Moody’s Rebel Code: Linux and the Open Source Revolution and Torvalds’ autobiography Just for Fun: The Story of an Accidental Revolutionary fueled popular interest and related media coverage (Moody 2001; Torvalds and Diamond 2001). Interest in these accounts was heightened by popular press coverage that touted the explosion, revolution, or rise of FLOSS—often using the very same language and frameworks for understanding FLOSS put forward in the above accounts. Torvalds graced the cover of Forbes in August 1998 and was #17 of the most influential people in Time in 2000. And along the way Linux won the Prix Ars Electronics at the International Competition in CyberArts in 1999, the same year V A Linux broke IPO records. Many of the above accounts were written at the height of the “Dot-com bubble.” The destruction of capital wrought by the bubble and its burst took the form of investment in internet infrastructure—servers, fiber optic cable, office spaces, and equipment for coders, etc. 19 Rishab Aiye Ghosh’s “Cooking Pot Markets: an economic model for trade in free goods and services on the internet,” which, like Raymond’s work, is a shallow version of a gift economy under the pretense of a non-material world; and Weber’s working paper “The Political Economy of Open Source,” which seeks to explain FLOSS practices and histories in the terms of political science are significant early academic attempts to understand FLOSS (Ghosh 1998; Weber 2000). Beginning in 1996 the online peer-reviewed journal First Monday also served as a significant publication venue for practitioner and academic accounts and analysis of FLOSS related topics and issues (see www.firstmonday.org). 52 The consolidation of firms that followed the “burst” of the bubble led to a media landscape of product integration, “crowd” produced content, and internet privatization and individualization (i.e. individual based internet access via homes and later phones, instead of municipal wi-fi or the like). Ongoing accounts of FLOSS as somehow simultaneously the future of capitalism and its revolutionary antithesis set the stage for academic considerations of FLOSS. A Challenge to Assumptions: FLOSS Enters the Academy Practitioner and journalistic accounts continued, of course (Ghosh, Glott, Krieger, and Robles 2002; Lessig 2004; DiBona, Cooper, and Stone 2005; Wynants and Cornelis 2008), but academics outside of computing-related fields also started to pay attention to FLOSS. This attention took the form of curiosity, occasionally excitement, and sometimes outright confusion. As FLOSS entered the academy, it was marked by an understanding of FLOSS as an anomaly that challenged various economic, psychological, and sociological assumptions about Homo Economicus in group and individual decision making. Harvard economists Josh Lerner and Jean Tirole set the tone for this grouping of scholarship with one of the first academic accounts of FLOSS by arguing that “to an economist the behavior of individual programmers and commercial companies engaged in open source processes is startling” (Lerner and Tirole 2000, 2). In many ways, the issues raised in this piece and subsequent first disciplinary passes, such as Weber’s political science-based The Success of Open Source (Weber 2004) or early work 53 concerned with motivations (i.e. Hars and Ou 2001; Lakhani and Wolf 2005; Feller 2005), still haunt current literature. The questions that drove this first wave of academic scholarship were in many ways reactionary—“why do they do it for free?” “how can you make money?”—and failed to meaningfully engage with FLOSS work. Most academic literature on FLOSS continues to focus on four classic research questions: 1) why do commons exist and how are they managed? (e.g. von Hippel 2001, 2005; Bergquist and Ljungberg 2001; Chiao 2003; O’Mahony 2003; Marshall 2006; N. Jullien and Zimmermann 2006); 2) what are the social and economic implications of US-based copyright law? (e.g. Lessig 1999d; Boyle 2003; May 2006; Benkler 2006; Benkler and Nissenbaum 2006); 3) how are communities formed and governed? (e.g. Benkler 2003, 2006; von Krogh et al 2003; Weber 2004; Lerner and Tirole 2004; Bonaccorsi and Rossi 2005); and 4) what are the non-classical economic motivations of FLOSS contributors? (e.g. Himanen 2001; Lancahire 2001; Benkler 2003; Ghosh et al. 2002d; Lerner and Tirole 2002; Weber 2004; Gallaway and Kinnear 2004). Much of this scholarship is marked by an explicit goal to extract business, legal, or community models from FLOSS to adapt for commercial use, social movements, or other ends. An edited volume published in 2005, Perspectives on Free and Open Source Software, organizes contributions in a somewhat similar fashion, in addition to sections of business models and non-profits, but not explicitly focusing on the commons (Feller et al 2005). Many Linux-based firms went down with the bubble, but very quickly FLOSS found its way back into popular and academic press via hype and nonsense around “web 54 2.0” and “new media” in the mid-2000s. It is no accident that the technologies and practices referenced by the terms web 2.0 and new media are heavily indebted to FLOSS. Aside from the fact that this is true of all internet-based technologies, author and technofuturist O’Rielly, who popularized the term “web 2.0” in the technology press and with conferences, consistently linked the future of the web with “open source” and continues to sponsor major FLOSS events (i.e. OSCON). In the context of massive investment in data centers, embryonic hype about “the cloud,” embedded computing, and pervasive computing, scholarship on new media frequently does discus FLOSS, but as with much new media scholarship, with a focus on social practices removed from their historical, economic, and broader social and material context (see Chun and Keenan 2006 for a critique of this strain of new media scholarship). Studies of FLOSS that are not Necessarily about FLOSS Here we come back to scholarship that examines the lives of FLOSS coders and FLOSS code by putting them in various broad contexts—a significant departure from the often, but not exclusively, myopic work above. (To be clear, there is no strict temporal break here, all sorts of scholarship marches on, for better or worse.) 20 Scholars who have analyzed group formation, the national and regional contexts of FLOSS adoptions, FLOSS and development, and FLOSS governance have done key work that creates the conditions of possibility for an emergent cluster of current scholarship. Many scholars 20 Also, there is also a corollary body of scholarship in computer science and related fields that is interested in how FLOSS works as a development model and in evaluating its effectiveness on various levels (see reviews by Sack et al. 2006; Scacchi 2007; Jensen and Scacchi 2010) 55 doing this work have strong commitments to FLOSS, and I imagine have asked themselves a question I found myself wondering about frequently: is anything I am doing that is going to make FLOSS better, and is making FLOSS better part of a path towards a more just economy or the world in which I want to live in? I am most inspired by scholarship that is not concerned with whether or not FLOSS is a potential solution to problems or uses FLOSS as a test for other theories, but is willing to engage with some ambivalence and see FLOSS in a broad social and economic context. In particular, two interesting and excellent recent books have done work with FLOSS without which I would not be able to write this particular dissertation. 21 Kelty’s Two Bits: The Cultural Significance of Free Software and his definition of FLOSS as a practice helped me frame this project and its relationship to the internet and how forms of life and collaborating express and bring into being an imagination of a different moral and political order (Kelty 2008). Chopra and Dexter’s critical assessment of the sorts of liberation enabled (or not) by FLOSS in Decoding Liberation: The Promise of Free and Open Source Software is rooted in the long history of making software (65 years as compared to the significantly shorter 35 years software has been sold), and in doing so takes significant steps towards an analysis of FLOSS and capitalism: “as an international community, FLOSS employs the characteristic logic of late-capitalism: decentralized power, distributed sovereignty, and a reworked concept of commodity that stresses the provision of services rather than the accumulation of physical goods” (Chopra and Dexter 2008, 20). As developed in next chapter, code is a physical good that can be and is 21 These were the sorts of books that when I saw them I thought “oh, yes, now I do not have to do this work!” That is, they were both gifts that I appreciate very much, even if I have issues with the work. 56 accumulated and coders do not own their own means of production as Chopra and Dexter argue, but I am well indebted to their analysis. A small group of cultural anthropologists have started to create scholarship that is less about FLOSS and more about the what FLOSS is about—that is, it takes FLOSS as a mode of engaging with a set of socio-technical issues, and is thus about those issues (Ratto 2003; Kelty 2005, 2008; Coleman 2004, 2005; Lloyd 2007). By paying attention to the everyday lives, feelings, and practices of FLOSS practitioners, these scholars have begun to address serious concerns about scholarship on FLOSS, such as those raised by Chun: Open or free software may be nice, but they leave un-interrogated the question of proprietary hardware and structures of inequality that make it impossible for a good number of workers who create hardware to access software, open or not … these movements and their products are theoretically open to all, but participation depends on education, financial security, leisure time, and so forth, and the final decisions on which revisions get included often lie with one person (Chun 2006, 72). Recent research on intellectual property, which has been a central tenet in FLOSS scholarship, addresses the issues Chun raises and increasingly thinks outside of the limited reform paradigm that has characterized earlier accounts (e.g. Kelty 2006; May 2006; Jullien and Zimmermann 2006). Scholarship on FLOSS and development often has a more complex vision of FLOSS, if with a bit of a techno-liberationist bent—FLOSS will somehow solve problems of structural inequality, institutional racism, colonialism, etc.— but increasingly scholars are more meaningfully concerned with the varying national, regional, and specific organizational contexts of FLOSS production and adoption (e.g. Schoonmaker 2002; Chan 2004; Shen 2005; May 2006). This sketch of 57 FLOSS scholarship is not intended to be all-inclusive, nor is it necessarily the best way to think about the history of FLOSS scholarship. Rather, this organization traces my own trajectory with this work, with a focus on what has guided me, both in terms of being frustrated and being inspired. III. Some of the Usual Stories While the above scholarship on FLOSS has helped bring my research into being and helped me figure out how to “think from” FLOSS, I am thinking from FLOSS toward understanding code, digital things, work, fun, and that which gives me hope in Ubuntu— the beauty of people working to create the world in which they want to live. Some of the “usual stories” I heard time and time again started to sound quite different from what I was learning and observing about FLOSS and the difference seemed to be tangled up in ideas about time, infrastructure, and what the “digital” actually is. When thinking about digital things (meaning things that are in some way encoded), 22 it is easy to decide that the “digital” is so different from what we know as “material goods” that our assumptions about how value, extraction, labor-power, and the like no longer apply. Rather being an invitation to start anew, what is needed is a long hard look at the complicated thing that is code: for it is a material good, it is congealed human-labor, only it moves with a particular set of technological infrastructures that make code appear to defy materiality. 22 Things either created in digital form via some encoding process, such as how source code (human readable code) is turned into machine code (0s and 1s) via an assembler or interpreter; or a thing created by an encoding process whereby a digital version of an existing thing is created, such as scanning a photo or making a digital recording of an vinyl record. Of course there are many processes in-between these two poles, such as digital music tools or word processing programs. 58 Code, in a sense, presents some very complicated geographical problems. Time matters dearly here, as it does in all instances when the capitalist mode of production and another mode of production push into each other. Time is the arena into which capital relations seek to set the deepest roots. There is not any universal capitalist time, but rather, a time to which each particular form of capital relations march. Or, it is a time that seeks to make workers march as if the beat came from a metronome within our very own hearts, rather than from the toil of workers before and apart from us who made the particular machines (computing devices) that we bring to life with our labor that in turn, bring us into step. So, what is the beat of the machines of code? What are the spatial organizations of capital that enable this particular form of time? What is the life of code, its life-cycle, how long can it live, does it depreciate over time like other machinery, how does it transfer labor into other objects? Or, simply, how is life breathed into 0s and 1s? Or, in Marx’s language, how does formal subsumption work via time (Marx 1993, 645)? How does ideology and emerging hegemony normalize this subsumption; how does this enable capital accumulation to seem only natural, instead of as the theft of social wealth? These questions about time appear over and over throughout this dissertation and structure all that follows. To provide a brief glimpse into the larger world of FLOSS and its histories, and to demonstrate what a reconsideration of time can do, let’s take a look at some of the “usual stories” that folk tell about FLOSS. First, a story about a “creative genius” that points towards the material nature of code, its infrastructure, and the conditions of possibility for FLOSS; then a story about the origins of FLOSS and its politics that gives us a hint about the role of fun and work; and finally, a story of money 59 and a millionaire that poses some questions for how capitalism and the commons intersect and how it happens that commons might be made to do some work for capital. Usual Story #1, “Linus Torvalds in his bedroom” In January 1991 a computer science graduate student at the University of Helsinki named Linus Torvalds bought himself a person computer… (Weber 2004, 54) When university holidays began, Linus was able to devote himself fully to his project … Linus recalls that “the first summer I was doing [coding] full-time. I did nothing else, seven days a week, ten hours a day.” (Moody 2001, 40) I’d roll out of bed directly into the chair at my computer, less than two feet away … I was having fun … I felt so proud when the gnu shell worked that I was ready to let the world see. Also, I wanted feedback. (Torvalds and Diamond 2001, 84–87) The development of the Linux kernel began, in 1991, with Linus Torvlads obtaining POSIX standards electronically; posting his first release to an FTP site; and announcing the code, asking for help, and receiving bug fixes via email. (Chopra and Dexter 2008, 15) So the story goes. A curious and gifted coder, who is particularly enamored with working “close to the metal”—on “low level” programming, where the code is “closer” to the hardware and manipulation of physical memory and processor cycles—buys a personal computer. After playing Prince of Persia (a very popular video game at the time) for a few months, playing with some other operating systems that are UNIX-like 60 and finding them lacking, he decides to “scratch an itch” and build something that meets his needs and engages his curiosity. Over a long summer in his bedroom with black curtains drawn to keep out the nigh constant sun, he hammers out some code, and then uses the internet to share the code with others. Linux is released under the GNU Public License (GPL) both because Torvalds used GNU tools and because he wanted to get the most feedback possible. Raymond, a self-declared open source spokesperson and amateur anthropologist, lists universities as the site of origin of open source, along with Bell Labs, XEROX Palo Alto Research Center (PARC), and the US Department of Defense’s Defense Advanced Research Projects Agency’s (DARPA) Computer Systems Research Group (CSRG) (Raymond 2001, 10–18). Yet, Raymond’s key metaphor for understanding the difference between proprietary software development and the Free Software Foundation (the hierarchical cathedral) and open source software development (the voluntarily networked bazaar) elides the power of state-funded research sites in this common narrative of FLOSS’s origins. Raymond decides Linux is best described as a “free market” (Raymond 2001, 65). Like most scholars who let “free markets” stand in for the incredibly complex, material, legal, social, historical, and embedded conditions of money-based commodity exchanges, he ignores the role of the state in constructing the market. 23 Raymond’s work is part of the first generation of practitioner accounts of FLOSS, and although it is widely critiqued, many of his base assumptions about free markets and the creator of the Linux kernel, Linus Torvalds, are not. 23 Which is not surprising, considering Raymond is a avid libertarian. 61 Via the university, the state plays a role not only in creating markets, but in establishing the means of production. For example, universities, and social networks at and through universities, have provided access to server space and bandwidth—the first FTP site for Linux, (and many to follow) was set-up on the down-low by a sympathetic university employee at Helsinki University. It is universities that provide the material basis for Linux, access to software documentation, social networks, experts in computing, and access to expensive computers, bandwidth and servers (Moody 2001; Torvalds and Diamond 2001; Gonzalez-Barahona et al 2008). As early Linux hacker Alan Cox remembers, he had to “walk into the university with a pile of floppy disks” and download Linux on their internet connection (I heard a similar story a half dozen times from Ubuntu contributors about their early exposure of FLOSS) (Moody 2001, 72). All of Torvalds’ initial lieutenants 24 were first exposed to Linux at universities (MIT, Purdue, University of Wales, University of Mexico, and Australia National University). Yet, they did not necessarily garner their skills and understanding of FLOSS from the mechanisms of the university, as much FLOSS work at the university is unofficial, unknown, and irreducible to any research or academic agenda—such as Torvalds’ labor to develop Linux. 25 Torvalds’ relationship with the university system in Finland runs deep and is related to the spread of Linux. His grandfather was a professor and it was on his lap and from his university computer skills that Torvalds learned to code. A free university 24 Torvalds still makes many final decision about the Linux kernel, but his unofficial “lieutenants” handle bug fixes and design decisions for various parts of the kernel. 25 Although he was able to turn an aspect of his Linux work into a Master’s thesis (written “over a long weekend”). 62 education at the University of Helskinki without arbitrary ideas about “normative time” for degree completion and easily available education loans allowed Torvalds to buy the computer upon which he wrote the Linux kernel and made it possible to create the time with which to do so (Torvalds and Diamond 2001). The loan money was intended for food and housing, but because Torvalds was living with his mother, he was able to use it to purchase a computer (Moody 2001, 35). Furthermore, Finland is an early adopter of networked communication—Usenet first, and then the internet). This is partially explained by Finland’s long-term investments in communications infrastructure through various military operations and being a country where the English language is in popular use. Also, the Finnish telecom giant Nokia cannot be ignored in Linux’s development—Nokia is cited in FLOSS practitioner accounts as providing the “adoption context” in which the Finnish government and university system have supported both Linux and Torvalds (Moody 2001; Torvalds and Diamond 2001). Like the spread of UNIX—spread by “scholars on sabbatical and research fellows going back and forth between Xerox PARC and university departments (Weber 2004, 29)—Linux was moved by University students and professors. For instance, Linux was brought to China by Chinese students who visited overseas at the University of Helskini, UC Berkeley, and MIT (Yeo, Liu, and Saxena 2005). Torvalds in his bedroom is better accounted as Torvalds at the university—even though the majority of the Linux kernel was written over a summer in his bedroom. This 63 tale is instructive for any consideration of FLOSS labor. 26 Much FLOSS labor, like Torvalds writing the kernel in apparent isolation, makes such efforts look like the work of a lone creative genius. The lone coder narrative has been critiqued by scholars concerned with how collaboration at a distance works (Benkler 2006; Demazière et al 2006), as it is clear that any one coder depends upon the work of many others. However, while this “standing on the shoulders of giants” intervention is important, I am most concerned with how Torvalds’ story can inform our thinking about how the means of FLOSS production are often as dispersed as FLOSS contributors. Paying attention to the geography of FLOSS production, Ubuntu in particular, is in many ways a task of putting dispersed pieces together, revealing dependencies, and showing all that needs to be built and organized in order to allow, for instance, one person to code alone in his bedroom. Torvalds’ story also demonstrates the double freedom of workers: “free in the double sense that as a free individual he can dispose of his labour-power as his own commodity, and that, on the other hand, he is free of all the objects needed for the realization of his labour-power” (Marx 1993, 273). That is, workers are free to show up to work and they are free of the means of production. But FLOSS appears to be different, as mentioned above FLOSS workers easily appear as if they are not free of the means of production, but rather own and control it. After all, look at how Torvalds worked by himself, with his own computing devices, alone is his room to produce something as amazing as Linux! Or, look again and see how Torvalds was free of the objects required 26 I had no training in computers or network technology until my slight interest in computing led to the University of California library for which I worked to invest training hours and community college classes in me, eventually turning changing my job title from a “Library Assistant II” into a “Computer Resource Specialist.” Through this state investment I have gained certain skills and language that makes me feel comfortable talking about software and performing “geek” at times, all of which have led me towards writing this dissertation and not another. 64 to realize his labor-power. He struggled to get access to machines on campus, and even after saving for a year and taking out a loan to get his own computer, he was still free of the means he needed to create the kernel. Very expensive manuals had to be bargained for, loaned, or stolen from the university, and then server space and bandwidth had to be commandeered by a friend at another university. The history of FLOSS is a history of the re-theft of the common (the manuals, knowledge, and goods created from re-engineering proprietary code, the use of surpluses in server space and bandwidth); a re-theft practiced by Torvalds and many others as a matter of everyday practicality. The easy argument from here is to propose that today, with a well established FLOSS ecosystem and cheaply available computers, the game is completely different. But what does a FLOSS coder need to realize her labor power? A computer, an internet connection, access to various code hosting servers, the knowledge and support of a community built via access to sites of face-to-face contact, all are key to creating code. Coders only own one thing on this certainly not inclusive list: a computing device. It is absolutely possible to write code and get work done on your own, just as it is possible to build a car in your garage, but capital’s provision of the means to realize the possibilities of FLOSS labor power affords an incredible increase in productive and social capacity. FLOSS is a form of creation that made the internet we know today possible, and today continued FLOSS production is only viable via internet-based communication and collaboration tools. Capital is able to provide these means because of the private ownership or control of the infrastructure of the internet and this should give great pause 65 to anyone who wants to argue that FLOSS or other “knowledge workers” own their own means of production. Torvalds in his bedroom begins to make clear the role of the state in the capacity for FLOSS development. Although this dissertation does not meaningfully engage with various national, municipal, and transnational forms of the state in managing surpluses and regulating labor and firms, the state remains fundamental in understanding the role of place in the differential possibilities and contexts of FLOSS laboring. Torvalds growing up and learning in Helsinki and then moving to Northern California is no coincidence and as we shall see, neither is the other famous FLOSS founder, Richard Stallman, staying put in Cambridge, Massachusetts. Usual Story #2: “Richard Stallman and the Proprietary Printer” ... in short, the capitalist produces the worker as a wage- labourer. This incessant reproduction, this perpetuation of the worker, is the absolutely necessary condition for capitalist production. (Marx 1993, 716) Looking back to Linux’s progenitor, the UNIX operating system, we can see how the US defense industry, the university system, and publicly-traded corporations make up a trinity of UNIX and network development in which what is now FLOSS was forged. In 1979 DARPA requested Professors at the University of California Berkeley to develop a UNIX distribution for internal DARPA use; later, in the early 1980s, a committee of UC Berkeley, Stanford, MIT, UCLA, and Bell Labs professors and researchers served as a 66 “steering committee” for DARPA; while at the same time professors such as Bill Joy were leaving academia to found private firms (Sun Microsystems). This is significant not only in how public spending on military and education coalesced into a base for the emergence of private companies, but also in that it is the base for the emergence of FLOSS. In 1999 about half of the utilities packaged with Linux were developed by the Department of Defense funded CSRG at Berkeley (McKusick 1999). The collaboration of “private” and “public” entities has certainly been transformed by the possibility of going public and making millions. In the US, gone are the days of Berkeley graduate students working in secret with Bell Labs to debug software for the military, here are days of students working in secret to capitalize on their innovations or because of corporate non-disclosure agreements or working in secret under the auspices of the Department of Homeland Security—which is not necessarily better or worse, but rather indicative of the a change in form of military-industrial-university complex in the US from research and development towards security and start-ups. It was a similar process of altering university work relations—Massachusetts Institute of Technology’s Artificial Intelligence Laboratory workers leaving the university in the early 1980s for industry jobs and to start their own companies—that emptied the lab, leaving lab worker Stallman “alone.” This emptying was foreshadowed in late the 1970s when firms began to deny university hackers access to source code for the first time, even if it was for personal or non-commercial use (Coleman 2005, 146). This pattern runs through literature on the history of FLOSS coders and leaders—Symbolics spins out the MIT AI lab and hired all but two employees; Berkeley is fractured by Sun 67 and DARPA; Bell Labs’ work is undermined by AT&T’s legal troubles; Larry Wall leaves UCLA to do classified work for the Systems Development Corporation in Santa Monica. The story of Stallman ending up “alone” in the lab is usually told via his first encounter with closed code (up until this moment, at least for university workers, such a thing was relatively unheard of): The AI lab received a graphics printer as a gift from Xerox around 1977. It was run by free software to which we added many convenient features … Later Xerox gave the AI lab a newer, faster printer, one of the first laser printers. It was driven by proprietary software … so we couldn’t add our favorite features … The systems programmers at the AI Lab were capable of fixing such problems … Xerox was uninterested in fixing them, and chose to prevent us, so we were forced to accept the problems (Stallman et al 2002, 125). 27 A few years later as the emptying of the lab was hitting full swing, a major project was wrestled out of the lab’s control via licensing and “Stallman regarded the signer [of the license] as a trader” (D. K. Rosenberg 2000, 8). Then, depending on the account, Stallman took action: The general barriers placed against sharing and the particular evisceration of his community drove Stallman into a fit of depressive rage, and he first sought to retaliate against the specific corporations that splintered his beloved hacker community. Starting in 1982, he sequestered himself in near isolation for over 27 Source code refers to the human readable code that coders write—knowing the language it is written in (or another similar language) usually means being understand and change the code. If Stallman had the source code, he could change it and add the features he desired. Instead, the printer was distributed with on the “binaries”—the 0s and 1s that are capable of being read and acted upon by computing devices. (This code is also called binary code, executable code, machine language, and machine code; I will use “machine code” throughout this document because the term reminds us that it is code for machines, that can move and be active on a machine.) Source code must be turned into machine code to be put to work, or compiled, and once in the form of machine code, it approaches impossible to change any mildly complicated software without the source code. Things are bit more complicated than this and do not always work the same way with every language or type of compiler, but the gist is: source code (human readable) is written, then run through a compiler and turned into machine code (0s and 1s which are then able to move through the binary operation of a computing device). Machine code does the work, but cannot be changed without access to the source code in some manner (this can mean distribution of the source code, such as in FLOSS, or an Application Programming Interface (API) that allows some changes to be made, but does not reveal the entire operations of the code. 68 two years and adopted the persona of a revenge programmer (G. Coleman 2005, 147). Or, more commonly, “Stallman’s response to this state of affairs was a radical plan to develop an entire system built of free software” (Chopra and Dexter 2008, 13). MIT is not the corporate world that drew Stallman’s colleagues away from the university, but MIT was no better: “If I had remained on the staff, MIT could have claimed to own the work, and could have imposed their own distribution terms” (Stallman et al 2002, 18). Stallman eventually quit the lab, but the head of the lab let Stallman keep his university office, where he lived on and off for twelve years working on GNU related software, founding the Free Software Foundation and doing various free software advocacy (D. K. Rosenberg 2000; Moody 2001, 23). In 1990 he received a MacArthur “genius grant,” which he invested in a fund and calculated how much money he would need, minimally, “so that I can live on it for the rest of my life while working on free software or another worthy cause” (Moody 2001, 28). The usual story about Stallman and the printer is that in order to be able to work with code as he desired, Stallman had to create the GPL, a “clever hack” to copyright law. The genesis of the GPL, which Torvalds would later use for the Linux kernel as discussed above, is for many the genesis of FLOSS, or at least the entrenchment of FLOSS-like practices into a formal document, to be struggled for and disputed by FLOSS practitioners for decades to come. But Stallman’s story also tells us a great deal about the sort of laborers produced by the conditions and organization of FLOSS work. Obviously Stallman is an exceptional case, but this exception tells us a story of possibilities—even if the conditions that enabled this life are not easily reproduced, for better or worse. But this is also a story 69 of the form of life and ways of meeting one’s needs that make it possible to labor freely on free software. What made it possible for Stallman to work? A combination of the state and the university, plus a McArthur Grant, provided a form of guaranteed wage and guaranteed housing for Stallman. This should guide us towards a realization that FLOSS ways of organizing work to make something of great value and give it away for free demand that meeting needs is in some way socialized or guaranteed. Such a realization should guide how we think about other coders who do not have guaranteed housing or grants. If laborers’ reproduction is not socialized and has the extra burden of all the labor (living and dead) that reproduces an office thrust upon the individual (no janitors, system administrators, administrative assistants, or tech support; no desk, chair, copy room, printer, office supply cabinet, conference room, phone, or reliable high speed internet access; and no workplace injury compensation, OSHA, or building code standards) 28 — what sort of workers could be produced by these conditions? In the case of Ubuntu, how is the laborer reproduced both as a worker for capital and as a living breathing human capable of getting up each day to work again? Stallman’s story also reminds us how deeply dependent capital is upon hetero- patriarchal family forms by demonstrating what can happen in the absence of such a family form: Stallman has never married or had children. “That takes a lot of money. There’s only one way I could have made that money, and that is by doing what I’d be ashamed of”–writing non-free software. “If I had been developing proprietary software, I would have been spending my life building walls to imprison people” (Moody 2001, 19). 28 Or, as Jono puts it, “Its sometimes nice siting in an office with a meeting room with a decent conference phone, as opposed to sitting in my office, in my house, with a dog on my lap in my underpants … wondering where the nearest photocopier is.” 70 Stallman did not have his mother’s house and her work cooking and cleaning as did Torvalds—or like many of the Ubuntu contributors I talked to who in some way relied upon the reproductive labor of women. The labor of a contributor’s mother, grandmother, wife, or girlfriend all came up as providing some portion of the means to work on Ubuntu —and in moments of crisis, especially for unpaid contributors, a larger familial structure that could provide them with temporary or permanent housing was essential. 29 There are many cases where the work of women performing various sorts of reproductive labor enables the labor of coding. Stallman’s example makes clear that to insist “we must talk about freedom,” as Stallman frequently does, means to also insist that we talk about the material conditions to be able to have such a conversation about freedom, to able to prioritize the conversation Stallman insists we have. For Stallman, his exceptional case produced the capacity to talk about freedom in a certain manner by living a form of the future he dreamed, a situation that produced a different sort of laborer, operating with a different sort of time: … and I would go to sleep whenever I felt sleepy; when I woke up I would go back to coding; and when I felt sleepy and I’d go to sleep again. I had nothing like a daily schedule. I’d sleep probably for a few hours one and half times a day, and it was wonderful; I felt more awake then I’ve ever felt. It was exhilarating sometimes … it was in some ways, terribly lonesome (Moody 2001, 19). The relationship between capital and hetero-patriarchal family forms obviously has its ruptures and it is worth thinking about what forms of life are brought into being by 29 I do not know the details of the household labor for FLOSS workers except in a few cases. In these few cases, the wives, girlfriends, grandmother, or mothers of a Canonical employee or Ubuntu contributor performed the vast majority of household reproduction—and it was a frequent referent in other interviews. It can be inferred that this happens in other cases, but certainly not all Canonical employees or all Ubuntu contributors have such a family form to rely upon nor are all families structured in this manner. If I had this dissertation to do over again, it might be about household reproduction, fun, and the Ubuntu labor process. 71 these ruptures. However, it is important to remember that these forms, although prime examples of how people eke out life that both brings into being and meet needs and desires that are not of capitalism, are not themselves a solution to the damage wrecked by capitalism, in the this case, by hetero-patriarchy and capitalism, upon our collective capacity to create and meet needs and desires. Rather, like Stallman’s story, they are guides to the possibilities of a different way of living that would require a very different allocation of surplus—such as what it would take to bring a general or guaranteed wage into being. Stories like Stallman’s and Torvalds’ are often told as examples of what can be achieved by dedicated creative individuals—or in less neutral words, of what super- geeks can do when left alone with a computer. As Stallman, and perhaps Torvalds would argue, these stories should teach us lessons about the vast resources and significant numbers of people that have to be mobilized for a geek to be left alone at a computer and that we should be working towards a world where everyone has the wherewithal to pursue such work, to have such fun. Usual Story #3, “A Millionaire Founder from Outer-Space” My relationship to Canonical is not really a formal one because Ubuntu is sort of, well, Canonical does a lot of work in Ubuntu, but Ubuntu is sort of independent, they got a big grant from Mark Shuttleworth, like 10 million dollars or something. (personal interview with David, 6/17/08) 72 The first thing mentioned in most biographical statements about Shuttleworth is that he is semi-famous for becoming the second “space tourist” in 2002 when he paid $20 million to spend eight days on the International Space Station. This was before Ubuntu, but after Shuttleworth’s first FLOSS project: he did a lot of cryptography hacking in the early days of web certification and then founded digital certificate company Thawte in his parent’s garage using a Debian-based server 30 in 1995 and sold it to Verisign for a reported $575 million in 1999. In 2001 Shuttleworth created the Shuttleworth Foundation, with the goal of supporting social change based in open innovation and open source. The Foundation funded various FLOSS related projects, such as the development of the “Freedom Toaster,” a FLOSS vending machine that would burn customized FLOSS CDs (with specialized language packs, particular software, etc.). In 2004 Shuttleworth founded what was to be Ubuntu purportedly out of the desire to take on a challenging and interesting project and give something back to the FLOSS community, whose labor he put to work to make millions. Ubuntu’s “sort of independence” from Canonical is also a purposeful move by Ubuntu founders to keep Ubuntu as a “community distribution” that is not controlled by a parent firm dictating development goals or contributors’ rights and membership. This sort of independence serves, purposefully or not, to obscure the fact that not all Canonical employees work on Ubuntu. Many work on proprietary software development, which is a source frequent discussion in the FLOSS community, especially before Canonical’s Launchpad, a web-based system for developing and maintaining software, was “open- 30 Shuttleworth still is a Debian Developer, a point often mentioned in interviews when the issue of tensions between the Ubuntu and Debian communities are brought up, and he has contributed to the Apache web server as well. This baseline cred as a coder is crucial to Shuttleworth’s capacities as a FLOSS leader. 73 sourced” in July 2009. Canonical also employs web administrators, graphic designers, system administrators, human resources personnel, and other staff who are not part of the vision of Canonical as a firm of “excellent coders” that is common in the Ubuntu community. Yet Canonical does exert a great deal of control over Ubuntu development via the wage relation and the personalities and networks of some of its employees, but as is discussed in Chapter Three, this control is far from encompassing or complete. The usual story of Shuttleworth is not in FLOSS scholarship, but rather in FLOSS and related technological media outlets and in the conversations of Ubuntu contributors like David. When it is told, the tale usually goes as above, in a simplified form: Shuttleworth made millions off FLOSS, had some fun with the money by going to outer space, then decided he wanted to both give back to FLOSS and try to push FLOSS’s capacities to a new level so he founded Ubuntu. The story of Shuttleworth’s reason for Ubuntu is codified in the first bug added to Ubuntu’s “bug tracker,” written by Shuttleworth and now affectionately know as Bug #1: Bug #1 (liberation) Microsoft has a majority market share in the new desktop PC marketplace. This is a bug, which Ubuntu is designed to fix. Non-free software is holding back innovation in the IT industry, restricting access to IT to a small part of the world’s population and limiting the ability of software developers to reach their full potential, globally. This bug is widely evident in the PC industry (Canonical 2009). Bug #1 is a key document in the Ubuntu community, for even though Ubuntu contributors’ goals for Ubuntu are very diverse, the potential of Ubuntu to “change the world” in some way is shared: 74 By positioning Ubuntu as the solution to this bug, Shuttleworth put the dogmas of the free sharing of information at the centre of software innovation, reflecting this in choosing the name Ubuntu – an ancient Zulu word meaning “humanity towards others” whose associated ideology of shared humanity summed up the open model of development of Debian on which he sought to base his project and his experiment of software innovation (Lloyd 2007, 36). As Lloyd tells it above, the usual story of Shuttleworth is the story of what a person can do with money to try to make some form of innovation happen. For most commentators another moral of this usual story is that Ubuntu, or something like it, is only possible with such an “angel” investor. And the stability that Shuttleworth’s wealth offers is meaningful, as David mentions there is a fund (so far untapped) that functions as a guarantee that Ubuntu development will continue regardless of Shuttleworth’s whims or Canonical’s successes or failures. When the topic of Canonical’s proprietary software development came up at a California LoCo event, David defended Ubuntu with passion and certainty. This was right around the time that a groundswell of press critical of Launchpad was rising and Shuttleworth had just announced that it would be “open-sourced.” Many folk asked why it was ever closed and if such practices by Canonical should be trusted. Like many others, David takes comfort in Shuttleworth’s wealth, and expressed his belief that it would shelter Ubuntu from a need to be profitable and would make sure that Ubuntu would never, for instance, “get in bed with Microsoft,” or do anything that would, in the end, be antithetical to David’s free software ethos. 31 31 This is also indicative of a change in FLOSS politics. For instance, at a 2008 FLOSS convention, Shuttleworth mentioned that in 2005 Microsoft sponsored a lunch at the convention—and folk refused to eat. Three years later, Microsoft is a major donor to the convention and to several FLOSS projects. 75 This is a significant misread of Shuttleworth, who cares dearly about making Canonical sustainable and has a good working relationship with Microsoft and the Microsoft Foundation, but it is a common and powerful sentiment in the Ubuntu community. The independence David references is enabled not by a multimillionaire giving a very large grant, but as David hints at, by Shuttleworth’s explicit goal of placing Canonical into a temporal rhythm outside of the cycles of returns demanded by capital. Enabled by funding from Shuttleworth, Canonical’s search for profit exists outside of capital’s temporal relations in which profit is measured in yearly, quarterly, or even quicker earnings cycles. Shuttleworth is keen for Canonical to turn a profit or break even, but he explicitly locates Canonical’s goals for profitably in the range of decades—a cycle that is only enabled by Canonical’s dependence upon volunteered labor and the wealth of already existing FLOSS commons (Hesmondhalgh 2010; also, McRobbie 2002; see Andrejevic 2009). Shuttleworth’s initial statements ranged from saying it would take five or seven years to build the infrastructure required to make Ubuntu profitable (Morgan 2010). At the same time, Shuttleworth has pushed strongly, along with other Ubuntu manager/developers, 32 for the “synchronization” of release cycles within the larger FLOSS ecosystem. Such synchronization would streamline Ubuntu development (and general FLOSS development), and if synchronized to a cycle that works well with Ubuntu’s release cycle, help put Ubuntu in the center of a system of exchange. 32 Like Shuttleworth, all initial Canonical managers were also highly respected FLOSS developers, and the vast majority were Debian Developers. 76 This effort has met vigorous resistance (and found some support) from FLOSS workers—as well as from other capitalists and other FLOSS organizations (Byfield 2011). Such a project would require strong support from FLOSS workers (paid and unpaid) and without it, the project of synchronization of releases between various FLOSS projects and firms has fizzled and in some cases has led to animosity directed at Canonical and Ubuntu. Synchronization was a key element of Shuttleworth’s larger temporal plan for Ubuntu development, and its failure (so far) is a useful example of the many mundane and day-to-day struggles over the pace of work through which workers, for better or worse, bring the labor process into being. Especially when this process is embedded in the commons—meaning that the wherewithal for people to work on something requires access to a commons—a push from outside the commons to re-order the commons can be a death-knell for its productive capacity (see Casarino and Negri 2008; Hardt and Negri 2009). Shuttleworth and most FLOSS contributors know this well, for they have seen it happen to FLOSS communities, especially those related to for- profit firms. This move by Shuttleworth to change and experiment with the temporal relations of software development can be understood as a move to keep capital invested in Ubuntu development out the temporal cycles of earning demanded by capitalism. The immediate change to the cycle of development implemented by Shuttleworth and those first Debian contributors who worked to create a Debian derivative that became Ubuntu is the six- month development and release cycle. These quick, six-month cycles of development define the ongoing re-negotiations of the relationships between time, space and software 77 in Ubuntu production (see Figure 2). The need for innovation does not emerge organically or naturally as part of the process of making software; rather it is through the imposition of management directives from Canonical that require each Canonical 78 Figure 2: Sample Ubuntu Development Cycle (Six Months) employee to plan, implement and then document a certain number of “unique” Ubuntu features in each development cycle. 33 The other story to Ubuntu being made possible because a very wealthy, eccentric, and brilliant benefactor and leader from outer space is thus both larger and smaller—and 33 This demand is stressful and difficult to meet for some developers, especially those whose work does not necessarily relate to new features or any other form of innovation: Management cares about making the distribution unique, which is understandable. We have quite short release cycles, six months. About half of that time is cut off for review, bug fixes. So we only have about three months to do the actual development work. They want us to produce something distinct, not just the theming … I get the pressure directly from my team leader. We have half-yearly performance reviews, so we need to come up with six items, define them, and how we want to work on them, and deliver it each release cycle. Its hard enough for me to come up something new each time. Thats a lot of pressure. 79 is very much so a story in flux. The larger context, as could be guessed by now, is Ubuntu’s implications for the nature of the relationship between capitalism and the commons. The smaller context (only in scope, not in meaning or importance) is the mundane work of people creating a place where their work can have some meaning. That is, contrary to Shuttleworth and hype, Ubuntu is not a product of some drive for innovation or new technologies, but for the most part, just a way of making something of value through which people have found a chance to do something that is meaningful and fun. As I return to in Chapter Two, this is not about motivation or why people work, but about how people find a way to work that reproduces the capacity to have fun. The cycle of development in Ubuntu, the movement of FLOSS code outside of the temporal imperatives of capital, is a move to keep things of value made in the Ubuntu labor process in a different system of exchange. This system of exchange is at once the commons and a form of gift exchange. Commons and gift exchange are ways of talking about different aspects of the same system and thing. As discussed briefly above, commons refer to a system for holding onto resources that humans somehow make valuable (use to meet a need) and in doing so people become part of a system of reproducing that resource (via the work of stewardship, maintenance, or some other way of combining human capacity to work with a resource that lives in the common). We can talk about a commons of code that is kept un-ownable in FLOSS that is put to use in a variety of anticipated and unanticipated ways; and from Ubuntu contributors and these usual stories, we can get some idea about 80 how people using FLOSS code to meet their needs (especially the need to make more FLOSS code) get very meaningfully tangled up in the reproduction of the commons. 34 It is through the gift, and gift exchange, that much of this tangling up occurs. Most simply, as Lewis Hyde makes clear throughout his wonderful work The Gift: Imagination and the Erotic Life of Property, “unlike the sale of a commodity, the giving of a gift tends to establish a relationship between the parties involved” (Hyde 1983, xiv). These relationships are meaningful, and when the giving of gifts moves from a second to a third party, when the gift moves through someone, a circuit or circle of a gift exchange begins to emerge. Hyde demonstrates that through this movement, the value of the gift increases, and he goes on to argue that: gifts that remain gifts do no earn profit, they give increase. The distinction lies in what we might call the vector of the increase: in gift exchange it, the increase, stays in motion and follows the object, while in commodity exchange it stays behind as profit (Hyde 1983, 37, emphasis in original). The vector of the increase, this movement of value following the movement of the object at hand, is another way to define the commons. As commons are legion, so is gift exchange—commons may “exist” without the gift, such as the fish in the ocean, but without the gift of shared knowledge and skills on how to fish ethically, commons cease to come into existence or can easily die. The management of the commons is tied up in the gift and reciprocal relationships, which in turn is created by gift exchange and is crucial to the maintenance and continuance of the commons—commons are crucial to building a system of exchange that does not lead to or enable overfishing. Key to 34 There are also commons of knowledge about how to make and use FLOSS code; and like the code itself, this knowledge takes material digital forms, in case of this knowledge, in documentation, IRC discussions, emails, web forums and the like. 81 understanding this relationship between gift exchange and the commons (as two aspects of the same totality) is Marcel Mauss’ argument that persons and things are indistinguishable in gift exchange (Mauss 1967). This does not mean that you are indistinguishable from the code you wrote, it means that the code-you-gave-to-me/us is always infused with that relationship. This way of keeping things of value in motion comes into being through the mundane work of moving code between FLOSS projects, which keeps gift exchange functioning on a variety of scales that have effects far beyond the act of the gift moving between two people or entities: 35 between people (such as between Torvalds and his friend who provided the first server space for the Linux kernel); between projects (such as between Debian and Ubuntu); between people and projects (such as people giving bug reports or small code fixes to Firefox). Yet such exchange frequently intersects with commodity exchange. 36 When Canonical produces the capacity for support, the creation of such a commodity (a support contract) requires the gift of Ubuntu. At the intersection between gift and commodity exchange the gift can easily die, or a gift circuit can be 35 FLOSS literature on gift economies often focuses on the fact that “on the internet the receiver is often unknown to the giver” (Bergquist and Ljungberg 2001, 313; se also Smith and Kollock 1999; Weber 2000; Benkler and Nissenbaum 2006; Bitzer, Schrettl, and Schröder 2007; Currah 2007). As Hyde explains, the gift is never about a relationship between two people—but the third party, the second giving that actually brings to gift into its own. Thus part of the bond created by the gift is always about a potentially unknown recipient, with unknown consequences, within the constraints of reciprocal dependency. 36 It is important to remember that a commodity is a good made for exchange on the market and that Ubuntu is not a commodity—it is explicitly made to NOT be exchanged on the market, coming with a promise to always be available free of cost, which disallows the creation of a market for Ubuntu. This does not mean that Ubuntu cannot be linked to something made for the market. For instance, you can walk into some computer stores and buy an Ubuntu CD with a year of “free” support. This couples Ubuntu to something made for the market—the material means for support—but Ubuntu itself is not a commodity. Sorting out commodities from gifts is a tricky affair and likely to be an increasingly important task as dependencies between capitalism and the commons increase in intensity and frequency. Furthermore, commodity exchange and capitalist exchange are often used to mean the same thing, but commodities can be made and exchanged without capitalism. 82 reconnected (meaning that the capacity for the gift is passed on to a third party, like David says, to anybody who needs it). Shuttleworth has used his capital to ensure that the gift keeps moving on, or at least is able to hobble on. For when gift exchange breaks, when the capacity to pass on the gift is squashed, other things break too. Such a break causes congealed labor to stop giving the gift of its dead labor to a current labor process—such as Stallman’s printer. Dead labor (in the form of the old code) could be brought back to life and combined with the living labor of coders (writing some new code particular to the new printer) in order to bring the dead labor congealed in the printer (the labor of the makers of its parts—its metal, plastic, toner, and code). But when code became a commodity not only was the gift broken, so was the printer and so was community’s capacity to create more gifts; the latter being the break that hurt Stallman the most. Shuttleworth’s frequent and strong advocacy in favor of synchronization reveals the stakes of this complicated system of exchange: There’s one thing that could convince me to change the date of the next Ubuntu LTS: the opportunity to collaborate with the other, large distributions on a coordinated major / minor release cycle. If two out of three of Red Hat, Novell and Debian are willing to agree in advance on a date to the nearest month, and thereby on a combination of kernel, compiler toolchain, GNOME/KDE, X and OpenOffice versions, and agree to a six-month and 2-3 year long term cycle, then I would happily realign Ubuntu’s short and long-term cycles around that. I think the benefits of this sort of alignment to users, upstreams 37 and the distributions themselves would be enormous. I’ll write more about this idea in due course, for now let’s just call it my dream of true free software syncronicity (Slashdot.org 2008, excerpted from Shuttleworth's blog). 37 “Upstream” and “Downstream” are terms that refer to a software project’s relative position in the FLOSS ecosystem. Ubuntu is “downstream” from many FLOSS projects, which means that much of Ubuntu contributors’ labor is related to “packaging” existing “upstream” FLOSS projects (such as the OpenOffice.org office suite, the Firefox web browser, the Gnome desktop manager and tens of thousands of others, the “upstreams” to which Shuttleworth is referring) into a fully functional operating system that is relatively easy and intuitive to use. 83 Reactions to this dream varied, as mentioned above, but many were very resistant to what sounded like a move to put Ubuntu at the center of the free software ecosystem. To be at the center of a gift exchange means to give the most—to be the entity through which the gift moves the most and creates the most dependency. To have Ubuntu be in such a position (along with other distributions) means that bug reports, code fixes, and the newest software moves to users and upstream organizations through Ubuntu. For instance, this would align with Shuttleworth’s goals for bug reports—to get as many as possible in Launchpad, linked through Ubuntu to other FLOSS projects, centering Ubuntu in a system of gift exchange and the movement of code. To understand how this movement works, in the material and mundane, next in Chapter One, “The Material World of Code” it is time to dive headfirst into code, that mysterious material thing. 84 Interlude: How Software Melts into Hardware Hardware melts into software and software melts into hardware. This is not just the computerized production of the computerized, but a moment when the boundaries that separate hardware from software fall away. These boundaries, how we separate hardware from software, are one of key ways that we make the computing environment around us into something that is representable and comprehensible. This is also the naturalization of divisions of labor that separate “mental” from “manual” labor, coders from circuit board assembly line workers, the laptop assembly plant from the software campus, Apple from Foxconn, Mountain View from Shenzhen. This separation is effective. I could think of the location and names of many software firms. I could think of the names of some of a few original equipment manufacturers (OEMs)—firms that make parts for computing devices and electronics—and original design manufactures (ODMs)—firms that design and manufacturer products that will be branded by another firm—such as Foxconn, the single largest producer of computer parts, the manufacturer of the iPhone, a giant that is both an OEM and an ODM. Yet I could not think of the locations of any OEMs, I had to look them up. This is in part because I have been studying software, not hardware. But OEMs and ODMs, their factory sites and factory workers are often all too invisible. And it is when OEM parts and ODM products are coming into being that software melts into hardware into software. At this point of design and testing, software and hardware are not so clearly differentiated. This is not just because it is hard to separate the two in their use; they melt into each other in production—very literally when something like a BIOS (basic input/output system) chip comes off an assembly line with code already part of the chip. As OEM and ODM parts and products are developed, software and hardware explode and disassemble. A circuit board that might eventually fit in your cell phone becomes the size of a table, for a moment. Canonical Field Application Engineer (F AE) Eddy, who works out of the Taipei office explains that when OEM boards are being designed: On the hardware side, they have a big board in the beginning, which becomes the reference board. The reference board will have lots of different ports and it’s big and a bit confusing. You are always putting on new components somewhere, it is never the same. Always new stuff on the board that you need to evaluate. Sometimes there are different “big boards” with different parts. The big board in the beginning is very unstable, it probably can’t even boot. We have to work with the BIOS, the kernel guys. In the beginning we are just guessing, putting things in, seeing what works. And to make it work, it’s just guessing what happened, really just guessing! Because you have no idea, because this is a new project or a new kernel. And we can fix it either using a software way or a hardware way. 85 It is not as if hardware is designed and comes into being as a laptop, and then software is built to run on that laptop: they emerge together. Eddy believes it is Microsoft’s dominance in this process, in chip and component testing, that is the biggest hurtle to FLOSS adoption: The ODM business is really interesting. From OEM to ODM to the end, real customer it is an long interesting process. Canonical and open source is striving to adopt into it. And I can tell you that Microsoft is so much better. The key part is the diagnostic tool. The Microsoft diagnostic tool is so great. You know of WHQL? Windows Hardware Quality Lab. It’s a certification that if you plug this into the system, it will work, there will be no driver issues. There is nothing like this for Linux. And it is really important. Think of it, there are thousands of components in a single board, and that board is not bigger than this [holds fingers a few inches apart]. How do you manage to make it work? It’s not black magic. It’s a lot of tools. Software tools, like Microsoft WHQL. In Canonical people think “this thing doesn’t work, so it is broken, it needs to be returned and fixed.” But who will fix it? Most of the coders, when they get hardware that doesn’t work, this just return it. If they really like this hardware, they will figure out a way to come up with a [code] fix. After the big board, in the beginning they will have like sixteen boards, and testing of which is better. The boards are very dynamic. They have SMT. Surface Mounting Technology. It picks up the components and puts it on the board. So they will do lots of experiments in the beginning. And before you get a board there is lots of work to do. Open source needs to get involved at the level of chip design otherwise it will not succeed. Let me tell you one example. Using Windows diagnostic tools there is an black hole, there is an invisible that you can not see. RTC, real time clock. Because Windows XP does not care about the RTC. It just works. It works. But with out RTC, Linux will crash. It will not boot. This is not just a technical issue to be sorted out in software for Eddy, as this problem became apparent as a board was being produced that would eventually become part of computer designed to run Ubuntu. He had to make a trip to troubleshoot a board coming off a production line: I can tell you how serious it is. Think about it, the manufacturing line, it is moving and because of a serious problem, they hold the line. It means that all the equipment is powered on, every worker, every operator needs to be standing by, the line is waiting for you. To fix that. And every second counts. In the factory, one second can become thousands of dollars. Of course, the labor processes, materials, and machinery of making software and the forces of production for making hardware are usually quite separate for most workers. As Eddy indicates, making a laptop is a lot like making a car, except personal 86 computing manufacturing has never really known the vertically integrated factory. Making the computer I am using to write this dissertation “involves more than 1,000 discrete acts of labor, typically conducted in ten to twenty countries” (McNally 2011, 54). And this likely conservative estimate of labor consumes plenty of resources: the production of a single PC requires sixteen to nineteen tons of resources and seven-hundred different substances, including metal (50%) and numerous heavy metals, synthetic materials (23%), glass 15%, and electronics (12%). More than three hundred kilograms of waste and three tons of carbon dioxide are also produced (Junker and Lang 2001 in Fuchs 2002, 10). Part of this waste is the acid used to clean the silicon that will be used to create the technology that is the basis of all digital computing, an integrated circuit, or, a chip (Mayer 2009, 138). It takes approximately six to ten gallons of water per chip to clean the acid off the silicon, and even with efforts at recycling water and reducing chip size, silicon plants consume and pollute massive amounts of water. Free software workers interacting with OEM and ODM management and engineering workers and with OEM factory line workers does not and likely will not cause an ethics or way of working with free software to spill over into hardware production. Yet, something along these lines is exactly what is at stake. What happens when and if software workers and hardware workers see themselves as part of the same collaborate project? That this is unlikely is obvious, simply because such collaboration is very distant and nigh non-existent. What collaboration is required to make this work become a point of interface through which it can be true that coders own their own means of production? How would hardware workers intervene in and change the process of making software? How would the rhythms of the FLOSS ecosystem change if there was an ongoing interaction with a free hardware ecosystem? In this hypothetical world, the jobs, forms of computing devices, and very ideas we have about software, code, and hardware would radically change. It is only through the separation of hardware from software on this very material level of hardware factories and software campuses that we have the computing environment that stands before us as we sit at a keyboard. It is essential to recognize that there is nothing natural, inevitable, or fixed about this computing environment, from human interface design (the physically abusive horror that is the inertia of keyboards and mice) to the cadence of manufacturing (an entire industrial process organized around new features, innovation, and filling up dumps, rather than stability, quality, upgradability, or reuse). This world, your keyboard, my phone, all could be very different and in the moments when software melt into hardware, these alternate futures and presents flash before our eyes. 87 Chapter One: The Material Worlds of Code When man engages in production, he can only proceed as nature does herself, i.e. he can only change the form of the materials. (Marx 1993, 133) All the phenomena of the universe, whether produced by the hand of man or indeed by the universal laws of physics, are not to be conceived of as acts of creation but solely as a reordering of matter. Composition and separation are the only elements found by the human mind whenever it analyses the notion of reproduction; and so it is with the reproduction of value. (18th century economist Pietro Verri, Marx's citation for the above; Marx 1993, 133) So far I have been fairly fast and loose with the meanings of code and software— though not without intention. 38 Before going into any further analysis of the Ubuntu labor process it is necessary to take a detour into code—that thing that is both the primary object Ubuntu contributors labor to create and the primary means required for creating Ubuntu. 39 In some ways having the very same thing as the means and object of work is not so deep—workers have long been using machines to create machines. Seeing code in this trajectory makes sense if code is considered another manifestation of a long line of machines that have been put to work to transform labor processes and that have also 38 Caveat on this chapter—watching The Matrix could make reading this more interesting. Or, a little bit of Neo might be a nice break if things get strange or abstract; it might even make reading more fun, and possibly make all of this make more sense. 39 It is essential to note that much of the “creation” that occurs as a result of Ubuntu contributors’ laboring is also well described as “gathering,” or in the technical parlance, “packaging.” 88 become part of our daily lives, such as a water pump or a tape player. Then we can see email in relation to the answering machine and the telegraph—both of which are technologies that shaped email’s technical structure and practices of use. All three of these technologies require large systems comprised of network infrastructure, the development of machines that process signals, and workers (as producers and consumers) who develop new sorts of literacies. All of these prerequisites for technology adoption were enabled through massive investments by the state, often at the bequest of capital seeking an educated workforce and stable infrastructure, all of which fundamentally changed many people’s relationship to time. The effects of digital computing and then networked computing and the internet are central is various academic literatures, but the thing at the base of these transformations and all things digital, computer code, remains in a mysterious black box, rarely interrogated by the glut of scholarship on digital media and digital computing. Code, as we shall see, is fundamental in how the temporality of these technologies comes to be and is experienced—code and how we know time are increasingly intertwined. I believe that code’s general absence from scholarship is because code, in its operation or execution, is not like any previous machine or media because of its qualities of transformation and movement, yet it is these two categories that scholars have on hand for dealing with technologies that rely upon computer code. While the possibilities resulting from the use of computing devices (not only those that are networked) are certainly game changing, it is far too easy to focus on the play and overlook how the rules of the game have changed and not changed. Even more dangerously, it is also easy to 89 erroneously infer rules from the appearance of the game; to see what is carried by code— music, video, text, ideas, knowledge, data, anything encoded—and compare that content to content from a previous iterations of media to deduce how things have changed. Code, however, is at once this content and the means of its transformation, creation, and movement. Scholars recognize that code is in play (or at work) in a variety of arenas: as the infrastructural driver of a mode of information production, i.e. the so-called “new media” (Manovich 2001), as a framework for structuring ideologies and acts of control and freedom (Lovink 2008; Chun 2006), as a creator of new laws (Lessig 1999; Thrift and French 2002), as a driver to the “new” economy, i.e. “creative industries,” “information society,” etc. (Castells 2001a; Florida 2002; Bayliss 2007; Scott 1999; Asheim, Coenen, and Vang 2007; Jessop 2000), as a opportunity for new forms of expression and self (Turkle 1995; Hayles 1999) and as the center of a new culture of hackers (Himanen 2001; Thomas 2002; Wark 2004; Coleman 2005; Kelty 2005). Although some healthy skepticism should be applied to the “newness” of code that threads its way trough all these literatures, there is certainly something to the “new.” At the same time, code is also fundamental. Code is new, in that it does not readily have an analog in other commodities, medias, art forms or human expressions—even the dominant trope for understanding code, taking it as a form of writing, is tenuous at best when our theories of writing are seeped in thinking about the relationship between spoken and written language. 90 Yet code is also fundamental in that the binary logic at the base of all machine readable computer code is very old (approximately eight century B.C.), mass produced programmable machines have been around since eighteenth century looms, and programmable, digital computers using binary first appeared in the early 1940s. The development of these first digital computers must be seen as extending out of logics of modernity, enlightenment calculus and physics, and the scientific conquest of universal knowledge. In this sense, code may be new, as a form, but the principle of its operations are old, and thus code is fundamental to modern life, as code itself as a form emerged out of the machinations of war (it was the push to break German codes during WWII that created the conditions for organizing people and resources to make the first digital computers). Norbert Wiener worried dearly about the militarization of science, and the use of computing machines to extend human capacities in destructive capacity; that machines could be used by “these worshipers of efficiency [who] would like to have each man move in a social orbit meted out to him from his childhood, and perform a function to which he is bound as the serf was bound to the clod” (Wiener 1962, 50). Wiener’s ambivalent approach to computing machines in The Human Use of Human Beings: Cybernetics and Society is instructive. Digital computing is thus also fundamental to the world before us, as it was in Wiener’s moment increasingly fundamental in communication and management, and in this moment, almost invisible in its ubiquity. Rather than try to define and understand the nature code in the abstract—a project to which I have lost many months, only finding failure and uncertainty—I begin from broadly locating code in its economic context. My hope is that folk (myself included) 91 pause to think: When I think about code or software, what do I imagine it to be? Where is it? What does it do? How does this imagination shape how I understand economic change, work, and the social life of things of value and their exchange in general? That is, in terms of its production and exchange, how does code function? What economic concepts help us understand code and what concepts end up occluding the work of code and need to be rethought? My challenge then, is to cobble together an understanding of code that can help establish connections between code and place, location, time, and bodies. Thinking about code “carrying” software—what is carried from where to where, using what resources at whose bequest, over what time period, by what energy and whose labor—offers the possibility to think seriously about the materiality of software and the practices that bring software into being and simultaneously enables its invisibility. In what follows I make a tentative case for four essential points for thinking about code. First, code’s formal structure (or writing) does not hold the key to making sense of code. Second, code is the material with which coders work. Third, the speed and movement of code is crucial to understanding code’s relation to information. Fourth, code must be understood as a good, not a service. Now it is time to finally delve into the relationship between code and software in order to understand the dual nature of code. 92 I. The Relationship Between Code and Software The meaning of a computer program is unambiguous and literal, and can be understood entirely by analysis of the tokens and structure. (Downey 2002) How to Think Like a Computer Scientist, Learning with Python, a popular textbook that teaches python, the primary programming language of Ubuntu production, introduces computer programs with the above statement that encapsulates the dream of universal knowledge embodied in code. In this dream, the realm of computers and computer code is completely knowable, and through digital computing’s capacity to turn the world into data, has the potential to know anything. Before delving into the relationship between code and software, this common sentiment about computer programs deserves some attention. A “computer program” is a nice concept that will allow us to focus on code and software: a computer program is code that can be executed and performs some action (almost always taking some input and putting that input into a form that can be stored and read later). 40 Any piece of what we would call software consists of thousands of computer programs—and I return to what constitutes software shortly. Contrary to computer science common sense, the meanings of computer programs are far from fixed or knowable. The meanings of the tokens (some representational object that marks the right to perform some action) and structure referred to above change 40 I have chosen not to use the language of computer science, such as Open System Interconnection (OSI) model for communications systems or the divisions between different categories of software typically used in computer science education. Instead I attempt to explain code in software from the perspective I came to know it—as a non-technical person who is interested in how things work. 93 over time—meaning that the “token” might read and write the same thing for the life of the program, but the initial source of the data for that token can change, changing the meaning of the token and making clear that the intention of the author does not define the meaning of a computer program any more than the meaning of a novel. In that vein, the reasons for the choices made by any program’s “author” are unknowable. Further complicating the meaning of a computer program, the structure of the program is also embedded with ideology—the program indexes users (humans or machines) of the data carried by a token as recipients with certain characteristics. The very structure of the tokens themselves carry ideology—representing particular ideas about how computer programs should operate, ideas with which the coder may struggle against and use the programming language’s rules against their expressed intentions. Complicating the “reading” of a computer program even further, the human readable language in which a computer program is written is often unreadable even by its own author. In other words, the program may perform its actions as intended, but figuring out how the program performs such actions is unknowable (or at the least, very difficult to know) because of how the program is written. I go through this litany of perhaps confusing reasons for why the meaning of code is not knowable from the analysis of its tokens and structures because the primary thrust for “software studies” within the academy is predicated upon this being possible. 41 Studies of networked media are numerous and diverse in “new media” studies, but few have studied code or software, focusing rather on media objects. However, Lev 41 Critical Code Studies (CCS) offers different visions of how code could be studied by focusing on the various structures of code and coding and the “extra-functional significance of source-code” (see http://vectorsjournal.org/thoughtmesh/critcode). 94 Manovich called for the development of “software studies” in his 2001 book The Language of New Media, challenging scholars to work at understanding transcoding (the “reconceptualization” that occurs when data/media/information becomes digital) and the two layers he identifies in all new media objects: the computer and the cultural (Manovich 2001). Manovich seeks to take seriously the materiality of media and how the structure of a computer program affects the choices and outcomes of media transcoding. However, as Chun points out, this version of “software studies” privileges code as readable text, ignoring hardware and the broader social and economic context of transcoding in a manner that assumes that a computer program is a translating device (Chun 2006, 15). Understanding computer programs as translators assumes that what you see has a direct correlation to what you do not see, not only erasing the ways in which code and screen do not correspond, but also continuing a privileging of the visual as a mode of knowing—as if seeing and thus reading code, or thinking like a computer scientist, would reveal its true nature. Code as Media or Text Like other media, software makes sociality possible. (MacKenzie 2006, 173) This formulation seems to lie at the heart of studies of “new media.” New media tools enable more people to participate in creating media in new forms (remixes, mash- ups, machinima, blogs, etc.) that are positioned as more democratic, more challenging to 95 media oligopolies and holding more possibilities for politics than “old media.” Yet such a formulation demands serious questions before even approaching evaluating the work of “new media,” the least of which is: Does media make sociality possible? Before this can be thought seriously it is also worth asking: are either code or software media? The short answer for now is that software can be media—in that it caries information and other signals—but code is something all together different. Those in the academy who write about code or software often begin their work not with defining code or software, but with explorations of why code and software are understudied, especially when they are in play as basis for arguments about “the network society,” “the digital age” or the like (Thrift and French 2002; M. Dodge and R. Kitchin 2005a; Graham 2005; MacKenzie 2006). A case in point is a special 2005 issue of the Annals of The American Academy of Political and Social Science on “Cultural Production in a Digital Age” wherein code is completely unspoken and software is thought as a media artifact. One article on newspapers and cultural production did not mention software, coding or any related labor in an analysis of the creation of an “internet Department” for a newspaper (Boczkowski and Ferris 2005) and another article that purports to analyze the “production” of children’s software titles proceeded to treat software as a media object, an analog to children’s movies (Ito 2005). This is not to say that either of these articles do not offer valuable, productive and interesting insights, but rather that for various reasons, code and software as objects of study are not just unaddressed, but seem to be out of bounds, especially in “non-technical” fields of study. 42 42 Perhaps unsurprisingly, the recent push for the “digital humanities” is also mostly void of any meaningful consideration of the material realm of code or the conditions of its production; favoring instead a techno-liberaionist bent. Even in such scholarship’s critique of the liberating promises of technology (e.g. Balsamo 2008), the belief remains that if only the right people (humanists) played a 96 Within geography, where the material and infrastructural are key objects of study, reasons given for software or code’s occlusion include arguments that software takes up “little in the way of visible physical space” (for instance, there is a seduction to “mapping the internet” in terms of locatable fiber optic cables, root servers and traffic flows, but the same cannot be done for software); that software’s actions are temporally differed; that code operates invisibly in-between nodes understood to have agency; and also that we are “schooled in ignoring software” as we are in ignoring standards and classifications (Thrift and French 2002; M. Dodge and R. Kitchin 2005a). I find this partially convincing— more so the fact that software cannot be seen and that the work of software is located in other nodes of action, less so the argument that we are schooled in ignoring standards and classification—in part because standards (law, social codes) and classification (taxonomies, racial hierarchies) are frequently not ignored, even if their study is marginalized. Yet thinking about classification and standards does hint at a potentially more compelling reason for why software remains in the background. There is a desire to understand software as standards and classifications (see especially Lessig 1999, Code and Other Laws of Cyberspace), and whether or not this is an acute or useful way to think software, it can be read as a desire to think software in terms of policy. New standards can be proposed and advocated for, classifications can be rethought, new taxonomies introduced and software enters the realm of an ordered, knowable system. Social scientists could then end their papers with policy recommendations and all would be well. But alas, software is not easily thought in terms of policy. Which is not to say that role in shaping technology, the promises of technology would be delivered. 97 software should not be taken into serious account in the formation of government policy, as software intersects with battles over “net neutrality,” intellectual property rights, censorship and privacy. For instance Stephen Graham’s call to expose inequalities of “software-sorting” technologies with policy-based research is certainly an important move (discussed below). Rather, the point is that social science tools and patterns of intellectual worth evaluation are at least partially rooted in a pseudo-empirical policy imperative in which thinking about code as an object of study does not easily rest. On the humanities side of things, scholars interested in various post-structural theories have found thinking about code and/or software as media or text (especially as text, and often positioning the internet 43 as a thing of text itself, without mentioning code of software) to be a fertile proving ground for theory. Chun succinctly describes the imaginaries of possibility produced by the internet as “theory come[sic] true:” i.e. the internet being rhizomic or smooth and striated space (Deleuze and Guattari 1987; come true in Nunes 2006, 62); netsex proving that sex is discursive (Foucault 1990a; come true in Blair 1998); “passing” on the internet proving that gender is performative (Butler 1993; come true in Wakeford 1999a). 44 An edited volume from 1999, Cyberspace Textuality, makes evident Chun’s argument. Marie-Laure Ryan, the volume’s editor, points out that theorists of “electronic textuality” have found parallels with the work of Derrida, Foucault, Lyotard, Baudrillard, Deleuze and Guattari and that: 43 In this humanities literature, the internet is often treated is if it is the World Wide Web. As a reminder, the internet is the infrastructure, the cables, switches, servers, fiber, and every computer that is connected with this infrastructure to the public internet (there are plenty of non-internet networks). The web is but one means of utilizing this infrastructure; others include peer-to-peer connections, steaming movies, email, chat messages, voice-over-IP and video calls, and backup services, and there certainly will be more ways of using the internet that are not the web which we cannot readily anticipate. 44 Concept is Chun’s, the examples are mine. 98 the aspects of contemporary literary theory that find their fulfillment in hypertext hardly need explanation ... the open text ... intertextuality ... nonlinearity ... the death of the author ... the empowerment of the reader (M.-L. Ryan 1999, 101). This work that Ryan assigns to hypertext is only enabled through an understanding of software and its division from hardware: “a computer, it will be remembered, is a machine able to execute sets of instructions ... through software, however, it can simulate a number of existing devices and human activities” (M.-L. Ryan 1999, 87). “Hypertext,” a stand-in for a wide variety of softwares and technologies that through their agency as material-independent constructs enable the politics of literary theory’s critique of the text and the author to “come true,” indexes an understanding of difference that is unbound from “bodies, place and time” and translatable into digital texts without loss. In the same edited volume mentioned above, N. Katherine Hayles demonstrates that she takes code more seriously than most, in that she addresses software directly as an agent, rather than leaving the work that software is presumed to do unspoken. Hayles is willing to make the assumption that artificial life is already here in some mode, and to think about software as an agent in early experiments in artificial intelligence where “a program ... is and is not a simulation, for it at once mirrors the world outside and engages its own independent simulation” (Hayles 1999, 218). Hayles ends her chapter by concluding that literature and science are no longer separate discourses, that they speak in perhaps the same voice, from the same sites “constituted through a chaotic dynamics that generates global patters out of local differences” (Hayles 1999, 220). This statement encapsulates one key tenet of software imaginaries: software is the means by which “the global” is stitched together and source of the pattern through which it is organized. 99 Although coding “languages” are not like written or spoken languages, it is still through the deconstruction and analysis of language that scholars argue that we can understand internet technologies, and therefore understand new global/local conditions and spatialities. Geographers Nigel Thrift and Shaun French define software as a “vast Derridean intertext,” or “Derrida’s critique of phonocentricim and logocentricism made flesh” or “a product of the actual writing of code” (Thrift and French 2002, 310). In all three possible definitions, the writing of code is understood as a supplement to existing spoken or written language. While in the earliest of moments of coding when code literally replaced spoken commands (uttered to a computer, i.e. to a human doing computations), this might have been true, but current coding languages complicate the matter. There may be some interesting analysis to be done regarding the function of the English language as a referent for coding phrases, but coding languages have no spoken form. For Thrift and French “programming languages, email and other forms of ‛net speak,’ [and] software packages” are all collapsed into new sets of “textualities” that characterize communication in an internet age. Recognizing that these forms of “writing” are fundamentally different, Matthew Fuller, one of the other founders of software studies, seeks “software criticism” that is aimed at figuring out new ways of understanding code to the end of undermining software oligopolies who seek to control the language of the digital age (Fuller 2003, 11). The criticism that Fuller proposes is very formalist, arguing that it: should be possible to analyze a piece of software on the basis of procedurally documenting every point which constitutes an event, to record the points at which we move from one state to another or at which boundaries are produced to certain behaviors (Fuller 2003, 143). 100 This sort of criticism can certainly be useful, for instance, in evaluating the discipling effects of Microsoft Office’s “Clippy” object (the “talking” paper clip help box) as one might approach a similar analysis of the discipling project of teaching cursive writing in elementary schools. Doing so would take the organizational modes of computer program design seriously, using the object-oriented programming 45 of Microsoft Word to implicate labor practices (although not explore them) and link these practices to the possibilities of use offered through a particular computer program: “the use of toolbars in Word is predetermined not only by the inherent qualities of object-oriented software, but by Microsoft’s approach to using it” (Fuller 2003, 142). Yet, such a formal structure of analysis—a mode based in seeking to regain “control of language” and the development of better computer programs—places power solely in the hands of high level decision makers within software companies, not in discourses of and by coders or users. For instance, when thinking about the choices that coders make, Fuller argues that decisions are based solely upon the number of lines of code necessary to accomplish a particular function (Fuller 2003, 150). Such implicit rational-choice modeling of coders’ choices turns coders into automatons, ignoring education patterns, workplace conditions and other political-economic processes while denying the potential for coders to locate some other meaning or purpose in their work—or to see how fun is (or is not) at play in coding. Both “Software Studies” founders, Manovich and Fuller, do important work of pushing for a formalist study of code; much is a mode of understanding that is fraught with problems, but not with out merit. In these formalist works, code is a system of rules 45 Object Oriented Programming is a modular system for organizing and structuring both the coding process and the functioning of applications where each “object” in a software application can handle data independently of others “objects.” 101 that translates one symbolic language to another. Thus code “works” in a computational sense regardless of a computer program’s function and the work of code and the labor of bringing it into being are shut out of the “work” of code. A formalist study of code should be possible without closing off code this other work (perhaps following a model like social art history 46 ), something akin to what geographers have attempted to do in focusing on the digital and everyday life. There is a large literature in geography on “cybercities” (see Cybercities Reader, ed. S. Graham 2004) that explores the ways in which communications technologies are interwoven with the fabric of everyday urban life and rethink cyberspace as a material and ideological spatial process. Interestingly, a handful of Britain and Ireland based geographers have taken up precisely this point—exploring code and software in the making of spaces of everyday life (Donert and Graham 2000; Thrift and French 2002; M. Dodge and R. Kitchin 2005a, 2005b; Graham 2005; Martin Dodge and Rob Kitchin 2009; Beer 2010; see also Wilson 2012). 47 Although this literature rarely addresses code or software directly, Thrift and French attempt to understand and document this process of “weaving” as being a combination of computer programs and everyday life. They consider computer programs to produce a series of “writing acts” that automatically 46 “Social art history” emerged in art history in the 1950s when theories of the social, political, and cultural life of art became more central to the discipline and interpretation becomes about questions of audience, reception, cultural context, historical specificity, contingent meanings, etc., rather than the supposedly intrinsic or timeless or “artful” formal qualities of the object (Nelson and Shiff 2003). Formal analysis is not tossed out with this move, but rather put in a different context, something that might be very useful for the emerging discipline of code studies. The forthcoming 10 PRINT CHR$(205.5+RND(1)); : GOTO 10:, a multi-author book on a single line of code may offer an example of this sort of approach to code. 47 Why it appears to be only in the UK and Ireland that geographers are writing about code is an interesting question onto itself. I imagine it has something to do with British cultural studies (Burmingham School) but I don’t know how or why. 102 produce space (Thrift and French 2002, 310). This departs from more formalist approaches to code by arguing that code cannot be reduced to a referential textuality or to a mode of translation. Thrift and French decide that regardless of how software might be best thought to “work,” it puts into question what counts as “life” and it is best to move forward by thinking about hybrid human-object networks (cyborgs) and the performativity of the writing act of software. Thinking through the development and functions of algorithms deployed to parse day-to-day life (that govern the operation of traffic lights, Amazon.com and Netflix recommendations, elevators, dating services, cars, who is stopped by security at airports, etc.) via a semi-formal analysis (in that they do not address coding practices, rather the functions of code) is a good start towards a loose model for addressing the lives and work of code and coders. To understand this deployment of code they argue that two geographies of “software programming” need to be addressed. First, where this coding occurs, by whom, under what conditions and with what tools as the “modern economy is built on software ... and the need to produce more and more lines of code,” and secondly, a geography of power (Thrift and French 2002, 325). This geography of power is understood to function by way of a particular application of governmentality where software is given agency onto itself: [Software] has changed the nature of expertise by producing new templates for decision making [sic] and it is changing the nature of human subjects by producing enhanced capabilities and by questioning not just what techniques of the self consist of, but whether the self is a meaningful governmental category (Thrift and French 2002, 325). 103 Although they do not talk directly about the production of code, by starting to think about the geographies of code (where it is made, by whom, how it moves, etc.) and the role of code in capitalist accumulation (the need for more code), Thrift and French offer a path towards understanding code and software. The challenge then, is to establish connections between code and place, location, time and bodies. This process of rendering connections between code visible is very slippery. Adrian Mackenzie provides many examples of code as art in an attempt to demonstrate moments where code becomes visible and makes the above connections, but I am skeptical of this as an exercise that reveals that workings of code because the very act of “seeing code” is a moment of mystification and occlusion that further produces the abstraction of code. Coders can read source code (and in some cases, machine code) and see the traces of movement between bits of code. Focusing on when code becomes visible makes sense in terms of Mackenzie’s goal of moving software from “ordinary invisibility to visible importance” (MacKenzie 2006, 170). Visibility easily becomes a metaphor for there being some sort of veil to be lifted by appropriate theory and knowledge that would then render software visible and knowable. However, another reading would understand “visible” as “in play” where all kinds of sensory receptions of software and orchestrations of bodies (biopower) are engaged in an ongoing circulation of code. Which is to say, making code visible is not all that deep. It is like thinking about and following the effects of any other good that is commonly ignored in our daily lives and brings focus on the people who transformed the good and where those different transformations occurred, the good’s movements before 104 and after its use, and how these process will likely continue after that good’s use in the moment. Fortunately, this path towards thinking about the labor geography and materiality of code, or a similar path, has already been marked out by scholars concerned with code itself. I am particularly inspired by the work of Mackenzie, and his book Cutting Code: Software And Sociality. Following Bruno Latour (Latour 1993) Mackenzie asks why the technological mediations that are increasingly interwoven into the fabric of everyday life are so rarely represented as such. Mackenzie asks great questions (often with frustrating answers) such as “how does something such as Linux become the object of intense feeling” (MacKenzie 2006, 71)? Having seen someone reveal a tattoo of a Linux distribution’s logo to settle an argument over which distribution is best, such questions resonate with me. Although I only came into meaningful contact with his work late in the work of this dissertation, Kittler’s fascination with the digital and electronics serves as a guide for much of my work that follows: Since computer technology (according to the heretical words of its inventor) is at the point of “taking control,” the term hardware no longer refers to building and gardening tools but to the repetition, a million times over, of tiny silicon transistors (Kittler 1999). Kittler’s concern for the politics of technology and for understanding what technological change actually means in a holistic material and philosophical sense is inspiring, if at times a bit opaque. Discussing the relationship between knowledge, technology, state investment in infrastructure, and the university, Kittler gets to the heart of what taking control comes to mean: 105 The short history of European universities should have shown, on the other hand, that knowledge is not to be had without technology, and that technology is not to be reduced to instruments. Moreover, the anonymity of knowledge, for which Alan Turing 48 gave his life, makes it ever more impossible to decide whether major states will continue as before to be responsible for knowledge institutions such as universities. One thing is certain, however: it will be decided, regarding the legacy of this time, who set up which hardware when (Kittler 1999). Combined with some crucial guidance from geographers insisting that we pay attention to both place and capitalism, Kittler and Mackenzie can offer us a path towards understanding code. The Dual Nature of Code Software and code are often thought as interchangeable, even by those who pay some close attention to computer programs (i.e. M. Dodge and R. Kitchin 2005a). Software is generally considered the “intangible rather than physical” 49 part of a computing device, a distinction that casts both software and code into the realm of the invisible, fleeting, and placeless. Even if there is no software as Kittler argues, it is still necessary to confront the commonsense belief that there is such a thing as software, that 48 Although Alan Turing’s work and life is not part of my dissertation, his biography, Alan Turning, The Enigma, is a beautiful book, about, as the sub-subtitle tells, “the extraordinary story of the brilliant scientist who broke ‛enigma,’ Germany’s most secret World War II code, who pioneered the modern computer age, and who finally fell victim to the cold-war world of military secrets and sexual scandal.” It is also an inspiration both in terms of writing and dedication. The biographer, Hodges, was a mathematician whose interest in Turing developed partly through mathematics and partly through his participation in the ‛gay liberation’ movement … he decided that only a substantial biographical effort could do justice to so many-sided a figure. After giving two years to this, his first full-length book, Andrew Hodges has returned to mathematical research (Hodges 1983). Hodge explains the math and material life of early digital computers beautifully, as he does Turing’s complicated life as a gay man working between Universities and the military. 49 A Dictionary of Computing, Oxford Reference Online, s.v. “software,” in Mackenzie 2006. 106 you can go buy software at a store or download software via the internet and that whole industries are organized around its production. In literature that does seriously consider both software and code, code is generally understood to be the thing from which this bigger, more cohesive thing of software is made: something like parts (code) to make a toaster (software), or something like a blueprint (code) from which a building (software) is made. Or, in Mackenzie’s more elegant formulation: code carries software. Thinking about code “carrying” software—what is carried from where to where using what resources at whose bequest over what time period by what energy and whose labor—offers the possibility to think seriously about the materiality of software and the practices that bring software into being and simultaneously enables its invisibility. This still leaves open the question, what is software? But it does at least partially define code as a “base” element of some kind. From this position Mackenzie states that “I use code to understand the mixture of mutability and stasis associated with software ... using code reduces the risk of freezing and formalizing software” (MacKenzie 2006, 6). This mutability is an essential property of code and resisting the formalization of software is key, but it still falls short of getting to the material base of code and its relationship to software. Mackenzie encapsulates a wide variety of arguments by proposing that software “embodies a mixture of the mutability, contingency and necessity symptomatic of recent time” (MacKenzie 2006, 2). While software might not embody “recent time,” as its logical and theoretical roots are old, it certainly does in many arguments about the the role of the internet, cyberspace and the “network society”—see Manuel Castells’ assertions that “open-source [software] ... is the root of the internet 107 world” (Castells 2001a, 9). Software and code are heralded as the root of flexibility and contingency, especially in accounts such as Castells where the differentiated capacity to engage with such “flexible,” networked systems accounts for global inequality and broad social and economic changes. Mackenzie puts such assumptions into question by arguing that the sociality of software is hard to represent and more importantly, we cannot assume that we know what software is. Considering how software definitions have changed over time—once any part of a computer that could be altered, from memory to removable metal parts, was called software (Moglen 1999)—I take not knowing what software is not as a starting point from which to define software, but as an ending point and an ongoing reminder that it is important to frame such work not as a search for definitions, but an open question about dynamic relationships. Below is a piece of source code from a 1994 version of the Linux kernel. I hesitated placing code in the text of this document—it is akin to using a photograph of a crowded square to represent a place, knowing the limits of a single captured moment, the photographers gaze, and the like. Also, I am not interested in what can be gleamed from a formal analysis of the rules and logic of writing code, but rather what hints about the broad social context and labor process can be gleamed from such moments of looking at source code. This all said, I think it might be worth demonstrating how code is not legible without other software; how code is always citing both other coding practices (in this case another piece of software that is proprietary and “closed” and cannot be understood) and just how much of coding rests on the unknown, even as it is represented as a process always approaching universal knowledge. Furthermore, here we can see 108 how code appears as both a piece from which a larger whole is assembled and as a set of instructions—but exceeds both analogies: /* * Yeah, yeah, it’s ugly, but I cannot find how to do this correctly * and this seems to work. If anybody has more info on the real-time * clock 50 I’d be interested. Most of this was trial and error, and some * bios-listing reading. Urghh. */ #define CMOS_READ(addr)({\ outb_p(0x80|addr,0x70);\ inb_p(0x71);\ }) source: Kernel 0.11, main.c, 1994 51 It is tempting to propose analyzing code by the notes that coders leave for other coders and themselves (anything above with a “*” in front of it above) as part of an enriched formal analysis of code ala Fuller or Manovich, but especially considering how code such as the above is inaccessible in any proprietary software product, such a project might not be able to deliver the truth about code it seeks to unearth. Yet such analysis of the structure and form of code remains important. Mackenzie uses this piece of code to demonstrate how “code can be read as permeated by all the forms of contestation, feeling, identification, intensity, conceptualizations and decontextualizations, signification, power relations, imagining and embodiments that compromise any cultural object” (MacKenzie 2006, 5). While this seems to be the beginnings of a promising exploration of the social context of coding and an interesting way to read the legible parts above, Mackenzie’s argument positions code and culture as separate processes where “technical practices of 50 The real-time clock (RTC) is the same problem that caused Eddy to find himself at a stopped manufacturing line sixteen years later. 51 Cited in Mackenzie, found at www. mentalhygiene.com/kernelnotes.html accessed 11/30/2006. 109 programming interlace with cultural practices” (MacKenzie 2006). A read of the notes above or any serious thought about “technical practices” or “cultural practices” reveals that such a false division rests on the valorization of technical practices as universal and without culture until they intersect with “cultural practices.” This tension of how to deal with code as “technical-cultural” runs through studies of the sociality of code—all too often privileging the technical as universal, even when seeking to locate the historical and cultural origins of technical practices. Instead of reading the intentions of such code for its cultural and technical origins (which is an important and worthwhile endeavor!) I am more interested in what the above code does. After several years of trying to read code, learning a bit of two programming languages, talking to coders and learning about the origins of code and its languages, I still cannot understand the above snippet of code in its complexity. Simply, what this bit of code does, and what most bits of code do, is to create a variable, ask another bit of code for a value, populate the variable with that value and then allow other processes that might need that value to reveal it—even if what is needed and reveal is often opaque and nigh un-readable. Or, even more simply, in a matter of milliseconds, with the help of electricity charging some alloy, the text above eventually transforms some material and creates something new and useful. Code thus has two forms of being: first as human readable text or as machine code (0s and 1s); then when machine code moves, code is both movement and machine, and is the stuff from which everything digital is made. Of course, things are a little more complicated than this, as the human readable form of code is written using code in its 110 moving, material, machine readable form. In order to write human readable code, compile that code into machine code, move, share, copy or do anything with that code, other code moves between its two states many times. What makes code different from any other bit of data entered into a computational device is its potential to be compiled and become active. If code is understood as human readable text that can tell some other code what to do (and eventually, through many layers of other code, to tell a computing device to send some output), it is easy to see why it is often thought of as a set of instructions. As machine language (0s and 1s) that ends up being part of a lot of other machine language that achieves some goal, code makes sense as a part or piece of machinery. Here it is important to note that the two forms of being for code I am distinguishing is not the same thing as distinguishing between source code and machine code. Source code is the human readable code that coders chose to make available in FLOSS labor processes; the very form of code that proprietary labor processes keep hidden by distributing only machine code. 52 Rather, the distinction I am making is one of movement. Code can refer to the material form in which something akin to a set of instructions reside, which can function as a piece of a larger whole; code can also refer to executing, moving, malleable, and unknowable (again, in this form code cannot be gleamed with any human senses) 52 For instance, when you download Adobe’s Flash Player so that you can view a YouTube video, all you are downloading is the binaries. From that code it is nigh impossible to figure out how Flash works. However, some coders are interested to take on the nigh impossibility of this task and have worked through the painful process of reverse engineering parts of Adobe’s Flash Player to create GNU Gnash, a FLOSS Flash player. This process is severely impinged by an Adobe license which makes it illegal (under the DMCA) to reverse engineer Flash if you have ever installed Adobe’s Flash Player (because by installing flash users agree to an end-user license agreement which restricts such work). Thus to work on the Gnash project you must have never installed Flash—which severely limits the pool of potential coders. 111 material which moves and becomes inseparable from the material on which and through which it moves. Code is thus not the instructions or information it may contain, it must be understood as being part of the machine acting upon those instructions. The dual nature of code I set up here refers specifically to that which is used to create computer programs. There is a sliding spectrum between this sort of code and what Manovich refers to as transcoding—the act of transforming some data into a digital form. For instance, a musical recording can be transcoded into some digital format and take on many of the property of the second nature of code: it becomes zeros and ones, moves through networks, rests on servers, but it can only do something useful when combined with other code that can decode its 0s and 1s and transform it into something potentially meaningful. This transcoded media is a passive in the machine, it is data that is called upon and turned into some sort of information. However, there are many sorts of digital creation that are not so cut and dry—using an image editor to create a file that has layers and other active components that interact with code, using a visual editor to create an interactive web page, and all sorts of other kinds of laboring on digital things that are not quite writing computer programs and not quite just the transcoding of data. These situations are more complicated to sort out. Knowing where acts of labor fall on this spectrum is important for understanding how the labor process of creating something digital functions, and for being able to trace the movement and exchange of the thing of value created by that labor process. It is only through sorting this out that we can understand how value and exchange works and be able to trace value and understand systems of exchange. Thus the dual nature of code is key to the potentiality of code to be 112 put to various uses, which, as Chapter Three shows, is essential to the negotiation between capitalism and the commons. On Becoming Software Code is the material with which Ubuntu contributors work; what they end up making is a material artifact. But code is not exactly a raw material—it is the result of the modification of a great deal of raw materials. How does code come into being? How is code created? Where does it come from? Code comes from the earth. It is created from the transformation of what Marx called nature, operating under what Virri referred to as the laws of physics in the quote introducing this chapter. Code is metals, silicon and plastics, and comes into being when combined with electricity at the hands of humans, or automatically at the bequest of another code/machine. When code is combined into some set of functional computer programs that create a reproducible output that humans can understand and act upon (again, or can be understood and acted upon by some code/machine), and when someone decides to partition off some set of computer programs for exchange, code has been made into software. The concept of software is useful for thinking about how code is exchanged. Note that this is not how code is made for sale on a market, but how code is made ready for exchange via a market or non-market mechanism, and remember that software has been around thirty years longer than it has been a commodity for sale on a market. Software is a construct of a shared imagination about the nature and workings of something which we cannot readily perceive, a construct that is imposed by humans in 113 order to make a useful thing transportable and exchangeable. Any of the tens of thousands of discrete operations that compose, say, an operating system, could be divided and exchanged as twenty, three or as a single software product. In other words, software allows for code to become something that can be shared, given, traded, sold, or otherwise exchanged between people who have a need or desire for something that code can do. Ubuntu comes into existence as “software” only through the act of imagining that Ubuntu is some discrete object—rather than a collection of icons, logos, and text on a screen that tell us that Ubuntu is somehow part of a computing device that sits before us. Ubuntu is something that can be talked about—you can “run Ubuntu,” “use Ubuntu,” “download Ubuntu,” “install Ubuntu,” etc. All of these phrases are indicative of the confusing nature of software. It is something that we are sure exists, but we only know it when it is active and attached to a verb. There is nothing that you can hold that is software—there is no Microsoft Word until the code moves and becomes part of a machine. This is what I believe Kittler to mean when he claims “there is no software.” On the other hand, it is very easy to put your hands on some code. Touch the bottom of CD. Open up an old floppy disk, a hard drive, a flash drive, or an old tape or floppy drive and you can hold code in your hand. With a magnetic force microscope or a scanning electron microscope (and some other code helping) you can see the material bits of stuff that are modified to be read as closer to on or off (see Figure 3). Code is the material. Software is the abstraction that allows this material to be exchanged. Code moves to bring what we experience as software into being. This is what is what I take Mackenzie to be referring to by arguing that “code carries software.” Software is an 114 abstraction because it does not exist unless it is being used; it cannot be used with out some sort of digital computing device. 53 Software can only be separated from hardware in our minds via the belief in markets selling commodities, or in other forms of exchange —and these ideologies are very powerful material forces that make our world what it is. Mackenzie and Kittler’s insights on the nature of code are essential to understanding what happens when code becomes fundamental to capital accumulation and to capital’s capacities to organize labor. The shared imagination of software, and how it only approaches existence when it is in motion as part of a machine is not analogous to something like a car part that cannot perform its intended function until it becomes part of a car. It is also not like an idea or a plan on paper or in someone’s mind that must be built before it comes into its full being. I have struggled to find an analogy for what software is like and have found none that 53 I repeat all of this not because it is deep or new, but in order to try out the repetition of something I am convinced is crucially important to comprehending our world. I am just not sure if this is because my head has been buried in code for years and I have rediscovered the obvious or if comprehending the materiality of code is key to the future of resource consumption, understanding capitalist and non- capitalist exchange and possibilities of a more just system of allocating surplus. Probably some of both. 115 Figure 3: Microscope Images of the Surface of a Hard Drive Platter and the Surface of a CD Peaks and valleys on a hard drive platter (peaks are 1s, valleys are 0s) Pits and land on a CD (change from pit or land represents a 1, no change represents a 0) makes any explanation of software more clear. The closest analogy comes out of one of the most major and confusing changes in our economic world (and, in no coincidence, one that requires code): the financialization of the economy, i.e. the development of new financial products, especially the derivatives market. There is a way in which these products do not exist except in the collective imagination of those willing to exchange such products. Like software, a derivative-based product on say, the future capacity of General Motors to pay back a loan, has a very material relation at its base: in the case of the derivative, GM’s fixed capital, in the case of software, the material world of code. In this manner, the relationship between code and software is indicative of the levels of abstraction at which capital’s new globalized extractive capacities function. The disconnect between these products’ circulation and valorization and their material base is central to capital’s capacity to continue to extract value from peoples’ whole lives. The current obvious example of this disconnect is that between the actual provision of the basic need for shelter upon which mortgage-backed securities rested and the hundred of thousands of people involved in the production of mortgage-backed securities who understood the product they helped create solely in the terms of spreadsheets created by complex computer algorithms. Making the connection between new and abstract products through which capital maintains its need for increased movement and new markets is fundamental to being able to identify and intervene in the theft perpetrated by such products. This theft occurs at increasing levels of abstraction and via the complex and differential speeds at which the production of digital things proceeds. The next two chapters begin to discuss how the theft of value operates through the Ubuntu labor- 116 process; first I spend a little more time with the temporal relations of code and how code and software are understood to move. Movement and Speed To begin to comprehend the speed at which digital production operates—the speed at which the machinery of code production proceeds—it is important to think about the differences between data and information. Data, in the world of computing, refers to information that is usable by a computing device. For instance, when something humans can understand—text, video, sound—is moved over the internet, it all just data, theoretically treated the same by the network, as it is for the most part treated the same by the computational power of a computing device (although sometimes requiring specific hardware). When data becomes meaningful in some context to humans, it is information. This definition is somewhat confusing, as for a computer, data is information-like, it is meaningful. Both cases these cases of transition (making information meaningful for computing as data, and making data meaningful for humans as information) take time, although they may happen at speeds beyond human comprehension. In the context of an emerging economy that has relied upon digital computation (networked and not) this difference can be usefully understood via the concepts of latency and lag on the internet. The capacity of a computer network to move data can be measured both in terms of its throughput (the amount of data moved in a given period time—usually bits/second) and latency (the time between the initiation of movement of data and movement taking place). The internet is an end-to-end network, meaning that all of the “work” is done at 117 the ends of the network while the network itself deals only in packets, theoretically treating all data moving on the network as the same (current “network neutrality” debates notwithstanding). Latency refers to the time it takes for the network to initiate moving data from one end to another, and is determined by the speed of light, as well as other factors. Latency is perceivable and experienced as “lag” in data become information—a delay in communication perceptible as dropped “frames” or pixalization in a streaming video or a video chat, pauses in sound on a voice-over-IP phone, etc. Lag, one human experience of latency, can be caused by other factors on the “ends” of the network, such as computational capacity. The “meaningful manner” in which data is received is one way that data becomes information, and as human capacity for understanding and our senses are part of making this meanings, it is important to consider human beings as part of the network, part of the system through which data becomes information. Thus, information is the result of receiving, processing and organizing data in a manner that is meaningful. It is important to note that “meaningful” can reference human beings as well as machines that put information to work, such as in algorithmic stock trading (complex computer programs making decisions) or high-frequency stock trading (those programs put to use to trade at high speeds with no interest in any qualitative measure of investments, but calculations designed to net a few pennies in microseconds). In these transitions, there is always some sort of labor, some work of making the transition and/or of making meaning. Considering latency and lag, it becomes clear that the instantaneous transfer of information or data is a myth—latency makes clear that data does not move instantly, lag 118 makes clear that the movement of information is far from instantaneous. More to the point, although latency and lag may decrease due to the increased throughput of networks, improved routing, elegant software design and more efficient hardware, they will not go away. Latency and lag will always exist in packet-switched networked communications, and will continue to matter dearly in the exchange of data and information. This is evident in a variety of information exchanges, for instance, latency and lag can be the difference in getting a ticket and not getting a ticket when the virtual line forms on TicketMaster’s servers; or the way that high-frequency trading firms buy server space as close to a stock exchange’s servers to make trades as fast as possible. Lag is affected by different Internet Service Providers’ (ISPs) arbitrary uplink and downlink load balancing processes, router failure or fiber optic cable damage, the time of day, the structure of software used to make sense of and view information as well as the hardware used on the “end” (i.e. they processing capacity of the computing device used). Latency and lag are useful concepts to apply to the question almost answered above: how does code come to be? The creation of code is far from instantaneous; rather it is a tedious, labor, and resource intensive process. The latency of code’s transformation, the time between the initiation of the process to transform human readable code into its active form, varies immensely. Computational power and various throughput limitations of data networks are primary factors, such that in a distributed code production environment a slower connection and the limitations of local resources (i.e. the computer in a coder’s home or a server on the other end) can mean that the process takes hours or days. For instance, to compile language packs, Thomas, a 119 Canonical employee who works out of his home in Taiwan, sets things up on a remote server hosted by Canonical in the UK, eventually goes to bed and hopes for an error free compile in the morning. But things can go wrong: For instance, servers can run out of disk space, it happened two days ago. Which means no language packs. So then I prod everyone to clean up their home directories on the server, everyone in the company, because the server we work on is company’s internal server. The only problem is that everyone has their own stuff and has access rights. The hard drive is full, 100%, and this is not good. So I say to people, please clean up your home directories, we are not able to build language packs anymore. And the reply I got is is, “please make sure it doesn’t happen again.” So I asked them to move the language packs to another server. They say temporary fix is possible … Such a problem is the exception, but this exception reveals the various time it takes for Thomas to pull things down from the server, load it back, for it to be processed, then transmitted back to him so that he can see the result in a meaningful way. It is easy to take these delays and make them abstract—it is just the delay of the network, slow hardware, etc.—but this process is based in some very material limitations of the capacity to work of both machines and the human body. What Thomas is waiting for is a large amount of data to be transferred through the network, compiled and turned into moving code, then stored as binary packages, tested and compatible with current versions of all other dependencies required to work with the current version of Ubuntu (which could change every six months). Once this code has been made, it waits in a repository, a secure server to which Ubuntu users connect to get new software and software updates (see Appendix C for a list of these servers), ready to be put to use: The labour which was objectified in the form of machinery did not of course directly cause men to spring out of the earth, but it made it possible for a smaller number of workers, adding relatively less living labour, not only to consume the 120 wool productively, and put into it new value, but also to preserve its old value, in the form of yarn (Marx 1993, 755). Marx’s discussion of a machine’s capacity to make dead labor spring from the earth to accomplish a task of transforming some material into another form applies to digital machines. In the case of turning wool into pants it is relatively easy to imagine the different moments at which wool (in some form) enters into a system of exchange: the markets for wool, yarn, and eventually pants likely function somewhat differently, but we can imagine that all are commodity exchanges, at different scales, in different locations. Os and 1s are a little trickier—even if code is being built with the goal of creating an object to be sold on a market, it can be very difficult to pick a moment at which code takes the form of a commodity, or how it functions in a system of commodity exchange— this difficulty is another reason why it is easy to give up on tracing value in digital production. In the case of FLOSS, in particular Ubuntu, which works between several different systems for exchanging things of value, a commodity chain analysis (such as wool to thread to pants) appears nigh impossible. However, it is possible, and in fact essential to understanding code production, to sketch out the systems of exchange at work in Ubuntu, and how code moves—even if a particular bit of code itself is not traced, even if it requires a fair bit of imagination. 54 54 This sort of sketch, and thinking about the various systems of exchange involved in a single labor process, might also make us take another look at wool-yarn-pants. There certainly may be non- commodity forms of exchange taking place that are eclipsed by the full circle that commodity exchange takes up in economic imaginaries. It seems very possible in FLOSS to conduct this trace—the names of all developers who have committed to Linux are in the kernel, there are systems that track all changes made to most code, changes that are most often linked to verified identities. But when that code leaves the version control system and is put to work or changed by another party, things get messy, as is evident in various lawsuits that attempt to determine FLOSS license violations (such as in the string of lawsuits filed by the SCO group against various Linux-related firms over the origin of some code in the Linux kernel). 121 Latency and lag are most apparent in a distributed code production process such as Ubuntu at another moment of movement. Creating a new version of Ubuntu every six months defines the rhythms of work for Canonical employees such Thomas, and it also defines the work load for Canonical’s servers and Ubuntu mirrors around the world (see Appendix C for a list of mirrors). On the day a new version of Ubuntu is released the vast majority of Ubuntu users download the release, which means putting packages such as the ones Thomas prepared into motion. And this motion is significant, consuming much bandwidth. Canonical hosts many of its servers in London, with three data centers and several hundred other servers used for internal production, web hosting, and other work. Canonical has data centers and servers elsewhere, but they are primarily in London because that is where the firm started, and is still where a significant number of Canonical’s system administrators live and work. As Earl, a Canonical systems administrator put it: “Buildings are quite sticky, you have long term contracts, there are a lot of things that keep you there.” Getting ready for release day is no small task, millions of Ubuntu users will be downloading new CDs or updating their existing machines, which creates a huge demand for bandwidth and requires a lot of hardware. Some CD images are now served by rented “cloud” infrastructure and by peer-to-peer BitTorrent downloads, but the majority of the work is done by mirrors and Canonical’s servers. Getting Canonical’s servers ready means Earl works pretty much non-stop for two or three days, “putting out fires” and taking care of things like getting every server at Canonical ready to play some role on release day: 122 We have about 50 servers we use to test to make sure that Ubuntu runs on different hardware. When we’re not doing that, we use them to build packages for Launchpad. Its basically a way of recovering the costs, because to host servers in London is not cheap. These servers are sent to us by [various] companies to test their hardware. Then at release time we yoink all of those servers and make them release servers. However, as they usually are three machines away from the internet, when they become release servers they need to be a lot closer. So traditionally on Wednesday nights before [Thursday] release, I’m physically re-patching servers. So anyway, I left the data center at 3 a.m., went home for about three hours sleep, and then headed back into London. In London we were frantically trying to finish up all the machines, hardware and updates. Just trying to cope and be as prepared as we could. This work at the data center means Earl has to physically move cables around to make the servers “closer” to the internet; instead of being “behind” several other machines, as is ideal for internal Canonical use. On release day, if Canonical does, say, fifteen GB/sec (21 CDs a second), then the three hundred additional mirrors, each of which do much less each, combine for something in range of ten times that bandwidth. As Earl explains, managing the mirrors is an important and challenging task: To be honest, managing the mirrors is quite hard. One of the things we have to do as the mirror coordinators is talk to people who contact us. They say “Hey, we’ve set up this dreamhost server, and we want to be a mirror, can you set us up?” And we have to say, “Are you aware of what that is going to cost you?” And quite often they are not. They want to do the right thing, but they haven’t really thought through the implications of becoming a real mirror that is listed and advertised. They don’t really realize the traffic they will get. We’ve had real trouble hosting us.archive elsewhere. If you are in the US, the installer will point you at us.archive. Within apt [the tool that manages updating packages], that archive can be on multiple machines, but those machines must be strictly in sync or shit will break for users. Which means essentially that its got to be one person [one systems administrator, or one entity] hosting that. And asking someone to take that hit 24/7 is a big ask. We actually hit up Argonne National Laboratory [run by the US Department of Energy in Chicago] guys who said “Hey, we’ve got some bandwidth again, can we be the us.archive again?” We turned it on, instantly they took a huge hit. They had like eight times as much traffic, literally [snaps fingers]. Before that was all coming out of London and then bam! 123 Argonne National Laboratory was doing crazy traffic! They can deal with that. Most people, they are going to get pissed! The mirrors are a bit of challenge. We are trying to keep the amount of bandwidth we have to buy every year under control. Even with Shuttleworth’s significant wealth, without the support of mirrors, Canonical and other FLOSS firms and projects could not afford their own operating costs and could not keep code moving. The lack of adequate provision of mirrors and servers would mean users experience slow downloads, slow updates or, as Earl says, shit will break. This movement is a central part of the process that brings code into being. For when the packages Thomas compiled above move from a mirror to a particular configuration of computing hardware (some individual’s laptop, a work station at a school or a firm’s data center) the code is made again, and interacts with other code, other calls and other demands for data. At this moment, the making of code is most visible as errors. Not surprisingly, even after thousands of Ubuntu users download release candidates to test the code’s capacity to work with the particular demands of a wide variety of code/machines, bug reports spike during the first week of release, as new code interacts with particular code/machine configurations in unexpected manners. From this brief discussion, it should be clear that the making of code is an ongoing process wherein code moves and is made again and again in slightly different forms. Some code is very stable (or otherwise isolated from change) and used over and over again with very little modification release after release; some packages may have hundreds of bug fixes and other updates to the code in a year. Overall, the creation of the code that carries Ubuntu is an ongoing, cyclical process that requires a great deal of movement. And not just of code. This six-month 124 cycle includes the movement of a lot of people too—several hundred to the Ubuntu Developer Summit, dozens for coding sprints, thousands to conventions, tens of thousands of coders to and from offices or across apartments, and many many fingers on keyboards. The organization of the labor into the rhythm of frequent releases is arbitrary —code could be released on an ongoing basis, but be less stable, or could be released every few years, and be more stable but lack current features and capacities. 55 Ubuntu’s release strategy is an attempt to find a middle ground, and perhaps more importantly, to position Ubuntu (and by proxy Canonical) at the center of FLOSS exchange. Thinking about the movement of digital things as “instantaneous” is a key assumption that allows for misleading rhetoric about cultural or informational goods and the occlusion of both the conditions and means of production for these goods. Latency and lag, or any similar concepts, are generally absent from literature in economic geography and other consideration of the information economy. The lack of critical consideration of the temporal rhythms of code production (both of code and of coders) leads to a fundamentally misleading discussion of code-mediated movements upon which current economy is dependent, such as electronic funds transfers as “instantaneous” (Dicken 1998; Warf 1999). 56 Time matters, and we must not assume that “quick” counts as “time does not matter” or to think that the time it takes for data to travel or information 55 Debian took this other model (of releasing software when it was done, often taking years); Ubuntu’s release cycle was designed to address the perceived problems that Debian’s release cycle created for “desktop users” and businesses—in addition to a regular six-month release of both Desktop and Server Editions (supported for eighteen months), a stable and well tested “Long Term Release” comes out every two years supported for three years (Desktop) and five years (Server). 56 One of the reasons that understanding the materiality of code is so important is that the current round of financialization of the economy post-1950s is increasingly dependent upon using code to create new financial products (e.g Pike and Pollard 2010). 125 to be encoded and move on a network makes time matter less than in the past—quite obviously it only matters differently, and is part and parcel of changes in how resources are consumed and how materials are transformed by human labor. The movement of code, both as part of a local computing device and over a network, occurs at speeds beyond human comprehension; however, turning the data moved as code by code into information that humans can meaningfully interact with in the Ubuntu labor process, thanks to latency and lag, create varying temporal rhythms of work. That is, in some ways, code production proceeds as Hyde describes the process for creating art in which nothing “can alter the rhythms of creative labor;” at the same time, Canonical also acts like any other industrial manufacturer and draws upon a long history of management techniques to make humans operate themselves in accordance to the temporal rhythms of the machines with which they work (Hyde 1983, 51). Mackenzie argues that one of the primary means of bringing what we know today as machine time into existence is found in the operation of algorithms. In particular, he explores how the essential algorithm used to decode signals (and sort them out from noise) in many forms of communication from wi-fi to speech recognition, the Viterbi algorithm, plays a key role in determining the time it takes for signals to be made legible and how computing devices and communication networks are structured (MacKenzie 2007). Contrary to notions that computerized machine time would mean some form of perfection of machine time into a pure and regular mechanized time, MacKenzie demonstrates that “the argument that machine time is relational and heterogeneous is both an empirical claim 126 concerning the actual state of communications today and a more general claim about how technology can be thought today” (MacKenzie 2007, 104). This relational and heterogeneous experience of machine time, such as that which Thomas experiences, is the means by which the temporal rhythms of machines become machine time. Machine time has changed as much from changes in the technological structure of machines, such as with the Viterbi algorithm, as with what Negri describes as a shift in process: “work-processes have shifted from the factory to society thereby setting in motion a genuinely complex machine” (Negri 1989, 90). For many, the temporal rhythms of this genuinely complex machine is defined by how the speed and rhythms of both networked communication devices and code carry work into parts and times of lives that were previously a bit more separate from work. This occurs courtesy of cell phones extending availability to bosses, clients and coworkers, by networks bringing email home, and through all those networked, digital devices and communication means that have become a normal part of work for many, but by no means all workers, although also far from being just the domain of elite workers. It is important here not attribute the rhythms of this complex social machine solely to networked communication. Too often such rhythms are imagined as extending from the technical character of communication devices and mediums—from email, cell phones, text messaging, blogging, third and fourth generation networks for “smart phones,” social networking, etc. Networked communication is a key to how the social machine before us developed, but focusing upon communication devices and mediums means too easily passing over how the actual rhythms of work develop and how they 127 function in the mundane and everyday. Making code and other digital things is not all collaboration and communication—in fact, much time for many people working in collaborative labor processes such as Ubuntu is spent in relative isolation from other workers, interacting with a computer. In the Ubuntu labor process, although many contributors are constantly connected to internet communication mediums (primarily email and IRC), creating blocks of time without being “connected” is a high priority and necessary to getting work done, such as Nick and his “computer mode” in Chapter Zero demonstrate. Thus it is a much larger relationship to the demands of a particular temporal and spatial organization of capitalist production, the possibilities of social life and meaningful human connections, and the temporality of code that defines the machine time—not only or primarily our relationships with communication devices and media. 57 Workers creating digital things appear to be much farther removed from the transformation of materials than, for instance, a welder; but nonetheless, this is what most digital workers do, they transform materials, consume resources—and they are able to do so all around the world from a single computer interface. In comparison to the welder, the difference of the actual labor process (not the end product) is almost entirely a question of scale—both coder and welder use a machine that consumes electricity to transform metal. Of course, the organization of labor around each worker, the conditions and experiences of work, as well as the exchange, movement and consumption of the 57 Perhaps this point is more clear in an obvious example. Facebook is not popular because it enabled people to do something that they had desired forever and is now possible—Facebook emerged at a moment when many people’s needs for meaningful human interaction were being transformed by conditions of work. More people living transient lives, some in very frequent contact with data networks and some not, some facing structural underemployement, and some working longer hours or more jobs or finding it hard to know where work ends and other parts of life begin is part of creating new needs that have made Facebook a part of many people’s lives. 128 goods produce may differ vastly, but what the work is, the relationship to resources and using human capacities to transform material are far more similar than casual appearance indicates. Thomas’s work consumes power on dozen of power grids, and is part of wearing down thousands of machines in dozens of locations that will eventually need to be replaced. Creating code is profoundly and unevenly material and must be thought of as such—and we must recognize that when a labor process “digitizes,” in many cases, this means the potential for that work to consume more resources, not less. Yet, economic frameworks within which the creation of code is located make it difficult to see this reality, and we shall turn to three such frameworks next. II. Services, Informational Goods, and Cultural Products ... a customized program written for one customer would be a labor-service, but a packaged program ... on a shelf ... is unquestionably a good. (Sayer and Walker 1992, 62) Geographers Andrew Sayer and Richard Walker observed almost twenty years ago that the “concept of services has entered popular and academic economic language with too little critical examination” (Sayer and Walker 1992, 56). Services can be measured to count for an increasingly large share of Foreign Direct Investment (Dicken 1998), to be the largest source of jobs in the US since the 1950s (Glasmeier and Howland 1995), to be the dominating force of the last third of the twentieth century (Brunn and Leinbach 1991), to dominate over the primary and secondary sectors (Forer and Parrott 129 1991), yet the term has been both “present and absent” in economic geography, in part because of ongoing confusion and disagreement over the definitions of goods and services (see Daniels 2006). Even with its often disputed definition, the rise of service sector is a fundamental trope in theories of the “global economy” in economic geography and in economics in general. What is a service? Often, services are simply defined as any product of labor that does not have the properties of a good. Peter Dicken defines goods by three factors: goods are tangible products of labor that can be stored, consumed away from their place of origin, and can be traded at different scales (Dicken 1998, 388). In turn, services are usually considered intangible, perishable and require consumption in the same time and location as their creation—although as we shall see this definition is frequently stretched. The concept of services is also often detached from the actual provision of services and deployed as a marker of the decline of manufacturing as the primary driver in economic development—the rise of the “service sector.” The creation of services, the supposed opposite of manufacturing, thus are also assumed to be governed by different rules—and thus have different labor process with systems of organization, management and conditions of work that emerge from the nature of “service work.” Creating computer programs is most often considered part of the service sector, which appears to make good sense, as the majority of code production is located “in-house.” Most computer programs are created not for the market, but for the inter-workings of a firm. This appears as a service, but such code is no more a service than a robotic arm made by a firm for its own assembly line. Like the robotic arm, such software is tangible, 130 can be stored and used elsewhere and can potentially be traded elsewhere. Sayer and Walker have a nice example that is useful for thinking about what a service might actually be: a haircut is a service, a toupe is a good. In the same vein, advice from a counselor is a service; a report from the same consultant is good. Thus the difference between services and goods is in the material form taken by the product of labor (Sayer and Walker 1992, 60). This example makes evident that anything digital is a good. Such potential, or the immanence of code’s movement, plays an essential role in FLOSS code’s capacity to move between different modes of production. This is developed in Chapter Three, but for now, it is enough to point out that the “software” that is a “labor-service” in Sayer and Walker’s example above cannot and does not exist in the FLOSS world. For code to be written for “one customer” that software must be proprietary, but even if it is proprietary, unless it is written for a specific, unique hardware setup, it is still transferable. 58 The writing of FLOSS code can never be the provision of labor-service. FLOSS code is always a good, it is always immanently transferable, always stores the labor of its coders and the dead labor of coders before, and can always be put to work in ways in ways never intended by its creators. Understanding FLOSS code as a good is essential to being able 58 Prior to the implementation of broad standards in computer hardware, software was written for “one customer” because each machine required its own operating systems and specialized programs. There certainly are many firms or organizations that have very specific internal configurations that require unique software, or the modification of commercial software, and the code written to make this particular suite of software function is somewhere between a good and service—functioning as something somewhat well-described by the concept of a service, but retaining the potential to function as a good. However, such code is only able to maintain the appearance of a service by restrictive licensing, non-disclosure agreements, copyrights, patents, or other forms of restriction that disallow the transfer of code. 131 to understand the labor process of Ubuntu and the movement of Ubuntu code between a capitalist mode of production and the Ubuntu mode of production. This said, FLOSS code can appear as a service, taking the form of what is sometimes called a “producer service.” The division between consumer services and producer services is particularly interesting (Dicken 1998). As Dicken argues, such a division is arbitrary as most services are “mixed,” in that they can be used by both end consumers and at various points in a production chain. Take the example of Canonical’s “Corporate Services” office in Montreal, Canada. Some of what happens there is a service, even in the most strict sense, such as advice to manufacturers or support to individuals and firms that happens in person or on the phone. As such, the office is a very rare place full of rare moments in which the labor of a Canonical employee is completely dedicated to serving only the ends of the firm. In this moment, the labor of tens of thousands is put to work for Canonical, through the labor of one waged employee who creates something that cannot be used by anyone other than than owner of a support contract. This is not through any natural characteristic of providing computer support; rather, it requires a great deal of law and effort to turn the valuable knowledge and occasionally code (much of Canonical’s code for providing support is proprietary) created in the process of providing support into a service. Ubuntu enthusiasts, coders and not, as well as Canonical employees provide support all the time for Ubuntu users who do not have a Canonical support contract—individuals and firms alike. This takes the form of a very popular web forum (around 1.7 million discussion threads with 1.5 million users, 75,000 of which are active), as well as numerous IRC channels and email lists. 132 Even the rare moment above, the work that a Canonical employee might do to create a solution for a client often creates an outcome that will find its way into the public Ubuntu world, although such movement is not guaranteed: After I left Canonical I started to realize that I was participating more and more on the community side. [When you work with Canonical] there are a lot of things that you have the opportunity to work with, but unfortunately, you can not share that with the community. For instance, I was working with hardware and I know that there are community people working with that hardware, but I have a non- discloser agreement because of the company [that has a contract with Canonical] … And we had some issues, with some misunderstandings, where we talked about the Dell agreement before Dell’s official announcement, it was no one’s fault, but it broke the non-disclosure agreement. So its hard because you know that you can give some tips or ever better or tell someone, “don’t work on this, there is a fix coming down,” but you can not tell people that. But now I’m working more with community. The visibility of my work increased actually, before my work was not visible. We would have a customer in Spain, we would be doing work together and that customer would be the one blogging about it on their community channel, but I could not do that on my side. Right now I feel that my visibility in the community has increased. When Ivan talks about the visibility of his work, it is another way of talking about something that existed, for awhile, thanks to the force of law, as a service, becoming a good, becoming something that can be moved and exchanged. Even if producer services are rare, the concept is interesting for another reason. Producer services, if rethought as the material form taken by processes of vertical disintegration, can be seen as externalized aspects of what was once part of an in-house production chain. Some of what is necessary to produce any given good that once occurred “in-house,” such as janitorial work, database design, transcription, component part manufacturing or the like, is now contracted out to another entity providing a “producer service” that does something for a particular production chain. Dicken 133 addresses this fact by arguing that “many services are deeply embodied in goods” (Dicken 1998, 391). I read this argument as the amazing length that scholars will go to maintain the myth of the service sector and as a signal that there is trouble afoot with the concept of services. Geographer Mia Gray argues that the only thing that the job categories that are categorized as services may have in common with each other is their exclusion from the domain of “agriculture, mining, construction, utilities, and industrial manufacturing” (Gray 2004, 24). Gray further argues that as the “service sector” is dominated by “low- end” service jobs, there is crucial analysis yet to be done about why the labor market and work place for these jobs are institutionally structured in a manner that yields low pay and poor workplace conditions (Gray 2004). In the case of the US, service work must be understood as not better or worse work than manufacturing work, but in the context of a great deal of organizing, struggling, striking, and legislating that went into making manufacturing jobs for some workers relatively stable, safe and well paid. Those Canonical employees working in Corporate Services provide only one end of the “service work” that enables Canonical to extract value from the larger Ubuntu production process. The other “end” are those who work to create a clean office, a happy and fed coder, etc., in order to reproduce the an Ubuntu worker through household and office labor. Contracted janitors, as well as spouses, parents, significant others (in most, but not all cases, women, reproducing in most, but not all cases, their hetero partners or direct family members) provide the base material conditions of possibility for the production of Ubuntu. Such work can be described as a service, but the term’s lack of 134 precision (in part because its definition as “not a good”) and its ideological role (explored in detail below) in creating disconnects between meaningfully connected parts of labor processes demands a better concept for describing this work. Because of the organization of the Ubuntu labor process, and its often thorough integration into contributors lives, it is clear that making Ubuntu produces something more than just code that can be executed perform some task. Of course, this “something more”—socialized workers, emotional states, relationships, communication networks, etc.—is produced by most any labor process. But something in the organization of work in what is called the “service sector” makes this truth particularly apparent, and what the nature of this truth means for the future of work, where it comes from, and what exactly it is that has changed is of much debate. Academic literature and commonsense discussions of services is one way to grapple with these changes—however misplaced the concept of services might be. What is often going on in “service work,” which is often about producing goods, can be described as immaterial production, the production of emotional states, feelings, relationships, and the like. These things or states are not easily stored, moved, or exchanged, but they are very often tied up in goods, such as Ubuntu, that are stored, moved, and exchanged. I return to the concept of immaterial production and immaterial labor in Chapter Three; next let’s take a look at how an idea such as services used to make sense of the world comes to be a very real material force that shapes our world. 135 How Ideology Works: the Case of Services Computer code fundamentally changes the speed and frequency at which materials are transformed. However, as I have tried to establish above, what actually takes place in a labor process of making code is not fundamentally different from any other labor process: humans labor to transform some material, using their bodily/intellectual faculties. 59 Working on code, like working with any other material, can be organized to be fun, boring, creative, meaningful, and/or destructive to body and mind. This is worth stating over and over again because labor processes related to producing digital things so easily appear as somehow fundamentally different from other sorts of laboring—and digital work is often a false idol of success and freedom from drudgery promised as the payment supposedly waiting at the end of higher education supposedly open to all. It is certainly true that some workers, though by no means the majority in the world, are no longer directly producing products in a form that leaves their place of work for consumption, and that “workers spend more time transforming data, manipulating ideas, or organizing social labor than in hewing wood, drawing water, or bending metal” (Sayer and Walker 1992, 23). The appearance of code as an antithesis of, say, steel, (as the coder is the antithesis of the welder) has made it common sense that “transforming data” and “manipulating ideas” is labor of the mind, not the body; performed in the ether, not in the material world; productive of a service, not a good. Building on Kittler’s work, Chun describes what I above called the “shared imagination” of software in terms of ideology: “software cannot be physically separated 59 As numerous scholars who have actually paid attention to the process of creating digital things have argued, such work very often looks like repetitive work in an industrial factory, and is described by workers in such terms (see Lovink and Rossiter 2007; Nick Dyer-Witheford and De Peuter 2009). 136 from hardware, only ideologically” (Chun 2006, 19). Chun understands computers as ideology machines, and software in particular, as an “ideological phenomenon ... a phenomenon that mimics or simulates ideology” (Chun 2006, 19). Specifically Chun finds Althusser’s definition of ideology as “a ‛representation’ of the imaginary relation of individuals to their real conditions of existence” to be the most useful for understanding how software came to be (Althusser 1970 in Chun 2006, 20). It is thus through software that the “user” is brought into being, particularly through the ways that operating systems construct “users:” though “my preferences,” icons, log-ins, etc. Although software as ideology is useful for analyzing some aspects of the sociality of code, as Chun points out, it limits the ideological operations of software to thinking about either software as an executed program or software as code (Chun 2006, 22). In such a formulation of software as ideology power has but one place, in the hands of programmers/hackers/coders. This not only allows for those studying the implications of networked communication and media to think of power only in the terms of programmers (see especially Castells 2001a), it also shuts the materiality of code—its material form, labor, circulation—out of any discussion of the sociality of software. Yet thinking about ideology using Stuart Hall’s definition of “mental frameworks ... which different classes and social groups deploy in order to make sense of, define, figure out and render intelligible the way society works” brings the focus back on the power of discourse as a material force (S. Hall 1996, 27). This conception as software/ideology makes room for the materiality of software, as it emphasizes the material force of ideology. 137 For instance, taking a look at how ideology works via the development of “services” makes clear that ideology is always a material force, intimately tied to mundane life, and not necessarily good or bad, false or real, but productive. Services first rose to prominence in the US as a category through which the economy can be understood during industrial shifts in the 1970s. At this time, the way data on industries and employment was understood changed—and the change was not necessarily the data itself or even how it was collected. Amy Glasmeier’s analysis of rural services hints at how and why services became a focal point of analysis and drove economists to reconfigure how they thought about the same data: services received little attention until the late 1970s, when manufacturing began to falter. In general, service industries have been seen as nonproductive and derivative of other sources of growth. Until recently, more precise definitions and disaggregated service industry data were not in great demand by scholars (Glasmeier and Howland 1995, 23). The conception of services relies upon a classification of the economy into sectors: primary (resource extraction), secondary (finished goods) and tertiary (the service sector) (Brunn and Leinbach 1991; Dicken 1998). There is much more detail to these sectors and the division goes on to quaternary and quinary sections, with varying lines drawn between the sectors. The nature of the classification is not important at this moment, my interest is in how such classifications gain force. Following the work of Marc Porat in the 1970s and his book, The Information Economy: Definition and Measure, scholars have brought into being a concept of the service sector that is based on employment classification and the “best available census data.” Pip Forer and Nigel Parrot notice that futurists like Porat, Alvin Toffler, and Tom 138 Stonier “mirror” the classification systems used by the US Government—Standard Industrial Classification (SIC) codes)—and the Organization of Economic Co-operation and Development (OECD)—International SIC codes (Forer and Parrott 1991, 306). There certainly was a growth in employment in what came to be called high-end service jobs, especially in the “FIRE sector” (Coffey 2000), then in the 1990s in the “technology industry.” In 1990 the SIC and international SIC codes used to identify the “industry” of a particular firm were redesigned to reflect services (for instance, a fast food employee became a service worker in the 1990 census, based in a 1987 rewrite of SIC codes). It is through tracing patterns out of data collected under these codes—the “best available census data”—that the rise of the service sector has been charted. At the same time as intellectuals working for the research arm of capital were trying to figure out and represent these economic changes, so were geographers and other academics. In geography, Alan Scott’s 1999 article on the music industry forecast “cultural industries” as a key part of the future of capitalism and as the new field for economic geographers to study (Scott 1999). Scott is attributed as coining “cultural industries” (Leyshon 2001), which is more or less synonymous with the “creative industries” (or at least seeks to explain the same phenomena). However, “creative industries” has a different and telling origin that is key to exposing the relevance of the terms popular use in academic and elsewhere, and services generally. The United Kingdom’s Department of Culture, Media and Sport (DCMS) brought the term into popular use by creating a classification that could be used to measure the “creative industry’s” impact on a region or city. The DCMS was created under the direction of 139 Tony Blair, renaming the former “Department of National Heritage,” and one of its first tasks was the creation of the “Cultural Industries Task Force” (Flew 2011). The inclusion of software in the “creative industry,” now taken for granted in related policy and discourse, was used as a means to artificially inflate this sector (in initial DCMS reports software accounted for the vast majority of growth and jobs—which, by most accounts of the actual work, are not particularly creative) (Garnham 2005). According to the DCMS “software and electronic publishing” (a non-intuitive category) now accounts for close to half off all growth and the majority of jobs in the “creative industry” (DCMS 2010). The UN Conference on Trade and Development (UNCTAD) and the UN Education, Scientific and Culture Organization (UNESCO) both use the creative industries to promote a particular sort of growth, one that sees all forms of culture as “assets” to potentially be sold and traded and that works in collusion with the World Intellectual Property Organization—such that a UNCTAD report can excitedly claim that “trade in creative goods and services increased at an unprecedented average annual rate of 8.7 per cent” (UNCTAD 2008). The DCMS definition of the creative industries echoes through UN and other reports: “those activities which have their origin in individual creativity, skill and talent and which have the potential for wealth and job creation through the generation and exploitation of intellectual property” (DCMS 2001, 3; Bayliss 2007, 891). The relatively quick policy acceptance of this term enables both a parsing of the economy into arbitrary “high growth” sectors and, via this growth, justify intellectual property regimes that enable new forms of resource extraction. Akin to services, the creative industry is not about what is being made in the industry, but where 140 the onus for the value of the product supposedly comes from: creativity, the mind, mental labor, or the like. A cottage industry of writing about the “creative [blank]” (insert a word into the “blank” to create a neologism) emerged, in which the concept of creativity took a few different forms. Sometimes creativity is unquestionably a good thing, such as in Richard Florida-esque formulations in which creativity is understood as a positive economic indicator and driver in policy and planning agendas (Florida 2002; Norcliffe and Rendace 2003; Asheim, Coenen, and Vang 2007; Bayliss 2007); other scholars are more focused on trying to understand where “creative” work fits in existing production cycles and how new “creative industries” are transforming value creation (Scott 1999; Leyshon 2001; Drake 2003; Tornqvist 2004); while other authors argue that “creative work” is part of an ideology that justifies a moralizing individualism, commoditization of the commons and further exploitation of the “flexible worker” (Jessop 2000; Osborne 2003; Currah 2007). In this scholarship, even in some of its critiques (e.g. Markusen 2006), creativity becomes a taxonomic category (i.e. creative-class, -city, -worker, or -industries), and being “creative” in turn is defined as extending out of categories of work as well: it is tied to education level, the false mind/body split imagined to occur in laboring mentioned above, the capacity to “innovate” (as defined by the market) and/or job categories. The idea that certain qualities of work extend naturally out of certain types of work is a key component of ideologies of work and code’s relation to the labor market and education. As this was happening and the idea that “creative [blank]” was essential to developing a competitive regional economy began to approach common sense, capital 141 worked with the state to pass labor laws in the US that brought new meaning to “high end service work:” in California, an employee who does “creative” work and makes more than $41,000/year became exempt from overtime. Firms such as video game producer Electronic Arts have lobbied vigorously to get such laws in place, convincing US state and Canadian provincial governments that hopes of attracting “creative [blank]” that would stimulate various regional economies rest on the approval of such exemptions (Nick Dyer-Witheford and De Peuter 2009, 61). With the purported goal of simplifying overtime law the US Department of Labor adopted both a “creative professional” overtime exemption in 2004—for “performance of work requiring invention, imagination, originality or talent in a recognized field of artistic or creative endeavor”— and a “computer employee” exemption in 1996 for workers engaged in a bit more complicated, yet still vague, set of activities, made even more vague under a 2004 revision that essentially left the exemption decision in the hands of employers, justified by a quick pace of change in the computer industry (US Department of Labor 2008). 60 The wage standards are lower for salaried employees, $23,000, leaving many software, “computer,” and “creative” workers amongst the nearly half of US employees exempt from overtime (Von Bergen, Mawer, and Pool 2005). With this legal force amassed behind an ideology of creativity (in which “creative” also functions to differentiate this form of “service” from its “low end” counterparts), various industries began to take the form we know today. For instance, the concert of organizational methods gleamed from total quality management and agile 60 This is from a US Department of Labor factsheet, the kind typically posted in a workplace, tattered and half-hidden by other documents: Fact Sheet #17A: Exemption for Executive, Administrative, Professional, Computer & Outside Sales Employees Under the Fair Labor Standards Act (FLSA) . 142 production, this legal force and an emerging ideology of work, the software and gaming industry began taking form based in the creation of campuses instead of factories (Google, Microsoft, Electronics Arts and other firms all call their factories “campuses”) and the creation of labor processes that would keep workers “on campus,” healthy and happy, working long hours. As it turns out, changing laws and adding exemptions does not make the work of creating digital things “creative.” Workers sued Electronic Arts, claiming that their work was not creative, but rather route and predictable (De Peuter and N. Dyer-Witheford 2005, 63). The power of ideology is that it always takes a material form and has material force. These are imagined renderings of the world that come to have the force of law, census data, white papers, and city planning guidelines. As we can see in this short example, ideologies can create conditions that provide evidence for a given imaginary as reality—such as the overtime exemption. What is too often missed is that this force does not necessarily mean a change in how work actually proceeds, but rather profound changes in how we understand work; which in turn may enable various re-organizations of the speed, location and conditions of laboring. That is, ideologies of work are also (or maybe even primarily) ideologies of surplus; they provide a framework for making sense of and making natural extractive strategies (capitalist or not) and allocations of the fruits of labor (for better and most often worse, unjust and uneven). The origins of any ideology about work are of course not only of the moment, but part of long history of ideology and ethics. Such ideologies are ever changing an yet do not disappear with the emergence of something “new” like creativity, thus any attempt at 143 periodization would be amiss; it is enough of a challenge to begin to describe an ideology of a moment, activity and world in which I am embedded. Perhaps because of the ease with which a discussion of ideology becomes (auto)ethnographic, it is ethnographic and journalistic accounts of ideologies of work that I find the most compelling. Studs Terkel’s 1974 book Working: People Talk About What They Do All Day and How They Feel about What They Do, comprised almost entirely of edited quotes from long interviews with people who do all sorts of different work, is incredibly useful for identifying and comprehending changing ideologies of work. Similarly, Alain de Botton’s 2009 account of the work involved in several labor processes, The Pleasures and Sorrows of Work, offers insight into the mindsets through which we understand our working lives. Such journalistic and ethnographic accounts are not to be sidelined in a discussion about ideology. Not only does such intellectual labor have merit and analysis of the world onto itself, such scholarship also provides me with an essential historical and contemporary comparison to begin to be able to identify how ideologies of work are at play in Ubuntu. So, how do such ideological developments take form and force in the Ubuntu labor process? First, it is difficult to separate mindsets regarding work in Ubuntu from larger ideas about how FLOSS works (or for that matter, from ideas about work in general). Second, while what I discuss below emerges out of a very international project, there is far from any universal ideology of work within Ubuntu or FLOSS. National, regional and other cultural ideologies about work matter dearly and emerged in my work frequently—however the structure of my ethnography was not designed to be able to 144 meaningfully compare, say, French ideas about work to Taiwanese ideas about work. And such categories themselves are suspect; generations, class, gender, immigration status, etc. all matter—i.e. everything that would complicate the very idea of of a cohesive “French” or “Taiwanese” ideology of work. Although very different ideas about work emerged in my research, there are also a few ideas that characterize the dominant ideology of work in Ubuntu. Meritocracy is the key. I heard or read “it’s a meritocracy” hundreds of times in the course of research, and even though most folk will readily recognize that, of course, Ubuntu or FLOSS more generally does not always function as a meritocracy. Yet the belief that FLOSS is meritocratic and that Ubuntu is or should be even more merit based is ubiquitous (see G. Coleman 2005). In a nutshell, this belief extends from code, in that code is considered universal, that anyone can learn to code, prove themselves, and then be judged only by the code they produce. In the end, this means the best naturally rise to the top in the Ubuntu community, which David finds comforting: “What’s nice [is that] the people in charge are basically there because they’ve been working the hardest and they’re good at what they do. Everything is a meritocracy.” Within Canonical, meritocracy is most commonly expressed in discussions about Canonical’s “culture of excellence,” here as explained by Jono: we struggle in terms of hiring people, we struggle in terms of hiring good people because this culture of excellence demands really good people, and so we really don’t have any option but to be choosy … we don’t care where you come from, as long as you’re good. Market forces are considered capable of delivering this meritocracy because the FLOSS world imagined to not be bound by the constraints of a firm or other hierarchal 145 organizational forms. The emergence of the service sector, cultural industries and the general vertical disintegration of production has meant that more components of any given production process are decided by some market (“free” or not). In the case of Ubuntu such change in the organization of labor is not only about a belief in the efficiency of markets, but also to also produce a fun and rewarding labor process. Shuttleworth discusses these dynamics of the Ubuntu labor process as both a key value of Canonical and the means by which Canonical is capable of “making a difference:” (10:14:21 AM) sabdfl: it feels like a delightful place to work and i want to protect and defend that (10:14:26 AM) sabdfl: since i’m here all the time :-) (10:14:33 AM) sabdfl: and i think the other team leads feel the same way (10:14:56 AM) sabdfl: we do like to hire from the community, because we know then that people are committed to the values of free software (10:15:02 AM) sabdfl: and can work on a global distributed basis (10:15:29 AM) sabdfl: i think we make a big difference despite being only 7% of the size of Red Hat The belief in meritocracy has wide reaching explanatory power that helps people make sense of contradictions and inequalities in the Ubuntu labor process. In particular, that only 2-9% of FLOSS contributors identify as female causes Ubuntu and FLOSS workers to ask themselves serious questions about gender inequality, the culture of work, and education on a regular basis. A discussion on the “Ubuntu Women” email list serve was started when one participant asked how gender does or should matter: I was born and raised in the USA (as a male); it may be our ‛culture’ (or lack / perversion thereof) but the question that *I* could not answer from your simply reading your intro ** was, what is your gender. The next question was, does it matter? or is there a legitimate reason I need to know the gender of participants here? (UWVol28I1, Wed, 30 Apr 2008 05:19:33 -0700). Another participant (not person in question above) replied: 146 In my case, my full name reveals my gender, country and some years ago after a few instances of harassment, i switched to using a gender-neutral nick online. It saved me the stress of dealing with creepiness online … Personally speaking, in the technical/free software community, I dont think knowing the gender/location/age/country of the person in a tech community should matter at all (UWVol28I1, Wed, 30 Apr 2008 15:25:55 +0100). The tension between meritocracy, inequality and harassment often arises, and it very frequently takes this particular form of asking “should gender matter or not?” Which, quite often, gives rise to a more revealing (and unanswered) question asked by another participant: “Why is the *someone* who starts the conversation always a male? Or, because that question is probably unanswerable, why did you find it so important to find out Kadambari’s gender, why does knowing that matter to you (UWVol28I1, Fri, 02 May 2008 12:14:40 +1000)?” One part of the answer is that for many involved in the FLOSS world, any discussion of inequality is bound by the terms of an ideology firmly rooted in the belief in meritocracy, and the only room for this discussion is whether or not gender should be factored into some form of merit. Another key component of the ideology of work within Ubuntu is the firm belief that “work” is the means to fully realize one’s capacity to make a difference in the world. This belief is framed as the antithesis of working on the “production line” where the self dies, there is no room for creativity, etc. Working in the FLOSS community or even working for Google, which, after all, has campuses, not factories—is understood as working in something like the anti-factory. This means that career or occupation have often become a key—if not the key—means of defining self and self-worth, as well as the primary means thought which we are presented an avenue to “do something meaningful with your life.” This is not new, and is very similar to the pride of autoworkers 147 interviewed by Terkel in 1974 talking about how much it means to them to “see a Chrysler bumper and and know that I made that.” A similar sentiment runs through Ubuntu work, many folk expressed excitement and awe at the idea of “millions of people” using something that they helped make, and that this thing, Ubuntu, is something that can make life better for people by providing access to computing technology were it otherwise would not exist, be priced out by the cost of proprietary software, or not be translated into an appropriate language or format. 61 The most interesting part of this ideology of work for me is the belief that coding is and should be fun. The following chapter spends a good deal of time exploring exactly what this means, but the complexity of fun is glimpsed in how different folk talk about fun. Community Manager Jono frames fun in terms of, unsurprisingly, how fun affects how people feel about and do their work: “people feeling like you’ve got control... that’s a big aspect of fun I think, feeling like you’ve got the ability to conduct your fun.” This makes fun appear to be linked to autonomy, but as I explain later, such fun is only possible embedded in a system of dependency. When I asked kernel developer Nick about the most fun part of his work he lit up and replied excitedly and without hesitation: “The most fun is that I saw my patch applied! And you know my name will be always there as part of the Linux Kernel! I used Linux for a long time and now my name is on the wall!” Here fun appears as a motivation, but from how Nick talks about his work and 61 Ubuntu is fully translated from English (the primary language of software development) into twenty- nine languages and some work has been done on 160 of the 218 language projects that have been started; however, bug reporting and much support remains in English. This creates language-based “silos” of bug fixes and documentation that are not shared between Ubuntu users or developers. That is, a bug experienced by a Portuguese-speaker user might find its solution in a Portuguese-language IRC channel, but never make it into Ubuntu’s bug-tracking system unless someone who understands both English and Portuguese sees the issues and takes the time to transfer to the bug into English and enter it into the bug tracker. 148 the joy he finds in coding of any sort it is clear that he does not work with the goal to get patches applied. In an application letter to be a “Ubuntu Universe Contributor” (to have the authorization to make code commits to the “Universe” repository), an Ubuntu contributor referenced the title of Torvalds’ autobiography, noting that “All I did is ‛just for fun’, I’m interested mainly in learning, learning, and more learning...and I feel Ubuntu development will be a great source” (MOTU Council Digest, Volume17 Issue19, Mon, 28 Jul 2008 15:19:47 +0200, archived by author). This is the part of the Ubuntu ideology of work that I focus on in the next chapter: the belief that working with Ubuntu is and should be fun, and that this fun is productive of all sorts of valuable things that are based in the work of making code. To be clear, none of this short discussion about ideology is to say that a mental framework for making sense of the world based in thinking about services, creative work, or meritocracy is false and should be replaced with a correct ideology based in the actual conditions of the world. Rather, the point is that any ideology is capable of taking on material force when it becomes or is on its way to becoming common sense. There is always struggle over what is common sense, such as the Electronic Arts employees that sued for overtime or the ongoing discussion of gender inequality in Ubuntu. I am simply interested in a theory of working with code that connects workers to the materials, goods, and people that might otherwise appear as disconnected from the work at hand. Services, creative industries, and software are all concepts tied up in frameworks that occlude connections—and it hurts my head and has taken me years to be able to approach a framework for understanding code that I hope can help forge such connections. 149 Informational and Cultural Goods: Is that what Code is? For this exact reason, connecting the product of labor to near and distant economic processes, places, and people, I agree with Sayer and Walker that the difference between services and goods is in the material form taken by the product of labor (Sayer and Walker 1992, 60). This is particularly relevant to thinking about the information economy or informational goods, which is yet another approach to thinking about the transformations that the “service sector” and “creative [blank]” seek to explain. Dicken explains that the difference in form between services and goods is that services are about processing “information rather than material” (Dicken 1998, 389). Information, especially digital information, is almost never non-material. 62 When laboring produces something that becomes digital, the material form of that labor can be fleeting—data traveling as a set of packets between switches that route internet traffic exists and is removed a dozen times in a hundredth of second. Yet the digital is simultaneously overwhelming in quantity and permanence—if that data is hosted on a server connected to the internet that is accessed by a search engine bot or some person willfully copies it, that thing could exist for many years beyond its intended life or well outside of its intended audience, as various scandals and leaks frequently remind us. In order to understand code’s relation to information it is essential to discarding any notion that information has a necessary relation to the concept of services, that information requires mental rather than physical labor, or that creating information means creating something which is not material. In the case of FLOSS, the digital detritus of the 62 Even in moments when it exists as a set of waves or electrons, digital information must be understood to be taking a material form and consuming a scarce resource (electricity, bandwidth, and/or wireless spectrum, not to mention wearing down machines of metal and plastic). 150 full life of making code will are typically made publicly available as documentation and as part of the open production process that enables anyone to see how things work: emails, online discussion, conference presentations, text posted to the public internet in some form, all are purposefully archived and a forgotten email will come up in an online discussion five years later. In such a case, information cannot be separated from its material form, which must be kept in mind when thinking about the role of information in any given economy. The information economy is a relatively old idea, dating to at least mathematician Norbert Wiener’s Cybernetics (1948) or economist Fritz Machlup’s The Production and Distribution of Knowledge in the United States (1960) (Wiener 1962; Machlup 1977). And what the concept seeks to describe is not a new phenomenon—as Yochai Benkler argues we are at least 150 years into the information economy (Benkler 2006; see also Hepworth 1989). The vast majority of this literature, especially Castells’ work, is marked by a lack of analysis of code, computing infrastructure and the architecture and operation of the internet. For Castells, the information economy is “a social structure made of information networks powered by information technologies characteristic of the informationalist paradigm,” a confusing definition that rests on the primacy of information in the economy, but primary in abstract “paradigms,” rather than the infrastructure or attention to what “information technologies” mean in their (implicit) digital form in Castells’ work (Castells 2001a, 161). Which makes sense when looking at OECD data, services, cultural and creative industries, and the like. And such an approach works well when grounded in both the technologies at hand and the lives of the people 151 who use them, such as how such networks hit the ground via cell phone use and the other, non-digital networks that constitute people’s lives (i.e. Cartier et al 2005). Absolutely, one of the things that code does is enable people to process, understand, modify, and transmit information in new ways. This is not just about changes in personal communication and media consumption, it is also about the very basic sending and reception of signals—between machines, feedback cycles in production processes, sensors in cars, etc. All sorts of signals are carried by code and all sorts of goods use code to carry signals and to make them meaningful. Some of this is very basic substitution designed to make an old good new or newly differentiated in an already saturated market: watches, toasters, coffee makers, and the like that rely on code for new “digital” features where once there might have been analog switches and sensors. A toaster that uses code should make clear that code and the digital have no necessary relation to what might be called an “informational good.” The “information economy” is not a particularly meaningful concept—we can just say economy—the interesting question for sorting out code is to ask about what is exchanged in the economy that makes a concept like “information economy” make sense? The exchange of information really means the exchange of something that carries that information and makes it useful, often called an “informational good.” To begin to define such an “informational good” it is useful to quote again from Sayer and Walker’s The New Social Economy: all goods communicate symbolic information, if only in their appearance: chairs carry the utterly conventional meaning that they are things to be sat on ... only certain goods, however, have as their principal use-value an ability to store, transfer, and interpret information (Sayer and Walker 1992, 63). 152 An informational good thus ultimately refers to the good’s use-value, not necessarily its trade as a commodity; and not its existence in any particular form or media, meaning that a chair could have its primary use-value in storing, transferring, and interpreting information. How things are made to mean, how information goods are tied up in mediascapes that are often simultaneously the space of everyday life and the space of capital accumulation, is what makes a good “informational” in these terms. It is also important to remember that markets for exchanging informational goods, even if they are markets enabled by networked digital computing, are not necessary fundamentally different than any other market. Such a market is by no means a “more perfect” market, for “if the internet could reduce friction, the same technology can also be deployed to create more of it” (Bar 2001, 31). Only a small fraction of “e-commerce” exchanges involve the movement of digital goods, and e-commerce allows for the continued domination by entrenched firms: “93 percent of business-to-business e- commerce today takes place in ... ‛private or proprietary exchanges’—marketplaces controlled by the market’s dominant player” (Bar 2001, 43). The primary change in a market that uses digital computing is the speed and frequency at which exchange occurs. There is also significant change when a new player enters into that agglomeration of human decisions that constitutes a market. Algorithmic decision making increasingly helps determine mundane decisions that once might have been made by people. This is neither better nor worse, but holds the capacity to further abstract capitalism from any care about life or the future, and do so through the mundaneness of the market—by 153 changing how decisions are made, from how many screws are purchased for a factory to when contracts are promised in a futures market. Any market is still a collection of people making overdetermined choices about what the person imagines to be their own, some other entity, and/or capital’s best interest. Whether or not these decisions are augmented by an abacus or tens of thousands of lines of code that constitutes a “learning” algorithm, capitalist markets are still about capital extending beyond its capacity to comprehend or care for the future. Even the “Flash Crash” of May 2010 is not a different phenomenon than any other crash—but the speed at which it occurred is certainly different. This speed, coupled with the obfuscation of the role of code and computer programs in markets, serves to further disconnect any given market from the materials which are actually being exchanged. This abstraction is fundamental to our collective participation in markets that deal in death and are in no one’s interest, with no future. This abstraction is enabled by code, further demanding a theory of code that enables connections between such abstractions and material, bodies, and places. To begin to clarify the meaning of informational goods it is useful to address the idea in relation to the concept of “cultural production” in economic geography (Sadler 1997; Power 2002; Norcliffe and Rendace 2003). Geographers Glen Norcliffe and Olivero Rendace’s provocative study of comic production in North America neatly encapsulates assumptions about how the information economy works and how production is understood to be different, via their definition of “cultural production:” 154 we define cultural production as involving creative acts that require the focused use on intellectual faculties that are then integrated with other outputs to produce goods and services that have aesthetic appeal (Norcliffe and Rendace 2003). Although Norcliffe and Rendace are thinking in terms of “cultural” goods, there are three concepts at work here that need to be pulled apart—the idea that some goods are “cultural” and others are not, the relation of art and design to the production of goods and the production of “informational goods.” Such a pulling apart must be understood as arbitrary, political and incredibly fraught and complicated, yet necessary for thinking about economies and goods. First, I want to discard the idea that some goods are “cultural” (comics or garments) and other goods (toothpaste or machine screws) are not (e.g. T. Barnes 2005). Thinking of culture as “whole ways of life” means understanding machine screws as cultural products in that they are a fundamental way in which we create, remake and maintain the material fabric of everyday life. One of the ways that a comic book does differ from a machine screw is that it is an informational good in a way that a machine screw is not. To clarify, counter to Norcliffe and Rendace, the difference is not that making a comic book is being “creative” versus the making of a screw being “vocational or technical” (Norcliffe and Rendace 2003, 241). To think this is the difference between these two goods is to write the meaning created by the consumption of a comic book back into the production process as if the author, producer or artist is the origin of meaning, instead of recognizing that meaning is created in use and can never be fully captured by the exchange value of a comic book. Thus, although there is something different in these sorts of goods it is not because creativity or intellectual faculties are deployed in their production. Yet Norcliffe 155 and Rendace are talking about a good that clearly has a different capacity to communicate than a machine screw: comic books are consumed as if they have the capacity to make and remake the world. Much like Ubuntu: Ubuntu is as much a “cultural” or “creative” product as is a machine screw, but Ubuntu is an informational good when used to convey information, the screw is not often used to convey information; machine screws are not often imbued with the belief that they can remake the world, even though the machine screw, in a long historical analysis, is likely more significant in making the world we know than Ubuntu ever will be. And, in moments of code’s movement, machine screws are part of Ubuntu. Code can be a sort of informational good, sometimes, and is as cultural as anything else, but this last piece, how we imbue code with meaning and represent code’s potential to change the world, signals that there is something else going on with code. Extramedial: A Necessary Addition to Informational Understanding code requires not only addressing its production, circulation and consumption; there is also something its “representations of use,” or what Chun calls the extramedial: “representation of networked media in other media and/or its functioning in larger economic and political systems” (Chun 2006, 15). Which is to say, how we imagine software and code to do things outside of the realms of the production, circulation, and consumption is incredibly important. The extramedial is different from what I have been discussing above—which has been the ideologies we use to make sense of code and software. The extramedial refers to acts, artifacts and media, from an Ubuntu 156 teeshirt to Microsoft’s recent “to the cloud” advertising campaign. Although the extramedial is not a primary vector of my analysis it is essential to understanding FLOSS —and without using Chun’s term Kelty and Coleman have covered much of this terrain in their anthropological studies of FLOSS (Kelty 2005; G. Coleman 2005). Extramedial is a key concept because it demonstrates that how we imagine code to be and to do things in the world and in our lives is also about how power works. Imaginations and beliefs in code are not a product of our independent imaginations, but operate in concert with representations of code in media, by ICT corporations, through commercials, and in moments when computing devices fail or disasters take down computing or network capacity. At the same time this all matters for FLOSS—the stories that coders tell themselves on Slashdot (a very popular technology news and discussion website that bills itself as providing “news for nerds, stuff that matters”) at conventions, in books and on email lists matter—and so do teeshirts, tattoos, and stickers—in creating shared imaginations of what code is and what it can do for the world. At my first week-long FLOSS conference, I noticed many things that would later become background visual noise: Levis with brown belts, the occasional group of punk/goth looking folk, running shoes, brown loafers, black boots, white guys, and a group of six white men all wearing khakis and collared shirts and wearing the same uniform until I notice that none of them match and they appear to have no actual relation to each other. But what was most striking was the tee-shirts and computer stickers. Seeing a man wearing a “No, I will not fix your computer,” and five minutes later seeing a woman wearing a “Yes, I will fix your computer” teeshirt made me realize something 157 was up. Teeshirts referencing other teeshirts appearing to indicate a gendered division of labor turned out to have a different explanation: the first being a popular shirt from an online vendor, the second being a database company’s promotional shirt that played off the first. There were many Ubuntu related shirts. Aside from the polo shirt with a small logo of a firm, organization, or FLOSS project on the breast, Ubuntu was the most popular by my count. There were many hacker, geek, or FLOSS related shirts that I did not at the time recognize, many I did; many that were funny, many that I assumed were funny, and one with some meta commentary that summed up much of the scene: “my geek t-shirt is funnier than yours.” But everyone has laptops. This is true almost all the time, if people are not walking, they have a laptop open. Most laptops have stickers— FSF, EFF, Debian, Ubuntu. Geographer Stephen Graham thinks about software somewhat similar to Chun, focusing on the the role of software in shaping social and geographical politics of inequality. This work does not take as its focus how software is produced or discourse about software directly, but the effects of what he calls “software-sorting” technologies. These “code-based environments” (such as facial recognition technology and online geographic information systems) “continuously and invisibly classify, standardize, and demarcate rights, privileges, inclusion, exclusion and mobilities and normative social judgments across vast distanced domains” (Graham 2005, 563). 63 Graham quotes a study of facial recognition software that reports “Asians are easier [to recognize] than whites, 63 Like Graham, I am concerned with algorithmic decision making and believe that understanding algorithms is key to understanding our world. In particular, algorithms appear utterly necessary to understanding capitalism—especially new forms of old racial capitalism—yet algorithms, how they are produced and how they work remain mostly off the radar. And, in my case, still quite out of comprehension. 158 African-Americans are easier than whites, [and] other race members are easier.” According the Graham the main danger of this is that: algorithmically controlled CCTV systems might work to deepen already establish ecologies of normalization, and demonization, within neoliberal urban landscapes of power ... these very logics [of exclusion] could, conceivably, be embedded in biases within the very code that makes facial recognition CCTV systems work (Graham 2005, 574). Leaving aside what “other race members” stands for, the reification of racial categories, and the presumed visual nature of race itself, this formulation seems to miss how whiteness and racial difference are formative in the developing of such technologies and the imagining of their use. While locating “bad code” (or “racist code?”) is certainly not impossible, it seems to be a somewhat different point of analysis from Chun’s use of extramedial to bring focus to the larger milieu in which code comes to have meaning. Thus the solution to this problem as framed does not demand an exploration of racialization, but a multidisciplinary effort to open-up these “black boxes” because of the “invisibility of operation and design of such systems” (Graham 2005, 574). What Graham is trying to get at, I believe, is something akin to the manner in which software—as a packaged, intentional construction—indexes its users as certain sorts of recipients. Mackenzie’s answer to how software can be made intelligible “lies in the ways code indexes people or machines as recipients” (MacKenzie 2006, 15). “Recipients” is one of four entities of software (code, originators, recipients and prototypes) that Mackenzie bases in Alfred Gell’s anthropological theory of art as an index of agency (Gell 1998). Such a formulation only works if indexing is understood not as an index internal to code itself (i.e. an output directed to someone or another piece 159 of code) but rather that in the execution of code, be it a doorbell or complex regression analysis, indexing occurs with already imagined recipients. That is, for whom the door bell tolls and what the sound of the bell means is configured through a whole set of performative spatial/aural/linguistic relations. “Who code is for” functions in a similar manner, with similar overdetermined complexity. This recognition is a key step towards understanding what code does. From this opening, the extramedial makes it possible to think about the social relations in which code is embedded. This means that software/code is always indexing people and places as differentially potential (or not) recipients of code. Combined with its extramedial representation, the execution of code indexes software’s proper use and proper place (where is code “reasonable” to be put into use, linked intimately to who is imagined to appropriately use code) by way of how code is imagined to function. Chun’s theorization of code’s relation to law is similar: “law’s effectiveness depends on enforcement (self- or otherwise), code’s enforcement stems from itself” (Chun 2006, 67). Thus, Mackenzie’s focus on how code indexes users can be re-read as providing hints at how ideas about how subjectivity is tied to the proper(ty) of code, or, how code is tied up in indexing difference. The extramedial indexing of difference became clear when I asked Ubuntu contributors “how do you think Ubuntu can or will make a difference?” The question was almost always answered as if the question asked was were “where” could Ubuntu make a difference. While this is a good indicator of how Ubuntu contributors think geographically, that the where in these responses was “the third world” or “developing countries” is indicative of FLOSS discourse on 160 technological change, which often positions places where there is the least amount of computing use and infrastructure as the place of the most possibility. There is a great need to explore the materiality of code in its production, circulation and use; a need that is complicated by the fact that all three happen simultaneously. How would our understanding of the internet or economies change if grounded in an understanding of code rooted in energy consumption and electron movement, hard drive platters and heavy metal mining, silicon and water consumption, keystrokes and hand solders? How would it affect the consumption and production of everyday truths about code and software? I believe such a stepping back from code to ask “what is code?” to be essential because code is not quite like anything else—and to this end, I welcome being wrong about what code is and am sure that being able to wrap our heads around code will be an ongoing process. Nonetheless, drawing upon the work of scholars seeking to figure out various aspects of changes engendered by the creation, circulation, and use of digital things, there are a few key points about code that I am convinced are essential to understand what code is and what it does. First, contrary to computer science common sense, there is no total knowledge of code. This should be relatively obvious, and certainly many computer scientists would be quick to point out the same—in any machine or any human transformation of the world, there are things that factor into production and outcomes of what is made that can never be anticipated. This truth also makes clear that a formal analysis of the structure of code cannot expose what code is or does. 161 Second, code is material. Software is an abstraction that allows this material to be exchanged. It is worth repeating: Code is the material with which Ubuntu contributors work; what they end up making is a material artifact. Code is metals, silicon and plastics, and comes into being when combined with electricity at the hands of humans, or automatically at the bequest of another code/machine. This materiality is the base of code’s dual nature: code is the material form in which something akin to a set of instructions reside; code is also an executing, moving, malleable, and unknowable material which moves and becomes inseparable from the materials and machines through which it moves. Third, code moves at speeds beyond the capacities of human observation, and this speed makes time and place matter in different intensities. Thus, code is very much so involved in the creation and experiences of capitalist time. The speed and movement of code is a key factor in shaping the experiences of its production—meaning that the way the Ubuntu labor process proceeds is indebted to both the speed at which code operates and the time it takes for code to be turned into some meaningful form of information. Fourth, code is sometimes, but by no means always, an informational good. This has nothing to do with the nature of code; rather an informational good is determined by how the good is used, and code is often used to carry information. In the case of Ubuntu (and many goods) it is not just that code carries information, but that we imbue such code with a belief that it has the capacity to change the world in some way. This additional layer of meaning in code comes into being through extramedial representations of code— 162 the way that people, firms, organizations, and governments present code in other media, from ads to teeshirts. Fifth, when thinking about code’s place in our economic imagination, code must be understood as a good; not a service. The concept of services has a particularly revealing history as an ideology that has helped explain industrial change and various reallocations of surplus (theft). This particular ideology has gained material force and in the case of the Ubuntu labor process it is intimately tied to an ideology of work based in the belief that labor is organized by a meritocracy, that as coding is creative work and as such should be structured differently from other work, that one’s contribution to the world and realization of self should and is best manifested through “work” (which is itself a blurry category in this ideology), and that coding work is and should be fun. Keeping the dual nature of code in mind, its inextricably from computing hardware, and its movement and materiality, Chapter Two bring us back to the Ubuntu labor process and how fun has a role in organizing the work of making code. 163 Interlude: Bug Jam It’s about the fun! The event is not a competition about who fixes the most bugs, but it’s about the unique experience of having Free software enthusiasts in one room, enjoying the feeling of making the world a better place. (Ubuntu guide to hosting a “Bug Jam”) After some confusion navigating via bicycle from a regional commuter train to a small private Orange County university I wandered into a slightly cramped computer lab to find Carl setting up a projector. Carl would later give a short informal presentation on encryption and secure identification, but for the moment we were both just struggling with waking up, finding coffee and getting ready to do some Ubuntu-related work on an early Saturday morning. The “Global Bug Jam” event that followed felt surprisingly normal to me. I was interested in everything that was going on, or at least most everything. Much of the technical discussion was well over my head, but after a year of following Ubuntu and thinking about code, the debates, arguments, puns, and jokes were familiar. The “Jam” lasted about seven hours, beginning with two hours of semi-formal prepared talks. After the talks, the fifteen of us walked over to a local burger counter for lunch, with many jokes about geeks and nerds on the way over—with some collective absent mindedness we all stepped into a street with a bit of traffic and someone joked that an SUV could take out ten geeks crossing the street in one fell swerve. Folk told stories of absurd moments in software and computing history and debated legal and ethical points of intellectual property, constantly referencing books, theorists, blogs, and well known FLOSS coders. After lunch, nothing formal happened; no one was leading the group anymore, people simply settled into working on what they wanted to learn or accomplish. Some university students installed Ubuntu on two very old computers, including working on a hardware hack to run Ubuntu on a laptop with an 800 MB drive (ancient and tiny in 164 computer time). One person spent an hour trying to remember a GPG 64 password, and to everyone’s joy, remembered. Key’ s were signed, 65 some folk worked quietly on their own projects, random videos were projected, and devices were shown off—a Linux phone, a Nindendo DS spoofed to look like it was running Ubuntu, my EEE PC laptop (one of the first “netbooks”) 66 with a freshly installed Ubuntu Netbook Remix in place of the other version of Linux that came installed on the device. I talked about the machine a bit and several people tried it out. I was happy that it worked, this device and another netbook would become primary research tools. I used them not only for organizing all my research notes, transcribing interviews, and writing the dissertation, but also, with the addition of a few FLOSS stickers, these laptops ended up serving as markers of belonging and conversation pieces that make me feel more comfortable at FLOSS events such as this one. For the most part people just worked without any particular goal in mind while helping each other out and by the end eleven bugs were “touched” in some way—and one was mine. Collaboration took two general forms, one when someone like me who had never worked on a bug before made a semi-deferential request for help, i.e. professing ignorance or stupidity. Collaboration between those who acted as peers often took the form of taunting and challenging: David: “How long would it take you to write a Python script to do this?” Sam: “Three minutes, but sadly for you, I have to leave now.” David: “I’ll hold you to that.” 64 GPG, or Gnu Privacy Guard is a form of public key encryption that allows for secure communication. My notes on setting up my GPG key for the first time are full of frustrations—what can be described as a simple act, “Ubuntu contributors sign the Ubuntu Code of Conduct using their GPG key,” actually took me several hours over a few days, lots of reading, many mistakes, and eventually some help from folk on the LoCo Team. For a new non-technical Ubuntu contributors, the support of the LoCo team, or some other form of mentoring, is often essential. Now I might casually reference such an act as normal and easy, but the difficulty in doing so reveals the immense amount of technical knowledge that is assumed in FLOSS communities. 65 Keys are signed so that people can verify each other’s identity and create a “web of trust.” At the key signing, I presented my ID and the public-key to a few members of the LoCo Team, who later digitally signed the public-key, verifying that this key corresponds with me. This form of encryption can be used to encrypt email message and to verify the sender of an email, or some other forms of digital communication (or commits of code). The “web of trust” is created because if someone trusts the identity and key of a person who signed my key, they can then implicitly trust my key to represent me, even if we have never met. 66 At the time, this small (7” screen), inexpensive (I picked it up for $100 used) internet-ready laptop form factor was positioned by many in the FLOSS world as the future for the Linux desktop and in public talks Shuttleworth frequently presented his dream of having hundreds of thousands of these devices running Linux. Yet, the work of getting Ubuntu pre-installed on netbooks turned out to be far more difficult than anticipated. Several Canonical employees in Taiwan attested to the intense stress and difficulty of working from the FLOSS world with proprietary hardware developers who built such laptops and their component parts. 165 Sam, the leader of the California LoCo, casually established a form of technological superiority simply by saying several times that he could not help someone because he never uses a GUI (Graphical User Interface). Sam works almost exclusively with the text-based interface of the command line, which requires a different set of skills and knowledges that are valued as a higher, more pure form of interacting with computers. When most people left, I remained with Sam and Carl to play some video games. They were both pleased with the turn out and the eleven bugs, and happy when the above pictures appeared on Jono’s blog (see Figure 4). Two days after the “bug jam,” the bug I confirmed and assigned to a package was taken on by someone else who finished the triage and assigned the bug to a different, more appropriate package. I read the log not really understanding what had been done with the bug, but it felt good to think that I may have played a small part in getting the bug eventually fixed. (I was also excited because the bug affected my netbook.) Doing the work to confirm the bug was not exactly fun, it was often frustrating—but in the moment of understanding what I needed to do and hunting down the package that was causing the bug and figuring out the system, it was fun. And it was fun to work with others in the same struggle to figure things out. After the jam I was certain I would do my “Five-a-Day” and triage five bugs each day in accordance with a Canonical program that tried to encourage both bug work and reporting it in a manner that generated useful data for Canonical, but I never really worked on bugs again (besides a few bug reports here and there). Months later, at the Southern California Linux Expo I 166 Figure 4: Images Taken at the California LoCo Global Bug Jam Posted on the Ubuntu Community Manager’s Blog (with me, second from the right, looking like a dork) found myself helping someone triage their first bug and wrote the following in the my daily research notes: “I actually helped someone with Ubuntu bug reporting ... it was cool!” This moment, which Hyde would identify as the completion of a cycle of gift exchange, is one way the capacity for fun in the Ubuntu community is reproduced. 167 Chapter Two: Fun at Work ‛The joy that I had from being able to do programming and actually produce something’ soon became too strong, he says. ‛Fun’ was central to what might be considered the golden age of hacking: ‛We had fun writing programs, we had fun playing hacks on each other.’ (Stallman in Moody 2001, 15-16) The majority of time spent making computer code is spent debugging—finding various types of errors in computer code—a task that can be very tedious, and often not fun (c.f. ACM and IEEE 1987; Walls 2005). FLOSS is frequently promoted as superior to proprietary software precisely because of its debugging process, encapsulated by a oft repeated quote from Torvalds that “given enough eyeballs, all bugs are shallow” (Torvalds and Diamond 2001; Raymond 2001; Weber 2004). “Torvalds’ Law,” as this pithy remark is often referred to, may or may not actually result in better or more quickly produced software, but the labor relations it references are central to FLOSS development. Releasing a new version of Ubuntu every six months requires a great deal of coordinated eyeballs, even if they are as loosely and informally coordinated as in a bug jam. It is out of the need to reproduce a rhythm of work that can coordinate tens of thousands of people’s efforts that the above quote claiming “it’s all about the fun” emerges. I encountered the “Global Bug Jam Guide” when someone shared a link to it during a bug jam planning session in a monthly IRC meeting of the LoCo team (see 168 Appendix E for the full guide). The guide is designed to help LoCo Teams figure out how to host a bug jam, and how to publicize the event both before and after its occurrence. The reproduction of the capacity to have fun takes the form of photos such as the above of the bug jam that get posted to blogs. Such descriptions and prescriptions of fun are key to organizing fun—which, in Ubuntu and other labor processes, is also to say, key to organizing work. That is, this figuring out of how fun intertwines with work is necessary for the production of Ubuntu and is as important to the future of Ubuntu as the eleven bugs that were touched during the bug jam. The relationship between fun and volunteered labor, or what Tiziana Terranova calls “free labor” (Terranova 2004, 73), emerges as unavoidable in Ubuntu and FLOSS, but it only becomes unavoidable under a certain set of logics and conditions, and with an eye turned towards experiences of working, towards paying attention to what a bug jam feels like as well as daily and more mundane experiences of work. Fun, or something like it, is found in numerous social science endeavors to understand motivation, occupational choice, the social implications of changing working conditions, productivity, entertainment, recreation, and more. Psychologist Edward Deci’s pioneering work, Intrinsic Motivation, proudly proclaims in its preface that the book contains an “enormous amount of research which establishes unequivocally that intrinsic motivation exists,” (Deci 1975) a work which decades later would influence economists and others to start studying happiness (e.g. Frey and Stutzer 2002). Johan Huizinga sought and struggled with his colleagues to “integrate play into culture” and his thesis Homo Ludens has become a touchstone for sociology, media studies, art history, and 169 other disciplines concerned with play, development, and learning (Huizinga 1998). Mihaly Csikszentmihalyi’s development of the concept “flow” to explain that state of absorption when people’s skills are matched with environmental challenges has opened up a field of inquiry into working conditions, happiness, and creativity in psychology, anthropology, and elsewhere (Csikszentmihalyi 1975). The bodies of scholarship related to these three works form a framework through which fun makes its way into scholarship —as a form of intrinsic motivation, as an outcome of play, or as an example of a “flow- like” state. While all of this scholarship sheds some light on fun, my research on how fun works in the Ubuntu labor process has revealed that fun is much more than a motivation, that as an affective state, fun cannot be reduced to play, and that fun, although flow-like, has a social life beyond its moment of experience. Studying fun is thus a way of asking the question that I believe lies at the base of scholarship from Richard Florida to Giles Deluze and Felix Guatarri, from Michael Hardt and Antonio Negri to Studs Terkel (Florida 2002; Deleuze and Guattari 1987; Hardt and Negri 2000, 2009; Terkel 1974): how do we recognize, think about and represent those aspects of laboring that qualify (affectively, emotionally, humanly) experiences of work, and how should we categorize what appears as new types or forms of working? In what follows I take aspects of the above scholarship and turn its focus from looking at why people work toward how work proceeds and understanding where and how fun fits into the order, organization, and processes of working. 170 Observing and peripherally participating in the Ubuntu community for the past four years conducting ethnographic research has filled me with an appreciative ambivalence for the Ubuntu labor process. The “fun” of working with Ubuntu sits at the center of this ambivalence. Fun is a means through which labor is organized in a way that makes it “natural” that workers give their labor to some purpose—this “purpose” is simultaneously capital accumulation and the reproduction of an organizational form (“the community”) based in a system of exchange that is non-capitalist and servers other ends. At moments and in particular places, the use of unpaid, often precarious labor makes Ubuntu appear as a nightmare wherein the flexible worker has been nigh-perfectly exploited: contributors give labor not only to those who profit by selling support for Ubuntu, but also to firms like Google, IBM, and others that rely upon Ubuntu, and in doing so pass risk from firms to the bodies, homes, and family units of Ubuntu contributors while filling shareholders’ pockets. In other places and times, in different social and economic contexts, Ubuntu appears as a FLOSS dream, creating new forms of social life and exchange that promise a more just and humanized system of software production and use: value is created and circulated in a system of exchange organized around the reciprocal relationships of gifts and with that often expressed and vague goal of “making the world better.” The creation of the capacity for fun is a reminder of how prevalent counter- capitalistic impulses and organizations are—even as they are integrated into the capitalist mode of production. This reminder is no minor point. Following J.K. Gibson-Graham, who sought to problematize how we use capitalism as a totalizing descriptor, even when 171 we know better from how we live our lives and what we see and know of the world, it remains all too easy to use capital, capitalism, or capitalist as such. For, “not only do non-capitalist practices fail to disappear over night but they cannot help but reappear (even as taints or contaminants are always appearing in anything ostensibly pure and perfected” (Gibson-Graham 1996, 244). These non-capitalist practices are not anti- capitalism or likely to be the source or form of what follows capitalism, but they are with us and are part of making our world. Fun and FLOSS reveals how deeply capitalism is dependent upon non-capitalist life and production. Ambivalence, although a rather trendy academic term, is worth holding on to as a way to keep in mind these multiple and contradictory conditions of work in the Ubuntu labor process, especially the wide range of working conditions and sorts of labor performed by those who give their time to Ubuntu (see Hesmondhalgh on ambivalence and a review of scholarship on volunteered labor, Hesmondhalgh 2010; also, McRobbie 2002; Andrejevic 2009). Fun is a pivot point between modes of production, and paying attention to fun is also a way to understand current qualities of work and how they came to be, even with an eye ever turned toward imagining a future where work is different. As this pivot, fun is key in creating the capacity for value produced by work performed in one mode of production (the “Ubuntu mode of production,” based in something akin to gift exchange and creating and relying upon the commons) to move to another mode of production (the capitalist mode of production, increasingly dependent upon a relationship with the commons as a mode of extracting value). 172 The microcosm in which this fun and the movement of value occurs in Ubuntu is not representative of larger structures of employment or the experiences of very many workers in world. However, the relation between fun and and how it becomes natural that people are willing and happy to give their their labor to capital is a general one. Theorists, workers, activists, and academics have noticed this change for decades (e.g. Costa and James 1975; Schiller 1999; A. Negri 1999; Foucault and Collège de France. 2008), and recently have been engaged in figuring out how this complicated immersion of (what appears to be) people’s whole lives into processes of capital accumulation is entangled in two related but distinct technological processes: The digitalization of objects and means of work; and relatedly, but quite distinct, the reliance upon package switched networks (primarily the internet) to handle the movement of these goods and the communication required for their production and consumption. I believe that much scholarship has lost track (rather literally) of how work proceeds by focusing on the internet (without a great deal of organizational or material specificity) and without paying attention to the digital itself (e.g. Shields 1996; Castells 2001a, 2002, 2004; Benkler 2006). Even in cases where the digital appears to be at the center, the material specificity of what the digital actually is seems to be lost. For instance, a recent special issue on “digital labor” introduced “digital” in this context: To be sure the term ‛digital’ does not simply refer to digital machines and processes but to the entire political, social and economic context and infrastructure within with they have emerged. This is how we now live in a ‛digital age’” (Burston, N. Dyer-Witheford, and Hearn 2010). I recognize that scholars may well understood the material basis and life of digital things and digital labor, and take this life and materiality for granted, as something already 173 worked out and understood. But I worry that this is not the case, and that paying attention to figuring out what the digital is has been passed over, and done so in a way that may lead us to easily make arguments that miss or displace the materiality of the digital, its temporal relations, and in the end, encumber our capacity to make sense of capitalism. Counter examples of exciting, engaging scholarship on things digital are of course also abundant and I would not be able to write this dissertation without folk who think materially with a willingness to be surprised by how things work such as Geert Lovink, Lisa Nakamura, Dan Schiller, Mathew Wilson, and Alexander Wehiyle (as well as the folk I explicitly drew upon in the previous chapter to work through code) and conference-like events such as UCHRI’s Seminar in Experimental Critical Theory (technoSpheres), ephemera Journal’s Work, Play and Boredom conference and the Internet as Playground and Factory conference (Schiller 1999; Nakamura 2002; Lovink 2005; Weheliye 2005; Wilson 2012). Together I consider this very diverse group of scholars and projects to be concerned with possibilities of the form and life of the commons in relation to digital objects (and their analog compatriots), work, and the structure, use, and ownership of the means of producing such objects. Through meaningful considerations of how people organize themselves and are organized— especially the necessary critique of our easy acceptance of the digital as outside of other parts of sociality by scholars such as Nakamura and Lovink—an understanding of the digital can contribute much to being able to see what has actually changed (or not) when internet-based communication becomes part of social lives and economies. This examination of the digital is essential to understanding capitalism and in turn to be able to 174 see and think about how these forms of organization are related to the possibility of holding resources in common. Thus, rather than focusing on how the organizational and communicative possibilities of the internet created new possibilities for fun, I instead focus on what might be old about fun and how working with digital material might or might not be fun. The intensity of early and continued hype around digital and internet-related transformations are certainly partially at fault for the commonsense passing over of the digital in favor of the internet or networks (and the easy conflation of the digital and the internet) (e.g. Rheingold 1993; Negroponte 1995; W. Mitchell 1999). For it appears to make good sense that understanding digital things is covered nicely by talking about the internet. On the contrary, as discussed in the previous chapter, the digital and the internet must be disentangled to think about what it means to work with digital things. Most simply, the relationships between working with digital things and fun is both general and old. It is general because making “digital work” appear as somehow “non-work” is general and should give good warning that the terms and concepts we have at hand might not capture what we think they capture. It is old because the way in which capital is capable of extracting value from people who produce something useful as a byproduct (or sometimes direct goal) of activities organized by fun is general and can serve as a guide for re-locating the abstractions of current forms of economic exchange, as well as give some hints towards other possible, non-capitalist forms of managing resources and exchanging things of value. 175 To begin to think about fun’s role in our economies and lives, it is essential to see fun as defined by and exceeding the scale of the individual. This is not as odd of a statement as it might sound, for the same could be said for most affective states. Instead of using fun as a category or indicator—in which fun would be defined and tested against the experiences of individuals, either self-reported or observed—I insist that fun be located in the social system of its emergence, which always exceeds individual experiences. Although fun is an affective, embodied emotional experience, the means for its expression and effects of its expression well exceed the individual; fun is social. Focusing on the social context of fun is essential to making sure fun is not cast aside as “just” an emotion or feeling—and at the same time making clear it is worth considering emotions and feelings in any attempt to understand how and why people do what they do. Unfortunately, the one scholarly project that takes fun seriously as a fundamental aspect of the FLOSS labor process, the Fun and Software Development (FASD) study treats fun as solely the domain of individual experiences. Although this study would appear to be a very informative project for my work—the study concludes that “Open Source Software can be understood, at least partially, as a by-product of an activity that makes fun and a development model that supports the need for fun in an optimal way”— the authors approach fun as a motivation (Luthiger and Jungwirth 2007, 35). This move uses fun as an indicator to measure correlations between fun and productivity, leading to an analysis that assures corporations that they can “safely invest in an environment of fun for developers in their company” (Luthiger and Jungwirth 2007, 1). 176 Fun can certainly be useful as such an analytic category beyond an investment indicator—but in order to make fun any sort of indicator, commonalities between experiences of fun have to be identified by pulling out certain aspects of fun as essential. Defining fun as an emotional state which people desire allows for the FASD study to conclude that fun accounts for somewhere between 27% and 33% of FLOSS developers motivation. Using fun as an indicator means making hugely important theoretical choices in deciding which commonalities should be used to create the indicator. Such choices sensibly follows from the chosen focus of study, such as individual decision making or group formation, or in the case of the above study, motivation and productivity. Once indicators are identified, tests can be designed, such as the self- reported surveys designed for regression analysis as used in the FASD study. I purposefully avoid forcing the experience of fun to submit to sets of identifiers or features. This act of refusing to define the importance and merit of fun with social science categories is a move to argue in favor of taking fun as already holding a set of politics and theoretical engagements prior to the act of scholarship—engagements and politics that might not survive submission to a social science measure. In other words, measuring fun could easy obscure many of the aspects of fun I care about. 67 67 I recognize that there may be, at times, decent purposes for submitting fun to the development of an indicator and breaking fun down to its constituent parts—but to do so would not serve my research goals of connecting fun with a labor process and people’s lives. I put together a follow-up survey for all of my interviewees with the idea of generating some data that could more clearly link fun and other aspects of working with Ubuntu to the organization of the labor process, but could not decide whether or not to use it. And then I accidentally let my account expire on the “open-source survey company’s” web-hosted survey I planned to use and lost all of my preliminary data and the tool. Which is onto itself a good example of the dangers of relying upon “the cloud” to hold data (and the dangers of absentmindedness). In the end, this dissertation, or a future project, may have benefited from such data, but I am also relieved not have more data to sort through. 177 As a labor geography, this dissertation focuses on building a theory on fun based in a detailed analysis of how work works, in and across places of production and reproduction, rather than allowing “creative,” “cultural,” digital,” or other typologies of work to define the social organization and implications of work as emerging out of some natural conditions of the type of work at hand. That is, I hope to contribute an idea of “digital work”—the variety of experiences and organizations possible when working on digital things—that conjures up a vision that sits next to “metal work” or “needle work” rather than misnomers like “cultural work” or “creative work.” I. Why This Fun Now? Working in the digital media industry was never as much fun as it was made out to be. (Terranova 2004, 73) Why do managers, capitalists, and their cronies with research jobs care about fun and about making certain types of work out to be fun? And care they do; by far the largest body of literature that deals with fun is “management guru” and corporate motivation writings (c.f. Firth 1995; Hemsath 1997; MacErlean 1998; Weinstein 1996; Yerkes 2007). Coming out of a strain of US-based psychology that has focused job fitness, career placement and the like, there is a strong belief that fun can make people work harder, or, in their parlance, when “people experience a regulatory fit when they employ means of goal pursuit that fits their regulatory orientation, and this fit increases motivation that can enhance performance” (Bianco, Higgins, and Klem 2003, p. 1091; 178 also see Redman and Mathews 2002). A key aspect of capitalist ideology in the face of the threat and reality of longterm structural unemployment is the belief for the full set available jobs there are people who have a better “regulatory fit” for each job—a fit that is theorized as realizable through racist ideologies such “American’s do not want those jobs” or job placement tests. Fun is one means by which this “fit” is theorized as realizable—and it becomes worth it for management to tweak “regulatory fit” so that more people are having fun, making it easier to encourage them work more intensely, for longer hours, take their work home, and in general give a more sustained gift of their time to their employers beyond their pay or meeting their own reproductive needs. 68 Canonical employee Tom, who works from his home in the southern US, explains that this happens at places like Microsoft’s Seattle “campus,” where the actual work can be fun, but that management make[s] work fun to keep people at work longer. This is exactly what Microsoft did when they started to make their campus in Seattle. This is a very common way of trying to attract people and make them stay longer at work. Nothing more. Fun is not just the idea of having a water gun at hand to squirt others. Fun is something more durable. Do you enjoy the people you are working with? Do you get good feedback on the work you’ve been doing? This is the fun that really matters. Fun thus emerges within a system, and is specific to that system and the constraints from which it emerges. For example, staring at a computer screen and manipulating lines of text may not appear to be fun, but having fun in everyday work—rather than only in exceptional moments of breakthrough, innovation, or as a break from work—is a basic principle which structures many FLOSS labor processes. Fun is not in opposition to 68 Although by no means are all workers deemed worth the expenditure of creating an environment that is “fun.” 179 work, nor does it follow management literature’s fascination with “making work fun” through extra-work fun such as work parties or casual days; here fun is always fused to the conditions of working with others and exerting human energy to transform something from one state to another. Interestingly, although perhaps not surprisingly, even within management literature, there is an assumption is that fun humanizes the organization of work by creating happy employees who work according to their skills—which happens to yield higher productivity. Which seems funny, as bosses learned long ago the dehumanizing conditions can be great for productivity—so why the rise of this idea about fun now? Their answer is simple: It is not very difficult to see why fun at work is now a popular managerial discourse. Work has never before been so un-fun-like. Employees are working longer hours than ever before and job insecurity and downsizing is widespread. Workplace stress is rapidly increasing and new work problems such as bullying are emerging (Redman and Mathews 2002, p. 60). Certainly, there are arguments to be made that work has been far more “un-fun-like,” but the point remains that in the US, shifting work practices and anxiety over the material decline in standards of living related to the stagnation or drop of real wages would make “fun” a popular fix chosen by managers over living wages, job security, guaranteed pensions, or affordable health benefits. Terranova’s above statement is thus worth repeating—working with digital things is most often not as fun as managers, job postings, management gurus, and the like make it out to be. This is an essential caveat for any analysis of the role of fun in work. Any labor process may or may not be fun depending upon how it is organized. Quite 180 obviously there is nothing essentially fun about digital work, and many labor process of making digital things, supposedly essentially “fun” endeavors as Terranova indicates, are organized in a manner where fun functions primarily to as a means to extract value and as an ideological camouflage for various sorts of deplorable and exploitative labor practices. Describing the 15,000 AOL volunteer workers who labored as chat hosts without compensation and eventually asked the US Department of Labor to investigate AOL for possible labor violations and back wages, Terranova cuts to the chase: “They used to work long hours and love it; but they also felt the pain of being burned by digital media” (Terranova 2004, 73). Terranova’s analysis is often discounted in analysis of FLOSS as too pessimistic and too focused on capital’s role in creating working conditions (e.g. Coleman 2004; Kelty 2008), however, her point about how capital benefits from free labor is essential. The burn of working with digital things can take the form of “burnout” in Ubuntu—a euphemism for stress-induced conditions from mental breakdowns to serious digestive problems to fainting and getting bloody noses from fatigue and lack of sleep—reminding us that there is a politics of fun (who decides how and where that which is made via fun will be used, moved and owned), and there is nothing liberatory or transgressive in and of having fun. Thus it would be a mistake to assume that some sort of “fun” selfhood, in the form of knowing the self, specifically of knowing the non-rational self, will release us from the bonds that discipline and constrain joy, pleasure, or fun. The last line of Michel Foucault’s The History of Sexuality, an Introduction sticks in my head, warning of false promises of this logic: “The irony of this deployment is in having us believe that our 181 ‛liberation’ is in the balance” referring to the apparently liberating unearthing of the “truth” about sexuality in discourses that followed Sigmund Freud’s work and up to sexual liberation of the day (Foucault 1990a, p. 159). Knowledge of the shadow of a fun hidden from us will not release a liberatory politics of fun, but excavating its discourses, examining its role in labor processes, human needs, and the organization of our time may be a start towards imagining an economy in which excavating, seeking, and theorizing fun makes no sense as our conditions of work will not drive us to do so. I work from a definition of fun as specific to the system in which it emerges, a fun that takes form as a state of “flow” through the repetition of joyful acts and moments where individuals (in solitude and as part of a social entity) temporary break free from disciplined constraints (Marcuse 1970; Csikszentmihalyi 1975; Huizinga 1998; Rutsky and Wyatt 1990; Foucault 1990a; Deleuze and Guattari 1987; Agamben 1993; Bayat 2007). Personally, I know this fun in relation to woodworking, skiing and other sport, and those other activities that might be rattled off in response to the ever-popular question “what do you do for fun?” With more thought, it also emerges for me in cleaning, painting (walls), snow shoveling, biking to work, and every once in awhile, caffeine- fueled spastic typing. The point is that fun is common. We usually take fun for granted, as a commonsense aspect or absence in our daily activities—our cooking, making of things, collaboration, conversations, leisure, transportation, and even what we call work may or may not be “fun.” 69 Wondering why this is the case is crucial to opening up our 69 The formulation of “we” begs the question of how specific the concept of “fun” is to the cultures, languages, and Western, individualism-centric politics of the world I am studying. Saying “fun is common” pushes fun up against a set of universalist assumptions about human needs, activities, emotions and politics. But in some ways, I am interested in pushing up to that point, and wondering about how a need for something like fun might take singular forms across many people faced with capitalism stealing our capacity to meet our needs. I also choose to use “we” purposefully to not 182 understanding of human needs and politics, especially in relation to imagining and/or building a more just system of working and managing surplus. This means addressing where it is that we chose to and are able to locate fun and what possibilities emerge from taking the pursuit of fun in everyday activities out of the realm of common sense and into seeking to understand how fun is possible here and not there, for them and not us, at this time and not later. Asef Bayat’s excellent work on fun, “Islamism and the Politics of Fun,” directly and insightfully defines fun as process: I take fun to refer to an array of ad hoc, non-routine, and joyful conducts— ranging from playing games, joking, dancing, and social drinking, to involvement in playful art, music, sex, and sport, to particular ways of speaking, laughing, appearing, or carrying oneself—where individuals break free temporarily from the disciplined constraints of daily life, normative obligation, and organized power. Fun is a metaphor for the expression of individuality, spontaneity, and lightness, in which joy is the central element (Bayat 2007, p. 434). I do not follow Bayat on fun’s relation to individuality—simply because there is great fun in being part of something beyond yourself; or, to say again, fun always exceeds the scale of individual. Furthermore, it is important to remember that fun can be part of how organized power and constraint moves and is exercised through individuals. These qualms aside, Bayat’s definition of fun is extremely useful in that it focuses on the “conducts,” the sorts of actions and processes people engage in when they are having fun. Interestingly, very few scholars writing about fun mention work or labor, save something that fun is defined against. There is a body of scholarship on joy and the work ethic, much based on Hendrik de Man’s Joy in Work in which he puts forth the sensible separate myself from from those whom I study (Ubuntu workers) and the professional stream in which I swim (worker-scholars at academic institutions) and to articulate a humanist sort of “we” (again, warily treading up to a form of universalism). 183 and revolutionary idea that “there are not really any factors that favour joy in work... there are only inhibitive factors” (Man 1977; c.f. Campbell 1989). There are a few more “popular” works that follow this vein of thought on the work ethic, such as the “self help” best seller Joy at work: a revolutionary approach to fun on the job (the change from “in” to “at” is significant) and essayist Alain de Botton’s critique of such “self help” ideas and celebration of the beauty and perils of work The Pleasures and Sorrows of Work (Bakke 2005; Botton 2009). I follow the tendency of this scholarship in exploring the possibilities, for better or worse, of supposedly and hopefully less-alienating forms of working. Scholars in media studies analyze fun in relation to play and in doing so offer a path to connect work and fun. Using Jacques Derrida’s notion of the “play” of text, media studies scholars Julian Kücklich and Marie Curie Fellows explain that the emergence of play should also be understood as the ‛give’, or margin of movement, that exists within the system of logocentrism as in a well-worn machine ... This is its own space of play that it would have confined to the margins but that Derrida exploits or finds active within the central workings of the system itself (Kücklich and Fellow 2004, p. 20). Such play, the fun of such play, 70 emerging out of the room and space for movement, is key to how I define fun and its relation to the labor process in FLOSS—or as I must be clear, its potential relationship to any labor process. Bayat’s move to locate fun in the moment of breaking free from disciplined constraints, combined with this sort of “play,” 70 Here it is important to be clear that play, however it is defined, is a way of describing an approach to some human activity—an activity may be “play” or “work” or “serious” or “real” based not on what actually occurs, but the approach, whether or not what is taking place is game-like. Play may be fun, painful, difficult, boring, joyful, or any which way you have ever felt while playing a game. There is certainly a relationship between fun and play, but in this project I am not interested in play or games, but fun, wherever, whenever, and however it might occur. 184 is an excellent starting point for thinking about fun. “Breaking free” might be a bit off, but Bayat’s consideration of the constraints the define the conditions of fun is instructive. So, what constraints frame the fun had within FLOSS? While it might appear that FLOSS is about breaking the constraints imposed by proprietary software production or the constraints manifest in a workplace structured by the rules and priorities of industrialized software production, the system of constraints which enables fun in FLOSS is more basic: it is the constraints found in acts of writing code. This means that the same moment of fun found in working on FLOSS could be found working at Microsoft and its potential exists in the same essence at a coffee shop, at an IBM office, or anywhere code is worked upon—even as these labor processes, their management structures, and socialized provision of the means of reproduction (or lack there of) all affect access to fun. That is, the history of code, in its norms and standards of how working with code should proceed, is fundamentally linked to the fun of Ubuntu. And, perhaps even more counter-intuitively, this means that the same moment of fun can be had in working in any medium, working with and against the constraints of any system. In the Ubuntu labor process, there are all sorts of fun that are not about code, as there is plenty of non-coding work, but I focus on coding, and other work with digital things. To locate the fun of FLOSS at the level of code is relatively obvious to anyone who has had fun while coding, the non-obvious is that this fun might have nothing to do with any natural property of computer code; rather it is found in the provision of the means and materials to code (like saw and wood, needle and thread, arc-welder and steel) and the accumulated work of 185 coding practitioners from punch-cards to Perl (a coding language) who cared to create a structure of working based in fun. Fun and Meaningfulness There is a tension is the fun of making code, or of making anything, between fun as a means and ends onto itself (fun for fun’s sake) and fun as part of a system with some other ends (fun for the sake of making something of value). Free Software Foundation founder Richard Stallman’s 1985 GNU Manifesto highlights this: making programs free is a step toward the post-scarcity world ... People will be free to devote themselves to activities that are fun, such as programming, after spending the necessary ten hours a week on required tasks such as legislation, family counseling, robot repair and asteroid prospecting (Stallman 1985). The fun of making programs is crucial to Stallman’s vision of winning, of creating a utopic future of socialized labor; yet at the same time, the outcome he seeks is for coding to be fun and for people to be able to pursue fun activities—it is also for the sake of fun itself. Tim, who works for Canonical in Taiwan on enabling mobile internet device architecture for Linux has a slightly different take on this tension. He works from home and prior to going to work from Canonical he spent a great deal of free time working on various projects that would allow FLOSS to run on video game hardware or to create FLOSS replacements for proprietary software that is used for the development of video games or other media. He finds the most fun and joy in being able to use and purchase hardware that he could not before. Like Stallman, he will go to great lengths to avoid the 186 use of proprietary software. So for Tim, being able to run FLOSS on hardware that would previously only run proprietary code is to get to use that hardware for the first time. Because of this he works long hours, and nervously professes to me that he does not always have the time to live the sort of social life he or his family (with whom he lives) wants him to lead: “there is pressure from family to get married, but I have no time for girlfriends.” His love of good code, coding, and FLOSS was unmistakable through the entire interview and then he caught me off guard at the end by declaring that if free software had everything I needed I wouldn’t write code … I want to be like my brother playing games all day and dating girls but I can’t ... I am a programmer I know how to fix programs. If you buy a game [today], in three years it won’t work on hardware [because hardware will change], but if you go to the company and ask for the code, I could fix it. But they wouldn’t give it. Tim and Stallman’s very similar utopic vision—a future where work is organized in a manner that there is no need for FLOSS or for all the reverse-engineering that Tim does, or where what we call work no longer exists—highlights a tension in what I have been calling fun and what might be called “meaningfulness.” In clarifying this tension, there are three points that must be made: First, the experiences and outcomes of fun are not determined by some choice between fun and meaningfulness; Second, this tension is not about motivation, but about what we do with what is produced by fun; Third, this tension is against ideas of “creativity” or “creative work,” but all about creation and making. Or, to sum of all three qualifications, in FLOSS, and in any way of making something that is fun, both the process and the result matter dearly—and are separable only after the fact, in some later analysis. This analysis is important and it means asking questions about what happened to the process (Is it 187 reproducible or sustainable?) and what happened to the result (Was it valuable? Is it owned and exchanged in manner that makes it still valuable?). It is tempting to frame this as follows: what is most valuable may not be the most fun; what is most fun may not produce anything of value. But fun and meaningfulness (creating something of value) is not a zero sum game. Any analysis of what is called innovation, or of great moments in sport, or of workers who manage to eek out surviving another day of work would yield moments where fun and meaningfulness are compounding. Yet, at the same time, when working for a wage and caring about what you are making, process (trying to have fun) and result (as defined by capital) are very often at odds. This might mean the frustration of not being able to work on something in a way the feels appropriate to the material at hand, not be able to make it right, or not being able to have fun—in other words, there is a way that meaningfulness and fun that are intimately bound up in each other that is not often accessible under capitalist production. I see fun as a way to understand the form meaningfulness takes; and as a way to remember that the point of organizing work in a more humane fashion is not to make it more efficient (even if it does so) but in the end, to eradicate work with fun while meeting our collective needs. One of the primary ways that we have under the current ideologies of capitalist work to express this tension between meaningfulness and fun is through creativity. FLOSS is no exception. A study of 684 developers on 287 FLOSS projects found “creativity” or the desire to “create” to be the number one motivator for FLOSS coders (K. R. Lakhani and Wolf 2005). My qualms with motivation as a vector for representing 188 and analyzing work and labor processes aside for the moment, the desire to create, to make something, and to be creative are obviously significant. Yet I am focusing on fun and meaningfulness, not creativity, as they get at something different; something about processes that is not necessarily linked to the creation of anything, not even to being creative, certainly not to productivity or innovation. Fun helps separate out the desire to create from ideas about certain work being “creative;” the meaningfulness I discuss above is about the desire to create—to bring something useful into the world, from beautiful code to a well crafted fender to the joy someone experiences watching a play. When fun and meaningfulness come together, something that is perhaps best described by Tom’s idea about “durable” fun comes into being. At stake is not necessarily a different experience of fun; so what does “durable” mean in the Ubuntu labor process? Durability stands in for all kinds of complexity, especially in relationship to time and purpose. For fun to be as Tom desires, first: You’ve got to get the mundane things taken care of. That’s one of the big things we’ve done with Launchpad—love it or hate it—one of the beautiful things it does is the Launchpad janitor … When you submit a bug, it tries to encourage you not to submit the bug, it encourages you to comment on an already existing bug, which reduces our bug load. Things that developers hate—I mean they love the feedback, they love getting bugs, they love learning about it, they love knowing about that—but having 300,000 duplicates is a pain in the ass and nobody wants to deal with that. So we try to solve that problem using tools, especially in Launchpad. And so that keeps things fun. Trying to remove the mundane from developer’s lives is really important. Launchpad is a example of a technological structure built over decades to keep the labor process fun (even if Launchpad also has the effect of making work for some people in upstream project less fun). Launchpad is relatively new, but the technical structure and 189 ideas about version control, bug tracking, and organizing code build upon that which came before. For Launchpad to do what Tom would like it to do, Canonical employees, Ubuntu volunteers, third party developers, and others need to be convinced that it is a good idea to put all bugs into Launchpad. For instance, imagine using Ubuntu and coming across some odd and frustrating behavior in the Firefox web browser. Curious, you search for a fix and find nothing—looks like this is some sort of bug. Where do you report the bug? Bugzilla, Mozilla Project’s 71 bug tracker? Or Launchpad because the bug appeared when using Ubuntu? Or maybe it looks like the bug is part of a plug-in, like Zotero (a bibliographic application that runs in Firefox), which uses an onlin forum for tracking bugs? Depending on where the bug is reported, how it is linked upstream or downstream, any potential fix will find its way back to your computer via a different route and in a different time frame. Here “different route” is very literal—the report and then, possibly a bug fix, will travel through different servers and repositories in a different order at a different cadence. 72 The movement of this code, and the value created by a bug-free version of Firefox for Ubuntu users, Firefox users and/or Zotero users matters. 71 Mozilla Project is the organization that develops and supports Firefox through the for-profit Mozilla Corporation. 72 Bug reporting gets far more complicated if the user is working in a language other than English. Although Ubuntu is translated into many languages, Launchpad and other bug reporting systems are only available in English: So I only hear something because a co-worker happens to speak that language and I have never heard of this problem until they tell me. Local users tend to search in their own language first, and of course Launchpad is only in English, and most people might not know that there is Launchpad, or even how to file a bugs. And this is something that I think is our fault, Canonical’s fault, and I think that western developers who only speak English and a bit ignorant and arrogant about it. They just say “people should just go file a bug.” … So we are actually missing out on more than the majority of bug reports. 190 Sometimes there might be an agreed upon “correct” spot to report the bug, but often there is a large gray area—and where the bug starts from, gets fixed, and then gets populated to other code matters dearly for the experience of work and the possibilities of fun for FLOSS coders. 73 This tension between figuring out how to develop the best process to deal with bugs and new features such that coders might have fun trying to fix a bug or develop a new feature is well described by Kelty’s explanation of the title of Torvalds autobiography, Just for Fun: the ‛fun’ referred to in the title reflects the privileging of adaptability over planning. Projects, tools, people, and code that were fun were those that were not dictated by existing rules and ideas. Fun, for geeks, was associated with the sudden availability, specially for university students and amateur hackers, of a rapidly expanding underground world of networks and software (Kelty 2008, 213). A bit ironically, in order to keep this feeling of adaptability available to its employees and to Ubuntu contributors, Canonical management deploys scientific management tools to track how effectively bugs are dealt with by individuals and teams and ranks all This loss is serious and something that is relatively infrequently discussed, a project that looks specifically at how language affects the movement of code would likely reveal much about how FLOSS works and could have much to contribute to FLOSS development. 73 In Ubuntu this is most controversial when a new feature could be implemented in one of three development loops: the Linux kernel, the Debian code upon which Ubuntu is built, or in Ubuntu itself. If it starts in the kernel, it will go to Debian, then to Ubuntu, and that takes time. If the feature is implemented in Ubuntu first it will take time to then either get to the kernel or Debian (and any other interested party in the FLOSS ecosystem). And the relatively low number of Ubuntu or Canonical related commits to the kernel are frequently cited by critics of Ubuntu and Canonical as evidence of Canonical not “giving back” appropriately, that Ubuntu “hoards” code by making changes to Ubuntu versions of upstream software. The criticism is that even if these changes are FLOSS licensed, by not making the changes upstream it makes it more difficult for others in the FLOSS ecosystem to use the code. Of course, upstreams might not want those changes or make the changes easy to implement—this is an ongoing issue in the FLOSS ecosystem. 191 individual, teams and projects by how successful they are at getting bugs into Launchpad (see Figure 6 on page 225 for an example). Such metrics also measure the success of initiatives such a “bug jams,” “five-a-day,” “hug days” and the like. 74 Through these technical structures and in moments where a coder or contributor makes a decision about what to work on or how and where to file a bug report, the tension between fun and meaningfulness is at play and being sorted out. Bug work is both fun and not fun, but in doing bug work (and other sorts of Ubuntu work) people are able to find a state of working that has meaning and is fun. As I hope to make clear in sections below, the meaningfulness that is part of fun is best understood not a motivation or reward that explains why people do certain types of work, but as the working out of a need that determines how people work. Fun and the Management of (Machine) Time Fun is all about time. And it is fun’s relationship to time that I find so fascinating and crucial in understanding the conditions and organization of work. This argument will go through a few detours, but I am convinced all are essential to getting to the next chapter and being able to think about fun’s relation to capital’s extractive strategies and capital’s dependency upon the commons—in which time is central. First, if fun is to be a mode for analyzing the conditions and organization of work it is essential to ask: how has 74 For instance, in 2009, “bug jams” became “global jams” and were switched to being about working more generally on Ubuntu, not just working on bugs. The “five-a-day,” which initiative encouraged Ubuntu contributors to touch five bugs a day and report which bugs they worked on to a tracking system run by Canonical, revealed certain types of work flows and contributions not otherwise visible to Canonical management. “Hug Days” focus on “hugging” one package or project with a lot of bugs that need attention (thus hugs). 192 it become “common sense” that working with code in general, and FLOSS in particular, is fun, and in certain places, is considered work that should be fun? Or, to come back to the question at hand in a different context, why the belief in this fun now? The history of industrialized code production is key to answering these questions. For instance, most programming languages are designed to increase code readability 75 —explicitly designed to make workers replaceable and ensure that knowledge is not lost with a departing worker worker and intended to increase productivity by enabling horizontal divisions of labor (Friedman 1989; MacKenzie 1998; Ceruzzi 2003; Adler 2006; Chopra and Dexter 2008). Within the development of best practices for managing computer programmers, there also lies an ongoing socialization of hackers and coders. This socialization exists prior to such management—many coders, system administrators, and the like are socialized norms of communication and interaction they need to do their work prior to and after being at their workplace. This socialization, combined with workplace coordination via various software production management techniques creates a sort of “free association of producers” that exceeds capital’s intent to organize workers (Adler 2006). The simple answer to “why this fun now” is that fun is part of bringing into being a work environment supposedly required for “creative work" and that fun is a method of retaining employees who work longer hours while stretching social relations of production out across time and space in order to decrease capital’s risk. Canonical deploys “fun” to attract workers and organize their labor. However this fun does not 75 There are, of course, significant exceptions, such as the popular Perl programming language, which is notorious for its lack of readability. 193 originate with the firm, nor does Canonical control it; rather such fun emerges out of working with Ubuntu, both in terms of working with code and in the social worlds of the Ubuntu community. At the same time, the answer is that coders have fought (organized and not) to keep something they encounter as a labor of fun and joy full of that fun and joy. At stake in this process, as Tom indicates above, is not necessarily a fun that is different from some other type of fun at Microsoft or another firm, but the creation of a more “durable” fun. The complexity that “durability” stands in for is broad—fun is a concept that can describe moments and needs, i.e. everyone engaged in a labor process can be having fun, but that fun has many different relations to purpose and to the object of work. A durable fun for workers means something different than a durable fun for capital and reproducing FLOSS labor is about reproducing the conditions for work to be fun. Thus, fun is essential to understanding the stakes and conditions of FLOSS laboring (and as we shall see in the next chapter, how Ubuntu is able to function as a spatial fix for capital). The relevance of such history is revealed in the Python programming language. Python is used in Ubuntu to standardize code, to make it easily readable by any coder, and to enable productive work flows in a distributive collaborative environment. Shuttleworth links the technical structures of this programming language to the software development methodology deployed in Ubuntu, a version of “agile” development. He promotes this form of development at FLOSS conferences and media outlets, arguing that “lessons learned in classic production environments can be applied to software 194 development—like from the auto industry” (Taft 2008). 76 Canonical does not cross-train coders with all teams, as happens with some software firms that practice Agile, but Canonical employees do learn how other teams work and sometimes get switched around when needed. Without life-time employment or other related guarantees of well-being (and for many Ubuntu workers, any remittance or guarantee) it is necessary that the Ubuntu community and Canonical find other means by which to reproduce itself and its labor process. When having fun, time is lost—machine time, watch time, the regular checks against an atomic clock via the Networked Time Protocol that most coders’ computers perform, all can be lost in fun, in a flow-like state. That is, until such time is re-asserted by capital, family, friends, an alarm, hunger, or fatigue. Herbert Marcuse’s question about the emergence of happiness—“if happiness is a biological need, how does it materialize?”—points towards the importance of understanding how different forms of human needs emerge. Marcuse argues that in capitalism, the emergence of needs “operate through the construction of a pacified environment” (Marcuse 1970, p.72). Following Marcuse, it is necessary to think about what material conditions produced this need for fun, and what sort of time it produces and depends upon. Mark Blythe and Marc Hassenzahl’s research on user experience traces the “semantics of fun” in the English language to the end of the nineteenth century are invaluable in addressing Marcuse’s question. They expose that “when production is 76 Software production is obviously quite different from the auto industry (where applications of agile production varied greatly), yet such development methods are quite popular in FLOSS (Poppendieck et al 2003; Rosenberg 2007). A detailed excavation of the larger genealogy of industrial code production (and corollary developments in flexible accumulation) and charting their relationships to fun’s centrality in the Ubuntu labor processes is unfortunately for another project. 195 mechanized, when labour processes are rationalized, when time is ossified to demarcate work and leisure, the word fun appears as its [work’s] correlative” (Blythe and Hassenzahl 2004, p. 93). The emergence of fun alongside of industrial capitalism is by no means to say that the experience and need for something like fun did not exist prior to this organization of bodies, time, laboring, and surplus. Rather, the emergence of fun as a human need must be understood in relation to our ideas, experiences, and struggles of working in capitalism. Fun thus signals an antagonistic relationship to the structuring of human time by capital, via machines, clocks, and especially time-stamped networked communications, both synchronous and asynchronous—which provide a sort of confirmation that fun might emerge out of capitalist relations of production and machine time. In Ubuntu, one of the primary ways machine time comes into being is through how time zones structure communication practices. Time zones can be the enemy of fun in the Ubuntu labor process, and many contributors complained that communication issues related to time zones frequently got in the way of fun, and produced a great deal of stress, long days, and were sometimes a key reason for a Canonical employee to quit their job. Time zones structure work in many instances, and one of the ways this becomes visible is through the alternating requirements in the rhythm of Ubuntu work for synchronous digital communication (such as phone calls, video chats, IRC) and asynchronous digital communication (such as email, web forums, blogs, and micro- blogs). All of these forms of communication are time-stamped, sometimes down to the nanosecond. This means that anyone involved in the communication process can know 196 when the communication was initiated and track response time (via management tools, or just checking to see how long it has been since you sent an email to which you would really like a quick reply). Thus there is some gaming of communication—sending email at certain times to make sure you appear productive—as well as the imposition of “working hours” in new ways—as mentioned above, one of the ways Canonical employees demonstrate that they are working during their “core hours” is being present in various IRC channels and responding to various forms of communication in short order. 77 For many Ubuntu contributors, especially Canonical employees who are the lone or one of a few people on their team in particular time zone, the time of day dictates what type of communication they use. For instance, Thomas’ day generally moves from asynchronous communication towards synchronous communication: I’m basically required to work eight hours a day, forty hours a week, but it’s a little hard to balance this time. I wake up at eight, get the kids ready, back here by nine. First thing I do is check there emails [shows me all his mailing lists sorting methods]. Going through these emails usually takes about one and half hours in the morning. I usually do this while having breakfast [laughing]. My wife comes back around noon, so I have lunch break around twelve or twelve-thirty, during that lunch break we go shopping, or just take a break. Usually I start working again around two. Sometime I need to lie down take a rest. I’m working again from two to five-thirty, then I go to pick up the kids. Then playing with the kids, have dinner, send them to bed around nine-thirty or something like that. After that I go back online from ten to midnight. Two hours, that makes eight total, to fulfill my requirements. During that last two hours I usually do discussion with my co-workers in Europe because that is the time when they are working. I am the only one on the team who is in this timezone, all the others I deal with regularly are in Europe. So we could do discussions in the late afternoon, four or five o’clock for me, but they haven’t really done anything yet. So ten to midnight is the only time I can get code review or actual discussions. (Me:) Is that a time you would want to be working because of your schedule and 77 Time-stamps can also be gamed for fun, and are often used in practical jokes. 197 your kids or is that a time you are working just so you can communicate with Europe? Both. Its necessary for communication and if I need to do something together with someone, that is the time to do it. Also because a lot of my local friends work doing daytime, they are always online at night, so this is the time to get back in touch with them. I use work time to catch up with them. I admit I use work time to do that. It is actually necessary, the company requires me to stay informed. I need to spend some time to read websites, check with people. Although the official opinion is that it should be done on our free time, I respond with “Which free time? What ‛free time’ is that?” Thomas begins his day with asynchronous communication, catching up on email, much of it sent from people working while he is sleeping. Then, when waking and working times do intersect, he spends more time with synchronous communication on IRC. It is not uncommon amongst Canonical employees to eat dinner, put children to bed or perform some other domestic or familial obligation, and then get ready for meetings and more work. Nearly every Ubuntu contributor eventually confronts time zones: I set alarms a few times for 4 or 5 a.m. in order to be up and be able to participate (mostly by lurking) in IRC channels for a Ubuntu Develop Summit (UDS) in Barcelona, Spain. This is part of what it means to be beholden to a form of machine time, mediated through time zones. The problems this causes do not go unnoticed. Canonical has added time zone requirements to job postings, and there have also been efforts such as adding additional regional membership boards so that contributors can apply for Ubuntu membership during time-zone appropriate hours. Large teams with folk in many time-zones rotate meeting times in order to at least distribute the 3 a.m. meetings, but when it is one to many as in Thomas’ case, some people still face the brunt of this temporal disjointedness. 198 The affect of this sort of machine time, operating in concert with synchronous and asynchronous communication, has the effect of an unending, global workday for some Canonical employees. Not every employee experiences time in this manner, and there are many other factors at work, but nonetheless: Because of this awkwardness of working together with different timezones, you are basically on your job 24 hours. They are awake when I am sleeping. If they have a problem, they ping you on IRC. They say they want to build a CD image but there’s a dependency that breaks the CD builds! The first thing I see in the morning is “oh shit, the dependency broke.” I heard folk talk about how horrible it would be live on the west coast of the US, how bad it must be to be in a time zone like in Taiwan or New Zealand and that depending on your time zone, going to UDS and developer sprints creates “almost persistent jet-lag.” Yet it is, at least in part, this fun, and the sort of time experienced in this fun, that makes the experience of time zones and machine time worth it. After hearing this story from a Canonical employee, I expected him to complain: At the time I was hiring in London because back when it was just me and one other guy and I was hiring two other people, I didn’t care about time zone because there was no way we could do 24/5 or 24/7 [support]. Now when I’m hiring I’m always concerned about 24/5 so the reason I’m trying to chose between these two guys in Australia is because I need someone for better 24/5. Back in the day, there was no need for that. I was on call 24 hours. And I still am, my guy in New Zealand clocks off at about 4 a.m. at the moment, I think, and there is no one else around until 8 a.m. So if the emergency phone goes, it’s me from four until eight. Not only did Earl not complain, he seemed to find much fun in his work. Of course, this variety of responses to working conditions is likely true in any labor process. Yet even employees who left Canonical under what seemed to me to be very difficult working conditions—twelve-sixteen hours days, always on call, lots of pressure—expressed sentiments as the following: 199 A lot of people resigned from Canonical at the same time [I did] and I know that for a fact. I had a friend who I helped apply for a job at Canonical call me and ask, should I be concerned because you left and all these other people left? And just told him my story [of leaving to find a job with less travel, and more regular working hours]. I left on good terms, I still have friends there, and if I had the opportunity to go back to Canonical, I would do it, no problem! It is the people, the chance to do work that is very meaningful, and more that bring out loyalty and appreciation for Canonical—but really it is not about Canonical, but Ubuntu or free software. It is what a job at Canonical can allow people to access—these are things that increase the likelihood of the reproduction of fun, of the creation of a different sort of time within the difficult world of working and communicating between time zones. In a flow-like state, in the moment of having fun, time is defined by the relation between a human and an object of transformation (in this case code); a sort of “human- object-time” as opposed to machine-time (human-object-time does not preclude the involvement of machines, rather, it requires a different relationship to machines). Although human-object-time might appear as just another form of machine-time wherein our relationship to time is structured by the needs of capitalist production, what happens in flow-like states is something different. Such opposition does not mean that flow-states are un-expropriatable, but it does mean that because of the change in temporal relations, capital must operate differently when a labor-process is structured by fun. II. Why We Do Versus What We Do One of the most significant roadblocks to thinking about the role of fun in the organization and qualities of work is that it already has a place in the economy of our minds. Fun is all too often positioned as a motivational factor. Fun makes intuitive sense 200 as a motivation, for we do many things because they are fun, thus fun is very useful to explain certain human behavior. Unfortunately, motivation then becomes the end of story for fun. To follow fun—to take the path that fun puts forth—the causal ties between fun and motivation must be broken. It is crucial to think beyond motivation, and even against motivation, not only to understand fun, but to break the grip of the idea that understanding motivations—the reasons people do what they do—can stand in for understanding labor processes and affective experiences of work more broadly. Or, more directly this means that asking “why do people do that?” is not the interesting and rewarding question it might appear to be. The “why do they do that?” question plagues FLOSS-related research. Fun plays very diverse roles in discourses about how FLOSS should and does work, yet when fun enters academic discourse it is as a minor note, and is only used to explain why FLOSS contributors give their time (Bergquist and Ljungberg 2001; von Krogh et al 2003; Weber 2004; Lakhani and Wolf 2005; Horn et al 2006; Moody 2001; Raymond 2001; DiBona et al 2005; Luthiger and Jungwirth 2007). Sports researcher Ørnulf Seippel explains that “motivation” in social science research is typically framed as an independent variable that can explain success or failure of an activity or choice. Fun as motivation is flawed because it establishes “intentions prior to action: first a mental state of affairs of some kind, then, rather mechanically, some kind of action” (Seippel 2006, 53). Seippel argues that instead, we should deal with the “meaning” of sport and study the experiences people have in their activity on a daily basis, and see how these experiences might be explained by a social context. While I do not follow Seippel directly, for experiences also create the 201 “social context,” this move away from motivation is crucial to study something that is experiential, temporary, ad-hoc, and process-oriented like fun. Where Motivation Leads Where does thinking about motivation tend to lead our intellectual labors? Not surprisingly, to a set of typologies of motivation that are posed to explain divisions of labor by personal choice, exploitation by desire. Motivation also has a tendency to turn the wage relation on its head by understanding employers as seeking to create a set of motivations that match some natural pre-existing condition in the “labor market.” Almost prior to thinking about motivation, the concepts of “intrinsic” and “extrinsic” motivations enter into play to explain economic choices (Deci 1975; Brandzaeg, Bae, and Heim 2004). Although useful for differentiating types of rewards that might be possible with in a given labor process, such a salary (extrinsic) or feeling like you are making the world a better place (intrinsic), mapping these different rewards onto motivations creates a false division of human motivation. This division holds great explanatory power because it serves to fill many of the gaping holes in rational-choice based theories of micro- economics and markets—and thus appears as an intelligent corrective to a deeply flawed economics. Rational-choice favors an explanation of most human behavior based in extrinsic motivations—an actor will make the choice that generates the highest net-gain of benefit x based in the needs of situation y. These extrinsic motivations (money, fame, power, stability, security, etc.) clearly do not account for the actual choices people make —we make non-rational decisions all the time. For instance, my research in FLOSS, and 202 other research (especially Horn, Demazière, and Jullien 2006) indicate that choosing to pursue a career in FLOSS creates numerous financial, health and “social capital” losses. To save the day of rational-choice, the magic fixer of intrinsic rewards steps into the explanatory foray. Intrinsic rewards allow economists and others who study FLOSS to conclude that the measurable benefits correlated to what appear as intrinsic motivations can explain why coders chose to contribute to FLOSS projects (c.f. Bitzer, Schrettl, and Schröder 2007; Hertel, Niedner, and Herrmann 2003; Lakhani and Wolf 2005; Orman 2007). Particularly revealing is a line at the end of a very frequently cited paper on FLOSS by Harvard Business School economists Lerner and Tirole: “it is heartening to us how much of open source activities can be understood within existing economic frameworks, despite the presence of claims to the contrary” (Lerner and Tirole 2002, 231). The relief is palpable in Lerner and Tirole’s paper, for people giving their labor away for free is very contrary to their understanding of the world. While thinking about the complex interchange of intrinsic and extrinsic motivations certainly does paint a more rich picture of why we do what we do (and it relieves Lerner and Tirole’s anxiety) it is imperative to think beyond motivation, for ideas about intrinsic and extrinsic are dead ends. Humans share broad and a potentially unknowable range of motivations for the work we do. What appears as an explanation of the motivations behind someone to selling or giving away their labor more often actually indicates something about the given labor process and its particular structuring of work, divisions of labor, or specialization. 203 The alternative of focusing on “what we do” shines bright though in the morass of motivation. For instance, Csikszentmihalyi stands out as a researcher who was willing to find fun and to be surprised by its life—simply by recognizing that fun and flow are not about motivation. Csikszentmihalyi’s work on “flow” puts assumptions about certain types of work as being more or less “creative” or more or less likely to enable fun into question (Csikszentmihalyi 1975). His initial research used surgeons, rock climbers, and chess players as test subjects to understand the state of “flow” that people entered into when their capacities and enjoyment peaked. Yet, several years later, he ran the same research on “working people” in Chicago and in a letter to a colleague expressed his surprise that twenty six percent of workers described the same sort of flow experiences as his earlier “creative” test subjects, who he understands to have very different reasons for engaging in the activity at hand, i.e rock-climbing verus janitorial work (Schwartzman 1980, 319). Csikxzentmihalyi’s work reveals that the motivations people bring to their work is not determined by the type of work they are engaged in that that motivation has no relation to their capacity to work in a state of “flow.” Terkel demonstrates that the amount of creativity people feel they express in their work, or that is required by their work, has very little to do with job category or type of work; rather people have very similar experiences of feeling creative or taking pride in their work across a wide variety of types of work (Terkel 1974). Such scholarship inspires me to use fun to develop a consideration of “what we do.” Focusing on “what we do” is a move to get at the experiences of work and to examine the forces which shape those experiences. Thinking about motivation can never lead to this point and although interesting to think about, 204 motivation is a red herring that serves to distract from any attempt to understand the qualities of work. That Which is Hidden Behind Motivation The manner in which focusing on motivation blinds us to what is actually happening in any given labor process is revealed in a popular tale of motivation. In a talk at a FLOSS developer conference (titled “Would you do it again for free?) and in a blog post (titled “Does money kill good motivations?”) FLOSS advocate and software engineer Stormy Peters reenacts a debate in psychology about what happens when extrinsic rewards are introduced in systems understood to be dependent upon intrinsic motivation (Peters 2007, 2008). In her argument encouraging FLOSS folk to question the merits of introducing paid work into a FLOSS project and to think about the unpredictable consequences of paying people for FLOSS work, Peters references a New York Times editorial which recaps a famous psychology experiment: Nursery school children were given the opportunity to draw with special markers. After playing, some of the children were given “good player” awards and others were not. Some time later, the markers were reintroduced to the classroom. The researchers kept track of which children used the markers, and they collected the pictures that had been drawn. The youngsters given awards were less likely to draw at all, and drew worse pictures, than those who were not given the awards. Why did this happen? Children draw because drawing is fun and because it leads to a result: a picture. The rewards of drawing are intrinsic to the activity itself. The “good player” award gives children another reason to draw: to earn a reward. And it matters—children want recognition. But the recognition undermines the fun, so that later, in the absence of a chance to earn an award, the children aren’t interested in drawing (Schwartz 2007). 205 This 2007 editorial is referencing a 1973 review article (Lepper et al 1973) that evaluated a seminal 1971 study (Deci 1971) on intrinsic motivation in psychology, which led to controversy and debates on the effects of extrinsic rewards on intrinsic motivation. These debates concluded with some general agreement that extrinsic factors could be detrimental to intrinsic motivations in a wide variety of environments (Deci 1975; Tang and V . C. Hall 1995; Schneider 2005; Deci, Koestner, and R. M. Ryan 1999). These studies, which appear and purport to be about motivation, can be read to tell a very different tale. The study referenced above concludes that the exchange of rewards for pictures changes the children’s motivation for painting—before they were motivated to create paintings by joy, fun, creativity, artistic expression, or the like; later they are motivated by the desire for an extrinsic reward. Thus, it appears that when motivated by money instead of joy or fun, people are likely to produce fewer objects and objects of poorer quality. This sentiment echoes throughout scholarship and hype regarding the “creative” or “cultural” industries. So, we have experiments in psychology that offer more rich and complex pictures of human motivation that are useful for educators and managers seeking to effectively motivate students and workers. While this is potentially trouble onto itself, there is a far more significant misunderstanding of what happens to people and the object of their work when a labor-process is restructured by so-called “extrinsic motivators.” Offering children rewards for drawings does not change their motivation for drawing or using markers; it re-structures the labor process. New structures are created in the labor process that were not in place before. The children have a new relationship with time. 206 The very relation between work and the object of work is reformed to make commodities for a market instead of objects that exist solely for the pleasure of the work and the potential pleasure of someone’s use and appreciation—this is how “recognition undermines the fun.” The shocking story of this experiment is that it appears that a single cycle of commodity exchange can quite substantially alter future experiences of work. This story thus tells us a great deal about alienation and about how fun and commodities can both structure a labor process; but it does not tell a story about motivation. The children in Deci’s research are motivated to create pictures with markers for the very same reasons, but the experience of doing so has changed significantly. A story of a labor process transformed is that which is often hidden behind a story of motivation. How Fun Helps Create Surplus Value When There is None to be Found There is no technology, no time-saving device that can alter the rhythms of creative labor. When the worth of labor is expressed in terms of exchange value, therefore, creativity is automatically devalued every time there is an advance in the technology of work. (Hyde 1983, 51) Hyde reaches a similar conclusion about changes in labor processes, but from a different angle: nothing can alter the rhythms of creative labor. How can this be true? How would this devaluing Hyde refers to actually take place? What is it that is actually devalued, if there is nothing that can alter the rhythm of what Hyde calls “creative 207 labor?” Taking a generous read of what sort of work can be considered creative, Hyde’s base proposition is that there is no way to change the socially necessary labor time to create a “creative” thing by means of technology, either by machine or by management techniques (such as the introduction of a reward). There are other means by which was is “socially necessary” can change, but this also changes the nature of the thing being made —such that works created are always very literally of their time. What is socially necessary changes the potential ways of making that are available and each different processes changes the form of the thing being made—like how a chair is a different thing when made with power tools than when made with hand tools. So, when media scholar Mark Banks and others argue that the creative process cannot be controlled by capital, what I believe they are identifying—without calling out the actual relation at hand—is that capital cannot readily change the socially necessary labor time required to produce certain goods. And more importantly, if a capitalist were to try, the results would likely follow the path of the children’s pictures. So, if a capitalist is trying to organize workers to make some widgets that require “creative labor,” the capitalist faces a scary situation: the rate of relative surplus value is fixed. Typically, if this rate is fixed, capital can increase the overall amount of value extracted simply by increasing the number of workers laboring to make the widget at hand. If the rate of surplus value is an average of the rate of exploitation of all workers involved in a production chain, increasing number of workers means more surplus value in total. Yet one of the “laws” of software development, “Brooks’ Law,” argues that in software development adding more workers does not mean more widgets or the increase 208 in the mass of surplus value that capital seeks. Frederick Brooks’ highly influential 1975 work, The Mythical Man Month, formulates the law in this form: “adding manpower to a late software project makes it later” (Brooks 1995). Adding more workers, or more “man-months” in Brooks’ terms, cannot speed up the rhythm of making this thing, software. It cannot be sped up, but even worse, as Brooks discovers, adding more people working more hours often significantly slows down the project because of the time spent communicating about bugs, reconfiguring the division of labor when new coders are added, and the learning curve specific to each project (Brooks 1995; Brooks in Rosenberg 2007). Adding more people increases the communication necessary to work together to a point of limiting returns: crudely, more communication about what needs to be done and how to do it leads to less being done. So what else can our sad capitalist do? Seek an indirect means by which to extract surplus-value from a labor process wherein the socially necessary labor time can either be reduced or diffused in a manner that does not create lower quality or fewer widgets. Here we can turn back to the story of children who start to draw less and of lower quality when the labor process was changed by the imposition of a pseudo wage relation and commodity production. If a capitalist desires to produce children’s magic marker drawings for the art market, purchasing children’s labor-time (either by paying hourly or through piece-work) would appear as a logical way to organize this labor process to extract surplus value from children. It makes sense that the rate of surplus value could be increased by having children work longer hours (absolute surplus value) or by using some technology to increase produtivity (relative surplus value)—a magic 209 marker that lasts longer, an easel that automatically places paper before the child, or a production line where each child takes care of one color. But no, the imposition of the wage relation has already made the children produce less and of lower quality and our capitalist needs lots of unique, high quality widgets. The old system worked so much better! Just provide the workers with the means necessary to produce the unique widgets which they cannot possibly individually own (and fight anything that approaches collective ownership of those means) and figure out some way to get between the widget’s production and its use (as a reminder, software workers control the means of production for making software—a global network of cables, servers, buildings, land leases, and more—as much as a five-year-old controls the means of production to make drawings). Managerial literature on fun is founded in the belief that making work fun can increase surplus value by increasing productivity—more widgets per hour of work than before. But a labor process built in fun may or may not increase productivity in the way that happier, content workers are popularly argued to do so (Achor 2010)—FLOSS being an excellent example. FLOSS supporters (and detractors) often debate whether or not FLOSS is a more productive way of creating code (in articles such as “Brooks’ versus Linus’ Law”), and for the most part, at least agreeing that FLOSS collaboration is no guarantee of increased productivity and sometimes is slower, less productive, and produces arguably less effective code (Schweik et al 2008). And as these workers collaborate, share, and develop social relationships based in a love for making something, they might end up changing the socially necessary labor 210 time to make a widget. They might make it increase or decrease. They will also likely put in a lot of time with this widget and if the widget’s production is dependent upon positive network externalities wherein the use value of a particular good is increased by more people’s use (i.e. a cell phone network, the more people that have cell phones the more valuable access to the network becomes). For instance, Microsoft depends heavily upon positive network externalities. Microsoft Office users struggling to use the software and taking the time to figure out some challenging problem and post the solution on a list serve, chat board, blog or telling their friend or co-worker how to, say, format a page properly, all of this increases the value of Microsoft Office. Such volunteered labor is also structured by fun—and without this free labor, Microsoft could not be the multi- billion dollar company it has become. When an object is of labor has meaning, like Ubuntu has meaning to Ubuntu contributors, when it is something that will change the world, the makers of such an object will likely figure out ways to keep making more of this widget, and how to get the widget out into the world into the hands of more people in order to further increase the value of the widget. Such volunteered labor is not just the gift of free labor-time to a firm (a fine way to increase surplus value), perhaps even more useful to capital, it is a means of organizing work that could not otherwise be organized. The fun of solving the problems of Microsoft Word or of working with Ubuntu organizes large parts of the labor process required to produce the widget at hand. What this means is that doing fun work does not replace labor costs (although firms certainly have this dream, with “crowdsourcing” and the like), fun creates new system of production and exchange built in the commons which 211 Figure 5: Model of Extractive Strategies capital is able to somehow get in-between and extract surplus value where there was none before. This “somehow get in-between” is the goal of “open-source business models” and various extractive strategies (see Figure 5). Value is extracted by providing workers with the means to do that which is fun (whether it be a wage or something else 78 that serves to nurture and support what is held in common) and then finding a way to get between the existence of that common resource and its use. I do not have a ready name 78 The something else (the means for communication) will be discussed in detail in the following chapter. 212 for these extractive strategies—they appear like surplus value when there is a wage and commodity, and also like rent (which is a temporally differed form of surplus value)—it makes the most sense to me to call it surplus value and struggle with trying to understand how value is extracted from commons that are created by and sustain the production of digital things. Tracing relations of dependency seems to be a good way to begin to see how fun and extractive strategies work together in Ubuntu. From Autonomy to Dependency Related to motivation is a widely held belief that workers, especially so called “creative workers,” seek and require a higher level of autonomy than other workers in order to do their work. This appears to follow perfectly logically from what I have laid out above: capital cannot control creative work, therefore to do the best creative work possible, workers desire and need autonomy, especially from capitalist management techniques and technologies. However, it is a cruel mistake to believe that this desire extends from workers! It is, oddly enough, capital that desires such autonomy. And not just the obviously cruel autonomy of a short-sighted capitalist who mistakenly believes it to be in the interest of capitalism to “give” workers the autonomy to find their own health care, training and education, pension, and office. 79 This autonomy is more like self- direction, or that ever perverse and self-abusive sounding desire to “be your own boss.” People may want to be free from control of their boss in order to make something that 79 In a time when planning of all or any sort seems to have been thrown out the window, short-sighted capitalist might be redundant. Yet this is precisely what makes the long term plan of Shuttleworth and Canonical interesting—not as a solution to economic woes and injustices, but as a plan, of any sort, from which some other plan may be built. It becomes hard to imagine a different plan when the plan is to disavow planning. 213 meaningful and to do so in a humane manner, or to have more control over their time and not have to go to an office everyday, but this is not the desire for autonomy. To engage in process of making something meaningful creates relationships that beholds people and things to each other—in the face of these bounds, capital desires that workers remain autonomous, disconnected (in the end) from the object of their work. Banks develops a similar argument specific to “flexible workers” who toil in the “cultural industries” under neoliberalism: such work relies upon the regulation of self into an “enterprise” in which individuals carry risks and believe that they are the sole masters of their own fate, success, or failure. This regime of truth about failure and success takes the form of a nigh-militant belief in the FLOSS community, and in Ubuntu, that meritocracy rules. The vast majority of my interviewees brought up their belief that Ubuntu is a meritocracy when discussing what they liked about Ubuntu, when defending FLOSS elitism and its severe male over-representation, or theorizing about how FLOSS could improve the world. When asked, all recognized that merit does not determine everything, but the belief remains strong and ask Kelty argues, an essential aspect of FLOSS communities (Kelty 2008). Of course, as de Botton elegantly points out, the worst thing about the false belief in meritocracy is the implicit or explicit correlation that those who “fail” are deserving of their lot in life (Botton 2009; see also Sandage 2006). While there is certainly something to Banks’ analysis of capital’s reliance upon “enterprises of self,” there is much danger is assuming that simply because this self is desired by capital, such a self exists or that it extends from workers complicated lives and constitutions of self. Out of this work on enterprises of self Banks makes the increasingly 214 commonsense argument that “capitalism must offer creative workers some degree of ‛space’ and autonomy in order to spark ideas; otherwise there can be no new cultural production of any real value” (Banks 2007, 29). The belief that “creative workers” need more autonomy than other workers to make things of value also venerates systems that operate on supposedly “intrinsic” motivations such as having fun—which very conveniently for capital, creates a workforce that produces the need for its own precariousness (c.f. Hesmondhalgh 2007; Gill and Pratt 2008). Banks asks a very important question about workers who appear to have become “enterprises of one” such as editors, directors, production assistants, consultants, and others who are in the precarious situation of working short term job after short term job: “what are the emotional consequences of making oneself into an enterprise subject” (Banks 2007, 57)? I wish to ask another side of this question, for as it is asked, our focus is rightfully turned toward exposing individual and socially destructive consequences of such working conditions. What are the social and emotional consequences of understanding our working lives in terms of such an “enterprise subject?” It is necessary to rethink the role of “autonomy” in “creative” or “cultural” industries in order to see the emotional consequences of thinking about ourselves or other workers as desiring autonomy and becoming subjects beholden to the desires of capital—for instance, the popular trope of becoming a “neoliberal subject.” Banks stands out as a scholar who pays attention to labor processes and actual work and in doing so he develops an excellent critical analysis of neoliberalism and the construction of “autonomy” as the driving motivation force for cultural workers (as well 215 as the creation of very concept of “cultural” or “creative” sectors). Yet, this analysis of neoliberalism ends up naturalizing “autonomy” as the actual motivation of so-called “cultural” or “creative” workers who are willing to endure exploitation in exchange for autonomy: “the fetishization of creativity, and industry emphases on reproducing personalized, performtive and self-directing modes of work ensures that self-exploitation has become more pronounced in this most ‛talent’-driven and individualistic of sectors” (Banks 2007, 43). Autonomy, which becomes the only path to success, and produces self-exploitation, under the neoliberal regime of truth in Banks’ analysis, is positioned as a natural desire of workers that capital has twisted to ensure norms, standards, practices, and ways of regulating self reproduce exploitative working conditions. My ethnographic work with Ubuntu contributors reveals that what easily appears as a desire for autonomy is better understood as the development of a form of reciprocal social relations and dependency. This is where, again, we can see fun as always defying the scale of the individual. Ubuntu could be read as a labor process in which “neoliberal individuals” are authorized and enabled to have fun as relatively privileged workers in the long and distance chain of digital production. Yet it is actually better understood as a labor process built by the deeply embedded, highly interdependent, and precarious capacity to have fun. Yet fun too easily appears as proof of autonomy and of autonomy’s merits as an organizing and civilizing force in production. This misstep extends in large part from a misread of fun as a motivation. That is, if fun is a motivation, then it necessary to provide workers with the capacity to have such fun and get their work done—and to produce high-quality unique widgets. As motivation 216 is about the individual, then the best way for capital to enable such work is to provide them with autonomy. However, recognizing fun not as a motivation that drives and individual to do something, but as a component of a labor process that cannot be held in isolation, that is always part of system of exchange and working, we can begin to see that fun is far better understood in terms of creating relationship of dependency, rather than requiring autonomy. One of the easiest places to see this dependency in all of its nuances in Ubuntu is in repositories. As already mentioned, repositories contain “packages” of code that can be used with Ubuntu—when an update is run on an Ubuntu machine replacement packages are downloaded, or if a user wants to install a video editor, a driver, or some other application, that package (and other dependent packages needed by the desired package) come from a repository. Repositories are thus the primary form through which dead labor in Ubuntu is organized, stored, and then brought back to life. Ubuntu repositories of code categorize dead labor by its freedom and level of support. 80 The primary repositories in Ubuntu are: Main - Officially supported software. Restricted - Supported software that is not available under a completely free license. Universe - Community maintained software, i.e. not officially supported software. Multiverse - Software that is not free. The infrastructural network required to move this code is frequently visible: both in terms of the infrastructure required to host a repository and the dependency it creates, such as in a thank you note on the Medibuntu website (a repository that provides multimedia 80 There are many other repositories, such as PPAs (Personal Package Archives, hosting supplied by Canonical) that allow any individual, team, or third party to distribute packages. 217 applications that cannot be integrated into Ubuntu because of legal reasons, such as libdvdcss which decrypts DVDs): Special thanks to: * Gauvain Pocentek (a.k.a gpocentek) for his help * Medibuntu testing team (see medibuntu-testers on Launchpad) * mirrors owners Gauvain Pocentk is Ubuntu contributor who volunteers his time and was thanked by his given name and IRC nick for his work in packaging as well as in organizing and making sure that mirrors are updated—he is also far and away the most prolific contributor to Medibuntu (see Figure 6). The Medibuntu testing team, although no longer in existence 218 Figure 6: Medibuntu Karma Ranking and Canonical’s Explanation of how Karma Works as a dedicated team (testing teams were restructured), is thanked because of their work in testing new packages prior to major releases, an essential part of any development process. “Mirror owners” are thanked for, as discussed above, they provide the material means for Ubuntu code to move. Such entities (usually Universities, ISPs, 81 or FLOSS- dependent firms) own the servers and provide the bandwidth to make the distribution of FLOSS possible. Mirrors make clear that dependency is also very material, not just about some collaboration or interpersonal relationships—although it can be meaningful interpersonal relationships that bring mirrors into being. 82 Where Banks and others (especially Hesmondhalgh 2007; Lerner and Tirole 2002; Raymond 2001; Weber 2004) see “enterprising” workers enjoying greater autonomy as a trade off for taking on other risks, I see the desire and/or necessity for dependency driving the organization of workers in the “cultural industry”—often characterized by labor processes that requires depending upon others and being depended upon. 83 These reciprocal social relations are indicative of the relations that Hyde has identified as essential to the functioning of “gift economies” (Hyde 1983). As Hyde is keen to point out, these relationships create forms of dependency that exist alongside and in 81 Internet Service Providers’ rationale for providing FLOSS mirrors is somewhat different that firms or universities. If, say, someone who has a Time Warner internet connection wants to download an Ubuntu CD image and the request goes off of the ISP’s network to the ISP contracted by Canonical in London, Time Warner has to pay for that off-network download. If Time Warner provides an Ubuntu mirror, the default for a request for a CD image stays on Time Warner’s network and saves the firm an off-network charge. 82 In the case of firms that provide mirrors, the resources are often provided in order to “give back” to the FLOSS ecosystem they depend upon. For instance, Savoir-Faire Linux (a large Montreal based firm providing FLOSS based “training, consulting, development and support services” provides a mirror for Ubuntu repositories, for as one of their directors explained “We provide the mirror to show commitment … and without free software everyone goes home.” 83 This dependency is often recognized in scholarship as “trust.” For instance, see English-Luek et al on what they call “trust relationships” between workers (who often collaborate at a distance) in high-tech Silicon Valley firms (English-Lueck et al 2002) 219 antagonism with commodity exchange. This dependency is obscured by normalizing “autonomy” as both the desire of workers and the outcome of the production of commodities in the “cultural/creative” sectors. The exchange of things of value in Ubuntu demands an alternative explanation. Here I do not see Ubuntu or FLOSS as an anomaly, for the markers of dependency leap off pages, screens, and out of speakers: look to the acknowledgments page in any book, liner notes of any album, or the “special thanks to” section at the end of film credits for a glance at complicated webs of financial, emotional, artistic, and intellectual dependence. When thanks are not given, when citations are left out, or dependency is otherwise unacknowledged, gift exchange is broken, and things become a lot less fun. Acts that ignore or flaunt dependency hurt, create frustration, and carry the weight and knowledge of something that could have been better, more humane, decent, and part of building the capacity for future fun. This sort of future-building dependency is as common as it is fleeting. It is the means by which we work together, by which we strive to make fun, or to otherwise remake our conditions of working. “Autonomy” makes perfect sense and has great explanatory power under a regime of truth in which the onus for creativity, innovation, success, and failure is placed upon individual shoulders and capital’s desires are assumed to translate to the actual motivations, emotional states, and subjecthood of workers under this regime. However, such an analysis based in autonomy as a prime motivator falls to pieces (or more literally, the pieces fall together), with an examination of labor processes which bring the products of, for instance, some creative insight about user-interface design, into being in Ubuntu. 220 In a rare case, one person may have a flash of insight to solve a problem (leaving aside the labors of others indirectly relied upon to get to this insight). This individual alone could write the code to implement such a stroke of creative genius. Yet, it takes much other work to bring this solution into being: someone else may review, test, and/or commit the code (which is hosted somewhere, physically requiring power and materials) and then there are more testers and bug reports before this small piece of code is released. Then people use it (or not), maybe submit more bugs, add more ideas, write documentation for others to use this code more efficiently, and answer people’s questions on online forums. This labor process needs fun, and this need is expressed through many forms of dependency in the FLOSS “ecosystem.” These dependencies take form, for instance, through discussions of how code should move upstream and downstream between different sorts of FLOSS projects, with different global configurations of labor and movements across time as code is reused and re-purposed. Fun and Subjectivity Although dealing with subject formation or how Ubuntu contributors identity’s are produced by and are productive of their work is not a central part of my dissertation, there is a bit to be said about subjectivity and fun. Nick Dyer-Witheford and Greig de Peuter’s excellent work on video game production makes a common formulation that is related to above beliefs about autonomy: “video games reassert, rehearse and reinforce Empire’s twin vital subjectivities of worker-consumer and solider-citizen” (Nick Dyer- Witheford 2001, xiv). Although this sounds solid and true, there is a larger conversation 221 about subjectivity and capitalism at stake here. Such an assertion about games and subjectivity deserves some skepticism, as the actual acts that constitute virtual gaming are part of people’s complicated lives. Dyer-Withefored and de Peuter often tend toward collapsing the subjectivities dreamed of and demanded by particular forms of the state or capital into a general vision subject-making/becoming engendered through gameplay. They frame their work by arguing that “virtual play … makes becoming a neoliberal subject fun” (De Peuter and N. Dyer-Witheford 2005, xxx). There is certainly an ideological element to playing games, similar to how ideology is discussed in Chapter One, but this is far from the same thing as becoming a neoliberal subject, and it is worth questioning what it means to call a person a “neoliberal subject.” Foucault argues that one of the main projects of neoliberalism 84 is to reintroduce the qualities of working that are abstracted by the imposition of the wage relation into an economic analysis that has been “cut off from its human reality, from all of its qualitative variables” (Foucault 2008, 221). Neo-classical economics do not have frameworks readily available for thinking about or representing these qualitative aspects of work, 84 Rather than rehearse what might already be clear, let me come out and say that I do not think that analyses of neoliberalism are well-suited for thinking about the qualities, experiences of affective relations of work. However, I leave the use of thinking about neoliberalism as an open question because it seems possible that its analysis continues to have something to offer even and especially at this moment of crisis (Nick Dyer-Witheford 1999; Harvey 2005; Herod and Aguiar 2006). In general, existing scholarship on neoliberalism is ill-equipped to address volunteered labor, capital’s ever- changing modes of extracting value from commons, and affective relationships of work. In many ways, these are the limitations of a concept that well describes an ideology, but not the dynamics of a mode of production; that provides a mode of coherent analysis for connecting disparate policy objectives, but does not make sense to describe subjects or affective relationships. In a nutshell, although neoliberalism is an attempt to deal with nearly the same issues I am concerned with, it lays tracks so far off from my destination that I cannot follow it and hope to end up where I need to go—attempting to explain the Ubuntu labor process as neoliberal would be a gross simplification that would miss much of what is at stake in Ubuntu and for the future of the organization of work. Deciding whether or not neoliberalism is “over” with the current crisis of financial overproduction, whether or not a critique of neoliberalism is a mode of analysis that serves as a guide to a more just world, or if neoliberalism is on the way out as popular way of understanding capitalism is not my objective. Simply, I am skeptical of framing an analysis of everyday life and work in terms of neoliberalism. 222 thus, “the problem for the neo-liberals is basically that of trying to introduce labor into the field of economic analysis” (Foucault 2008, 220). Foucalt argues that neoliberals conveniently find fault not with capitalism for abstracting the qualities of labor from human life, but with economic theory and practices for not taking into account the effect of labor’s qualitative modulations on production and labor processes. Neoliberalism makes sense to describe economic policies, sorts of governance and possibility more, but it does not make sense to use the concept to think about subjectivity—even though many scholars discuss the emergence of a “neoliberal subject” (c.f. Brenner and Theodore 2002; Peck and Tickell 2002; Ong 2007; Nonini 2008). In order to think about what it means to call someone a “neoliberal subject,” or more generally, to deploy the concept of neoliberal subjectivity as a means to explain how capitalism works, I turn to a case where it might appear as if the concept and identifier “neoliberal subject” is apt. David, the California LoCo team member I met on my first day of fieldwork, describes how he started feeling guilty about pirating software in order to run a computer he gave to his godchildren, but that: Instead I had the opportunity where I can take Edubuntu, completely free and open source software and give it to them, and give them a gift. And so now I have that computer with the same OS, not only will it always be up to date, they can’t break anything, they don’t have the admin passwords. They both learned to type their name twice to login. They’ve learned how to start programs. They can use the mouse. And the moment that they feel like they want to go a little bit deeper, they can, they can go down to the hardware on this machine, if they choose. Because they can examine all the source code, the can edit all the config files. Nothing is hidden. I don’t think they will ... I’m going to make them program a little bit ... if that’s a spark and she likes it, there is no barrier to her, there’s no ceiling. 223 It means a great deal to David to be able to give these gifts to his family and it is evident in his voice and visible excitement with which he talks. Like many other Ubuntu contributors I have talked with, David described himself as a sort of informal computer technician and support provider for his family and friends. What is most exciting to him is when his “gift” gets passed on. David recounts a visit to his aunt and uncle’s house: He says, ‛thats the version of Ubuntu you use?’ I say ‛yeah.’ He says ‛install it.’ ... they saw my speech at LUG Radio Live ... they saw the YouTube recording of that, they said that, you know, hearing me talk about that, they really wanted to try it. Their old computer was slow and the their anti-virus had expired, and just took forever, and you know, so I said, alright well, boot into [Microsoft Windows] XP for iTunes, go back and just, you know, go back to whatever suits you best. I figured they would just use [Ubuntu] for web-browsing. Turns out other than iTunes, they basically stopped using Windows. I was so happy! They were so happy with it. To be able to share that with anyone who wants it, I can say, this is for you, it’s a gift. Freely given. With no obligation on your part. I think that, you know, not everyone wants it and I don’t bring it up with everyone, but people are searching for help with their computer... [Now] they can say, you know what, our nephew gave us this and we tried it and it’s the best thing and it’s free and we can give it to you... it’s the gift the keeps giving, you know. But you can really help each other, if thats something that they need. It is tempting to explain the relationships between people, goods, knowledge, and work forged by David’s gift to his family as emerging out of and indicative of neoliberal working conditions—in which services are withdrawn and de-socialized, leaving individuals to be “creative” and develop individual solutions to social problems. Access to computing resources is a social problem, and it has emerged as a social “need” in a moment where its provision can only make sense on the scale of the individual. While public libraries and schools are a primary point of interaction with computers for many, every aspect of computing, from network connections to how computing devices are developed, marketed, and sold, operate as if the individual is the natural scale and domain 224 of digital computing and networks. For in the absence of the social provision of computing infrastructure or education, David appears to step in as a creative individual providing these resources and solving problems for his immediate family unit. However, while this all might occur in the context of neoliberal policy and rhetoric, whose purveyors would likely valorize David’s gifts as a prime example of how well individual responsibility works, at the level of subjectivity and in terms of the exchange of goods neoliberalism’s explanatory powers falter. David is not “becoming neoliberal” even though he is operating in conditions that are in part the result of neoliberal policy. Furthermore, the exchange that creates a bond between David, his family and the larger community of Ubuntu contributors is a gift, based in work he considers incredibly fun—and in his eyes and my analysis, this gift is not a gift of an individual. His work, what he does for Ubuntu on a daily basis—writing small amounts of code, doing public relations work, public speaking, and providing support for others— is not neoliberal, and he is not becoming a neoliberal subject. Further, regardless of his action, there would still be an implied violence that makes me uncomfortable with calling anyone a “neoliberal subject,” unless perhaps it is to mean a purveyor and supporter of neoliberal policies, i.e. a neoliberal, as in identifying someone as a neo-Malthusian or the like. I must be clear that even this does not make someone a neoliberal subject, anymore than anyone playing a video game based in war makes someone a neoliberal subject. Our lives—our subjectivies—are just to complex to be reduced in this fashion. Disallowing the idea that people “become neoliberal” is essential to enabling a labor geography that takes seriously how workers actively bring conditions of work into 225 being (not to sounds like a broken record, but do so for better or worse). David’s work (which he often calls play or fun) is engaged in multiple forms of exchange that have very different relationships to capital, other workers, his friends and a broader conception of the public. In what he describes above, his work circulates as a gift and in this exchange (between him and his family and in the broader circulation of Ubuntu code). Yet, his labor remains immanently useful for capital, potentially ready to work for Google or another firm is some unanticipated way, as it already did by creating ad revenue for Google via YouTube. Why David does what he does is unknowable and his reason for doing what he does ceases to matter the moment the gift of his labor leaves him. How resources are organized to do this work, how things of value move, these are the complicated questions that matter and whose answers reveal something meaningful about the world we have before us. In the next chapter I expand on how this immanence becomes central in the negotiation between capitalism and the commons; first a quick comparative look at Google to help set the stage for fun and excavate the broader stakes of fun. 226 III. Fun at Work: Eyeglasses and Laundry By itself, a star fleet could not build another fleet, or even keep itself indefinitely provisioned with high-tech supplies. It was an old, old problem: to build the most advanced technological products you need an entire civilization—a civilization with all its webs of expertise and layers of capital industry. There were no shortcuts; Humankind had often imagined, but never created, a general assembler. (Vinge 2000, 207) In the groggy gray morning of the first day of the bi-annual Ubuntu Developer Summit (UDS) at the Google campus in Mountain View, California, two Ubuntu contributors smoked cigarettes and drank coffee outside of a Google building while discussing each others glasses. I had just ridden three miles on a borrowed bicycle, from a cold Craiglist-rented room in south Mountain View, and was trying to wake up and convince myself that it would be okay to spend a week at a technical event amongst committed developers. The bus from the $175 per night hotel where Canonical employees and “sponsored” community contributors were housed had just deposited additional dozens of Ubuntu contributors, some looking as uncertain and out-of-place as me, others excitedly greeting friends. The night before I visited the workspace for Facebook’s “engineers” and the shock of the opulence available to Silicon Valley’s elite and its juxtaposition to the other Mountain View residence I had visited was fresh. The small house where I rented a room for $220 a week from a single mother told a tale of manufacturing jobs lost, real estate booms and skyrocketing rents, and the increasing disparity between rich and poor. The Mountain View bike trails passed through NASA’s 227 Ames research park on the way to the Googleplex where rumor claims Google’s private “party jet” is housed; like many of my fellow attendees, I was in awe of the Googleplex. An overheard conversation that began with a kind opening remark—“I like your glasses. Where did you get them?”—and quickly turned into a discussion of the merits of carrying vision insurance versus buying glasses out of pocket from online vendors stuck in my head for months. The two Ubuntu developers compared notes and debated insurance providers. The consensus was that dental insurance is important, but it is too easy to forget to purchase it on our own, and that vision insurance might be nice because out of pocket expenses are surprisingly high, and it would be a luxury to carry vision insurance. Both developers were skilled at fixing their own glasses and only replaced glasses for themselves and family when they broke beyond repair. We stood twenty feet from what looked like a large mailbox just inside of the building into which Google workers 85 were dropping their laundry on the way to work. Later in the day we would walk to other side of the building to a cafeteria that served fresh, healthy and incredibly good food to Google workers, and for the coming week, those of us attending UDS. Google is, by most accounts 86 and in my research, a fun place to work. Aside from taking care of workers’ needs with on-demand catering, good transportation, 85 I use “workers” here and not developers or contributors because according the security guards who kept those of us attending UDS out of “Googler Only” areas, everyone who works at Google, including the “permanently contracted” guards, have access to most “free” amenities such as laundry, child care, food service, and recreation facilities. 86 See glowing reviews of the Googleplex in Time and Fortune (Lashinsky 2007; Indpendant 2006; Hoagland 2006) as well as Google’s own celebration of the Googleplex (Google 2008). There are counter-stories of it being easy to get lost within the Googleplex and “drift” unhappily and some employees I talked found that Google’s exceptional internal transparency, coupled with a stringent non- disclosure contract creates a very insular world wherein it is difficult to talk with people outside of Google, making it more likely that more aspects of Google worker’s lives revolve around Google. And there are critics of this approach who argue that Google is squandering would be share-holder profit by making work “fun” (Economist 2007). 228 housing options, and decent health care, the Googleplex also provides workers with playrooms, toys, recreation, and exercise space—essentially a still functioning version of that mythical Silicon Valley startup’s office from the late 1990s. Bayat’s definition of fun is useful again here, as it points out that fun faces the impending possibility of commondification, or becoming part of a discursive regime of power controlling and containing the very limits and possibilities of fun. For power is central to Bayat’s definition, in which he argues that: beyond its physicality, fun also presupposes a powerful paradigm, a set of presumptions about self, society, and life that might compete with and undermine the legitimizing ideology of doctrinal power when these ideologies happen to be too narrow, rigid and exclusive to accommodate ethics of fun (Bayat 2007, p. 455). Bayat tends toward seeing fun’s relationship to power in terms of its capacity to challenge the workings of power, but in his definition—the presumptions about self, society and life —make clear that fun, like power, is not good or bad, it is just productive and of the system of its emergence. Fun at the Googleplex has the potential to many things, the least of which is institutionalizing presumptions about the self, society and life that align with the firms capacity to reproduce itself and expand. This is not to say that workers at Google are not having fun, or that the commodification and institutionalization of fun always works in the same manner—just think about park space. It is often created as a “place for fun” (amongst other things to which this fun is presumed to be subservient, such as moral and social order). In the state-sponsored (or firm-sponsored) development of a “place for fun,” fun itself confronts the organization and control of place: the basketball courts are not always open, the lights 229 turn off at 11 p.m., there is a baseball backstop instead of soccer goals, etc. And all of this occurs around a set of moral prerogatives that tie together the state and capital in seeking control of time and the reproduction of workers and the “moral body” of the public, even as people make parks and public space do and mean different things, often in the face of policing and surveillance (c.f. Davis 1994; Hayden 1997; D. Mitchell 1995; Valentine 1996). Like a park, creating the Googleplex complete with facilitates and places designed to engender certain sorts of activities and not others is no easy task—it requires a great deal of coordination, infrastructural transformation, legal work, and in the end usually does not create the outcomes its boosters, supporters, and developers might have desired. For instance, it was no easy task for Google to create and organize the amenities of the Googleplex. Swimming pools, a very popular request from workers, 87 like many other things at the Googleplex, require negotiating a complicated set of zoning and regulation issues and figuring out details like lifeguards. Childcare, which is now excellent, took a long time setup because the Googleplex is in a light industrial zone with a wide variety of soil contaminants which made citing childcare difficult. Also, as mentioned, all Google employees have access to amenities and services. At least a few interns realized that Google will do their laundry, provides all meals, has showers, has exercise facilities, and so they started living full time at the Googleplex, leading to new rules about where Google employees can sleep and a “no living at the Googleplex” message sent out by HR. Like the public park, people will use places in unintended ways and finding those limits often means the imposition of law and policing of unwelcome 87 Interview of Graham, former Google employee. 230 people and uses. Practices used to control of time and morality of the park, the campus, and the factory enter the particular workplace that is the Googleplex, where workers are encouraged to have fun, so that they may work long hours (ideally in a state of the very productive “flow” of having fun as described by Csikszentmihalyi). After explaining a portion of my work in terms similar to the sentence above an employee from Google’s Open Source Programs Office who led me on a tour to other parts of the Googleplex asked an obvious and tough question: “if Google is using fun to extract more value from its workers, and they’re having fun, what’s wrong with that?” 88 In the grand scheme of methods used to extract surplus value from workers, certainly this does not seems to be the most harmful. Yet, it has its own insidiousness in the way in which Google (and Ubuntu) are part of forming an emerging web for extracting value from all kinds of work. Canonical and Google are obviously very different firms— making different things, at different scales, using different models to extract value and having near opposite approaches to transparency—but they share similar objects of work and collaboration challenges, and in doing so are dependent upon each other as organizational forms. The first time the shadows of the relationships between firms like Google, Ubuntu, and FLOSS hit me with their complexity stands out in my field notes: 8:45 p.m., Friday. I had a free lunch sponsored by Google today. To give everyone a taste of what it is like to work for them, I guess. In my bag are three “Google Women” mugs. They are pink and were on every seat in the WiOS track conference room after lunch and will make nice gifts (see Figure 7). Google invests heavily in FLOSS, their spokesperson professing “because it’ s the right thing to do.” They pay people to code full time on FOSS projects that “Google likes.” They have a fund to buy pizza for Linux User Group meetings (they 88 Interview / Tour with Kerry, a program manager at Google’s Open Source Programs Office. 231 support the reproduction of FLOSS labor-power?). They developed and fund the “Summer of Code” (a program that brings students and mentors together from around the world to work and rewards students with stipends for finishing a requested FLOSS project). They sponsor “geek girl dinners” (talks and dinners for women in technology). Is every line of FLOSS code written potentially useful to Google, potentially increasing the surplus-value they can extract from their already overworked workers by running their system at a lower total cost of ownership, delivering better searches, more and better tools that get people using Google services, constantly giving gifts by adding value to Google’ s services and thus increasing Google’ s capacity to sell people’s attention to advertisers? Are all the people who give their time to Ubuntu also giving their time to Google (as Google uses Ubuntu internally)? Many of Google’s employee’s create things that are not made to be exchanged on a market (not commodities), but rather are designed to provide the means for other Google employees to make products for exchange (as a firm’s machinist might provide a cog for 232 Figure 7: "Google Women" Mugs at Session in the "Women in Open Source" Track at SCaLE an assembly line or the janitor might provide a clean workspace). The product Google produces for exchange is attention to ads (not unlike how television channels sell viewers’ attention to advertisers), and to capture and sell aggregate personal data (not unlike a “membership” card at a grocery store). Much work is also deployed to capture the labor of millions of internet and web users in the form of people creating Google maps, integrating Google products into their own websites, and by coders who use Google’s open programming interfaces to create new features. Dealing with Google’s complex internal ecosystem is a separate project, but Google’s reliance upon FLOSS and volunteered labor is revealing. It is no coincidence that following Ubuntu led to Google. Google has twice hosted UDS, and Google’s Open Source Program’s Office works to support Ubuntu and other FLOSS projects. Google, for a variety of reasons, is heavily invested in reproducing the capacity for FLOSS labor. One aspect of the reasoning behind this is most clearly expressed in a recent keynote address at Google’s main developer conference, Google I/O. Google’s Vice President of Engineering Vick Gundotra unveiled a beta release of a new Google concept/product, Google Wave (which ended up as quite a flop). The audience of developers were given access to the beta test (a highly envied “privilege” that was met with enthusiasm). Gundotra explained that Google Wave was “open sourced for many reasons, not only do we want to contribute to the internet, but frankly, we need developers to help us complete this product” (Google. 2009). As this quote demonstrates, capital’s need for and dependency upon volunteered labor of FLOSS 233 contributors is a well known and frequently discussed fact with which economic theory of digital work must contend. Reproducing Fun, or, A Few of Fun’ s Externalities For both Google and Ubuntu management and contributors, to what ends are the institutionalization of fun ends up serving is an open question. It is certainly possible that much of Google’s management and board is concerned with achieving as much of their mantra of “do no evil” as is possible while adhering to the high order (and legally enforceable) ethics of a publicly traded company required to seek profits—but the outcomes of the institutions, infrastructure, and social relations that Google enables are not likely to be the stuff dreamed of or desired by its creators, board-members, or stockholders. As organizations, both Google and Ubuntu are interested in the reproduction of a broad ecosystem of software production and thus are concerned with how is it possible to ensure that the next cycle of development is also fun. A failure to reproduce this system means the loss of coders, both paid and volunteer, a great concern in both organizations. At the Googleplex there are rules for fun, simply in the very existence of a particular areas for fun to be had in the workplace. However, institutionalizing fun, and corollary rules to extract more value from workers does not preclude the existence of fun at the Googleplex. That is, the fun of working with Ubuntu is not in some higher order, different, or more radical fun. In what we might call work, play, creativity, or sport depending on its place, time, and participants lies the possibility for some ad-hoc, in-the-moment emergence of fun that cannot be commodified or 234 institutionalized. It must be understood that the potential for this sort of fun (say, in playing basketball) lies right along side to and is not opposed to the simultaneous emergence of conditions that might be utilized to sell a lot of commodities (basketball shoes) or help to establish capitalist institutions (the NBA). This does not mean there is less beauty, hope, or inspiration to be found in an NBA basketball game than there is in some other, more “pure” form of the game. In arguing for fun as analytic to study work it is important to address the structured, “ruled” aspects of work that could create fun as well as something like the maintenance of the conditions of fun rooted in dependency that require a non-capitalist system of exchange for reproduction. There are a wide variety of ways, in different times and places, workers and managers have sought to reconcile human needs that are both created by and left unfilled by the theft of fun from work. FLOSS is organized not only by the desire to make work fun, but by the need to create a form to hold onto this fun for the next cycle. Part of the fun that Google provides is the socialization of basic needs and household tasks plus security—this changes the system in which fun emerges. Constraints are experienced differently when you know you have food ready to eat provided for you every day, to find time for laundry, to have childcare if needed, to know where your healthcare or next pair of glasses is coming from, not to mention the increasingly rare feeling of meaningful security created through a guaranteed-to-be-adequate retirement. Ubuntu workers do not have access to this sort of fun in the same way—the sort of fun that emerges in a system where basic needs are met. 235 The Googleplex, like the starship in Vernor Vinge’s world, is created by the externalities of a whole civilization. The technologies produced and relied upon by Google and Ubuntu also require an entire civilization to create, and it is only because of the stolen surpluses at many stages of producing such technology that the wherewithal for having fun working at Google (or Ubuntu) is acquired. We all can imagine what sort fun can emerge in a state without worry (from its lack and/or momentary emergence), and how hard it can be to have fun when feeling, for whatever reason, that meeting basic needs today, tomorrow, next week, next year, or in thirty years, is uncertain or unlikely (even though these precarious conditions make finding fun feel all the more important). I bring this up to remind myself that although FLOSS workers are very capable of reproducing a fun way of working, such fun exists, in part, in a space carved out by its externalities. Google and Canonical are fundamentally different firms in many ways, yet similar in their reliance upon the externalization of labor costs and risks. Neither Google nor Ubuntu produces or assumes any risk of the production of the cheap computing devices that are both the means through which workers labor and the means by which consumers are able to access their respective products. 89 Both Google and Ubuntu benefit from the state investment in a global communications infrastructure, which has received uneven investment across regions and nations. Both benefit from an international division of labor (Mosco and McKercher 2008) in the production of computing devices; Google 89 With Google’s August 2011 proposed purchase of Motorola Mobility (at the time of writing, waiting to be approved by US and EU regulators), Google is tied more directly to the manufacture of computing devices (through ownership, but no more or less tied through use and function, especially considering that Google’s self-reported reasoning for the purchase was to pad the firm’s patent portfolio). I read this news with some perverse joy, for perhaps now people might listen to me just a little bit when I insist that Google is a hardware company. 236 more markedly, with its dozens of data centers around the world, each costing over $US one billion each and each consuming very significant amounts of power (often at cut rates), using in total at least two-three million servers built by Google (making Google the largest computing manufacturer in the world) (Levy 2011, 181–196). Ubuntu relies upon that atomization of workers, even those who are paid, wherein forces of production that might be located within the firm—janitorial work, administrative and clerical support, administration and management of healthcare and retirement benefits, network administration, computer support, etc.—are transferred to the worker or the worker’s social unit (and often to the household labor of women (Sullivan and Lewis 2001)). Google brings these, plus other aspects of reproduction, into the firm, socializing the various “household labor” discussed above as amenities. Ubuntu relies upon the unpaid labor of not only its direct contributors, but the paid and unpaid labor of all who contribute to any “upstream” projects. Google relies heavily upon the labor of FLOSS contributors as it uses FLOSS in nearly every aspect of production: Linux runs its data centers, most Google projects are in some manner built upon FLOSS labor. Google’s management recognizes that there are sorts of fun, labor, and lives that Google ends up supporting (probably not purposefully) that have no measurable benefit to Google, the firm. This is not because Google is kind and fuzzy or careless, but that this is acceptable for Google because so many of their other costs are externalized to FLOSS volunteers, to cheap electricity, and to tax breaks from regional governments for Google data centers, as well as the generally low costs of the fixed capital required for performing web searches (in which the production of processing power and storage 237 capacity further externalize the environmental and human costs of raw material extraction and related manufacturing. In this analysis, it is essential to understand Google as a hardware company—their initial innovation was not only a search algorithm, but server cabinets that could fit more processors in a rack than existing solutions. One of the first Google rack servers sits in the entrance to their showpiece Building 43 on the Googleplex, reminding visitors and workers that software does not run in the ether—or that Google’s great innovation is the creation of a widespread belief in the ether. Stepping Back from Fun: Context and Recap As Google helps us see, fun’s dependency is broad—much of the fun I discuss is made possible by in-numerous thousands of people working to make small parts of what becomes a software/hardware ecosystem. Why there are some labor processes built on fun and others not—why this fun now—has everything to do with organizing labor, but contrary to appearance, nothing to do with the type or object of labor. There are types of computer hardware manufacturing (prototyping, hobby builders, etc.) where work is organized by fun. There are “software factories” out there where the work of making software is route, boring, painful, and organized by principles that make fun very difficult to eek out. The relationship between fun and work is deeply tied up in the genesis of work: why is work done? This is not motivation—this is about how work is organized, this is about how labor processes come to be. The Ubuntu labor process came into being through a complicated mixture of a capitalist seeking to make something beautiful and to extract surplus value from an existing labor process (the Debian Project) that was not 238 organized in a manner that readily allowed for a symbiotic relationship with capital. This non-capitalism of Debian is not anti-capitalism, it was derived from the object of work, from people who care deeply about code asking themselves, how can we make the best code, and how can we do so sustainably and ethically? Fun was part of the labor process of making code before Ubuntu and will be so after. The fun of working with code thus has both nothing to do with code and is also fundamentally about the limits and possibilities of that material which is code. In other words, the fun of code is in finding the limits of play within the system that defines what can be done with code. These limits are defined, of course, both by the material at hand —how fast code can move—and by the rules of work—set by various entities involved in the labor process, community standards, the employee handbook, the informal rules of the shop floor, etc. Yet, I must believe that fun is general, that each and every object of labor has fun within it, a fun that emerges when people are able to work in a manner that is in accordance with the material at hand. I know this sounds flighty and vague, and I have struggled with some other way to say it, but this is the singular core belief that has emerged out of four years of dissertation research and writing about fun (see Appendix C: Manifesto for Fun for a extended version of this statement). Any work can be fun; and one way we can recognize and pursue a just and ethical way of working and allocating surplus just might be to seek the reproduction of fun. I have no choice but to believe that if something like fun was a priority in organizing work, many decent impulses that currently only find their expression in violent and twisted processes forced through a capitalist system of exchange could find a different form of expression. 239 For instance, how might the much touted “entrepreneurial spirit,” make sense if thought through fun? First, it is essential to start with the proposition that there is nothing necessarily capitalist about taking on the risks of starting a business venture—though there is something particular about the assumption that the bearer of that risk is an individual. People organized labor and resources in new ways to make something useful beyond meeting their immediate needs in order to exchange with others before capitalism and will do so after capitalism. An analysis of the familial, social, and ethical contexts of current entrepreneurs might find that the desire to bring a thing into the world in some material form, and the willingness to assume the risk to do so, does not emerge from capitalism. Instead, through an aggressive campaign of business classes, how-to books, seminars, and accounting lessons, entrepreneurial desires get pushed into a capitalist form and the need for capital to sink itself into production processes in the form of machines, buildings and payroll easily turns entrepreneurial desires onto the joys of surplus labor. This is not to say there are not entrepreneurs who dream of living on the surplus labor others, but rather that many entrepreneurs, perhaps most, dream first of thing that they wish to carry into the world through the love and fun of their labor. This distinction between entrepreneurialism and capitalism is useful for thinking about what happens before start-ups start up. For this project, the distinction serves as a crucial reminder to not discard and discount FLOSS and Ubuntu contributors who have entrepreneurial dreams of taking some risk (to themselves, likely to their family unit, perhaps to their community of coders, and in many cases, even to the code base with which they work) in order to making a living working with Ubuntu. (And as a reminder 240 for me, because hearing someone talk about their business plan or how they want to be an “open source entrepreneur” used to turn my stomach and turn off my ears.) This is a reminder to take the most commonly asked question about FLOSS—“how can they/I/we make money when people work for free and give away what they make?”—back to its prior, and more meaningful question, “how can they/I/we bring FLOSS into the world and make sure we have the means to do it next time?” This means taking scholarship about FLOSS business models out of the hands of those who will only see a “business model” as a more or less effective and sustainable means to extract value from a productive system and be willing instead to hear “business model” and “entrepreneur” and think of the desire to make a thing, the labor of its making, the act of being willing to part with that thing and what then happens when when individuals and groups try to figure out how to reproduce this cycle in conditions that are not of their choosing (regardless of how they may feel about these conditions). Fun offers a way to deal with the incredibly complex social and emotional aspects of how we work, how we reconcile our alienation and exploitation, and it further unveils an essential contradiction of working with proprietary software that Stallman pushes us towards: propriety software robs us of the dependency, joy, pride, and fun of making things. There are a wide variety of ways, in different times and places, that workers and managers have sought to reconcile the human needs that are both created by and left unfilled by this robbery. Moving away from thinking about fun as a motivation also encourages a historical treatment of any given labor process and a recognition that any labor process can be fun. 241 Fun is then a means for focusing on “what we do,” but the same could be said numerous affective experiences of work. Understanding that any labor process can be fun is significant not for the intellectual exercise or to excavate the myriad of ways that workers have created fun within their workdays, but in that it can also be a path that leads to historical understanding of the development of bureaucracies, the implementation of management techniques, changing education systems, worker struggles, and state interventions. I hope that following the path that fun puts forth might lead to a better understanding of how we do what we do, and how work might be different and surplus could be allocated justly. But I would happily settle for just a small step towards making sense of how we do what we do. 242 Interlude: Conferences Hold the Allure of Possible Magic Convention centers are not the most exciting places. But they can hold utopic moments where the possibility of a world transformed becomes real—places often described as having “palpable excitement in the air”or other forms of feeling like new possibilities of FLOSS exist and could come into being at any moment, for any temporary grouping of people. As with any project, there are many origins to this work: a friend who convinced me to use Debian for the first time, an advisor who told me to focus on the labor process and smiled when I said I wanted to research fun, and other moments long since forgotten. But the one that remains, the one that reminds me why I care, is Comic Con. The magic of Comic Con—the “worlds largest comic convention”—persists through all of the promotion of movies, television shows, and every sort of “cultural product,” and in somehow in the face of its detractors who decry it as having “gone corporate” and “just gotten too big.” That is, there are many valid critiques to be leveled at the practice, institution, and culture of Comic Con, but there is still beauty in people transforming a convention center, the surrounding streets, and the local grocery store into the world in which they/we want to live wherein it is normal for a Wookie to purchase a prepackaged salad at a Ralphs grocery store. After my first day at the Open Source Convention (OSCON), I could only conclude “OSCON, it’s no Comic Con.” Yet there was something of the same magic. And not just because both Comic Con and OSCON both have talks and an expo floor crawling with people seeking swag. The very next day, this happened: I talked to a guy wearing an Ubuntu hat, pin, and sticker. He described himself as “just a user” and gushed about how excited he was to see and maybe meet Larry Wall, Mark Shuttleworth, or “any of the mySQL guys.” He said “this is like Comic Con for me.” I wished I was at Comic Con instead of this convention (research notes, OSCON 2008). Although I felt like an interloper, I could not deny that people were practicing living in a world they wanted to bring into existence and the conference “recharged” this commitment. “Recharged,” “remind me why,” “reconnect,” these are the things people often said about OSCON. Why can’t the world always be this way? The answer perhaps lies somewhere in cooperation and skill. But only in that it is these are two elements, along with machines, that eased capitalism into being. A certain scale of cooperation of specialized, de-skilled workers, subject to machine time, allows for socially average labor that makes capitalist production possible. Through cooperation the worker “strips off the fetters of his individuality, and develops the capabilities of his species” (Marx 1993, 447). What are these shackles of individuality? 243 And what does it mean to break them only to find out that the means by which they were broken, cooperation, is the means by which the capability to work for the good of all is appropriated for the development of private wealth? And that the increased productivity wrung from this social organization of cooperation welded to machines is but a means to cheapen commodities, which cheapens labor itself through decreasing socially necessary labor time; which means to cooperate is to give a larger gift of free labor-time to capitalists. What form of cooperation can make machines become subject to worker- time, to human-object-time? At conventions, there is a magic that makes none of this matter, that makes time different, that uses our skill and cooperation for what we desire: it is the magic of festivals, of the carnival, of possibility. I felt the allure of this magic of cooperation and skill sharing/building most acutely by its absence. Research is profoundly lonely at times, especially when surrounded by people who are actively struggling to bring the world in which they want to live into existence. I wondered and searched for answers as to why people go to FLOSS conventions for a year, finding various interesting reasons. In the end, it is this allure of magic that led me to realize the obvious, it is what conference do. In this way, “what we do” answers the unanswerable question of “why we do.” It is the allure of magic that brings conventions into being (as well as an uncountable number of other reasons that functionally explain why people attend), but it is only after that magic takes place and takes form that it begins the process of struggling to explain why we expend resources to be part of such moments. This is the magic of experimenting, practicing, dreaming, failing, hoping, building, prototyping, and being together as people who might not otherwise be together—who knows what might emerge? 244 Chapter Three: A Spatial Fix and Ubuntu Economics Jono (Ubuntu’s community manager) is fond of saying “we all know why we do this, it’s fun.” When he asked approximately 250 Ubuntu contributors gathered at the welcome talk for a week long developer summit at Google’s headquarters in Mountain View, CA “why are you here?” the responses shouted out varied: “it feels like charity,” “to create opportunities for those with disabilities,” “bug #1,” “its fun,” “its cool,” “learning,” “I need something to run,” “freedom,” “its sexy,” “sexy freedom,” and “equality.” Jono followed this with the claim that Mark Shuttleworth “is here because it’s the most important thing he can do.” Shuttleworth reportedly feels a debt to free software, sees “Ubuntu as a vector for upstream communities,” and this is his way of taking responsibility for his debt. The form this publicly stated responsibility takes is to figure out how to most effectively get the “good stuff” that is out there in the FLOSS ecosystem onto people’s desktops (which is another way of saying “Ubuntu is a vector for upstream communities”). These are the primary public explanations offered for “why we do” in Ubuntu: because it is fun, and because it is a practice that enables contributors to make the desire to “give back” or “make the world better” a real and everyday part of working. The fun that Jono references above cannot exist in the temporal relations of capital. As in the previous chapter, this does not mean that the fun of Ubuntu, or of any other labor process in which workers mean it when they say “I do this because it is fun” or “I play for the fun of the game,” is somehow outside of capital, or that what is 245 produced in such a labor process cannot be readily expropriated. Thus, although the Ubuntu labor process exists outside the temporality of capital, oddly, rather than being out of capital’s reach, such a labor process becomes a relatively safe fix through which capital can keep money in motion, redistribute risk outside of capitalist space, and produce new markets, consumers, and workers. The analytical challenge then, is to turn back to that fascinating world of the “business model,” which, in the case of FLOSS, is shorthand for figuring out how to take some value out of this system that produces a lot of valuable stuff without killing such a system’s capacity to produce that stuff. Or, in another shorthand, as Jono asks at the beginning of “community” sessions at Ubuntu Developer Summits, “how can we keep this fun?” These stories that Ubuntu contributors tell themselves about why they do what they do offer some insight into how the Ubuntu labor process is able to reproduce itself, as well as produce something value. In other words, it tells us something about how Ubuntu economics work. This vision of making the world better is a way of talking about the global sense of space in Ubuntu, or more generally, the space of the Ubuntu mode of production. Any society or mode of production produces its own space, consisting of the division of labor, the organization of resources, and the social relations of reproduction (Lefebvre 1991, 85–92; Massey 1994). The space of Ubuntu production and the dominant spatial practices of Ubuntu are thus well understood through code (as laid out in Chapter One). The possibilities and constraints of the material life of code plays a key role in reproducing the Ubuntu mode of production. In FLOSS, the division of labor takes a distributed, highly specialized spatial form that relies upon computer code, a global 246 communications infrastructure, and non-capitalist exchange (Terranova 2004; Chopra and Dexter 2008; Lovink 2008). For instance, time-zones become a key temporal-spatial category by which Ubuntu contributors organize themselves and make life decisions— and time-zones become an important factor, and in some cases the determining factor, that organizes Ubuntu contributors daily rhythms’ of work. Within this discontinuous, international division of labor, Ubuntu contributors develop global senses of place in which they make sense of their transnational social relations and particular global experiences of time in and through the complexities of the places at which they work. The dominant spatial practices in Ubuntu—the way space is made via the residue of doing things things in a certain way that become accepted social practice, and take shape because of how power moves through the people and resources engaged in these practices—is articulated through various means of communicating and collaborating in Ubuntu. That is, there is a residue of practices (the way things are done) and discourses about these practices (discussion about how exchange should and does occur, about what is valuable and worth doing, and about who is part of “the community”) that together form the dominant spatial practice of Ubuntu. This residue is not metaphorical; it takes form via millions of emails, IRC chats, in-person conversations, differential memories of these events and the continued reference of precedent in FLOSS communities. These practices are organized by fun, dependency, meritocracy, and a particular global sense of exchange and value. There are, of course, several dominant spatial practices that coexist. In Ubuntu these coexisting practices become apparent in the ongoing negotiation that 247 must occur between dominant capitalist spatial practices and those of the Ubuntu mode of production. It is the coexistence of these two dominant spatial practices, each founded in a different mode of production, that makes Ubuntu—and FLOSS more generally—difficult to grasp. The flux of an ongoing negotiation between these two modes of production makes all kinds of ways of working, producing, and exchanging possible, and such possibilities do not go unnoticed by capitalists. How can such space hold in the face of capitalist space? How can a common (and its constituent spatial practices) continue to function in the face of territorializing capitalist space? Again, somewhat oddly, it is the manner in which capital is forced to engage with FLOSS commons (rather than seeking to enclose, or commoditize FLOSS commons) that enables what I have been calling the Ubuntu mode of production to hold, take form, and develop. The commons do not need capitalism; capitalism needs the commons. In what follows I explain how the spatial and temporal relations of this uneasy movement between modes of production form a spatial fix. In short, a spatial fix is about capital’s need for an ever-changing geography to both keep capital in motion and to fix it to the environment in some manner in order to avoid crisis and over-accumulation. FLOSS offers such a fix. Two modalities of this fix are usefully thought together. On one hand there is the Ubuntu mode of production’s genesis as a spatial fix for surplus in an ongoing moment of crisis in capital’s increasingly abstract modes of extraction. On the other, there are experiences of the everyday work of making Ubuntu, where various frictions and 248 confluences enable such a fix to uneasily come into being through the movement of something of value: useful human labor congealed in that mysterious material thing, computer code. The particular material life of code makes it appear as if sorting out how value works is a lost cause—marked by exclamations such as “the conversion of virtual play into measureless immaterial labor” (Nick Dyer-Witheford 1999, 27) or that now exploitation is “beyond measure” (Hardt and Negri 2000, 356). On the contrary, I argue that paying attention to the labor process and workers’ experiences reveals the details (the uneasy parts, the painful and funny parts, the small changes in a labor process) that create this ongoing event. And it is an ongoing event, not an act or moment, that we can look back at over time and across scale and identify as a spatial fix. The general form of this fix is using the commons as a source of value and a way to store value—capital put into the commons has no immediate or guaranteed return, but it is kept in motion and fixed in some places and not others. I. What is it that Makes the Commons a Good Fix? Using labor that produces and maintains a commons as a means to absorb capital’s excess is not new, but the nature of digital goods and networked means of communication allow for new forms. It is also by no means a unique argument to point out how commons provide a spatial fix—pop economists such as Peter Barnes argue that “if the commons is a victim of market and government failures, rather than the cause of its own destruction, the remedy might lie in strengthening the commons” (Barnes 2006, x, emphasis in original). Barnes directly lays out a case against enclosure of the 249 commons, and in favor of protecting our “common wealth” for that capital may survive— an argument that echoes in varying forms through the “Creative Commons” movement and the work of other anti-copyright/patent/enclosure scholarship (Lessig 2004; Benkler and Nissenbaum 2006; Hyde 2010). What these “commonists” describe is the hope that the commons can form a grand spatial fix for excesses of capital (both in terms of the destruction it has wrought and the surplus it has unjustly allocated), and that when the wealth of the commons is better taken care of, there will be even greater surplus to reap and that somehow, commons-based capitalist production will be just. To talk about commons, especially in the context of finding hope in commons, is to inevitably run into the tragedy of Garret Hardin, which might be reason enough to consider using some other concept instead of the commons. But like many others (Bollier 2002; Moten and Harney 2004; Coleman and Dyer-Witheford 2007; Casarino 2008; Hyde 2009; Patel 2010), who see the commons as a key to somehow reclaiming life stolen by capital, I want the commons back. Not back to a mythical prior state when commons were held, conceptually or materially, in some pure form, but back to a term worth holding on to. To a form worth caring about and struggling over in the face of the tragedy of commons (e.g. Hardin 1968; Torres 1992), yet also not toward managing commons (e.g. Ostrom 1990; Baden 1998), or in the direction of other scholarship that positions commons as some sort of natural solution that only needs appropriate legal or legislative apparatus to solve inequality via a more just capitalism, especially in the case of “cultural” or “knowledge” commons (e.g. O’Mahony 2003; Barnes 2006; Curien et al 2006; Hess 2007). 250 It is easy to start with what commons are not, to go through the often needed motions of showing that Hardin’s conception of the tragedy of the commons starts from assuming that commons exist in some way prior to humans, and then are threatened by people acting in their self interest and destroying what is in common by some form of overuse. Commons are not this sort of tragic; even if tragedy does occur. The literature on managing commons makes clear that commonly held resources have been, are, and can be managed in a way that will avoid such destruction. Yet managed is not quite the right word for how commons are held. For the most part, scholars concerned with the legal apparatus and social movements necessary to prevent enclosure of commonly held resources (from land privatization to patenting software) focus on the limits and limiting of private property to preserve resources and ways of life, and to create more just economies. Commons may enable life—as Donald M. Nonini puts it, commons are the “great variety of natural, physical, social, intellectual, and cultural resources that make human survival possible” (Nonini 2007, 1)—and commons are certainly worth struggling to reproduce, but saving commons might not stop death and will not stop exploitation. In a more positive definition—as in action, not in outlook—a commons is a whole system for circulating something of value wherein the goal of circulation is to reproduce what is circulated in a manner that makes it available to all who are of the common (not evenly, not necessarily collectively, and quite often very clearly, not for outsiders). This means that commons must have a commonly held resource, a community engaged in circulating that resource, and some system for making rules about that resource (Caffentzis 2008, 8). That said, the key quality that makes a common a common is 251 circulating something held in common in a manner that prioritizes the reproduction of that thing and the community’s access to it. The commons is the system; gift exchange is the mechanism of circulating that- which-is-held-in-common. The mode of circulating things in the common is well described as a gift economy in which the circular movement of things of value create relationships between a community of givers and receivers of the gift (see Hyde 1983; Bollier 2002). In this economy, gifts must be passed on to complete a cycle of exchange, and being in a position to give creates dependency, power relations and reciprocal relationships, and an increase in the gift. Gift exchange is a form of circulating something of value that ensures the reproduction of the gift, that makes sure that-which- is-held-in-common can be made again and be used by those who are part of the commons. Turning back to Hyde on the vector—both the direction of movement and what is moved—of the gift, we can see how the gift is a mechanism for maintaining the commons: Gifts that remain gifts do not earn profit, they give increase. The distinction lies in what we might call the vector of the increase: in gift exchange it, the increase, stays in motion and follows the object, while in commodity exchange it stays behind as profit (Hyde 1983, 37, emphasis in original). “Following” or “staying behind” is not metaphoric; in the case of FLOSS (or code generally), if an entity, say a firm, uses some FLOSS code and improves it and releases that code back the FLOSS ecosystem, the improvement moves with the FLOSS code as a potential increase of value for all to use. If that improved code is somehow separated from the FLOSS code (most FLOSS licenses make it illegal to not release improvements) and can legally be kept separate (this can be as simple as creating some proprietary code 252 whose usefulness depends upon FLOSS code 90 ), then the increase, the code itself, can stay behind as potential profit. Or, more accurately, if that firm also invests in either the communication infrastructure or purchases the labor of someone in the commons, the increase that produces is extracted from the commons as surplus value. The action that drives the commons, that keeps the commons common, is gift-like circulation, wherein the vector of increase stays with that-which-is-held-in-common. Peter Linebaugh describes this action in another manner and argues that it is better to think commons in terms of commoning, of how commoners make things common through their labor (Linebaugh 2008, 45). There are many ways of owning or not owning what is held in common, many types of rules, many possibilities of community formations for holding things in common, but that-which-is-held-in-common must move as a gift. This is what it means to claim that commons and gift exchange are two ways of describing the same system. Such circulation varies based on what is being circulated, but such circulation is always an act of laboring, of commoning—our lungs are part of a whole system that keeps the atmosphere viable; limits on the number of fish caught and making some species of fish “game fish” that cannot be commodities keeps lakes stocked; and making a complaint about a bug in some software provides necessary testing to keep the development cycle moving. All of these modes of circulation are gift-like— whether the giver thinks of their gift as such or not. On the other hand, commodity exchange threatens the common, not because the thing being exchanged necessarily becomes something different, and not even necessarily 90 With Canonical, examples of this include Ubuntu One, Launchpad (which was proprietary for years), and Landscape (a proprietary application for managing Ubuntu installs). 253 because it takes goods out of people’s hands (commodity exchange may be more efficient and deliver more goods to more people using similar resources): commodity exchange threatens to destroy the relations of dependency, the organization of labor, and possibly the way of life that prioritizes reproducing the common. 91 The common itself is a place, or set of places, where that-which-is-held-in- common can survive. There is always something held in common, how it is held varies —but what is held must remain in the common to survive. It is easy to see how commonly held things—grass, code, fish, or water—cease to survive as the gift that they are when they leave the common. Commons in which there is a commodity that is moved out of the commons, to use one of George Caffentzis’ examples, Maine’s lobster commons, make clear that-which-is-held-in-common is often access to the commons, and access is a gift. To accept this gift means to accept rules designed to make sure the commons are reproduced, even as people of the commons must engage in commodity exchange (of lobsters) to survive (Caffentzis 2008). Spatial fixes are almost always dependent upon commons as a source of value. The wealth of the commons creates much that capital needs, and as Nonini indirectly points out, by providing that which human beings need to survive, the commons also 91 To be slightly more precise, commodity exchange threatens the commons; capitalist exchange destroys the commons. If a community were to sell some apples from a common apple orchard in order to buy tools to maintain the orchard (commodity-money-commodity), this exchange could keep the vector of increase with the commons—although the act of becoming dependent upon a (presumably) capitalist market for tools does threaten the commons. And there are all sorts of systems for owning and selling the apples on the market that could still keep the commons alive (in other words, many ways of negotiating between capitalism and the commons). But if the apples become the intermediary, and the goal is to take money earned from the apple orchards and invest in tools, labor, and other means to make more apples to sell for more money, the goal is no longer to maintain the commons, the goal of the exchange is more money (money-commodity-money 1 ). This is how capitalism destroys the relationship and exchange that maintains the commons—even if the orchards themselves survive. And as Gibson-Graham might remind us, the non-capitalist life that existed in the commons does not simply die with the destruction of the commons. It hobbles on, steals apples, plants another orchard. 254 often provide that which capital needs to survive: labor-power. As commons are degraded or enclosed, capital’s dependency upon all sorts of commons will likely be increasingly obvious and as likely to take the form of dispossession as negotiation. That is, the negotiation that takes place to enable FLOSS to function as a spatial fix, that allows capitalism and a commons to co-exist, is not a natural outcome, but rather one that is wrought by FLOSS workers seeking to reproduce themselves. Rethinking “Knowledge Commons” In Commonwealth, Hardt and Negri argue that knowledge commons are a whole “different notion of the common” from, say, a common field of grazing grass. Such arguments proliferate in literature on commons, predicated upon the general concept that there is a qualitative and meaningful difference between so-called “natural” and “artificial” commons; or with a little more analytical focus, between natural-resource commons, social commons, and cultural commons. Whether called knowledge, artificial, intellectual, or cultural, all of these “types” of commons are considered non-rival, wherein one person’s use does not impede another person’s use of what is held in common—and such non-rivalness is especially taken for granted in the case of “digital commons.” Of course, a cursory glance at how commons of digital things function makes it pretty obvious that this is not the case. Digital things are rival. My use of, say, wireless bandwidth in a room full of people on their laptops, decreases someone else’s capacity to use the internet. This is a frequent occurrence at FLOSS conferences— leading to conferences organizers to make announcements before keynotes such as: 255 “yeah, the wireless sucks, sorry … but please stop your BitTorrent downloads, hold off on your software updates, make it suck a little less for everyone.” Hardt and Negri argue that there is a more important reason that artificial commons are different—the means of dispossession are different. Dispossession is different because there is some essential difference in the sort of goods in the common and thus a difference in the means and implications of their exchange. The primary means of dispossession of “knowledge commons” is through the use of copyright law and patents—both of which function to rob everyone of resources that could be or were held in common, each with its own separate means of dispossession (c.f. Bollier 2002; Barnes 2006). However, arguing against these forms of dispossession is not necessarily arguing in favor of the common (or evaluating if the common might be worth or not worth fighting for), and looking to the machinations of copyright law is not the same thing as looking at the functioning of a common. Collapsing one into the other (taking a discussion about patents and copyright—means of ownership of the intellectual content of things—for a discussion of the commons) shuts down meaningful understanding of how social relations, production, and exchange of goods actually works in any given commons. This is an essential intervention into a deluge of scholarship on copyright law, patents, and “free culture” that engage with the commons primarily in relation to the means of dispossession—not in terms of how the commons actually function, much less what this functioning may or may not tell us about a future without private property. An example of this collapse—in which the content and meaning of things comes to take priority over and stand in for the material life of things—and the disconnects it 256 produces, is found in Hardt and Negri’s use of a famous Thomas Jefferson quote: “he who receives an idea from me receives instruction himself without lessening mine; as he who lights his taper at mine receives light without darkening me” (Jefferson 2007, 333- 334 in Hardt and Negri 2009, 238). This obvious sounding proposition makes a good case for arguments against patenting of certain types of innovations, such as software patents—and is very frequently used to do so—but what Jefferson is actually discussing, a patent for a grain conveyor, tells a larger story about commons (even if Jefferson was not trying to tell this story). Jefferson makes an appeal to the commons against renewing the patent for this invention, since “turning to such books only as I happen to possess I find abundant proof that this simple machinery has been in use from time immemorial” (Jefferson 2007, 333). Jefferson goes into great detail about ancient Egypt, the history of the screw of Archimedes and a local farmer in a nearby county, and in each case identifies essentially the same technology at work. These are not simply ideas floating in the ether, for Jefferson focuses on ideas plus labor: “Stable ownership is the gift of social law and it is given late in the progress of society … It would be curious then if an idea in the fugitive fermentation of an individual brain could of natural right be claimed in exclusive and stable property” (Jefferson 2007, 333). This questioning of the legal and moral basis for patenting is a question bound up with labor for Jefferson. He built a mill using the patented ideas at hand, and paid the patent fee when the owner requested it: Although I had no idea he had a right to it by law for no judicial decision had then been given yet I did not hesitate to remit to Mr Evans the old and moderate patent price which was what he then asked from a wish to encourage even the useful revival of ancient inventions. But I then expressed my opinion of the law in a letter either to Mr Evans or to his agent (Jefferson 2007, 337). 257 Working from the same passage about the taper as Hardt and Negri, Lewis Hyde focuses on something closer what Jefferson appears to be talking about: how is it possible to think of ourselves as owners of the commons (Hyde 2010, 131)? This is a move towards trying to understand how a commons of ideas and knowledge works in practice and as part of production processes, rather than a moral appeal to the nature of the good at hand. Such moral appeals are frequent, and found on stickers, tee-shirts, and articles with claims such as “knowledge wants to be free” or “the internet routes around censorship.” The use of the Jefferson quote about receiving light without darkening the source is useful in an argument about patents, but like the above frequently uttered claims about the nature of knowledge or the internet, this quote tends to work to obscure more than it reveals. Hardt and Negri are certainly not the worst culprits, for they do argue that “the second notion of the common [the “knowledge common”] is dynamic, involving both the product of labor and the means of future production” (Hardt and Negri 2009, 139). However, it is more important to focus upon how commons work, rather than a typology determined by the object or thing that is held in common. For while a commons of grass and commons of code are certainly not the same, the distinction between natural and artificial/knowledge is not useful in understanding either in terms of how they are reproduced or the relations that define that-which-is-held-in-common. A field of grass and code are both artificial social products whose value comes from the two possible sources of value: nature and human labor. The levels of abstraction from “nature” and human labor are certainly different, and the appearance of each common seem 258 irreconcilable, but through a little tracing of nature and labor, all the generations of human labor involved to make grass grow in a field can be as obvious as all of the natural resources required to make computer code move inside of a computing device. So-called “knowledge commons” are always material—potentially as infinite as grass in field, potentially as scarce as fruit on a tree. Along with many others, Hardt and Negri would beg to differ, putting forth instead the argument that today, “biopolitical production [which is about the production of social relations rooted in the common] is not constrained by the logic of scarcity” (Hardt and Negri 2009, 283). This is a true statement when applied to the capacity of the owners of the means of production to ignore the material reality and logics of scarcity, but biopolitical production remains constrained by the reality of scarcity, whether the scarcity is acknowledged or not. While the above paragraphs may seem to be a tangential aside from spatial fixes, it is from this Jefferson quote (and from very similar sentiments uttered by “commonists”) that Hardt and Negri and others proceed to argue that a common of code is an “artificial common” or a “knowledge common.” The proof of this sort of commons’ artificial-ness is based on the supposed essential characteristics of the goods that populate the commons: First, their cost of reproduction is negligibly low to zero; and second, the “substance” of the commons is immaterial as it is found in the social relations that define the commons (the transfer of an idea from mind to mind). 92 To get to scarcity, it is worth taking a detour through some of Louis Althusser’s thoughts on production processes related to “the object of knowledge.” I have found this 92 That the content of such commons have a nigh-zero cost of reproduction also provides an ideological base for ideas that coders and other “creative types” own their own means of reproduction, as discussed in Chapter Zero. 259 work particularly useful in thinking about what the concept “knowledge commons” attempts to address. Although I find “knowledge commons” to be wholly misleading, the concept is attempting to grapple with something very important and meaningful. Following Althusser, the production process of the object of knowledge has its own order, in which: … thought is the historically constituted system of an apparatus of thought founded on and articulated to natural and social reality. It is defined by the system of real conditions which make it, if I dare use the phrase, a determinate mode of production of knowledges. As such, it is constituted by a structure which combines (’Verbindung’) the type of object (raw material) on which it labours, the theoretical means of production available (its theory, its method and its technique, experimental or otherwise) and the historical relations (both theoretical, ideological and social) in which it produces (Althusser 1970, 41). Thought works not on any “real object,” but on the object of knowledge, and that itself is a “raw material,” or, the object of knowledge, is not a “real object,” but is still a raw material, an object which will be transformed by the faculties of thought. There is then a difference between the raw material Galileo, Newton, and Einstein each worked on when thinking about physics; and that raw material is the “object of knowledge.” Thus: Far from being as essence opposed to the material work, the faculty of a ‛pure’ transcendental subject or ‛absolute consciousness’, i.e., the myth that idealism produces as a myth in which to recognize and establish itself, ‛thought’ is a peculiar real system, established on and articulated to the real work of a given historical society which maintains determinate relations with nature, a specific system, defined by the conditions of its existence and practice, i.e., by a peculiar structure, a determinate type of ‛combination’ (Verindung) between its peculiar raw material (the object of theoretical practice), its peculiar means of production and its relations with the other structures of society (Althusser 1970, 42). Althusser lays out ground upon which I desire any analysis of knowledge and work to stand upon—thought has a material basis, occurs in and is of the world and technologies 260 at hand, and is not opposed to other sorts of work. The distinctions between “object of knowledge,” “real object” and the like are worth sorting through because when the inevitable occurs, and the deployment of our faculties for thought become entwined in a labor process concerned with producing something other than more thoughts, it is important to understand the role of “knowledge work.” And not in the crude and wholly misleading sense in which “knowledge work” means any work that is “more mental than physical,” but figuring out what work actually has knowledge as its object, and what work also includes the deployment of faculties to transform other materials. For instance, there is an important difference between a member of the Canonical Sales Team who works with the existing raw material of knowledge and transforms it into new material designed to promote Ubuntu and a member of the Server Team who works with what might even be the very same computing device using what might appear to be the very same interface. In the case of the coder working on the Server Team, the interface is a means for interacting with the raw material of code and transforming this “real object,” which is then possibly populated into hundreds then thousands then millions of transformations around the world (as discussed in Chapter One: how code moves from archive, to mirror and is downloaded to all machines requiring an update). The member of the Sales Team works with the raw material of knowledge that might be stored in a digital object (text and images in a variety of mediums), and transforms that knowledge into a form that might be stored digitally or might otherwise become part of the raw material of knowledge available to future workers (told to a co-worker, presented at a conference, used to trouble-shoot a problem for a customer over the phone). The 261 Sales Team worker’s object of work is, for the most part, knowledge (even though it is frequently accessed and created in a digital format). The Server Team worker’s object of work is code, which as in the work of the member of the Sales Team, has the capacity to carry knowledge; yet code is not knowledge, but a sort of raw material. Althusser encourages us to go a little deeper than looking at these different practices by asking the question: … by what mechanism does the process of knowledge, which takes place entirely in thought, produce the cognitive appropriation of its real object, which exists outside thought in the real world? Or again, by what mechanism does the production of the object of knowledge produce the cognitive appropriation of the real object, which exists outside though in the real world (Althusser 1970, 56)? This base question of how we “make the world” through producing knowledge of the world is an especially apt one for software production—precisely because of how Althusser asks the question: what is the mechanism? 93 This is far more difficult and detail-oriented than it appears in this moment; it is intimately related to “the spirit” of capitalism, and as we shall see, the mode by which capital is able to develop a symbiotic relationship with the commons. The process of knowledge is thus much more than “the sharing of ideas” or “the creation of new knowledge.” How we understand the work of knowledge (i.e. is it material? If so, how?) has a tremendous impact on what relations we might consider as important when trying to understand something that appears before us as a “knowledge 93 Althusser objects to the idea that the answer to the question about mechanism is to look to “social practices,” for they do not actually reveal the mechanism. This search for the “mechanism” is not about locating “practices”—Althusser’s example is to say “So what!” to “the proof of the pudding is in the eating” for “We are interested in the mechanism that ensures that it is really is a pudding we are eating and not a poached baby elephant, though we think we are eating our daily pudding” (Althusser 1970, 57). There is the practice of police firing guns at people; and there is the mechanism by which people become police and it becomes acceptable to aim a deadly weapon at another human being and pull the trigger. Like Foucault, Althusser is interested in the mechanism. 262 commons.” What I am arguing is that in order to understand the particular dynamic of capitalism and the commons, we must re-evaluate the logic and assumption of the commonsense argument that “when I share an idea or image with you, my capacity to think with it is not lessened; on the contrary, our exchange of ideas and images increases my capacities” (Hardt and Negri 2009, 283). While this is a classic example of a positive network externalities (such as the example of in Chapter Two about the value of Microsoft Word) this is an absurd basis for arguing the “knowledge” commons are a different typology of the commons! Such sharing typically requires a computing device, time on a network connection, another computing device(s) somehow hosting Linux, some sort of medium to copy the code to (in the form of disposable plastic or multi-use metal and silicon), all of which assumes prior knowledge of how to use these technologies and must include the time and likely social interaction it takes to install, configure, learn and boot Linux—all the time consuming electricity and a portion of the lifetime of many different machines at multiple physical locations. 94 Hardt and Negri expand upon this misunderstanding of sharing by arguing that if I use a machine, no one can use it at the same time; but if I use an idea as part of productive activity to generate wealth, anyone can use it at the same time to also produce something useful and generate wealth. But wait, is there no idea in play during my use of a machine? And can I share an idea and create a use-value without the application of labor, such as that exerted through a machine such as a computing device, a mechanical pencil or the like (and in the case of computing device, the use of which, if it is connected 94 Another way of saying this is via a favorite nerdy joke of a friend and I that sharing a hamburger is far easier, consumes less resources and enriches social life far more than sharing Linux. 263 to the internet, is also the use of thousands of other machines)? This ridiculous parsing of a labor process into machine and ideas to draw the conclusion of a radical shift in how production and wealth generation occurs seems misguided and misplaced. While Commonwealth makes interesting provocations about capitalism and the commons, by never thinking through laboring (whether in the abstract or in the empirical, which is not Hardt and Negri’s project) their conclusions about the nature of commons have the potential of impoverishing our understanding of the material basis of commons, their externalities and the means of their reproduction—all of which are key in dealing with the problem at hand (of capital’s dominion of life). Hardt and Negri form a bit of a strawman here, but I use them because I believe they actually articulate commonsense ideas and assumptions about the nature of knowledge and commons; while at the same time they offer a key insight into capitalism’s dependence upon the commons. An analysis of capitalism and the commons must grapple with means and mechanisms by which ideas, widgets, labor, and capital all move. But such arguments about the nature of ideas and “knowledge commons” reach conclusions about the nature of the commons (its causes, capacities, and social relations) prior to the analysis of movement, blinding us to the world before us. Certainly the means of dispossession differ immensely from a grazing field to a shared code base, but this is not indicative of a different notion or form of the common. Furthermore, writing backwards from the means of dispossession to the actual composition of the common is a major misstep that enables all sorts of dire analytical consequences—to be a little dramatic. All of the above about knowledge commons can be encapsulated in a very 264 minor, but very significant change in word order—knowledge commons or digital commons makes no sense, but there are certainly commons of knowledge and commons of digital things. Canonical and Control, or, How the Wage Relation becomes Absurd When capital is dependent upon a commons, such as in Ubuntu and FLOSS generally, capital faces some tricky problems. Capital is not capable of defining, determining, and organizing labor processes that create and reproduce the commons. In many cases where capital is dependent upon commons, this is no problem. If the goal is dispossession, reproducing the commons is a non-issue for capitalism. If value is extracted by rent, capital has no real interest in the labor process that creates the common. For instance, ISPs extract value from things held in common by owning the means of accessing these things (infrastructure). The content and organization of the commons do not matter to ISPs, or other rent seekers; that is until such firms become invested in the creation of content. It is also not such an issue for capitalists trying to attach something that is ownable to the un-ownable content of commons. For instance, firms making surfing gear depend upon what seems like the “natural” and un-ownable common of the ocean and to they are happy to let that which makes surfable breaks do their work without intervention. At least until it becomes clear that the ocean is a commons also made by humans and surfing gear companies start to try to invest (as they do) in efforts to protect and clean oceans, allow public access, and save coral reefs that create breaks. Capitalists that seek to use the value of the commons to attract people’s attention, from advertisers to 265 publishers, have a bit more interest in attempting to control commons. For instance, a comic book publisher has an interest in controlling the commons’ diet to create growth that is closer to the publishers existing machinery for extracting surplus value. Such a firm might provide free web hosting, or perhaps even awards, for fan’s creative outputs (art, fan fiction, and other fan-made media) in order to direct the labor of such commonly held resources into a channel that allows the firm to continue to extract value by selling advertisement or the like. It is important to note that none of the above three examples are well described as either the commodification or the enclosure of the common. Which is not to say that there are not related and vast attempts to do both, but that to enclose or commodify is often not a sustainable model for the continued extraction of surplus value and firms are increasingly aware of this truth. Although such awareness means nothing when blinded by the myopia of quarterly profits or other structural elements of capitalism that lead capitalists to continually and unavoidably make decisions that are bad for the future, even capital’s relatively immediate future of extracting value. So what of Ubuntu, wherein unlike the examples above, capital is directly dependent upon a labor process that is dedicated to producing something that is held in common? How can Canonical control the labor process? Why not just pay all contributors to Ubuntu based on their contributions? Canonical is relatively well capitalized and has the technical means for doing so. The firm already has very sophisticated systems for tracking and measuring contributions, so why not put these metrics to work via a form of distributed payment? It is certainly technically and socially 266 possible to redistribute all of the monies Canonical pays in salary so that every person who makes a contribution to Ubuntu is compensated for their labor—and more so, it is possible in nearly every related case to do so. This appears as an obvious path to equity, or at least a much more just form of resource distribution—or at the very least, an improvement, from a strict equity viewpoint, of paying four hundred people very decent wages and leaving tens of thousands with no wage of any sort. And it might work, for a while. But changing the vector of gifts would erect boundaries and kill the social relations upon which FLOSS is built. FLOSS supporters, contributors, and managers are concerned, for good reason, with what happens when paid work is introduced into a labor process that relies upon volunteered labor (e.g. Mako Hill 2005). This is what Peters was concerned about in her talk and writings that drew upon Deci’s study of children and their magic marker drawing —how can FLOSS be funded without damaging FLOSS’s capacity to make things of value? Shuttleworth cites such work when explaining why he chose to fund Ubuntu in this particular manner (and not fund Debian): And finally, it seems to me that the hard part is not making funds available, it’s allocating them to people and projects. I could easily write a cheque to SPI, Inc, [a non-profit organization that handles donations to Debian and several other FLOSS projects] for the same amount that I’ve invested in Ubuntu. But who would decide how that money was spent? Have you actually read the financial statements of SPI, Inc, over the past few years? Who would decide who gets hired full time, and who doesn’t? Who would decide which projects get funded to be worked on, and which don’t? As much as I admire the governance and social structures of Debian, I don’t believe that it would be effective to allocate funds to it and expect to see the same level of productivity that we have been able to achieve in the Ubuntu project. Mixing funding with volunteer work raises all sorts of issues … there are deep social difficulties with projects that blend full time paid work with volunteer 267 efforts … You can very quickly get into deep conflict over who gets to allocate money and hire people, and who decides which ideas get funding and which don’t. One of the things that I believe gives Debian its real strength is the sense of "untaintedness". And to a certain extent, the fact that Ubuntu does NOT force changes into Debian has helped to reinforce that healthy reputation for Debian (Shuttleworth 2011). As laid out in the chapter above, paying everyone on a piece-work like or other basis would fundamentally alter the labor process in a way that would quite likely destroy the Ubuntu labor process’s capacity for fun, and in the process its capacity to make Ubuntu; just as introducing a structure of paid work would likely do the same to Debian. The importance of the relationship between Ubuntu/Canonical and Debian can not be understated. Many involved in Debian reacted very negatively to the founding of Ubuntu and Shuttleworth’s statements above are in part response to various criticism. From the perspective of a former Debian contributor, Ubuntu looked like trouble: In 2002 I started playing with Debian … and shortly after the first Ubuntu version came out and they modified my packages, they modified them! And that was a big bad “oooo, evil!” They modified them, they destroyed our work and just messed it up. And then I get all the bug reports because I was upstream! And so that made me very angry actually. So I didn’t like that! Only later I learned about how Ubuntu works, and in 2006 when I got my Launchpad account and looked at the bug reports that were reported to my packages. I didn’t know how bug fixing works in Ubuntu, I didn’t do much, but put some information in the bug reports about how things work, about how things are supposed to work. But I didn’t bother to actually fix anything because I didn’t know how. I was active in some mailing lists and posted some very long emails about how things worked and shortly after that I got a mail from one of my current co-workers and asked if I would like to work with Canonical. That was the reason I got hired. Thomas, a Canonical employee who works out of his home in Taiwan, was excited to get a job with Canonical, and when hired, looked forward to working for a company that “got open source” and would enable him to work on what he cared about. Shuttleworth’s arguments about keeping Debian “pure” has a material basis, as Ubuntu is a derivative of 268 Debian and keeping Debian “pure” means keeping Debian’s labor process working in a manner that allows Debian to produce the code from which Ubuntu is built. Shuttleworth still frequents DebConf, the Debian Project’s developers conference, and many of his talks there and elsewhere are designed to explain how Ubuntu works, to allay Debian contributors fears about Ubuntu messing up their packages and creating a flow of bug reports and broken packages that makes their work harder. For instance, leading up to a regular Ubuntu release (one of the six month releases, not the long-term supported release that is designed with enterprise users in mind), Shuttleworth explained that he is concerned with exactly this issues promised not to mandate any features in Ubuntu and provided a short list of “cool shit coming down the pipeline.” This promise not to mandate is a practical as well as ethical statement. Joel, a member of the Support Team who works out the Montreal office, explains how he experiences the tension between the community and Canonical (or as he calls it, between the public and private) sides of providing support for Ubuntu: There were some official objectives where I was supposed to go onto the Ubuntu forums and learn in that way and respond to people’s questions and my Karma was supposed to increase. These things were mentioned [at six month performance reviews], but not really enforced. This is one of [the support manager’s] strong approaches. We can not pretend that we can do our jobs well under the private paradigm where there are clear lines of communications and clearly defined duties, like where I could call someone in the Kernel Team and they would take care of a problem. Instead we have to learn the tools and learn how developers think and how they work. And how to communicate with them. If you don’t speak their language, it’s not going to work. Again, these are open source people who happen to be employed by this company [Canonical]. We can not force them to do something just by saying “hey we are the Support Team and we have these customers,” it just does not work (Joel’s emphasis). 269 Thus Shuttleworth hedged on Ubuntu delivering on the “cool shit” above because “I can’t guarantee anything because this is dependent upon a developer really wanting it” (Ubuntu Founder Mark Shuttleworth in a Q & A session 2006). Canonical cannot directly control how Ubuntu is built for two immediate reasons: 1) Canonical simply does not employ enough coders to develop software unless the Ubuntu community is also interested in testing, supporting and in the long term, maintaining the code (even if Canonical did employ enough coders, with FLOSS licenses and without private property, controlling the code remains impossible); 95 and 2) paying a FLOSS contributor does not allow capital to control all labor exerted on a given project— many Canonical employees work on other Ubuntu commitments not prioritized by Canonical management. Thomas, who at the time I spoke to him was considered leaving Canonical, unsurprisingly reacted differently than most other interviewees to my the final question I asked every interviewee, “what’s the most fun thing about working with Ubuntu?” The most fun thing about my job? That is difficult. Because you have to deal with some many parts that you do not have much fun in your work. (Me:) Two years ago would have you answered differently? Well, the more you get to know how things work internally at a company, you get more disappointed. In the beginning, it’s a lot of fun, you get to do your stuff. And in the beginning I was able to do my stuff and it was fun! But then management changed and they tell me to do this and this, and I say ‛Hey, that’s not my stuff, I can not do this!” Why am I supposed to this? That is not fun anymore. 95 As will be discussed below, there are significant exceptions, such as Ubuntu One, a free data hosting service that relies upon proprietary code that was critiqued strongly by the Ubuntu community upon release by Canonical. Also, many of the features and development of the Ubuntu Server Edition are driven almost entirely by Canonical management. 270 What an Ubuntu contributor finds fun, both in terms of a way of working and in terms of the actual task at hand does not disappear in the process of selling one’s labor power. However, tetting paid to work often means taking on the un-fun tasks in the labor process, and the forced repetition of un-fun or destructive work on an object of labor that is fun can kill the fun that once was, or worse, cause burnout, which was something Thomas feared he was approaching. Following Marx’s discussion of the development of the “general intellect,” the socialization of workers engaged in production that requires cooperative labor tends to make “both private ownership and payment for isolated quanta of work-time appear increasingly as irrelevant impediments to the full use of social resources” (Dyer- Witheford 1999, 220). Many FLOSS contributors consider the gift of their time and labor a gift to FLOSS (or to the world, or to all computer users), not to a single project, not to a firm that might happen to employ them. This makes wage-labor feel out of place and non-sensible in FLOSS labor processes; or, in other words, wage-labor does not make sense in FLOSS ideologies of work. Thus, although the wage relation finds its way into the Ubuntu labor process, it is in ongoing negotiation with the commons through the bodily work and commitments of Ubuntu contributors, rather than as the primary means to control what product is produced and how. Selling one’s labor power and accepting a wage is usually what allows workers access to the means of production. But in FLOSS, workers already have access to the means of production—but do not own the means— and there is no way to lock workers out. A worker could get fired or quit Canonical and keep on coming to work in very close to the same capacity as before—such as Scott 271 James Remnant, one of the original employees of Canonical (before it was Canonical), who left for a job a Google and retained his core dev membership and seat on the Ubuntu Technical Board (Remnant 2011). 96 In this context, the “Ubuntu mode of production” makes Negri’s somewhat ridiculous sounding declaration that “communication is to the socialised worker what the wage relationship was to the mass worker” start to bear the ring of truth (Negri 1989, 118). For communication does not replace pay, but communication is what Canonical must provide in order to ensure workers’ ongoing participation in the Ubuntu community: the capacity to make and engage with a global communication network is a fundamental means by which Ubuntu workers reproduce themselves as the Ubuntu community. In this sense—the sense that networked digital communication is a prerequisite to the life of the Ubuntu community—the provision of the means for communication by Canonical for any and all who want to contribute to making Ubuntu must be seen as capital seeking, struggling, and often failing to determine, but not control, the means and form of this life. For Shuttleworth and Canonical management well know from failed FLOSS “communities” sponsored by firms, too much control could and has stifled FLOSS development, just as the lack of infrastructure and means for meaningful communication can contribute to a community of dedicated FLOSS contributors falling apart. Hidden in this somewhat obvious truth about the role of communication in FLOSS communities is a key, but often missed point—FLOSS workers do not simply populate existing communications infrastructures and networks with the particulars of 96 The Ubuntu Technical Board sets the “technical direction” for Ubuntu. This means making decisions about features, about which architectures and standards to adopt and support, and about more mundane (yet incredibly contentious) decision such as which music player to include by default. 272 their communication’s content, rhythms and social norms; FLOSS workers make, but again, do not own or control, the very networks upon which they depend. This creation occurs on at least three levels in the Ubuntu labor process. There is the creation of software tools (mailing lists, IRC channels, all are built on FLOSS and new channels are constantly emerging). Second, the creation of social norms and governance, codified in both formal codes of conduct and in frequent critiques, arguments and discussions (both online and at in-person meetings at FLOSS conferences, in the conference room and at the bar) about what constitutes appropriate norms of communication. And third, the provision of communication infrastructure—the common practice of building servers using old hardware and FLOSS software, the appropriation of state or corporate controlled infrastructure by FLOSS workers who hold key positions (for instance, the friend of Torvalds mentioned in Chapter Zero who provided the server space and bandwidth to host the first Linux repositories), as well as the investment of community resources in new network infrastructure. Canonical engages heavily in all three forms of communication provision and creation. Canonical has created software tools such Launchpad, which along with IRC, mailing lists, and the Ubuntu forums, are the central means of communication in Ubuntu. From the beginning, the creation of social norms and governance have been a key topic of debate, leading to the creation of the Code of Conduct as the guiding document for the Ubuntu community. One of its primary purposes was and is to create a FLOSS community that was more welcoming, which has nearly universally been declared a success—not that the Ubuntu community is without its problems, barriers to non- 273 technical people, and disputes over what sort of behavior is appropriate and/or discriminatory, but there is a general agreement that things are a bit better in the Ubuntu community than many other FLOSS communities. For instance, the Code of Conduct has been a conduit for talking about sexism in FLOSS: (04:33:10 PM) nixternal: QUESTION: you know something...I have been in this goofy free software world now since about 1993/1994...and it wasn’t until Ubuntu that I really saw a problem and witnessed on more than one occasion an issue, do you think that is because Ubuntu has become so huge that we are seeing the issues and that there is a need for the Ubuntu Women team? (04:39:37 PM) lamalex: nixternal: it may also be that the ubuntu code of conduct has acted as a consciousness raiser for you and made you more aware of sexism in foss (from the chat-channel for an hour long session on Ubuntu Women, during Ubuntu Open Week, 2008) Chats such as the above are enabled by Canonical providing support for the Peer-Directed Projects Center (PDPC), a donation-funded firm that runs the freenode network of servers, on which all Ubuntu-related IRC channels are hosted. Canonical is a “Diamond Sponsor” of the PDPC, having donated €1700 to support its operations, and Ubuntu is one of organizations thanked on freenode’s acknowledgment page (see Figure 8). 274 Aside from supporting organizations such as PDPC, owning and renting servers to host Canonical websites and Canonical developed software, Canonical employees also do much of the work of finding and keeping mirrors up and making sure there is the infrastructure in place for all of the above forms of communication. The wage relation becomes an absurd relation to impose upon the totality of Ubuntu labor process and to attempt to impose either the wage relation or private property in the Ubuntu labor process would destroy its capacity to produce Ubuntu by 275 Figure 8: Freenode Acknowledgments for Groups that have not given Direct Financial support, but “Provided Significant Resources.” destroying the relations brought into being by gift exchange. Thus, in Ubuntu the wage relation cannot be the primary mechanism through which exploitation is integrated into the whole of people’s lives. Knowing this, capital must seek to displace these relations into another form in order to both extract value and exert some control of the locus of the labor process. To be clear, I am discussing exploitation in a value-neutral sense—Ubuntu contributors are not dupes for giving their labor to firms, many to most contributors have very nuanced theories of what ends their labor may serve. Unpaid Ubuntu contributors give their labor for any number of reasons, and that labor exists as gift, even if it may end up being a gift to capital. Through communication provision and the vestiges of the wage relation, Canonical management attempts to steer the vectors of Ubuntu development in an uneasy negotiation with the community, and in turn, the commons. In a nutshell, commons have been around for a long time (as Cesare Casarino is fond of saying “commons are legion” (Casarino and Negri 2008)); then with the help of the state, an emerging capitalism sought the destruction of the commons in order to continue the march of capitalist relations into more aspects of more people’s economic lives (from agricultural enclosure in Eighteenth-Century England, Thompson 1970; to the enclosure of academic commons, Bollier 2002); through times of crisis and in the very same moments that commons start to develop and produce goods via networked social 276 organization, capital seeks not to destroy the commons, 97 but to form new symbiotic relationships with the commons and forms of life made possible by the commons. Symbiosis is important here (amongst flawed biological metaphors). Although certainly capital is often best described as and sometimes is a parasite of the commons, in order to develop longer-term relationships in accordance with capital’s favorite pipe dream of increasing rates of return, symbiosis is crucial. Capital actively seeks roles that make emerging or already existing commons dependent upon capital—as capital’s ideologues are fond of reminding us, all sorts of commons, including FLOSS commons, could not exist without capitalism. Which, of course, is precisely the point. Many of today’s commons are certainly built with the tools and means developed by capital’s particular allocations of surplus. This is how, we must dream, capital sows the seeds of its destruction. Alternatives to capitalism are created within capitalism with desires and needs that are before, beyond, and after capitalism. It is very easy to argue that there could be no Ubuntu without capitalism. However, Ubuntu’s progenitor, Debian, managed to exist in relative obscurity in another sort of space carved out of capitalism. However, I find it far more interesting to ask whether or not capitalism could be without Ubuntu—to think about how capital has reeled in and attempted to direct this particular FLOSS project. Capital seeks symbiosis with an entity (a mode of production) that can provide capital with the life force to 97 Although certainly there are attempts to destroy the forms of commons and a vibrant academic literature defending the commons. Capital is far from some unified force acting with singular intent—although I may have erred toward that portrayal in this dissertation—there are capitalists who would like nothing more than the utter destruction of the commons. Taken as a summation of choices made by capitalists, capital has moved in a manner that indicates its dependence upon the commons, whether or not the mouthpieces of capitalism would say so. There is certainly an interesting research project here about how commons enter into capitalist discourse—for instance, via buzz words such as “crowdsourcing” or “public-private partnerships.” 277 enliven its own being (another mode of production). The symbiosis between capitalism and the commons is the central dynamic of the Ubuntu labor process, a dynamic that seems to be central in more and more labor processes, from academic research to public- private partnerships, from urban redevelopment 98 to media production. The particular Ubuntu version of the general and crude history of commons above is already explained above, without being called such. In short form, a vibrant commons of code existed prior to Ubuntu (FLOSS in general, the Debian project and GNU/Linux in particular). Enter a capitalist with the desire to bring something very useful into the world: 99 a version of Linux that is user-friendly and predictably updated—goals which require a large, vibrant collaborative community of developers/advocates/testers/users. Private property and the wage relation are an absurd basis for such a community, but the provision of communication and a demonstrated commitment to creating a fun and open 98 Such as in the case of recent hype about Omaha, built on the “value-added” from a group of musicians, a record label, some restaurateurs, and capital from a lot of speculators who believe that the value from this “cultural hub” will translate to making Omaha a good place to invest in real estate and infrastructural development. See booster news such as Wired magazine’s “Small Cities Feed the Knowledge Economy” www.wired.com/magazine/2011/05/ff_jobsblockbyblock/, or the academic version “How a Music Scene Functioned as a Tool for Urban Redevelopment: A Case Study of Omaha’s Slowdown Project” (Seman 2011). 99 Whether or not such an entity (a capitalist) has this broadly human and decent desire becomes a moot point under capitalist social relations—it is not that capitalism overshadows or destroys this desire, it is that capitalism requires certain relations to achieve the desire to bring such a product into the world. Marx writes: “The product – the property of the capitalist – is a use-value, as yarn, for example, or boots. But although boots are, to some extent, the basis of social progress, and our capitalist is decidedly in favour of progress, he does not manufacture boots for their own sake” (Marx 1993, 293). This passage can nearly bring me to tears for not making boots for their own sake is so sad! I believe that nearly every Ubuntu coder, Shuttleworth included, makes Ubuntu for its own sake. But a capitalist, the embodied form of capital relations, can never make boots for their own sake; workers making boots can never control when and how they make boots, making it impossible to make boots for their own sake. This is indicative of the injuries and injustices that capitalism does to all, including capitalists. Nonetheless, Ubuntu is one of many cases in which production is organized so that a good can be made for its own sake, and the contradictions of such a system existing within capitalism cannot be understood as a zero-sum game. That is, as the contradictions are acted out through people’s desires, bodies and work, and people have multiple simultaneous economic relationships—capitalist, hacker, worker, enthusiast, manager, maker, and other relations (I do not have ready names apt to describe the multiplicity of relations possible in working with FLOSS). 278 community and working to deliver on the promises of FLOSS to make the world better might be a basis for such a community. In an ongoing negotiation between capital and the commons built by Ubuntu (which also existed prior to Ubuntu) private property and the wage relation do not disappear, but are both displaced from and essential to the Ubuntu labor process. According to Dyer-Witheford this displacement happens for two reasons: 1) as advances in machinery and organization reduce the requirement for direct labor in production, the need for people to sell their labor power—the very basis of capitalism’s social order—is systematically eroded. 2) the increased social nature of activity required for technoscientific development, which unfolds not on the basis of individual effort but as a vast cooperative endeavor. As this becomes more and more apparent, highlighted by the diffusion and integration of communication and transport networks, both private ownership and payment for isolated quanta of work-time appear increasingly as irrelevant impediments to the full use of social resources (Dyer-Witheford 1999, 220). I do not think the first point is as significant as it sounds—the directness of labor is not the grounds upon which people are exploited or forced to sell their labor power and this directness does not so much reduce but redistribute capital’s need for labor. That is, the belief in technological developments liberating workers from being forced to sell their labor power is without precedence, even though every tool that reduces the social necessary labor power to make a widget heightens contradictions. However, the second point is a different story. The social life of contributing to Ubuntu; the manner in which being an Ubuntu contributor is part of fun, play, recreation, work, learning, friendship, politics—in short, life—means paying an Ubuntu contributor for an hour of work makes little sense. Piece work (paying workers for each “piece” of a widget or widget they make, instead of an hourly wage or salary) makes as little sense—it is unclear what the 279 pieces might be. There could be payment for solving particular problems or implementing particular features, but such work is a tiny piece of the social life of being a part of Ubuntu. Private ownership is already irrelevant in FLOSS, but its occasional imposition into the Ubuntu world—such as with Canonical’s few proprietary projects or a firm using Ubuntu and not giving back (i.e. not releasing its improvements back to the FLOSS ecosystem) consistently evokes fervent discussion. This discussion is also a way that folk in the Ubuntu community retell their goals and reforge relationships that are about working differently than proprietary software development. Private property is not foreign to the commons, but yet it must be engaged in a particular manner for capital to negotiate a foothold in FLOSS labor processes. Capital needs to make sure that some of what is created by the Ubuntu labor process can become an excludable commodity. The obvious examples are that some of the software created by Canonical is proprietary and that the paid support provided by Canonical employees is tenuously excludable—both the software and support are made for the market and made such that an entity must pay to access the good or, in the rare case, service. Support, although usually considered as service, is not always so. Support and solutions provided by Canonical employees generates goods that become public and several Canonical employees have cited the quality of “free support” available as causing Canonical to sell much less support than the firm hoped. A solution is no longer strictly excludable when someone writes down in a wiki and is even less so when a community member will respond in real time in an IRC channel or within hours on a forum and personally walk an entity needing a useful thing (support) through a solution. Nonetheless, as both 280 government organizations and private firms often have contractual requirements to have support contracts for the software and hardware they use (often private and confidential) creates opportunities for the imposition of private property into the Ubuntu ecosystem, in that some of the code, documentation and support provided by Canonical becomes private property of the entity owning the service contract. The terms of this symbiosis are wrought through a negotiation of the absurdity of the wage relation and private property (Hardt and Negri 2009; Nick Dyer-Witheford 1999). Hardt and Negri argue that because “economic production is going through a period of transition in which increasingly the results of capitalist production are social relations and forms of life,” what we really need to do is “investigate the ‛technical composition’ of capital or, really, the technical composition of labor to ascertain who produces, what they produce and how they produce in today’s global economy” (Hardt and Negri 2009, 131). This is definitely one type of scholarship required to understand how capitalism works at this moment: Where is the wage relation and private property eroded? How do labor processes then function through and around the capitalist mode of production? What does this mean for people’s relationships to working and the possible forms of social life? This relationship between capitalism and the commons is fundamental and as old as capitalism—for as Hardt points out, one of Marx’s key discoveries is that capitalism depends upon labor power, not labor. Labor power can only and always be held in common. The development of language, skills, practices—what Marx called the “general intellect”—can only be held in common and must be common to all potential laborers in order to create the labor power that capitalism requires. 281 Immaterial is Poor Word Choice for Something so Full of Matter Whilst it may be simple to make a theoretical distinction between immaterial and material labor, it is not easy in everyday life. In practice, the two are actually closely intertwined. Immaterial labor … often needs supports (tools, technologies) as a vehicle, well-grounded in the material. It needs to be performed in concrete contexts. But, above all, immaterial labor very often sets material labor in motion. Showing one’s affection for a person means possibly setting off on a journey, buying a present or preparing dinner, it means following an immaterial expression with concrete acts. (Lorente 2004, in Fortunati 2007, 140) As hinted at in Chapter One, immaterial labor might be very useful for talking about the elusive qualities of work. In the process of working on this project, many ideas used to explain something new and particular about capitalism since, say the mid- nineteen seventies that I once though were opposing ideas—the rise of the service sector, biopolitical production, the creative sector, cultural production, the knowledge economy, immaterial labor, and more—started to seem very similar to each other. I do not know if this is because scholars are just coming to terms with an old truth about production—that it also produces workers and many complex social labor processes require the labor of a whole society to be sustained. Or is it because there is something fundamentally different about the way capitalist production is proceeding, something beyond its ever changing, expanding nature? I have no answer and am not sure if this is the right question, but of all of these related concepts, I have found immaterial labor a fraught, but useful concept 282 to think with, as it has its origins in seeking connections between disparate and obscured parts of processes for producing things. The Ubuntu labor process produces not only code, but also emotional states, relationships and forms of living—all of these are essential to the reproduction of Ubuntu contributors and are part of creating the need and desire for Ubuntu and FLOSS generally. These latter products of the Ubuntu labor process, although they have material form (as an emotional state does) can be described as immaterial products—products that, although material is almost every sense, cannot be readily stored, accumulated, or exchanged. Such products are also intertwined with material-substantial goods and infrastructure. Attention can be sold, emotional states can be channeled by advertising campaigns and management techniques (often unsuccessfully), such immaterial products can be used in these ways and others by capital in an attempt to increase the aggregate demand for all sorts of related material goods—from gear sold at the Ubuntu store to Ubuntu One 100 to a laptop with Ubuntu pre-installed. Furthermore, such immaterial production almost always relies upon and sets in motion, as Sylvie Lorente indicates above, all sorts of material processes. In the case of the Ubuntu labor process, fun sets in motion all kinds of work and in the moment of work, it is impossible to separate out some labor as producing immaterial results and others producing material results. Take a moment where it might be possible to say “that labor is producing immaterial products and thus can be called immaterial labor,” such as, say, an experienced Ubuntu Core Developer mentoring, supporting, and encouraging a 100 Ubuntu One is a free “personal cloud” service similar to Dropbox and other services that provide online storage and access to files via client applications installed on computing devices (from phones to home PCs) as well as via a web-based client. Ubuntu One uses proprietary server-side software and monetizes “the cloud” with monthy fees for more storage and/or more features. 283 new contributor. Even in this moment, such work is intertwined with the material world of Ubuntu in that it relies upon the wires, cables, fiber, machines, electricity and the like that form the communication infrastructure that enables such mentoring. The production of Ubuntu and the reproduction of Ubuntu workers are intertwined with support, friendship, and all sorts affective relationships are founded within the Ubuntu community. Thirty years ago Leopoldina Fortunati made clear that capitalist production relies upon a particular set of social relations to manage relationships between production and reproduction—the heterosexual nuclear family unit. These relations have functioned to obscure a great deal of the labor that is appropriated by capital in any given labor process. Fortunati puts forth an argument, echoed years later by Hardt and Negri, following Foucault, as “biopolitical production,” and in other scholarship, that “cooperation and self-management seem to be capitalism’s response to both struggles in the family and in the factory” and that “for capital, control over labor necessarily became control over the composition of the class, and that class struggle is also the struggle against the class composition that capital imposes” (Fortunati 1995, 142, 167; see also, Weeks 2007). Hardt and Negri err on the side of imagining biopolitical production as existing at the center of all production by arguing that it “shifts the economic center of gravity from the production of material commodities to that of social relations, confusing, as we said, the division between production and reproduction” (Hardt and Negri 2009, 135). However, considering the myriad of ways in which people’s lives are entangled with capitalist production it is essential to deal with the uneven and contentious integration of 284 production and reproduction 101 in any attempt to comprehend global networks of producing, moving and consuming goods. Immaterial labor is most commonly cited as emerging out of autonomist Marxism, popularized by Hardt and Negri’s use of Maurizio Lazzarato’s work, and is defined as labor that “creates immaterial production, such as knowledge, information, communication, a relationship, or an emotional response” (Hardt and Negri 2004, 108). Autonomist Marxism, as Dyer-Witheford explains, includes the influence of Rosa Luxemburg, Geog Lukaca, Antonio Gramsci, C.L.R. James, and E.P. Thomson and others who investigate how the working class is constituted through struggle—which is often a struggle for the common (Cleaver 2000, 13). Dyer-Witherford defines autonomist Marxists as those who focus on “on agency, on struggle, on self-organization and in their repudiation of authoritarian state socialism,” and thus this particular form of analysis and practice can be a guide to “confronting computerized capitalism with an alternative vision of community and communication” (Nick Dyer-Witheford 1999, 63, 65). Yet, Hardt and Negri’s definition of immaterial production is both too broad and misleading. The last two things in Hardt and Negri’s list, emotional responses and relationships, might be well described as immaterial (or perhaps affective), but the others are by no means necessarily immaterial, although they may be put in motion by immaterial production. Fortunati’s definition of immaterial production is based in struggling to integrate domestic and reproductive labor with an analysis of capitalist production, in which domestic labor is synonymous with immaterial reproductive labor. In telling an 101 Of course differential consumption and its social and reproductive life is often how this unevenness manifests; however, for this project I have chosen not to engage directly with the consumption and use of Ubuntu and other software. 285 alternative intellectual history of immaterial labor, Fortunati goes beyond the usual story that it emerged out of autonomist Marxism (Fortunati 2007). Fortunati follows Marx’s definition of immaterial production, which can produce either material goods (books, pictures, etc.) or can result in the production of something which is not separable from the act of production itself (such as with the work of actors, doctors, priests, etc.) (Fortunati 1995, 139). It is the latter sort of labor, performed in the domestic sphere (care, support, sex, affection, etc.) that reproduces labor power and enables both capital and state to externalize the cost of reproduction to household labor, passing this cost and risk on to the women performing this labor. Even in the realm of production, immaterial production is old; often seen as a concept and an empirical reality that emerged in the 1970s as a key part of capitalism, as Fortunati points out, in 1902 Werner Sombart discussed the emerging love of one’s own work and other elements of immaterial production (Sombart 1902, 27; in Fortunati 2007, 520–1). Popular definitions of immaterial are enough to make some Marxist scholars call for abandoning the term, as what is claimed to be at the heart of an epochal transformation—that in immaterial labor, biopolitical production, affective work or related arguments production also produces life—is as old as work itself (Camfield 2007). To claim this as the basis for a new category of labor or a new type of production thus seems a bit far-fetched, even if there are very significant changes taking place. Immaterial labor is a confusing concept, even in Fortunati’s more precise, grounded definition, in part because it is deployed as a general category, grouping together too many incommensurate types of work. 286 Yet there is something here, something to what is the concept is trying to describe. In an article seeking to link autonomist Marxist scholarship with empirical research on the “cultural work,” Rosalind Gill and Andy Pratt argue that: Notions include creative labour, network labour, cognitive labour, affective labour and immaterial labour. While such terms are not reducible to each other, their very proliferation points to the significance of contemporary transformations and signals—at the very least—that something is going on (Gill and Pratt 2008). Out of these terms, immaterial and affective both get at something interesting and important. Affective labor, the work of producing bodily emotional states, might be a better term as hinted at above—and such work, making sure customers/bosses/co- workers are in some way satisfied might be said to be part of many different labor processes. But, “if all work has affective dimensions then what does it mean to say that any particular job involves affective labor?” (Gill and Pratt 2008, 15). This questioning is dead on, for most all work does have an affective dimension. However, the issue lies not in the concept, but the idea that it can be applied to types of jobs that involve affective labor in order to understand the nature of that work. 102 102 Nor do I think that picking a term or coming up with a new one would solve any of these issues. Doing this research has often made me feel like a very foolish conservative curmudgeon who just wants research about “how it works.” I know such work is no good without analysis—some guide to action. Yet I want to believe that how it works is not only a first step in a guide to action, but that in work and the making of things there is already a guide to action; that there is already some path to a different way of making things in how we do what we do that is foiled, blocked, and/or perverted by capitalism. This path does not proceed naturally or without organization, breaking something, or the like. I just want to believe that it is there already, and in Ubuntu sometimes I think I see something. But then again, of course I think this, as these two quotes have stared at me, taped to my computer monitor for the last two years: The reform of consciousness consists only in making the world aware of its own consciousness, in awakening it out of its dream about itself, in explaining to it the meaning of its own action … it will then become evident that the world has long dreamed of possessing something which it has only be conscious in order to possess in reality … this is a work for the world and for us. It can only be the work of united forces. It is a matter of a confession and nothing more (Marx 1843). 287 One of the most important things I learned from talking to people in Ubuntu about their work is that categorizing labor by the assumed qualities of its output, by some typology of what is produced, is most often a mistake. It seems like a sensible enough thing to do (and is all too easy to do) but “immaterial labor” makes about as much sense as “material labor” or “creative labor” as a category for understanding conditions of work or labor processes. This is different than saying “care labor,” “digital labor,” or “metal labor;” such categories refer to the object of work, and there are jobs and labor that needs doing that requires working on care, digital things, and metal. In the moment of production it is unknown what such labor may end up creating; it is an open question if what is produced by any labor will meet anyone’s needs. This is cause for concern for any economic planner, factory owner, or anyone who has produced something with the hopes of meeting someone else’s needs besides their own. However, calling work creative or affective is a bit trickier—no object of labor is essentially creative, no one’s labor is certain to produce affective outcomes, much less the sort of affective relations any worker, manager, or capitalist intends. These fraught categories—immaterial, creative, affective, knowledge—do tell us something about ideologies of work or the spirit of capitalism. There is something incredibly important about the production of the immaterial and affective. It gets awkward, trying not to use “immaterial labor,” and instead talk about immaterial production or immaterial products, but I am convinced that it is worth it to keep the focus on the circulation and to cast out “immaterial labor” but keep the immaterial. The irony of this deployment is having us believe that our “liberation” is in the balance (Foucault 1990b). 288 One of the key reasons for holding onto the concepts of immaterial and affective is that capital has a tendency towards the “exporting of the logic and structure of the domestic sphere to the world of goods, which always ends up resembling and being assimilated to the reproductive world” (Fortunati 2007, 148). Ubuntu is like this, as are many labor processes in which people talk about their work being “like family,” wherein we “take care of each other” or the like. Whether known by immaterial, affective, or some other term, there are three essential processes at work here that make such production important. First, there is a great deal of work involved in reproducing anyone’s capacity to work and this labor of reproduction, most often performed by women, most often performed within the auspices of the hetero-patriachal family, has been and is essential to the production of surplus value. Capital has long relied upon the theft of this labor, and, as Fortunanti argues, the exportation of the structures and logic of this work (meaning it becomes the basis for forms of management and organization) means shifts in how this theft occurs. Second, although much affective or immaterial production occurs within the domestic sphere, more and more labor processes are dependent upon this labor occurring within the production process. This is essential to workers’ capacity to work long hours and to tying the meeting of the needs filled by immaterial and affective labor to commodities and/or branding and advertising streams. Third, the aggregate demand for products that capital must create to stave off crisis of overproduction are also increasingly dependent upon the immaterial and affective production to create capital’s dream of subsuming more and more of social life. 289 Yet such subsumption does not proceed according to capital or any other entity’s dream. Capital can call work creative when it is useful for getting overtime exemptions; EA workers will say it is not and sue for their overtime. Capital can tell workers they are part of a team; Target employees will laugh. A union might organize a strike; nurses will hesitate leaving the people they take care of. Anyone who has worked “customer service” can tell you that the work of producing affect is fraught; there are people you care about, bosses you do not care about (or do) and a slew of relationships that are part of life that make a strict boundary between being worker and not-worker difficult. All of this has been true for some time. People take pride in their work and develop meaningful relationships that exceed any description of “affective labor” or “immaterial labor,” but this is precisely what makes these concepts worth struggling through—they seek to capture essential aspects of how economies and production work that are easily lost. Any attempt to produce a meaningful human relationship is always a gamble, and always produces life beyond anyone’s capacity to plan or measure. There is just no knowing what such labor might produce. For instance, what line of code, what design, what conversation, what news story, what is it that makes someone using Ubuntu feel like Ubuntu can change the world? This question is certainly theoretically answerable, but what is most important is that it is only answerable after the fact of use, after someone encounters some aspect of Ubuntu and it convinces them that Ubuntu can change the world. Anyone who provides what might be termed “affective labor” can tell you this—it is trial and error to try to produce something that makes a baby stop crying, a child learn, a friend be comforted, a neighbor be cared for when sick. You might try to provide labor 290 with the intention of creating these ends, but how people react, what affect your labor might have is not determined by your intention, only by later use. This is of course just part of life, something we learn from, but such risk is different when capital gambles on such labor. And capitalists do their best to measure these affects and try to reproduce them in order to create a desired result. Canonical does this with bugs, very intensely. Other firms do it with advertising, sponsorships, charitable donations, prizes in the workplace, any number of other gambles to try to produce a desired outcome that either improves efficiency of production or increases aggregate demand. But it is always a gamble. And the labor involved in this gamble must be understood as part of a large system of producing a widget—we cannot take the terms of capital’s strategies for separating aspects of a labor process as if they extend from the nature of the labor or the object of labor. Instead we must seek the connections, we must see work for what it is— even and especially as capital’s capacity for abstraction abounds. This is my challenge for the next section, to seek connection through a spatial fix, to see how dead labor can move between modes of production. II. A Spatial Fix, or, Devaluing Capital with Dreams of More Surplus David Harvey’s concept of spatial fix is broadly useful for qualifying changes in the form of capitalism, or, as Erica Schoenberger points out, “it was far richer and, importantly, more flexible than notions such as the new international division of labor” (Schoenberger 2004, 428). This general richness, coupled with some specificity, makes the concept good to think with, and in a long moment of being buried in ethnographic 291 detail, trying to figure out how to organize this dissertation, it provided the help I needed to locate the larger context of this particular and interesting negotiation between capitalism and the commons in Ubuntu. Capital’s need for an ever-changing geography to keep alive the hope of displacing crisis had been on my mind, but Harvey’s The Limits to Capital was useful for remembering that “ever-changing” must be understood as non- linear, and that a spatial fix is not just about “expansion,” but about all sorts of surprising, mundane, counter-intuitive, violent, and stupid-seeming means of putting non-moving capital back into some form of motion and fixing it into the environment some place, from building bridges to fighting wars to research and development. Regions have provided the spatial fix for many “post-industrial” production crises: regions which compete for capital’s attention and do so in the hopes that capital with will stick in the region. The software industry has already seen movement of “back offices,” various waves of outsourcing, and the rise and fall of clusters of software firms (Howland 1993; Breathnach 2000; Leamer and Storper 2001; Pratt 2000, 2002; Indergaard 2004; Perrons 2004; Johns 2006; Muthyala 2008). These spatial fixes are not as simple as established software firms seeking cheaper labor, from center to periphery, as Yu Zhou et al expose in their analysis of the information and communications technology industry in southern China: “multiple rounds of ‘spatial fix’ are going on at once, each compelled by different interests and principally anchored at a different locality” (Zhou et al 2011, 120). This recognition of multiple capitals operating simultaneously makes clear that a spatial fix is not enacted by capital alone or in isolation. The state plays fundamental roles in determining spatial fixes, and labor is always part of bringing a spatial fix into reality, 292 and it is important to think of labor as meaning much more than labor unions and movements, but rather worker’s whole lives, their collective and contradictory interes, and various, perhaps not easily recognized, forms of class consciousness (Herod 1997; Cumbers and Nativel 2008). Spatial fixes are complicated. There are many interests simultaneously at work, different sorts of capital in motion, a variety of interests of laborers, and a whole lot of things of value moving. Such fixes falter, fail, stutter, and uneasily come into being. In the case of Ubuntu, there is some simplification, as Canonical is the primary capitalist entity at hand—but Canonical does not exist in isolation. Things get far more complicated when the Ubuntu mode of production has to interact with capitalist production. For instance, at both the Corporate Services office in Montreal and the hardware integration Office in Taipei, Canonical employees become the human interface between modes of production and their different spatial practices, temporal relations, and cultures of work. Working with computer component manufactures in Taiwan and southern China, Canonical workers enable things of value made in the Ubuntu labor process to interface with capitalist production. Working with a wide variety of hardware configurations and a large “testing” lab, Canonical workers in Montreal enable firms to exploit the labor of the Ubuntu community. At the point of interface between modes of production all sorts of things of value made by all sorts of Ubuntu contributors (and Linux contributors and contributors to upstream projects) are put to work for capital. Code moves and is transformed, is installed and tested, and every once and awhile shipped pre-installed on a computing device, perhaps then supported by Canonical. 293 Tracing the movement of value, of any given piece of code, through all the people who have worked on that code, through all of its transformations and movements, in and out of the FLOSS ecosystem, becomes quite a mess. Arguments about the impossibility of measuring and tracing such labor start to make sense. It becomes tempting to believe that now exploitability is “beyond measure” (Hardt and Negri 2000, 356). However, such measuring is not only possible, its quantitative and qualitative forms are essential to help us move from sweeping characterizations of economic and social change to meaningful analysis of what has changed, and an understanding of the qualities of work (see Caffentzis 2007; Dowling 2007; Böhm and Land 2009 for critiques of the “beyond measure” thesis). Productive Labor: A way through this Mess The worker produces not for himself, but for capital. … The concept of a productive worker therefore implies not merely a relation between the activity of work and its useful effect, between the worker and the product of his work, but also a specifically social relation of production, a relation with a historical origin which stamps the worker as capital’s direct means of valorization ... to be a productive worker is therefore not a piece of luck, but a misfortune. (Marx 1993, 644) There is a real mess of contributors working on generations of dead labor to make and remake FLOSS applications and package them together into Ubuntu. And it also begins to make sense that scholars would argue that following value does not work for thinking about “knowledge economies,” “immaterial labor” or “digital production.” 294 Recognizing the materiality of code, being precise about which work is actually about producing knowledge, and clarifying the role of immaterial labor in capitalist production are important steps towards being able to trace value. But if following value means following acts of labor—then how can the labor involved in making something of value in the Ubuntu labor process be measured, traced, or otherwise followed? To trace labor through the commons is one thing. Dependency can serve as a guide, so can gift exchange. Paying attention to dependency—to where thanks are offered—is relatively easy in FLOSS as there is a shared culture of acknowledgment. Gift exchange is completed by moments where some entity given a gift is able to pass it on to another in some manner; and this moment exposes at least three parties involved in exchange and reveals where value was before and the vector in which it is heading. But when the gift enters capitalist exchange it becomes a little trickier. What methods are there for tracing this labor, congealed, circulated, and extracted in a system of production that makes something useful and gives it away for free, when it enters capitalist exchange? The concept of productive labor offers a way through this mess, a method for understanding how it happens that labor, congealed into that material thing, code, (for milliseconds or decades), moves from an un-capitalist mode of production to be put to work for capitalist production. Christian Fuchs’s detailed review of how productive labor has been conceived in analysis of digital production provides an excellent starting point for examining how productive labor enables a better understanding of how value moves and how spatial fixes work. Fuchs defines productive labor as having three layers: First, the production of use values; second, individual labor processes that result in the 295 production of material-substantial outputs that can be accumulated; and third, the co- operative dimension of labor that requires many players, each of whom only makes a small part of the object of their collective labor (Fuchs 2002, 2). These layers sound very general, but the point is that each of these layers is required for labor to be made productive and to be able to generate surplus value for capital. It is important to remember that productive labor is just that, labor which generates surplus value for capitalists—it is not any sort of ethical or moral judgment on the quality or efficacy of the labor. Fuchs also argues that “it is key to remember that surplus value can be produced only if there is a physical output that can be accumulated, stored, warehoused, transported and resold” (Fuchs 2002, 1). For this assertion to hold, it requires remembering that what might be termed services are nonetheless almost always about the accumulation, storing, warehousing, transportation, and sale of physical outputs. Yet, identifying what it is that is “material-substantial” is not always obvious. For instance does a barber shop owner who puts capital into circulation by purchasing the labor of barbers warehouse the talent of the barber? Or perhaps slots of time on a barbers’ chair? This is no mere speculative exercise, it is difficult to sort out how material-substantial outputs of labor processes move (and get fixed) without slipping into categories that occlude more than they reveal, such as the service sector. In his review of how scholars have conceived of value and digital production Fuchs finds that all fail to meaningfully address how labor is or becomes “productive” by being put to use for capital accumulation. The reason for the failing that Fuchs identifies, 296 and for Fuchs’ own limited account of how and when labor becomes productive, appears to be two-fold. Fuch’s focus on how surplus value is produced in a bounded labor process elides two aspects of productive labor that make it so useful for sorting out the different modes of production in Ubuntu and other labor processes dependent upon commons: First, the temporality of productive labor is dynamic—labor can become productive years after its exercise; and second, intentionality has no relation to productive labor—although struggle to keep labor unproductive is another thing. 103 Turning back to Fortunati and the Wages for Housework movement is instructive on the latter point. Fortunati insists that what appear as (personal) services such as love, therapy, and sex are really emerging commodities under capitalism and play key roles in creating surplus value (Fortunati 1995, 23, 161). This is a significant departure from Fuchs who, like Hardt and Negri, insist that we avoid the reductionism of thinking that unproductive labor is not important to capital accumulation—it is indirect labor, which is for the most part is performed by women, that reproduces workers’ capacity to labor. This sounds right, expect that it misses the fact that indirect labor can also be productive. On the other hand, Fortunati brings into question the norm of thinking that our classification and analysis of labor should be organized by how any given labor falls on a spectrum of “directness” to a production processes—i.e. that it is often only the last folk to touch a good that are considered in its production. In Fuchs and others work, 103 There is a third tweak to productive labor that might be necessary, but I am not quite sure how important it is. There is often an unstated relationship between the wage and productive labor. Marx points out that a clown is productive if she gives more labor to her employer than she receives in a wage (Rubin 2007, 269)—but is there a necessary relationship between the wage and productive labor? Perhaps the answer is as simple as it is obvious: all unwaged labor is potentially productive and becomes so the moment it helps a labor process bring a material-substantial object into being that ends up generating surplus value. 297 productive labor is almost always thought in such direct terms—labor that is put to work, in the moment of work, for capital. I find it difficult to think of any example in which labor is directly turned into surplus value. The transfer of human capacity to the object which is transformed by labor takes time. Even if capital may instantly take ownership of the thing produced. The movement of that transformed entity—be it a part for a widget, a clean hallway, a full stomach, or a some computer code—into something that can be in some manner accumulated, takes time and space. There is no expiration date on the labor congealed into these material-substantial objects. (Although the conditions of an object’s possible use can and will expire and, as established, this includes computer code.) In the case of software production, making code always relies upon the reuse and re-purposing of existing code, and in turn the conditions of that existing code’s production. 104 As soon as there is a material output of labor (and emotional states are material), that output may or may not produce any value. There is never a guarantee that the object, or anything it becomes part of, will ever meet a need or desire. Thus, determining whether or not an output has any use simply cannot be made based on intentionality, it only matters if and when that output is again put to work as part of the many long chains of human efforts combined with nature (the two sources of value in the world) that ends up creating something that is used. Value can only be judged in an object of labor’s later use, in which time only has a relational meaning (i.e. later is all that matters); and more 104 This is far from a new analytic move—tracing the dependencies of any production process (Starbucks to the working conditions of coffee field laborers, Nike to its component sweatshops, etc.) in order to reestablish the connections of the world stripped from our eyes by the enthralling pleasures of the commodity is a well tried analytical and political tool. These tools find their opposite in “value-added” analysis of labor processes that identify some aspect of a labor process as “revenue producing” and others as “non-revenue producing.” 298 importantly, exactly what is material-substantial about the output of that production process cannot be known either. What this means is that we cannot judge labor productive or unproductive at the time of laboring, and we cannot know what it is about the labor process that will define the nature of what is material-substantial until something is put to use. That value is about “immanent causality” might be obvious to any scholar after Althusser wrote Reading Capital but I had rediscover the relationship between time and use-value in the movement of computer code for it to become alive with its obviousness. 105 Following Ernest Mandel, Fuchs submits that not all labor processes produce material-substantial outputs—the labor of concert, for instance, has no material substantial output. However, a concert is capable of producing one very important material-substantial commodity: labor-time. As much as I find it revolting, going to a concert reproduces my capacity to labor, my capacity to deal with the world, and me, as a 105 The world around us has always been and will always be overdetermined, or, as Avery Gorden expounds upon a simple and eloquent quote from Patricia Williams—“that life is complicated is a fact of great analytic importance”—complex personhood is a fact that we have to contend with in ourselves and others (Williams 1991, 10; in Gordon 2007, 3). Or perhaps the Merovingian from The Matrix said it best, or at least most dramatically: Beneath our poised appearance, the truth is we are completely out of control. Causality. There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the ‛why.’ ‛Why’ is what separates us from them, you from me. ‛Why’ is the only real social power, without it you are powerless (A. Wachowski and L. Wachowski 1999). “Why” is not the same as the truth, “causality” is by no means a grand narrative. Why is the power of ideology, of discourse, of the how the world around us is explained to come to be and hold together; causality is dialectical materialism (or something similar). In hoping for a different world, rather than to try come to grips with an apparently “new” world that for hundreds of years was modern and yet could never be so, choosing why and causality is not a reclamation of some modernist way of thinking or its progenitors, but a move reclaim the future. Casarino puts it in slightly different terms: the immanent causality that is value is always about the “one and only surplus” that constitutes two radically different modalities of surplus (the desire to be in common and the desire not to be, capitalism and a communism-yet-to-be) (Casarino and Negri 2008, 30). And to be aware of this world before us, we must embrace complicated life and seek its confusion and uncertainly in order to use the social power the Merovingian describes without claiming knowledge of the unknowable complexity of life. That is, to be a small part of tearing the means of knowledge from the talons of social science. 299 subject who sells that material-substantial commodity, labor-time. 106 The guttural realization of this truth is one of nauseated acceptance, knowing that the joy and beauty of music plays this role through my body hurts momentarily as it drives home Marcuse’s point about reproducing repressive society through meeting our needs. What might seem to be gloriously unproductive labor (labor that does not produce surplus value) has the potential to be productive labor at any moment and in ways that cannot be anticipated. Of course, the concert does and is many other things (an experience of beauty, art and joy that produces of all sorts of other social possibilities and other surpluses that can never be appropriated by capital), yet the capacity to potentially produce an emotional state that may or may not be put to work for capital cannot be denied, as much as I would like to do so. This is part of the misfortune of productive labor. In the FLOSS ecosystem, where the organization of production often melts into the air, such an expansive understanding of what constitutes productive labor is an unnerving necessity. Accounting for this melting—where a particular grouping of people and resources utterly necessary to make something might be here today and gone tomorrow—is no easy task and cannot be addressed by adding up all of the productive labor that goes into producing any single commodity. Such an accounting is so overdetermined and perhaps nigh impossible to unveil in even the best of commodity chain analysis, making it necessary to chose to exclude some aspects of productive labor when considering the making of any given commodity. But this is always the world that we face, and at the least, it is essential to realize that when trying to better understand the 106 Harvey argues that we have a similar reaction to the idea that “cultural goods” can and do become commodities: “we set them apart simply because we cannot bear to think of them as anything other than different, existing on some higher plane of human creativity and meaning than that located in the factories of mass production and consumption” (Harvey 2001, 394). 300 problematic of the current form of capital accumulation we are always making choices to represent some productive labor and mask others, and those choices matter. It is thus key to remember that in social production, the socialized worker “stands a different distance from the actual manipulation of the object of labor” (Marx 1993, 643). A large part of the ongoing project of understanding the current particulars of capitalism is understanding the dynamics, displacements, and externalities produced by the distance—in time and space—between the object of labor and the commodities and/or gifts that labor may become. In software development, this relationship to the object of work, code, must be seen in relation to the capacity for code to be reproduced at a low cost thanks to externalities such as the environmental and human costs of power plants, data centers, resource extraction, hard drive platter and silicon chip production, and state investment in internet infrastructure. The spatial fix that Ubuntu can provide is wrought through all sorts of meaningful relationships and social life that is enabled by the above esternalities. The internet as a platform enables a wide variety of organizational forms—a wide variety of distances between work and the object of labor—some of which are non-capitalist, many of which are or look like FLOSS. This no coincidence: as Kelty argues, the internet “looks the way it does because of Free software ... there are a number of practical, technical and historical places where the two are essentially indistinguishable” (Kelty 2008, 4). FLOSS is flush with non-capitalist relations, which enables a form of stability and pride and meaningfulness in work that capital needs and yet cannot readily generate. That is, this is a fix wherein capital uses a more sustainable and humane way of producing and 301 exchanging things of value as a fraught, uneasy attempt to stave of crisis in an inhumane system of production that places computers and other machines before humans. Thinking through productive labor enables a trace through simultaneous and dependent modes of production, which, in the case of Ubuntu, use the same labor and infrastructure. Revealing dependencies, once again, is key. Not to keep using myself as the unscientific “sample of one,” but at this moment it is entirely possible that the coffee I just purchased combined with the pirated music I am listening to are enabling my continued efforts in writing. In this case, any surplus value my labor might produce for the university (an unlikely event) is several steps and several years removed; yet I am far from the only who is able to keep working to produce (potential) value beyond the wage received courtesy of music and caffeine. Does such use potentially turn the labor of producing home-recorded black metal into productive labor as it becomes a meaningful input in a production process? Here immaterial production is essential to making connections between labor processes and comprehending capital’s capacity to extract value. Such an uncertain musing takes the form of a substantial and meaningful question when considering capital’s particular relationship with commons. Not unlike how Fortuanti and others (e.g. Costa and James 1975; Federici 1975) argued that housework and prostitution produce and reproduce labor power, capital’s primary commodity, so too do the commons, to borrow from Nonini, as systems that make human survival possible. Focusing on these seemingly abstract and mundane connections is generative of two key questions. First, paying attention to the goods and services that enable the reproduction 302 of workers makes connections between FLOSS labor and all sorts of other labor process apparent. 107 Making these connections is a potential basis for making it common sense to ask: is a more just way of distributing resources is possible? A second, interrelated and very practical question has faced software developers from “the beginning:” how is it possible to control the object of labor such it is not put in service of capitalist accumulation in a manner that is detrimental to fun or to the reproduction of FLOSS workers? Or, is it important to keep FLOSS labor unproductive? If so, considering that the GPL and other licenses have no bearing on whether or not FLOSS labor becomes productive, given that the object of FLOSS labor has a nigh- unexpirable potential to be put to work for capital, and that intention at the time of labor or use has no capacity to stop capital from extracting value, what can be done? Some FLOSS contributors have also asked: how can FLOSS be made productive (take a material commodity form and, through the application of waged laborers, create surplus value)? Yet, even and perhaps especially for those seeking to make FLOSS and capitalism work together as discussed above, they must ask the same question as those who desire to keep FLOSS labor unproductive: How can we ensure the reproduction of the commons? The distinction between productive and unproductive labor helps us understand how FLOSS is made to fit within schemes of capitalist accumulation via the application of specific labor(ers) capital is betting will be productive, and specific instances in which the object of labor can be accumulated. Productive labor is an analytical tool capable of 107 A frequent, somewhat silly example of these connections is that energy drinks, cafes, video games, and the like are included in “credits” or “thank you” listings on FLOSS websites or in code comments. 303 thinking through what appears as unmeasurable and untraceable. It enables sorting out how, where, and when those processes and relations that make commons reproducible are at odds with and/or support those processes and relations which are the basis of capital accumulation, private property and waged labor. Ubuntu contributors maintain FLOSS commons and keep code and other things of value in motion. Code in the commons remains imminently productive, making FLOSS commons a very appealing spatial fix for capital. What is in a Spatial Fix? (Labor’ s own Fix, the Grip of Dead Labor, Time) Andrew Herrod’s concept of “labor’s spatial fix” is a useful twist on Harvey’s spatial fix. For workers’ reproduction is usually thrown into crisis under capital’s spatial fix (or capitalism generally), and this too requires a spatial fix. This is a fix to both the literally damage caused by laboring (reproduction) and an attempt to fix the means for reproduction in place (some stability) (Herod 1997). Even in the absence of workers organizing in their class interests, workers actually do the work of creating capitals’ spatial fix, and in doing so, create social relations, friends, conflicts, vested interest with other workers, dependencies, and other meaningful things that are beyond the capacity of capital to control and create. A simple example of the implications of such a “labor geography” perspective is found in how the internet is understood as a technology. Many scholars position the internet as a product of the US Department of Defense’s Defense Advance Research Projects Agency (DARPA) and insist that the internet must be understood as a military 304 technology, even if it has other possibilities (i.e. Castells 2001; Chun and Keenan 2006). DARPA is definitely key in the story of the internet, but the story of the internet is also simultaneously the story of FLOSS, which, as is worth repeating from Kelty, is “a practice of working through the promises of equality, fairness, justice, reason, and argument in a domain of technically complex software and networks, and in a context of powerful, lopsided laws about intellectual property” (Kelty 2008, xi). Kelty’s ethnographic work and focus on the people who worked to make the set of technologies we call the internet tells a far more contested and rich story of technological development, one full of dialectical moments that offer a foundation and a method for understanding the role of internet technologies and internet-based labor processes. The struggles of FLOSS workers to figure out how to work together has created a form of production and also provided the means by which capital can enter the commons in search of a spatial fix. Faced with excess capital that becomes unmaintainable because it is in some way blocked, locked, restricted, or controlled, capital seeks a spatial fix (enacted through capitalists such as Shuttleworth). Capitalists rightfully fear the over- accumulation of capital: “excesses of capital in relation to the opportunities to employ that capital profitably... which can manifest as surpluses of commodities, of money, of productive capacity, and also leads to a surplus of labor power (widespread unemployment or underemployment)” (Harvey 2001, 300). Harvey points out that spatial fixes are driven by over-accumulation and can take the form of trade with non- capitalist social formations, if the formation is capable of integrating into the capitalist system of exchange and absorbing and fixing excess capital. This is based in Marx’s 305 arguments about the capacity of capitalist mode of production to integrate with non- capitalist nations via colonialism and imperialism to temporarily avoid crisis. The same can be said of non-capitalist modes of production that take other scalar forms—such as capital’s integration with the Ubuntu mode of production. Firms that have enjoyed sustaining rates of profit in industries dependent upon software production have also faced waves of over-accumulation and crisis (notably the “dot-com bubble” of the late 1990s) and FLOSS offers a potential spatial and temporal fix to these surpluses. Google, Microsoft, IBM, and other firms with record amounts of cash on hand 108 have moved significant amounts of capital into fixes provided by FLOSS: funding FLOSS developers, start-ups, research centers, providing code hosting, etc.—all with the hopes that this excess capital will be kept in motion and stave off crisis by providing an ever larger, ever more distributed, ever more stable and regular system of producing the goods, consumers, and workers upon which these firms depend. Here we witness capital’s attempt to find a way out of the continued dominion of dead labor over living labor (Harvey 1999, 428). For the dead labor of software is full of path-dependencies, grandfathered-in systems, proprietary lock-ins, and other ways that the very material form taken by dead labor keeps capital stuck into certain modes and paths of movement. The choice that FLOSS offers—FLOSS is frequently promoted as a way out of vendor lock-in and other such path-dependencies—is an offer to firms (and 108 Cash on hand for US technology firms doubled from 2006 to 2011 and technology firms account for six of the top ten US non-financial firms with the most cash on hand in 2011 (“Tech’s overseas cash hoard is growing,” "U.S. businesses stash 11% more cash, Apple is No. 1" San Jose Business Journal 2011). Private firms such as Google face serious concerns about overaccumulation (as cash on hand for US firms in 2011 is also at its highest rate since early 1980s, for instance, with Google at $35 billion, and Microsoft at $40 billion). Tech firms often destroy their surplus by purchasing other firms and purchasing and/or building expensive internet infrastructure (Malecki 2002). Of course, this is done with the belief that it will yield more profit later, the likely false promise of many a spatial fix. 306 other organizations) to be free of the dominion of dead labor. Investment in FLOSS such as above—such a fixes—are representative of capital’s dream to break out of this inertia. In this manner, Ubuntu is a temporal fix for surplus capital as well. Shuttleworth’s personal wealth is not public knowledge, but thanks to a timely exit from the “tech bubble” and selling the company he founded for over US$500 million, he had a fair amount of wealth even after a trip to outer space and a handful of generous donations. 109 Shuttleworth’s primary fix for this surplus was to sink it into creating Ubuntu and Canonical. Canonical can benefit from excess in labor power nearly anywhere in the world and Ubuntu creates a potentially huge number of new FLOSS and computing technology consumers (all of whom are also potential new workers). This configuration of labor, where Canonical job postings list a location of “your home, with broadband,” is a dream of freedom for capital: capital can move literally to anywhere on the globe where there is a high speed network connection. It appears as if labor does not have to be imported or any fixed capital moved, and any sort of “regional advantage” offered by co-location can be reproduced by internet-based communication tools. 110 Most coders employed by Canonical were already committed to the Ubuntu community or to FLOSS projects more generally, creating what workers in Canonical’s 109 After his trip to space, Shuttleworth was still the 193 rd wealthiest person in the UK, and far and away the wealthiest under the age of thirty. 110 Even capitalists cannot operate in conditions of their own choosing and time-zones, clusters of workers with skills in certain areas, centers of hardware production, and workers’ desire to have a beer with someone they work with all day and/or worker’s family and other social obligations still tend to exist. And after experiences with the challenges of working across different time-zones, many Canonical jobs now have a time-zone range preference—such as this listing from October 2011: “Location: Your home (given appropriate facilities including broadband internet), preferably in an American or European time zone.” 307 Taipei, joked about as the Canonical “double shift.” 111 This joke, told to me by several different Canonical employees and a former employee, is a joke in the sense that it is a light-hearted way to describe and critique the conditions of work. When I asked a member of the kernel team if he ever wonders who the work he is doing is for—is it for Canonical or something/someone else—he led into the “double shift” joke. The barrier is not so black and white, there is a gray area between work and other things for me. Because we might volunteer to do something for the community and Canonical encourages us to do that, but it’s for the community, it’s for upstreams. Canonical encourages us, so it’s okay for me to use my office hours to do that and it’s okay for me to use my own hours to do that as well” (Me:) “Are there ever conflicts between community tasks and customer tasks?” “Not really, because customer tasks are always a higher priority so I have to stop the community tasks. (Me:) Do you ever have any home and work conflict? Where you go to work and code and then go home and keep coding? (Laughing) I understand that! One of my friends told me a joke: working for Canonical you have to work 16 hours a day—8 hours for Canonical and 8 hours for the community. (laughs and laughs). It’s a joke! 111 As Coleman demonstrates, humor has many purposes in hacker and FLOSS worlds, from functioning as a communal gift to institutionalizing a form of play to demarcating insiders and outsiders, for “unlike the objects of hacker technical production, joking has no strict functional utility and speaks of the inherent appeal of creativity and cleverness for their own sake. Joking is a self-referential exercise that designates the joker as an intelligent person and cleverness as autonomously valuable” (Coleman 221, see also, Fischer 1999, Raymod 1993, Thomas). For instance, this exchange appears in my research notes from a FLOSS conference: 4:30 p.m., Sunday. Heckling is common, by men, mostly towards men. Jono Bacon (Ubuntu’ s “community manager”) is heckling Ted Haeger (who is giving a presentation promoting his new start- up). As soon as Jono sees that Ted is using Microsoft PowerPoint (on Mac OS) he stage whispers about how Ted hates freedom, must have made some good friends at Microsoft, does he belong here? Ted eventually singles him out: “what did you say?” Jono shouts “you hate freedom!” “No, I hate you,” and the presentation goes on. When Jono talked about Ubuntu he encouraged a “heckle zone” for people to “yell at me when you think I’m full of shit.” There is so much insider chiding, most people know each other, and they know what’ s evil, especially Microsoft and un-free software. This sort of masculinist culture is played off as “good fun,” and is part of presenting particular forms of authority; at the same time it is a discourse that sets up lines of insiders and outsiders—the insiders often end up being men, even those who are champions of inclusion. 308 (Me:) But sometimes it feels like that? Yes. Canonical employees, as well as those who volunteer their time, have to figure out how to find their own fix—some stability in the face of unclear barriers between work and life, the possibility of burnout, the challenge maintaining filial and familial relationships while working ten to sixteen hour days, and the particular exhausting rhythms of working across time zones and being up at odd hours to meet with people who share very little overlap in typical waking hours. The challenge of finding this fix is by no means the same for all Canonical employees. Again, time zones determine much here. I asked Earl, a Canonical systems administrator who works in the London office to clarify what he meant by the costs of Canonical’s “distributed” work environment—for instance, would he hire someone in the same time zone who was thousands of miles away? That’s no problem, the face-to-face bandwidth is nice, but to a large extent its the hours [of difference between time zones]. I’m thinking about the guys on the US West Coast and in New Zealand, I’m always talking to them in my evening. I don’t give as much time to them. Even the US East Coast guys get all of my afternoon; West Coast starts when I’m nominally clocking off. He starts at my 5pm. But the Taipei guys have it particularly hard. They are basically twelve hours from the people they do the most communication with. They’ve got to interact with Lexington. Its a really bad situation. And also Lexington is just a more traditional US-based, ah, company [the Lexington office is mostly staffed by former-employees of a firm Canonical acquired]. The guys there are not likely to jump on a call at 7 p.m. I was a bit shocked and appalled at some of the guys in Taipei. It’s totally normal for them, but they go out for an evening, but then about 8 p.m., they step outside and do their phone calls, its just like another patch of work for them. 309 Thus it is not just time zones, but a particular ideology of work in FLOSS, an ideology that is different than that in a “traditional company” that normalizes a work schedule determined by a global configuration of labor across time zones. Of course, this normalization has its breaking points and is a factor in burnout. When I asked a Canonical employee who was thinking about leaving the firm, in part because of his work day (which included late night work required by time zone distance) if he felt he had experienced or was experiencing burnout, he was not sure: I didn’t notice it. Maybe I had, but I didn’t notice it. At the last all hands meeting that was in May in Spain, just before UDS, they had a talk about burnout. About how to detect it and how to avoid it. No, not how to avoid it, but how to detect it. I didn’t go to that talk because I was busy with other talks. But they seem to have some scale of 1 to 12. One co-worker who is my contact person for Launchpad told me about it. I’m actually quite close to him, we share similar backgrounds, on the personal side. And he told me that he went to that talk and discovered that he is probably on level 9, one of the highest! Or was close to it, so he said that was really scary [laughing into a sigh]. So the pressure is quite high. Jono, who gave this talk, reports that he was surprised at the response of the talk, which he has now given several times at Ubuntu and FLOSS-related events and posted online. Numerous Canonical employees came up to him, expressing, as the friend did above, shock that they were at a high “stage” of burnout. From one perspective, Canonical’s community manager giving this talk is the result of reportedly high rates of burnout in the Ubuntu community and in Canonical and the firm’s concern about the loss or potential loss of developers due to burnout. From another, considering Jono says “I burnt out pretty bad … and I didn’t realize what it was,” it is also about a group of people who care about each other struggling to figure out what to do about working conditions that put their own reproduction, health, well-being, and capacity for fun into crisis (Bacon 2011). 310 As Harvey argues, the race for spatial fixes is an ugly game, often appearing as the export new technologies, but actually exporting unemployment, inflation, idle productive capacity, and the dealing of death and destruction with ever more sophisticated weapons (which are also the technologies at hand) (Harvey 2001, 310). Does such truth leave us with nothing but a gloomy portrait of FLOSS as a tool of sustaining capital’s domination over life? Such gloom exists, but ask most any FLOSS developer and they will also tell you tales of the beauty of making something that meets people’s needs and is freely given to anyone with such needs. The point of such gloomy seeming analysis is to understand the conditions of possibility for taking control over these distributed means of production, including the infrastructure they require and generate, to figure out how to use them in a humane system of production—a struggle in which FLOSS workers are continually engaged. This is not a clear-cut case of a spatial fix that expropriates resources from a system that exists outside of capitalist production; it is also a fix that seeks the expansion of capitalist relations, not through wage-labor, but through the provision of communication. This distinction between a fix that seeks expansion and a fix that seeks an outside source of value is often blurred, and when workers are considered part of the process, it is particularly difficult to disentangle the two (Doucette 2010, 144). The final section of this chapter offers one example for thinking through this tangled life of a spatial fix that brings focus on the labor process and laborers. 311 III. How a Cloud Strategy Hits the Ground Even though Canonical cannot directly control the labor process, as most Ubuntu contributors must sell their labor power to meet their needs, Canonical is able to employ and thus exert some control over the labor process and dictate that some work be done and not other work (and through Canonical, client firms are able exert some mediated control). Although folk desire jobs, the often easily missed vector of this relationship— the friction for capitalists struggling introduce the wage relation, not desire from workers for the wage relation: The thing is this, the main advantage and the main disadvantage if you come from the community side and you go to work for Canonical, is that you have a lot of passion, that is company behind Ubuntu! Before I used to have like two hands. In the day I worked with Windows, at night I was in the forums helping with the Columbian team and with the translations and all that and one day I realized I was working full time with Ubuntu. Its kind of difficult. And then you work for Canonical and sometimes you think, hey, this work I’m doing for the community is actually more beneficial for the company in the long run, but then you realize they are paying your pay check so you have to abide by certain rules. This Canonical employee eventually left to do other FLOSS work that would enable him to spend more time on the things in Ubuntu he cared about. Again, the “double shift” is an ongoing issue for Canonical employees who “come from the community.” Thierry, a Canonical employee based out of France, describes how this double shift emerges: Since my work is being a project manager, as a project manager I’m not supposed to be doing any coding. So I’m doing my coding at night, but on the Ubuntu project. It’s generally on issues I would like to see solved as a project manager and do not have any resource[s] to deal with [laughing]. 312 (Me:) So you ask the community, “Community, could someone work on this” [also laughing]? And then you turn around in your chair at seven o’clock at night and say “Hey, I’m community, I should work on this!?” 112 Ha! Yes, there was this one little script that one of my colleagues start[ed] writing and I was like “Hey, this thing is going to change the life of people doing virtualization!” And I tried to explain that to him, and he didn’t really understand it. So I started hacking all these little patches to it. And now it’s one of things that we advertise when we talk about virtualization [laughing]. Here the work Thierry performed outside of his formal job duties—labor that he finds fun —became productive when Canonical used it to promote virtualization. It is important to take a minute and trace how this labor actually became productive. By “hacking little patches,” Thierry is using a computer program to create code, taking form on hard disks in multiple locations, likely accessed and updated by Launchpad. That code is eventually added to a repository, and then mirrored to hundreds of servers around the world, consuming electricity, bandwidth, hard drive space and other limited resources along the way. Because this code is kept un-owned, any Ubuntu user with a network connection can call upon the package that relies upon Thierry’s code and put it to work in a variety of fashions. One of the key ways that virtualization is put to work and promoted is as a selling point for attracting enterprise clients to Canonical. As many enterprise clients will run instances of Ubuntu on servers they do not own, Thierry’s script is also of potential use to firms such as Amazon, whose Elastic Compute Cloud (EC2) “cloud computing” platform and Simple Storage Service (S3), will gain users via Ubuntu’s improved virtualization. In this case, the labor of Ubuntu contributors circulates in multiple systems of exchange simultaneously, always immanently productive. 112 This practice, of a Canonical employee writing a spec for something that Canonical management decides should be done by the community, not by Canonical employees (or that employees themselves decide they do not have the time or interest to do) and then the employee turning around and doing the work written up in the spec themselves is a common practice in Canonical. 313 The virtualization Thierry refers to is the practice of creating “virtual” installations of an operating system inside of another operating system—allowing for testing and for quick expansion/contraction when demand for computing resources changes. Virtualization is the essence of the current reigning buzzword in computing: “cloud computing.” I first heard of “cloud computing” during a very technical conference panel in which the term was highly contested and debated. In a later discussion at another FLOSS conference a Canonical employee argued that idea is to make computing resources like electricity. Electricity transformed from an “innovation to a commodity … and now what we can do is provide infrastructure as a service” (OSCON 2009). I was shocked at this turn of phrase, and more so when he argued that “this industry is in transition from a product world to a service world.” Later I found myself laughing out loud when I saw “the cloud” being deployed as a commonsense, yet magically abstract, concept used in a 2011 Microsoft Windows commercial (Microsoft 2011). The ideas behind “the cloud” are as old as networked computing and the client-server model in which relatively “dumb” client machines query and display data from a server where most of the computational work is performed. Yet, cloud computing’s primary difference is that virtualization allows for efficient utilization of the idle productive capacity of existing data centers’ computing and storage capacity. 113 And there is much idle computing capacity out there. By being able to very quickly bring dozens, hundreds, or thousands of new “machines” on and off line to meet various computation and storage needs, firms such as Amazon are able to rent out the spare 113 Renting space on infrastructure is the most common way firms (especially startups) use “the cloud.” However, the technology can be used on any server infrastructure and “private clouds” using a firms internal resources are also common. 314 capacity of their existing infrastructure. Ubuntu helps make this possible; and at the same time the very cheap storage and computational power of these data centers helps potentially increase the adoption of Ubuntu. For instance, in two of the most popular cloud services, Amazon Web Services and Rackspace Cloud, Canonical reports Ubuntu to be the most frequently deployed operating system (Barcet 2011). The definition on Wikipedia of cloud computing gets at the heart of the push for this particular mode of understanding our current capacity for computing: “Cloud computing is the delivery of computing as a service rather than a product” (Wikimedia 2011). 114 The cloud is one in a long line of concepts used to sell computers, but this time as an “individualized” service instead of the actual computing device—people and firms are paying for a computing device on something like a lease. To call cloud computing a service is of course ridiculous, it is the exchange and use of very material digital products and computing hardware. Because of cloud computing’s increased use of network capacity and hardware by requiring a centralized server infrastructure, cloud computing may actually use more scare resources than previous solutions. 115 The use of these resources, further distanced from the point of consumption, is one way the cloud hits the 114 I hesitate to use Wikipedia here, but as a primary means by which many folk are exposed to the concept of “cloud computing” this description exposes something essential. As the definition took form over 500 hundred revisions and many changes in the 2011, the idea of cloud as a “service” become central in the definition, reflecting current literature. For instance, earlier Wikipedia definitions of cloud computing were more along the lines of “’Cloud computing’ is a way of computing, via the [[internet]], that broadly shares computer resources instead of having your local PC handle specific applications.” (April 2010). 115 These excludes peer-to-peer solutions, such as BitTorrent, which are a whole different ball of wax as they are built on the connections between end users and do not requiring the same storage capacity. Although BitTorrent is for moving data between machines, similar technologies could be used to share computation resources, and perform many of the “services” of the cloud, such as SETI@home, which uses the spare processing cycles on over three million users computers to analyze radio telescope data in the search for extra-terrestrial life. 315 ground. For instance, I have backed up this document hundreds of times via Dropbox, a firm and application that provides backup between multiple computers and to “the cloud.” But I had no real idea where the data goes. Like trash, it just goes “away.” It does go somewhere, and not surprisingly, my dissertation (or at least parts of it) has traveled the world being backed up on data centers owned by Amazon. These data centers are located not just “around the world,” but in particular locations that may seem counter-intuitive, such as major cities. These cities imply high-rent—but major cities also mean good locations in power grids, access to internet backbone, and as Earl told us, buildings are sticky (see Figure 9). 316 Figure 9: Location of Amazon Data Centers (very likely not inclusive) Dropbox is built using Python, the same FLOSS programming language as Ubuntu, and like Ubuntu One, its server code base is proprietary. Along with my dissertation and other files, Dropbox currently moves about a million files every fifteen minutes and grew very quickly, making Dropbox a poster child for the scalability and expansion possibilities of “the cloud.” What exactly all of this means for the personal data that people trust to Dropbox is unclear—users are encouraged to put our trust in the cloud. On the Dropbox forums, such questions come up from time to time; for instance, a user asks: All the DropBox documentation says that my files are backed-up but that [is] such a general term that it is kind of meaningless without context. What about a terrorist attack or a flooding which destroys all the computers in your datacentre, is my data still safe? There’s no point saying the chances of that are really small because that’s what backups are for. Which garnered a response from another Dropbox user (not an employee of the firm): All files synced by Dropbox are encrypted and stored securely on Amazon’s Simple Storage Service (S3) over several data centers. [Followed by a technical discussion of Amazon’s technology.] Another Dropbox user added the following: Dropbox is hosted at Amazon S3. Amazon’s stuff is so f*cking large, it would be horrible to "back it up", so here’s what most companies do, Local redundancy, then off-site mirroring (basically, a back up) … [Another nuanced technical discussion.] Redundancy is so simple that anybody can do it, in fact, my video data is on a redundant drive. What you do, is you take, oh I don’t know, like 4 or 6 drives or so. Then all data, when written, is spit up and written to all but one of them … So, Amazon has it covered with many many datacenters which are individually protected by RAID schemes. That, and they have engineers patrolling the server rooms looking for that red light that signifies that a drive must be replaced. All they must do then is pop it out, replace it with the clean drive in their pocket and it rebuilds itself (Dropbox 2011). 317 This another way the cloud hits the ground—my dissertation has used resources around the world; and to keep me from freaking out about loosing even a few minutes of typing, it does so several times a day. Ubuntu One offers essentially the same service, but with more storage capacity. Canonical hopes Ubuntu One, “Ubuntu’s personal cloud service,” will be a means for growing Ubuntu adoption. Where the cloud hits the ground, it almost always uses FLOSS in some manner and calling it a “service” makes it all too easy to forget the machines, labor, and infrastructure involved. But what happens to code in the cloud? Gift to Capital and Back Again (a Return to the Dual Nature of Code) As a capitalist, he is only capital personified. His soul is the soul of capital. But capital has one sole driving force, the drive to valorize itself, to create surplus-value... Capital is dead labour which, vampire-like, lives only by sucking living labour, and live the more, the more labour it sucks. (Marx 1993, 342) The dual nature of code means that at every time code takes its material form as part of computing machinery, every time dead labor is brought back to life, the life blood of living workers surges through code, giving capital another glimpse at a tantalizing, pulsing vein. 116 As a reminder, from all the way back in Chapter One, code has two forms of being: first as human readable text, then when turned into machine code and executed, code is both movement and machine, and is the stuff from which everything digital is 116 The blood that capital needs must be fresh, as Shuttleworth answers his own question—how do you drive innovation faster?—with “you have to bring in fresh blood around the core” (OSCON 2008, keynote). 318 made. In Ubuntu, systems of exchanging code never allow for code to become capital; although through code’s dual life, it can move as capital. It is through the mundane and everyday movement of code between its different forms that a spatial fix is able to come into being. Code held in common, GPL’d code and other FLOSS code is also far from a raw material, labor has already been applied to change the states of the material that holds the code. This labor lies in wait, somewhere, as either human readable code or 0s and 1s —perhaps it waits in a software repository mirror, perhaps written in the textbook, perhaps part of another application. This is code in its other, unmoving form, code as something akin to a set of instructions (regardless of what language it is written in, if it is source code or machine code, this is unmoving code). Code, waiting and resting somewhere in the world, on some server, as dead labor, is brought to life all the time by FLOSS workers. And code, in this form, can never become capital, and it can never be private property. Unsurprisingly, for Canonical’s cloud strategy to come into being, it took some resting code to be put to work. At the Ubuntu Developer Summit for the 9.04 Jaunty Jackalope 117 release (released in 2009 in April), one of the goals that Shuttleworth frequently discussed was to make it very easy to get instances of Ubuntu running on platforms like Amazon’s EC2. At the time it took quite a few steps, and the hope was to make it “incredibly simple.” I spent most of my time during the summit in the server track, which meant sitting in a meeting room at the Googleplex with ten to thirty people listening to technical discussions that were very often over my head on variety of issues, many of which kept coming back to “the cloud.” 117 Ubuntu releases have a naming standard of “year.month animal alliteration,” such as the current 11.10 (October 2011) Oneiric Ocelot, which will be followed by 12.04 Precise Pangolin. 319 Much discussion centered around Eucalyptus, an “open source cloud management tool” developed at the University of California, Santa Barbra, and funded by the National Science Foundation. Eucalyptus was already made and was being used, but it needed a fair deal of work, to be packaged, tested, patched, etc. before it would become part of the selected packages to be officially supported in Ubuntu. The code had to move between many Ubuntu contributors, its original maintainers and back again before being pushed for larger testing as part of Ubuntu Server Edition and eventually put to use as part of Ubuntu. It was not until almost ten months later and the next Ubuntu release that Eucalyptus was promoted as a core part of the server edition. But before any of this could happen, there was a great deal of talk about how to approach the technical issues, trying to decide if solving these issues was worth the work, and coming to an agreement on what technology offered the best solution. And before any of that could happen, it took almost fifteen minutes for the twenty-five odd folk in the room to decide on a shared meaning of “cloud computing.” At this point I remember thinking that it is amazing that decisions get made at all, when the head of Server Team brought everyone back to the issue at hand by reminding everyone that “this EC2 thing is one of Mark’s [Shuttleworth’s] top priorities.” A respected coder on the Server Team was drawing models on a white board of the challenges of deploying Ubuntu in the cloud (complete with clouds) and making it scale quickly (i.e. How can we go from four to eight virtual machines? What needs to happen? How will they be managed?) when Shuttleworth entered the meeting seventeen minutes late, apologized and encouraged everyone to pay attention, “because this is important for Jaunty [the upcoming release]” 320 Shuttleworth asked pointed technical questions as the discussion went on, several times shutting down discussion of whether or not the whole idea of working on the cloud or with Eucalyptus was feasible or a good idea. He did so by very calmly saying things like “my understanding of what we should do is …” or “this is a goal of Jaunty, so it is worthy discussion.” Some Server Team members had a comfortable report with Shuttleworth, others were clearly intimidated, were nervous and stammered out responses to his questions. In the end Shuttleworth declared that it should be possible to get a virtual machine up in five commands in an EC2-like environment and that Eucalyptus could be extended to solve several related issues. I quickly forgot the Eucalyptus discussion until “the cloud” jumped to center stage over a year later, but Shuttleworth’s influence on the discussion stood out in my experience at UDS. 118 Here, on the Server Team, Shuttleworth’s capacity to manage the direction of Ubuntu development was at its height. Nearly every member of the Server Team is a Canonical employee, which is far from the case in other teams, especially the most visible, the Ubuntu Desktop Team. Yet grumbling persisted after Shuttleworth left, some contributors were not convinced that this was a sensible priority, some were not convinced Eucalyptus was the way to go, and questioned whether or it it was fully free software. The team had a discussion the day before lamenting that there are only three “community” contributors who actively participate on the Server Team—and those who 118 I might have also forgot about this because I was beyond exhausted after a sixteen hours of Ubuntu a day for a week, which as I found out later is referred to as an unproductive week after UDS called the “UDS hangover.” I spent every day at UDS, every night writing up notes (sometimes a bit intoxicated from UDS-related festivities) and every morning trying to write about the day before and plan for the coming day. Most folk at UDS also had work to keep up on, especially those who were not Canonical employees. Even Canonical employees were frequently looking for time to steal away and keep up on ongoing work. 321 were “from the community” had decidedly different goals for the Server Edition, such as making it easier to use for small office / home office (SOHO) users. But enterprise use is the goal, and as Shuttleworth made clear, “the cloud is going to be essential to our enterprise strategy.” The most common request to Server Team has been for a simple graphical interface, which would be great for SOHO use, but was not one of Canonical’s or Shuttleworth’s goals. 119 With some friction, the Server Team ended up setting goals and assigning tasks in order to meet the cloud computing goals laid out by Shuttleworth. So when, and where, in the development of Eucalyptus, in its use by Ubuntu and then through Ubuntu by firms, individuals, or other entities to set up “a cloud,” is this code moving as a gift? And when, and where, is this code a commodity? When and where is it capital? This example gets even more complex, for in January 2009 Eucalyptus Systems “began the process of commercializing the Eucalyptus project as an open source company” (Eucalyptus Systems, Inc 2009). The company now boasts that Eucalyptus has now been used to create 20,000 “clouds” and is deployed by over 20% of Fortune100 companies. At the same time, “the cloud” has become a major category through which Ubuntu is promoted. In a 2011 redesign of the Ubuntu website, “cloud” became a separate category from “server” and is a visible and highly-promoted aspect of Ubuntu—even though “the cloud” capacities of Ubuntu is still part of the Server Edition, the idea of “the cloud” as somehow separate from servers—servers being very material and very much so “a product”—whereas “the cloud” is deemed a service. 119 Low community participation is a relatively clear sign that the Server Team often works towards other ends than to reproduce the commons—although alternative explanations offered by members of the Server Team include: server is not “sexy” like the desktop and that the user-base are professionals server admins who have been socialized in wholly different mode of social life and sharing than, say, the user base of the Linux desktop. The latter is another way of saying that they have not been socialized in gift exchange. 322 It is in this these moments, when “the cloud” is deployed in a manner that allows it to appear as a service, that Ubuntu and its constituent supported applications, such a Eucalyptus, become capital. All this code becomes a form of fixed capital, owned by a firm, that becomes part of the machinery of production. It may seem odd to argue that Ubuntu, which is given away for free and is licensed such that it is un-ownable, can be owned by a firm. But when code moves, and becomes inseparable from the machines through which it moves, the ownership of those machines transforms FLOSS code into capital. FLOSS code, like any code, when put to work as part of production process, can become capital. Code is able to jump from being a gift to being capital without ever being a commodity. Such is the tenuous nature of the gift. This transition of code from unowned gift in the commons into capital without ever being sold or made for the market is the obvious part; how code makes it back to a gift is a little more complicated. FLOSS code can become capital when it is used to sell a “service” for legal reasons; if the code was used to sell a software “product” in some way, copyleft clauses that are in most FLOSS code would require that all code depending on the FLOSS code used in the product also be released as FLOSS code—not something most firms are keen on having happen. The conversion of FLOSS code into capital is a very real issue for the FLOSS community, especially with the rise of web services that run on FLOSS. Some FLOSS licenses have changed to close a loophole that allowed firms to take FLOSS out of common by using it to run a web-based service but not actually distributing FLOSS software, such as services in “the cloud” (see discussions about the Affero GPL and other licenses designed to deal with FLOSS being used on “server-side” applications). It is the 323 moment of distribution that triggers most FLOSS licenses, so without distribution, “copyleft” clauses that require the conversion of code back to a gift are not invoked. It is these clauses in many FLOSS licenses that would require such a firm to also release any changes, improvements or derivative software back into the FLOSS commons. Without this requirement, such code is kept out of the common and does not change form back being humanly readable, back to a gift. 120 In most of the short sketch above, the movement of Eucalyptus functions as a gift —a gift with deep roots and debts. Debts to the university, to the state, to the redistribution of surplus via the National Science Foundation, to the Ubuntu community, and to FLOSS generally, all these debts are tied together via the circulation of code and the gift of the labor of those working to improve Eucalyptus. The gift is constantly in circulation and this circulation between multiple givers creates reciprocal relationships between those who work on Ubuntu and those who work on Eucalyptus and those in- between and outside. This keeps the increase given by these gifts moving with the vector of the gift. If any entity were to take the code out of circulation it would cease to be part of gift exchange and exchange would breakdown or become difficult. And this is what happened. In late 2009, a firm called Eucalyptus Systems was founded by some of the developers of Eucalyptus from UC Santa Barbara, venture capitalists, and capitalists with experience in commercializing FLOSS. They created two versions of Eucalyptus, a GPL licensed version and a proprietary “enterprise edition.” in 2010, Ubuntu’s cloud strategy began to change, moving towards using OpenStack, a 120 Of course, it does so internally at firms or entities that run the code, but any changes or customization are lost, and this allows any other code deployed with that FLOSS code to stay proprietary. 324 well-received and well-funded cloud computing management tool akin to Eucalyptus. Ubuntu will still support Eucalyptus, but Canonical is putting its support, and the labor of Server Team developers, behind OpenStack by making it the default cloud solution in Ubuntu. NASA dropped Eucalyptus in favor of OpenStack for both technical reasons and because Eucalyptus was “not fully open source,” which appears to have influenced Canonical’s choice to switch to OpenStack (Metz 2010). 121 How to make sure that code can turn back into a gift and re-enter the commons, regardless of how it is used (for instance, put to work by capital) is the very onus of FLOSS licenses. Turning back into a gift requires that code turn back into its other form: human readable text. Dropbox, which uses FLOSS extensively to develop their proprietary software and currently supports a Linux client, received a fair amount of early criticism for using FLOSS code libraries in violation of FLOSS licenses. In response to user who questioned the legality of how Dropbox’s proprietary code uses GPL’d code (which would mean that legally, the proprietary code would also have to be released under the GPL), a Dropbox employee responds: first, thanks for investigating this. we’ll resolve the issue re: readline and libgcc in the next build (including them was inadvertent on our part -- thanks for bringing it to our attention.) we’ll also set up a place for acknowledgements … being compliant with OSS licenses is important to us -- obviously we wouldn’t be where we are without open source, and while we can’t open source the main app we worked hard to support the linux community (in particular) where other apps haven’t (and probably won’t) :) (Dropbox 2011a) 121 Ubuntu contributors made comments such as “the problem with Eucalyptus is that I wouldn’t call their development model ‛open’” (ubuntu-server list, Mon Jun 20, 2011), but as this development occurred as I was writing, I do not have full details on how the decision was made or the nuances of the debate. 325 As this representative of the firm explains, Dropbox is concerned with making sure that it interfaces properly with the gift economy of FLOSS while keeping its primary code base proprietary. As long discussions on Dropbox forums about proper licensing and about if and how FLOSS code can be used by Dropbox make clear, the movement of FLOSS code from capital and back to gift is not an easy process. It requires developers socialized in FLOSS practices, an understanding of the requirements of a variety of FLOSS licenses, and an infrastructure for moving the code and making it available in a meaningful manner. Code’s dual nature that I have “discovered” in its obviousness is similar to what Marx discovered a bit earlier about how “capital cannot therefore arise from circulation, and it is equally impossible for it to arise apart from circulation” (Marx 1993, 268). Marx was making a point about the complex interplay between labor as the source of value and circulation in relation to valorization. This is similar to the circulation of code because the dual nature of code allows it exist as part of two distinct, invisibly overlain systems of circulation. When FLOSS code becomes capital it does not do so because of circulation —it is able to become capital because it holds the dead labor of coders—but also it could not become capital without becoming movement, without become part of privately owned machinery. Through this movement, the spirit of the gift always haunts capitalist exchange. In Ubuntu, FLOSS, and other commons-based systems, the ghost moves ahead of the commodity. The circulation of code as a gift is how FLOSS labor processes make things of value, the gift must move in order for FLOSS labor to make something of value, the 326 gift form of code must come before its possible movement through capitalist circulation. In FLOSS labor processes the primary (but only) form of gift is source code, which moves extensively prior of the execution of machine code. In other cases, such as in my capacity to use of Ubuntu, the gift I receive is this executable, moving code as it becomes part of computing devices to which I have access. For me to keep this gift in motion, I must pass it on, and in doing so, make a very small contribution to reproducing that- which-is-held-in-common. 122 For some Ubuntu contributors, their favorite moments in FLOSS are when they pass on the gift of Ubuntu by giving it to others—several contributors told me about keeping Ubuntu CDs on their person at all times, so they could give one away whenever a conversation about Ubuntu arose, from when they are at work to riding the bus. FLOSS code can move between capital and gift, but it is important to note that by default, it is not a commodity, as it is not made for exchange on the market. It sure can be, but doing so is a fraught move, as Eucalyptus found out by keeping some code proprietary in order to make a Eucalyptus for the market and loosing some support in the FLOSS ecosystem (which is not to say that Eucalyptus Systems will not be a very successful firm by other metrics). Gifts and commodities create different sorts of relationships between their producers and Hyde argues that We might best picture the difference between gifts and commodities in this regard by imagining two territories separated by a boundary. A gift, when it moves 122 For me, passing on the gift takes several forms. The most immediate include installing Ubuntu on other people’s computing devices to help them meet some need, supporting friends’ use of Ubuntu and generally promoting the use of Ubuntu. Another very small form is to provide infrastructural support that allows others to access Ubuntu, such as leaving a bit torrent client open for days on a university computer when a new version of Ubuntu is released, giving the university’s electricity, time on the life span of a computing device, and bandwidth to the commons. The gifts are small and nothing special, but their repetition across millions of users keeps code in motion. 327 across the boundary, either stops being a gift or else abolishes the boundary. A commodity can cross the line without any change in its nature; moreover, it exchange will often establish a boundary where none previously existed (as, for example, in the sale of a necessity to a friend (Hyde 1983, 51). In the FLOSS ecosystem such boundaries can mean the loss of developers and alienation. This does not mean that doing so cannot be financially viable—it may in fact make good sense as a capitalist to do make FLOSS into a commodity (or attach a commodity to it) whenever possible, at least in the short term. There is, however, a belief that one key aspect of gift exchange in FLOSS that can be converted into a commodity: support. This belief is central in how FLOSS spatial fixes are imagined to function. There are reciprocal relationships created simply though the use of Ubuntu—use that often involves figuring out how to use and fix Ubuntu, which means asking questions on forums, IRC, email lists, other websites, maybe interacting with a LoCo team. Being part of the gift of figuring out how to use Ubuntu bleeds into its production—bug fixes, creating infrastructures of support via the repetition of asking questions—all of this is labor that makes Ubuntu useful. The giving of support is a key aspect of gift exchange and part of keeping the gift in motion. This movement of things of value is a key part of making the vibrancy of FLOSS life so appealing as a spatial fix. Within all of these people having fun making something of value, all of the relationships created via FLOSS communities, there must be some way to extract value! Some capital sunk into keeping this gift in motion by providing the means for communication or perhaps a salary for a few developers should make it possible to extract something, right? This capital might very well help create a whole lot of use-values, the challenge then for capital is to make those use-values productive. It is 328 this very labor of using and learning to use Ubuntu that capitalists most frequently dream to be the means of making FLOSS contributors’ labor productive. Selling support is the most common FLOSS “business model” and also one that frequently does not work as well capitalists might dream. Such that although “they’ll make money by selling support” is the most commonsense explanation of how Canonical will be profitable, Shuttleworth and other FLOSS capitalists and boosters do not necessarily see this as their long term mode of profitability. Shuttleworth makes clear his beliefs: “professional services and support is not going to make any money” (Ubuntu Founder Mark Shuttleworth in a Q & A session 2006). He argues that it is worth it for Canonical to provide support in order to develop the tools for managing Ubuntu on an enterprise level (which is one of the products Canonical sells, Landscape) and to set a price and standard for support that allows hundreds of smaller companies to charge something near that price and this is “good for the health of the ecosystem.” Good for the health of the ecosystem is good for Canonical, especially if the firm is able to find and maintain a position in core of gift exchange as a key giver. From this position, Canonical will be more likely to achieve the goal of “formalizing relationships for major [FLOSS-supporting] companies” and “collaborat[ing] more efficiently with the corporates” (Shuttleworth on Open-Season Podcast, 2009). The lack of long-term profitability in selling the kind of support that conjures up a vision of a tech-support person answering a phone is evident in that Canonical has struggled to sell support for Ubuntu even as Ubuntu use has grown immensely. Selling 329 support looks so appealing to capitalists because it is not just the labor of paid support workers that creates the surplus value that is gleamed from selling support—all sorts of gifts from all sorts of Ubuntu contributors are made productive through the sale of support. In theory, value is extracted from the commons with out disrupting the movement of gifts or messing with the reproduction of the commons. When a Canonical support employee relies upon a wiki made by folk who volunteer their time to Ubuntu in order to, say, install some current, but unstable bug-fixes in an upstream package where the stable version supported by Ubuntu lacks some feature that is in the current version, all the labor involved up to that moment is made productive in one fell moment of providing support. But selling support, even to firms who happen to employ people in decision making positions who support FLOSS, is not easy. At a major FLOSS conference Carl, a California LoCo team member, and I were talking with Jerry, a Canonical employee who was going to lead a “birds of a feather” (BoF) session later in the day about “the cloud.” Carl and I both mentioned that we were interested and were thinking of going even though the BoF was late in the day and it would get in way of our beer- related plans. Jerry countered with “then you better bring beer,” which made sense as BoFs are usually pretty informal. So Carl and I made a last minute beer run, which turned out to be more of challenge and involved more walking then we guessed. This led to us being twenty minutes late. When we got to the conference room, instead of the usual ten to twenty people sitting in a circle, chatting, Jerry was standing in the front of the room with a microphone facilitating discussion between thirty-five people, all sitting 330 at rows of long tables with white table clothes. Maybe fifteen people were actually participating in the discussion, but it was focused and pretty formal. Definitely not the place to bring a twelve-pack of Tecate. This was all made brutally apparent to Carl and I when we made our late entrance though a door behind Jerry at stage right, instead of through the normal entrance. Jerry said “hi guys” very kindly, perhaps making it seem like we were making this move on purpose, rather than attempting to make a shortcut from a loading dock after being lost for several minutes trying to find the conference room. Not long after we got there, some one in the audience interrupted Rick Clark and asked “wait, are you from Canonical?” Clark is the lead of the Ubuntu Server Team, who was sitting in the audience and was explaining some aspect of cloud computing using an Ubuntu example when interrupted. Rick seemed a little defensive, but calmly said yes, but “we’re not in the support department [another Canonical Server Team member is sitting beside him] so what I can tell you is ...” Fifteen minutes later Rick asks if it is okay if he plugs his session the next day, which is very on topic “Building a Private Cloud with Ubuntu Server.” But it feels a little odd and the slight discomfort is palpable, as in theory BoF sessions is a chance for folk with similar concerns to discuss an issue. It is interesting to see Clark discussing using Eucalyptus to setup a private cloud, when the cloud was in so much flux only a few months prior. The session never quite worked as a BoF and people seem somewhat surprised at the end of the session when Jerry confesses that he too is from Canonical and how this was interesting for him as “you [someone in the audience] were a perfect use case for us.” It feels a bit shady, or at least awkward, but 331 this is one of the natures of such a conference. Later, Jerry tells me that they specifically tried not to make a sales pitch, which is tricky, as he is on the Sales Team at Canonical. Walking this line between two different modes of production is awkward. It is hard to make a sales pitch, and hard not to sound like you are making a sales pitch. Performing such labor and walking this line has an immaterial element to it—creating certain feelings and relationships between (potential) customers and Canonical employees. But if the sale of support is successful, there will also likely be the production of new material substantial outputs—documentation of how to solve a problem. And this problem might be encountered by someone else, and such documentation often makes it back into the commons. As Ivan explains back in Chapter One, it might be a slow process because of non-disclosure agreements and the like, but eventually, one way or another, such documents usually find their way out to the community. Support becomes hard to sell when quality, freely given support is available and this mode for extracting value turns out not to be the source of surplus value it was dreamed to be. A spatial fix that relies upon a negotiation with the commons is far from a guarantee that any value can be extracted from the commons. This is the nature of the relationship between capitalism and the commons: it is fraught, messy, and brought into being by people who have very complex and multiple relationships to the object of work. All the Canonical employees in that BoF session care about code or FLOSS first, most of the time. This session might not be a very fun part of the work for most—this is an awkward intersection between capitalism and the commons and it takes place through 332 their bodies and their work. It is also a moment full of possibilities, that reveals dependencies between capitalism and the commons and between people and projects in the FLOSS ecosystem. Such awkwardness is a sign of there being other ways our computing environment could be organized, other ways of working, of having a little more fun. 333 Epilogue: We Simply Do Not Know What Our Work Does From the beginning of the writing process, my dissertation has been driven by Fredrick Kittler’s semi-famous passage about software: Programming languages have eroded the monopoly of ordinary language and grown into a new hierarchy of their own … from simple operation codes whose linguistic extension is still a hardware configuration passing through an assembler whose extension is that very assembler … we simply do not know what our writing does (Kittler 1997, 148). There is a corollary proposal, or perhaps a general proposal to Kittler’s particular thoughts on software: “We simply do not know what our work does.” In the case of FLOSS these two unknowns are nearly one and the same. On one had, the object of labor, code, does work, as a machine-like-thing, in the sense of using the prior human labor to transform the states of things (and is a machine in the sense that code has a lifetime and replaces human labor). Code performs transformations that we simply do not know, that are not legible or perceivable to human capacities. This is an invitation to do some quality guesswork, based in caring and careful research and writing. At the same time, once labor transforms code, we simply do not know to what end such labor might be put. No FLOSS coder, community, or firm can control how the code they produce is used; only that it is un-owned. All that I have written about “imminently productive labor” is something well known, and frequently discussed by FLOSS workers. Trying to know what we simply do not know about what our work does is an ever-lasting project under capitalism (and a real pain in the ass) but it is probably necessary to unraveling capitalism in a manner that does not tie more people up. Or as Stallman puts its, in his attempt to have some control over his work and make sure that the community he cares about has the capacity to reproduce itself: “If I had been developing proprietary software, I would have been spending my life building walls to imprison people” (Moody 2001, 19). Or as Benjamin Mako Hill asks, “how can we make sure that free software actually makes us more free?” Or, to ask the prior question that I am guessing Stallman asked and I know Mako asks: what does our work do? This is not the question I set out to answer, but it is the one that I found that matters, the simple and almost clear question that this dissertation is all about. What does our work do? Answering this question is a small and important step towards being able to call the world what it is, and in doing, bring it into a corporeal form to behold. In this moment, if there is a call for anything to be taken from this dissertation, it is a call for planning. Not knowing what our work does, even when striving to make the world in which we want to be living, is scary. Figuring out what our work does is an 334 early and ongoing step in planning. I set out on this project wanting to study FLOSS conventions for no good reason, convinced that they were hugely important. The magic of conventions is planning. FLOSS folk like and need to plan, from how to most effectively organize loosely affiliated groups of people working toward similar technical goals to how hack policy and legislatures to support open standards. Not knowing what FLOSS will do, but believing whole-heartedly in the possibilities FLOSS, demands planning, demands figuring out what what our work does, even if it is only quality guesswork. Everything in FLOSS is a gift and the reason that it is important to remember this truth is not because the gift is particularly transformative or particularly radical. Gifts are all around us, often ignored. Jono has it right when he says it is a little social science bullshity, but everything is a gift—it is important to remember this, to think about and deal with gifts in our reckoning of economies. Gift exchange will not solve problems or redistribute wealth any more than the commons will, but these systems of holding and exchanging things are not bent on their own destruction, but rather life and creation. There is hope in gifts and commons, for they help us understand the world before us. From watching and participating in some small struggles in FLOSS communities, I am all the more convinced that good planning is key to our futures. Planning can take the form of building the tools we need, imagining different ways of exchanging things and organizing ourselves, of figuring out what our work and our fun produces in the world and struggling to shape those often far removed products of our labor. In Ubuntu all the above happens all the time and it is very often fun. To say again, if there is one thing I learned about fun from this work it is that fun is general, that each and every object of labor has fun within it, and there is always fun to be had when people are able to work in a manner that is in accordance with the material at hand. I am still very curious where this might lead. 335 Glossary The following glossary may be useful for some technical terms used throughout this document. The definitions and any errors therein are mine. These definitions are meant to explain the terms as I am working with them; as such, the definitions may have some drift from particular disciplinary definitions. algorithm An algorithm is a set of code designed to sort information by using a set of steps in order to make some determination or decision about that information. Algorithms are most visible in human/computer interactions such as recommendations on a website based on previous user patterns (i.e. Netflix or Amazon recommendations), but they are also used in most basic signal process and have significant effects on our lives in unexpected manners. APT (or apt) In Debian-based Linux derivatives, APT (Advanced Packaging Tool) is an application that takes care of installing and removing software. This takes place via “packages” of software which are typically downloaded from software repositories on the internet. APT is one way to solve the technical problem of managing inter- related software dependencies and keeping software updated. This system of organizing software into packages structures much of the work on maintaining code in Ubuntu. bandwidth Bandwidth is a measurement of data moving capacity (or of data moved) and is usually expressed in megabytes per second or gigabytes per second (i.e. a 10 Gbits/s connection). Higher capacity and scalability in bandwidth is expensive, and is one of the major costs in providing any resource on the “cloud” or the internet. In the case of Ubuntu, mirrors are key to keeping bandwidth costs manageable. binary A system for representing information by only two symbols, usually 0 and 1 (or off / on). Our computing environment is binary based: binary counting is both the base of the logical languages used for creating code and the material base of storing data. Anything that can be used to represent 0s and 1s can be used as a binary storage medium (a loom, a set of hardwired switches, some plastic, or a metal platter). 336 BIOS A Basic Input/Output System (BIOS) is some code that is stored on a circuit board that is the first code to be run when most computing devices receive power. This code is the key to accessing the basic functions of the computer. bug An error, problem, or something unintended in computer code. Usually the result of functional code encountering new environments (i.e. being run on a different machine or interacting with some new code); but bugs are also just part of the ongoing work of making code. A term popularized in computing by an actual bug (a moth) being found to be trapped in a relay, causing an early computer to not function. capitalism A system of organizing work and materials based on the private ownership of the means of production and the appropriation of surplus value (meaning that value produced by a worker beyond what the worker receives in a wage). In other words, a system based on selling labor in which money is put in motion in order to produce more money. cloud The cloud or cloud computing is a misleading metaphor for a method of organizing computing resources. “The cloud” is actually made of data centers and thousands of servers that meet computational and storage needs of client computers or applications. Sending something to the cloud or relying upon the cloud refers to a way of abstracting computing resources from their material base—and has some technical base in “virtualization” (see definition below). code Code is often used to mean “source code,” the human readable logical language used to interact with the computing capacity of a machine. This human readable state is one form of code, but code has another form, when it is put to use it is material and movement, inseparable from machine. This dual nature is essential to comprehending code. Code of Conduct The Code of Conduct is the primary governance document in Ubuntu. It was designed as a corrective to some aspects of hacker and FLOSS culture and to codify others, and is a living document that has changed over time. The document was also designed to create a certain sort of community-based governance, and has been heralded as a key in the success and vibrancy of the Ubuntu community. See Appendix A for the full document. 337 code sprint A code spring is a week-long intense work session that brings together Ubuntu contributors (usually, but not exclusively Canonical employees) face-to-face to on a particular set of goals for a team. Part of the rhythm of travel and work for many Canonical employees, along with UDS (see below). compile To compile code is to transform some human readable source code into another language that can be executed. This process can take some time and fair amount of computing resources, depending all that is required for the code to become executable —there can be a good deal of waiting for something to compile. This waiting can be a moment that reveals the distances and resources involved in code production. computer A computer is an entity that performs mathematical computations (takes some input, processes it, stores it, and provides some form of meaningful output). “Computer” used to refer to human beings, but now usually refers to a discrete digital machine that performs calculations and has human (or machine) legible inputs and outputs. core dev Members of the Ubuntu Core Developers Team (core dev) that have rights to upload to the Main and Restricted Ubuntu repositories (the set of packages that constitute the core of Ubuntu). These developers are usually experienced contributors who have a history of working in Ubuntu and FLOSS, and the many are Canonical employees. crowd-sourcing Crowd-sourcing is a process that farms out small pieces of work to a large group of people, “the crowd.” It is usually done by a firm with the hopes of getting work done by unpaid or low-paid labor or to get work done that could not otherwise be readily organized. Amazon’s Mechanical Turk is the most common example, but less directly legible examples include “reCAPTHCA,” that little box that you type a word into to verify that you are not a robot on webpages (and also an example of work that is not otherwise readily organized). By doing so you are digitizing books for Google, and performing other value generating tasks. DARP A The Defense Advanced Research Projects Agency (DARPA) is a US Department of Defense agency that has organized workers into laboratories and teams which have in turn developed technologies such computer networking, and more directly insidious weapons. The goals of DARPA is to perform the research and development for military weapons and tools whose 338 need has not yet come to pass. Whether or not this makes the internet a military technology is an interesting question; at the least, DARPA must be understood as shaping much technological R+D and giving form to a particular state investment in what would come to be known as the military-industrial complex. data center A data center is ssually a large windowless building filled with servers, with power and data going in and with heat and much more data going out (data centers can take other built forms). Servers produce a great amount of heat in their operation, thus cooling data centers so computers (and their technicians) do not overheat is a major design challenge and power suck—data centers account for a significant percentage of overall energy use in the US. Downloading a file, using a shared document such as Google Docs, or using any service described with the word “cloud” means consuming this power and wearing down these servers, likely in several locations in world. Debian Debian is another version of GNU/Linux operating system. Debian is all volunteer run and is a highly respected organization and technical product in the FLOSS ecosystem. Ubuntu is based on Debian and all original Canonical employees were Debian developers. Every six months Ubuntu contributors take code from Debian and use it as the base from which the next Ubuntu release is built. Ubuntu was designed to have a regular six-month release cycle; Debian is designed to release a new version “when it’s ready.” The movement of code and people between Debian and Ubuntu has been a source of friction and debate in the FLOSS ecosystem. dependency A dependency refers to one discrete piece of code (such as a package in Ubuntu) needing another discrete piece of code in order to function. APT (see above) manages dependencies in Ubuntu and makes sure that when one package is requested, all other dependencies are met before installing the package. Dealing with this web of dependencies is key in fixing bugs and developing new features. digital Digital is often used and understood in opposition to analog. An analog technology, such as an analog storage medium, deals with the material waves produced by some phenomenon in another medium. For instance, light reflecting off a surface onto film or sound vibrating an apparatus that makes marks in a tape are analog means of storing information. Digital technology deals with discrete samples of, say, a sound wave, and converts a set of 339 points on the wave into a binary form—a set of zeros and ones. Thus all things digital require something (some machine, almost always using code) to understand how those zeros and ones can be turned back into a sound wave, into a letter captured from a keyboard stroke, or anything else for which a system has been designed to figure how to capture some signal in the world by a set of samples. distribution In the FLOSS world, a distribution refers to a version of the GNU/Linux operating system. Distributions are developed and supported by a variety of types of organizations, and have different goals and users in mind. Ubuntu is one of the most popular distributions, but there are many other distributions and popularity waxes and wanes as with the movement of resources and developers, technical choices, and the actions of FLOSS leaders and personalities. downstream A downstream or being downstream is a position defined by the relative movement of code. In Ubuntu, a downstream is a project that uses Ubuntu code, such as MythBuntu, an Ubuntu derivative optimized for MythTV, a FLOSS personal video recorder project. At the same time, Ubuntu is downstream from MythTV, as Ubuntu packages MythTV. driver A driver is some code that makes sense of the inputs/outputs of some hardware so that other code can use that hardware, such as a heat sensor on a circuit board. Such a sensor is a mesh of code, metals, and plastics and it puts out a signal when the circuit board has power. For that signal to be legible as a number on a temperature scale, there must be some code that can read the signal. The signal may be encoded in a way designed to work with some particular proprietary code, and without knowledge of how that sensor and its signal works, the sensor is useless. In this way, for FLOSS users, drivers can become a site of struggle between modes of production. encoded Encoding something refers to turning it into digital form or changing somethings already digital form. This process can thus take place when some information is captured by a digital device —like taking a photo—or when something already digital turned into another digital form—selecting “save as” while editing the photo you just took and storing it in a different file format. enterprise Enterprise refers to the size of a firm (or organization). An “enterprise” client is usually one that requires a large scale of computing devices—hundreds to hundreds of thousands—and 340 thus usually relies upon technical tools for the simultaneous or automatic management of these computing devices. Firms or organizations at such a scale often have contractually required support contracts, making enterprise clients appealing to firms like Canonical. Also, the scale of such organizations also creates technical issues and challenges that many systems administrators find interesting and fun. fiber Fiber optic cabling is the main transmission medium in the “backbone” of the digital computing networks and the internet. The ownership of this cable is big business and is one of the primary ways that the internet is private property. firm A firm is a way of organizing productive resources. A firm is usually owned by a private entity, composed of a group of people who have entered into a partnership with a hierarchal structure, and is designed to create some commodity (something to sell on a market). This form is backed by the power of law, in the US, taking the form of the limited liability company. fork As in fork in the road. To fork a FLOSS project means taking the code of a project in another direction, while the existing project keeps on. This is sometimes a source of contention in FLOSS—a fork can be both the source of new life for a project and tear apart the social world of a project: for instance, some consider Ubuntu a fork of Debian, others consider it a derivative. Either way, the fact that code can be forked is important to FLOSS projects—this is one way that project leadership (whether it be a firm or a volunteer board or an individual) is held accountable to the community of developers and users of project. FTP File Transfer Protocol is client/server system for storing and retrieving files over a network. FTP was one of the technologies that made it possible to share software over the internet—Linux was first shared via FTP. GNU GNU is a recursive acronym for GNU’s not Unix. GNU is a Free Software Foundation attempt that began in 1983 to create a non- proprietary operating system. The project remained unfinished until 1991 with the creation of the Linux kernel, which used GNU tools. GNU is part of the larger GNU Project, which seeks to achieve Richard Stallman’s goal of creating a body of free software such that no one would have any reason to use non-free (proprietary) software. 341 GPL The GNU Public License (GPL) is the most widely used FLOSS license. The GPL is a copyleft license, meaning that if code licensed via the GPL, whenever that code is changed or distributed by any entity, all dependent and new code must also be GPL’d. This reciprocity is opposed to “permissive” FLOSS licenses, which allow for derivatives to be licensed in a variety of ways. Because of the significant difference in how code moves and is shared between these two types of licenses, there has been much debate and disagreement about licensing in FLOSS. GUI A Graphical User Interface (GUI) is a layer on top of the functional capacity of a computer program that allows for interaction via visual metaphors such as “buttons” or the like, which take the place of text based, typed out commands. In FLOSS and hacker worlds, a GUI is often considered a “user feature” with occasional disdain, as opposed to the “power” and customization possibilities of the command line. As Ubuntu seeks to create a user experience that “just works,” developing effective GUIs and other “user features” has been a primary goal of Ubuntu development. hardware Hardware is an abstraction used for understanding our computing environment. Anything computing related that you can pick up and hold is typically considered hardware—even as such things are usually made with code as well. Definitions of hardware/software have changed significantly over time, and what counts as hardware or software has come to be backed by the force of law, such as software patents. internet Often defined by the protocol used for the packet-switched movement of data, TCP/IP, the internet is the totality of all public networks connected to each other via these protocols. The internet is thus all connected computing devices and the cables, switches, buildings, land, servers, electricity, and more, combined with millions of people’s labor. The internet is thus usefully thought of as a thing and as infrastructure, rather than as a protocol or an ethereal web of connections. IRC Internet Relay Chat (IRC) is a text-based communication medium that is the primary mode of communication in Ubuntu—in part because it functions as both a synchronous and as a asynchronous mode of communication. Communication in IRC is realtime, but it can also be easily logged and checked in on at a later date— making it a good tool for public meetings. Topical channels allow 342 Ubuntu contributors to “reside” in certain channels relevant to their work and interests, thus IRC channels become places where you know you can find certain people at certain times. Launchpad Launchpad is a website developed by Canonical designed for FLOSS development, including bug tracking, code hosting, translations and other features. Launchpad is used by a variety of projects in addition to Ubuntu. Launchpad was developed as proprietary software and then open-sourced in 2009, under some pressure from those in FLOSS communities that saw Launchpad as antithetical to the FLOSS principles championed by Canonical. Much Ubuntu work is collected and shared via Launchpad, which includes numerous metrics for keeping track of individual and team contributions. LoCo A Local Community Team (LoCo) is a region-based team of Ubuntu enthusiasts. LoCos are supported by Canonical with web- hosting and other communications infrastructural support, as well as a LoCo Council that approves teams, resolves conflicts and allocates resources. The LoCo Council is made of Ubuntu community members, usually folk who have been active in a LoCo team. LoCos are often a key vector through which people interested in Ubuntu get more involved in the project, especially in translations, promotion, and other non-coding aspects of creating Ubuntu. machine A machine is a device that replaces human labor—not augments, like a broom, but replaces, like a street sweeper. This means that machines typically have two or more moving parts and are in some way powered—mechanically or electrically. In their complexity, machines often exceed the capacities of human labor, such as the computational power of a computing device. Machines store the dead labor of their makers, which is called back to life in the use of the machine. machine code Machine code is code that is executable by a digital computing device, taking binary form (also called binary code, executable code, and machine language). The term “machine code” reminds us that it is code for machines that can move and be active on a machine. As machine code can not be understood by humans (or at least has a barrier to comprehension that is high enough to most often render it illegible), code that is distributed in this manner alone cannot be readily changed, making it the preferred mode of exchanging and moving proprietary code. 343 machine time Machine time is the compulsory movement of human bodies in accordance with the rhythms of machines. This concept is easy to see in many workplaces, and is especially clear when thinking about production lines. Machine time gets somewhat more complicated in labor process dependent upon computing machines. The place of laboring is essential to understanding machine time—such time can only come into being in place, and the place of work matters, be it a cubicle, a classroom, an assembly line, or a home office. mirror A mirror is a copy of some code on one server to an identical “mirror” in another location. For instance, the code that constitutes Ubuntu is hosted on many different mirrors, most hosted by universities, internet service providers, or other entities that have cheap or free bandwidth to donate and available servers (see Appendix C for a list). This allows for many people in many different locations to download or update Ubuntu at the same time and still maintain a reasonable download speed. Place matters here, closer mirrors are typically faster, as the data will have to be routed through less steps, but many other factors also affect the speed of downloads. Mirrors provide key infrastructure for FLOSS use and development. MOTU Masters of the Universe, referring to the “Universe” and “Multiverse” repository. The Universe repository consists of community maintained packages that are not officially supported by Canonical; the Multiverse repository consists of software that is not free (it is distributed only in binary form, or otherwise does not use a FLOSS license). There are approximately 150 MOTU members, who have applied to the MOTU Council, have had their work reviewed by their peers, and are granted commit rights (the right to comit changes in the code to the code base) to the repositories. This system is in flux at the time of writing. ODM/OEM Original Design Manufacturers (ODMs) and Original Equipment Manufacturers (OEMs) are firms that do the vast majority of electronics and computing manufacturing. ODMs design a complete product to be branded by another firm; OEMs design components to be used in other firm’s end consumer products. ODM/OEMs are relevant to FLOSS because the parts are usually made to communicate with proprietary softwares; thus, making FLOSS work requires working with ODM/OEMs or a great deal of reverse engineering (sometimes illegal because of intellectual property laws) or a different computer manufacturing system. 344 package In APT-based Linux distributions such as Ubuntu, a package is a partition of code that performs some discrete purpose—it could be a standalone program, but most programs are composed of or rely upon a set of many packages. “Packaging” is thus most of the work of making Ubuntu—making sure that each discrete set of code works with all others, has Ubuntu branding, and is as up- to-date and bug-free as possible. packet-switched A packet is a block of data (a certain number of 0s and 1s) and packet-switched refers to the system and network infrastructure for moving these packets via specific types of computers that queue and route (switch) these packets. Packets contain information about their unique destination (and IP address and some more “control information”) and each packet can be routed through a variety of possible paths, before being assembled by the destination machine in the proper order. Packets can get lost or slowed down in this process, experienced by users as some delay in receiving information or some loss (such as a dropped frame in a video). patches In between planned major updates or released, a patch is fix for some problem (some bug) in existing code. peer-to-peer networking Peer-to-peer (or P2P) networking is a form of moving data over the internet (or other network) that does not rely upon a central host, instead data is moved between machines that are both using the data, the most famous example being Napster. In this setup, every connected machine can function as both a client (sending a request for data) and as a server (“serving” the data to the client). This is closer to the original design intentions of the internet, where every machine is both client/server, unlike the model that evolved, where most data is served by content providers. This architecture is another way for performing the computing and networking functions currently provided by data centers. proprietary Also called closed-source or non-free in FLOSS worlds, proprietary refers to software that is licensed such that the owner has exclusive rights over how the software is used and distributed. Proprietary software is almost always distributed with only the binaries—only the executable machine code—and thus is can be used, but its operations are opaque and it can not readily be modified. Proprietary software is not any natural state of distributed code—software existed for decades before the idea or practice that it could be owned in this manner came into being. 345 repository A repository is a place that code is stored, waiting to be put to use. In Ubuntu, and other package-based systems, to access this code, the location of the repository is added to a list of sources and then a program such as APT is used to request and install packages for the repository. Repositories may be maintained and hosed (and mirrored) by any number of entities—for instance, Canonical provides repository hosting for anyone registered on Launchpad (but Canonical only supports software in the Main and Restricted repositories). server A server is a computing device that is used to “serve” data as one part of the client/server model of networking. A server accepts request from clients and performs some action, from sending data to performing computational task. This model is typically used to refer to discrete machines (separate clients and servers) but client and server can also be applications run on the same machine. software Software is generally considered the “intangible rather than physical” part of a computing device, a distinction that casts software into the realm of the invisible, fleeting, and placeless. Software is thus best understood as an abstraction that used to make sense of our computing environment. Code (see above) can be understood as the material that carries software. source code Source code refers to the human readable code that coders write —knowing the language in which it is written (or another similar language) usually means being understand what the source code is attempting to do. Source code must be turned into machine code to be put to work (that is, be compiled) and once in the form of machine code, it is impossible to change any mildly complicated software without the source code. Things are a bit more complicated than this and do not always work the same way with every language or type of compiler, but the gist is: source code (human readable) is written, then run through a compiler and turned into machine code (0s and 1s which are then able to move through the binary operation of a computing device). Source code is often privileged as a window into the truth of code; but it must not be considered alone, code’s other side, as part of the machine, must also be taken into account. technology Technology is some human developed device that augments human capacity to change some material from one state to another —from a hatchet to an integrated circuit. Usually refers to some set or system in which the technology is embedded—that is, any 346 given technology is of its time and place, and has meaning and value defined by the system it is part of. UDS The Ubuntu Developer Summit is a week-long biannual meeting of Ubuntu contributors. The goals of UDS are to work from proposed blueprints to create actionable plans for the next release, to discuss, clarify, and evaluate new organizational or management systems, and to “recharge” the bonds that hold together teams and Ubuntu contributors together. Almost all UDS meetings are open to the public, many Canonical employees are required to attend, and some sponsorships are available for non- Canonical employees to defray costs of attending. UNIX UNIX is a multitasking (meaning multiple computing processes can share a single central processor) operating system developed by Bell Labs in the late 1960s. UNIX quickly became very popular in many computing environments, including for academic and research use and was distributed, along with its source code, with computers. In the early 1980s, UNIX was distributed as a commodity for the first time, an effort that was in part enabled by a 1983 antitrust case against AT&T that made it legal for the firm to commercialize UNIX. This had devastating effects for many UNIX users, especially those at universities, and created the development and adoption context for GNU/Linux (GNU being a recursive acronym for GNU’s not UNIX). upstream An upstream (or being upstream) is a position defined by the relative movement of code. In Ubuntu, an upstream is a project that is used in Ubuntu, such as MythTV, a FLOSS personal video recorder project. At the same time, Ubuntu is an upstream for MythBuntu, an Ubuntu derivative optimized for MythTV. version control Version control systems enable many people to work on the same discrete set of code simultaneously (although version control may still be used by a single coder working on a project alone). Different systems have different organizational structures for how rights to make changes are allocated or how the review of code changes should proceed—thus it is very important to have a version control system that works well with the other system of social organization of any given coding project. All systems rely upon some method for “checking out code,”—time-stamping, identifying and ordering changes to the code, and locating and fixing bugs. In Ubuntu this is handled by the program Bazaar and the code is hosted via Launchpad. 347 virtualization Virtualization is the practice of creating “virtual” installations of an operating system inside of another operating system—allowing for testing and for quick expansion/contraction when demand for computing resources changes. This means that it is possible to run one operating system inside another (to run Microsoft Windows as a process inside of an install of Ubuntu). This process abstracts operating systems (and servers) from the machines upon which they run and makes it easier to move and scale applications and move both servers and applications across the machines upon which they run. 348 Bibliography Achor, S. 2010. The Happiness Advantage: The Seven Principles of Positive Psychology That Fuel Success and Performance at Work. Random House Digital, Inc. ACM, and IEEE. 1987. Exploring technology. Washington DC: Computer Society Press of the IEEE. Adler, P. 2006. Beyond “hacker idiocy:” The Changing Nature of Software Community and Identity. In The firm as a collaborative community: reconstructing trust in the knowledge economy, eds. C. C. Heckscher and P. S. Adler. New York: Oxford University Press. Agamben, G. 1993. The coming community. Minneapolis: University of Minnesota Press. Althusser, L. 1970. Reading Capital. London: NLB. Andrejevic, M. 2009. Exploiting YouTube: Contradictions of user-generated labor. The YouTube Reader :406–423. Asheim, B., L. Coenen, and J. Vang. 2007. Face-to-face, buzz, and knowledge bases: Sociospatial implications for learning, innovation, and innovation policy. Environment and Planning C: Government and Policy 25 (5):655–670. Bacon, J. 2011. Community Management Crib Notes - Dealing With Burnout. http://www.youtube.com/watch?v=I88yluGb9oE&feature=youtube_gdata_player (last accessed 21 November 2011). Baden, J. 1998. Managing the Commons 2nd ed. Bloomington: Indiana University Press. Bakke, D. 2005. Joy at work : a revolutionary approach to fun on the job   . Seattle, WA: PVG. Balsamo, A. 2008. Designing Culture: The Technological Imagination at Work. Forthcoming: Duke University Press. Banks, M. 2007. The Politics of Cultural Work. Basingstoke ; New York: Palgrave   Macmillan. Barcet, N. 2011. UDD: Developing applications for the cloud | Nicolas Barcet. http://nicolas.barcet.com/drupal/en/udd-dev-app-for-cloud (last accessed 13 November 2011). Bar, F. 2001. The construction of marketplace architecture. In Tracking a Transformation: E-commerce and the Terms of Competition in Industries, 27–49. 349 Barnes, P. 2006. Capitalism 3.0 : a guide to reclaiming the commons   . Berkeley: Berrett- Koehler. Barnes, T. 2005. Culture: Economy. In Spaces of geographical thought: deconstructing human geography’s binaries, 61. Bayat, A. 2007. Islamism and the Politics of Fun. Public Culture 19 (3):433. Bayliss, D. 2007. The rise of the creative city: Culture and creativity in Copenhagen. European Planning Studies 15 (7):889–903. Beer, D. 2010. Mobile Music, Coded Objects and Everyday Spaces. Mobilities 5:469– 484. (last accessed 2 November 2011). Benkler, Y. 2003. Coase’s Penguin, or Linux and the Nature of the Firm. Yale Law Journal 112. ———. 2006. The Wealth of Networks: How Social Production Transforms Markets and Freedom. Yale University Press. Benkler, Y., and H. Nissenbaum. 2006. Commons-based Peer Production and Virtue. Journal of Political Philosophy 14 (4):394–419. V on Bergen, C., W. Mawer, and P. W. Pool. 2005. To Be, or not To Be: That is the Question: Whether ’Tis Nobler to Implement the Fairpay Overtime Initiative or not? Southern Law Journal 15:122–141. Bergquist, M., and J. Ljungberg. 2001. The power of gifts: organizing social relationships in open source communities. Information Systems Journal 11 (4):305–320. Bianco, A. T., E. T. Higgins, and A. Klem. 2003. How “Fun/Importance” Fit Affects Performance: Relating Implicit Theories to Instructions. Personality and Social Psychology Bulletin 29 (9):1091–1103. Bitzer, J., W. Schrettl, and P. J. H. Schröder. 2007. Intrinsic motivation in open source software development. Journal of Comparative Economics 35 (1):160–169. Blair, C. 1998. Netsex: Empowerment through discourse. Cyberghetto or Cybertopia. Race, Class, and Gender on the Internet :205–218. Blythe, M. A., and M. Hassenzahl. 2004. The Semantics of Fun: Differentiating Enjoyable Experiences. In Funology: From Usability to Enjoyment. Dordrecht ; Boston:   Kluwer Academic Publishers. 350 Boczkowski, P. J., and J. A. Ferris. 2005. Multiple media, convergent processes, and divergent products: Organizational innovation in digital media production at a european firm. The ANNALS of the American Academy of Political and Social Science 597 (1):32. Böhm, S., and C. Land. 2009. No measure for culture? Value in the new economy. Capital & Class 33 (1):75. Bollier, D. 2002. Silent theft : the private plunder of our common wealth   . New York: Routledge. Bonaccorsi, A., and C. Rossi. 2005. Altruistic individuals, selfish firms? First Monday (Special Issue #2). Botton, A. D. 2009. The Pleasures and Sorrows of Work. New York: Pantheon Books. Boyle, J. 2003. The Second Enclosure Movement and the Construction of the Public Domain. Law and Contemporary Problems 66:33–74. Brandzaeg, P., A. Bae, and J. Heim. 2004. Enjoyment: Lessons from Karasek. In Funology: From Usability to Enjoyment. Dordrecht ; Boston: Kluwer Academic   Publishers. Braverman, H. 1998. Labor and Monopoly Capital: The Degradation of Work in the Twentieth Century Anv. Monthly Review Press. Breathnach, P. 2000. Globalisation, information technology and the emergence of niche transnational cities: the growth of the call centre sector in Dublin. Geoforum 31 (4):477– 485. Brenner, N. 2002. Spaces of neoliberalism : urban restructuring in North America and   Western Europe. Malden Mass. ;;Oxford: Blackwell.   Brenner, N., and N. Theodore. 2002. Preface: From the “New Localism” to the Spaces of Neoliberalism. Antipode 34 (3):341–347. (last accessed 3 April 2009). Brooks, F. 1995. The Mythical Man-Month. Pearson Education. Brunn, S. D., and T. R. Leinbach. 1991. Collapsing space and time: geographic aspects of communications and information. Other. Burston, J., N. Dyer-Witheford, and A. Hearn. 2010. Digital labour: Workers, authors, citizens. Butler, J. 1993. Bodies That Matter: On the Discursive Limits of “sex.” New York: Routledge. 351 Byfield, B. 2011. Ubuntu: Where Did the Love Go? — Datamation.com. http://itmanagement.earthweb.com/osrc/article.php/3925641/Ubuntu-Where-Did-the- Love-Go.htm (last accessed 25 May 2011). Caffentzis, G. 2008. Autonomous Universities and the Making of the Knowledge Commons. ———. 2007. Crystals and analytic engines: historical and conceptual preliminaries to a new theory of machines. ephemera :24. Camfield, D. [1]. 2007. The Multitude and the Kangaroo: A Critique of Hardt and Negri’s Theory of Immaterial Labour. Historical Materialism 15:21–52. Campbell, J. 1989. Joy in Work, German Work: The National Debate, 1800-1945. Princeton, N.J.: Princeton Univ Press. Canonical. 2009. Bug #1 in Ubuntu: “Microsoft has a majority market share.” https://bugs.launchpad.net/ubuntu/+bug/1 (last accessed 4 May 2009). Cartier, C., M. Castells, and J. L. Qiu. 2005. The Information Have-Less: Inequality, Mobility, and Translocal Networks in Chinese Cities. Studies in Comparative International Development 40:9–34. Casarino, C. 2008. In praise of the common : a conversation on philosophy and politics   . Minneapolis: University of Minnesota Press. Casarino, C., and A. Negri. 2008. In Praise of the Common : a conversation on   philosophy and politics. Minneapolis: University of Minnesota Press. Castells, M. 2004. Space of Flows, Space of Places: Materials for a Theory of Urbanism in the Information Age. In The Cybercities Reader. Taylor & Fracis Books. ———. 2001a. The Internet Galaxy: reflections on the internet, business, and society. New York: Oxford University Press. ———. 2001b. The Internet Galaxy: reflections on the internet, business, and society. New York: Oxford University Press. ———. 2002. The Rise of the Network Society. Malden: Blackwell. Ceruzzi, P. E. 2003. A history of modern computing. Cambridge, MA: MIT Press. Chan, A. 2004. Coding Free Software, Coding Free States. Anthropological Quarterly 77:531–545. 352 Chiao, B. 2003. An Economic Theory of Free and Open Source Software: A Tour from Lighthouse to Chinese-Style Socialism. In Proceedings of the International Conference on Open Source, 61—80. Chopra, S., and S. Dexter. 2008. Decoding Liberation: The Promise of Free and Open Source Software. New York: Routledge. Chun, W. H. K. 2006. Control and Freedom: Power and Paranoia in the Age of Fiber Optics. Cambridge Mass.: MIT Press. Chun, W. H. K., and T. Keenan. 2006. New media, old media : a history and theory   reader. New York: Routledge. Cleaver, H. 2000. Reading Capital politically. Edinburgh: AK Press. Coffey, W. J. 2000. The geographies of producer services. Urban geography 21 (2):170– 183. Coleman, G. 2004. The Political Agnosticism of Free and Open Source Software and the Inadvertent Politics of Contrast. Anthropological Quarterly 77 (3):507–519. ———. 2005. The Social Construction of Freedom in Free and Open Source Software: Hackers, Ethics, and the Liberal Tradition. Ph.D Thesis: The University of Chicago. Coleman, G., and A. Golub. 2008. Hacker practice: Moral genres and the cultural articulation of liberalism. Anthropological Theory 8 (3):255–277. (last accessed 22 October 2008). Coleman, G., and M. Hill. 2004. How free became open and everything else under the sun. M/C: A Journal of Media and Culture 7 (3). Coleman, S., and Nick Dyer-Witheford. 2007. Playing on the digital commons: collectivities, capital and contestation in videogame culture. Media Culture Society 29 (6):934–953. (last accessed 30 March 2009). Costa, M. D., and S. James. 1975. The Power of women and the subversion of the community. Falling Wall Press Ltd. Creative Industries Task Force. 2001. Creative Industries Mapping Document. http://www.culture.gov.uk/global/publications/archive_2001/ci_mapping_doc_2001.htm. Csikszentmihalyi, M. 1975. Beyond boredom and anxiety: the experience of play in work and games. San Francisco: Jossey-Bass Publishers. Cumbers, A., C. Nativel, and P. Routledge. 2008. Labour agency and union positionalities in global production networks. Journal of Economic Geography 8 (3):369–387. 353 Curien, N., E. Fauchart, G. Laffond, and F. Moreau. 2006. Online consumer communities: escaping the tragedy of the digital commons. In Internet and Digital Economics, 201–219. Cambridge, MA: Cambridge University Press. Currah, A. 2007. Managing creativity: The tensions between commodities and gifts in a digital networked environment. Economy and Society 36 (3):467–494. Daniels, P. W. 2006. On Services and Economic Geography. In Economic geography: past, present and future. Taylor & Francis. Davis, M. 1998. City of Quartz: Excavating the Future in Los Angeles. New York: Verso. Deci. 1971. Effects of externally mediated rewards on intrinsic motivation. Journal of Personality and Social Psychology. Vol. 18(1) 18 (1):105–115. Deci, E. L. 1975. Intrinsic Motivation. London: Plenum Press. Deci, E. L., R. Koestner, and R. M. Ryan. 1999. A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation. Psychological bulletin 125:627–668. Deleuze, G., and F. Guattari. 1987. A thousand plateaus : capitalism and schizophrenia   . London : New York: Continuum.   Demazière, D., F. Horn, and Nicolas Jullien. 2006. How free software developers work. The mobilization of “distant communities.” Cahier de Recherche. DiBona, C., D. Cooper, and M. Stone. 2005. Open sources 2.0: the continuing evolution. Sebastopol, Calif: O’Reilly. DiBona, C., and S. Ockman. 1999. Open sources: voices from the open source revolution. Sebastopol, Calif: O’Reilly. DiBona, C., M. Stone, and D. Cooper. 2005. Introduction. In Open Sources 2.0. Sebastopol, Calif: O’Reilly. Dicken, P. 1998. Global shift: transforming the world economy. Paul Chapman. Dodge, Martin, and Rob Kitchin. 2009. Software, objects, and home space. Environment and Planning A 41 (6):1344–1365. Dodge, M., and R. Kitchin. 2005a. Code and the Transduction of Space. Annals of the Association of American Geographers 95 (1):162–180. ———. 2005b. Codes of life: identification codes and the machine-readable world. Environment and Planning D 23 (6):851. 354 Donert, K., and S. Graham. 2000. Virtually Geography: Aspects of the Changing Geography of Information and Communication The end of geography or the explosion of place? Conceptualizing space, place and information technology. Geography : Journal of   the Geographical Association 85 (1):37. Doucette, J. 2010. The Constitutive Insde: Contingency, Hegemony, and Labour’s Spatial Fix. In Missing Links in Labour Geography. Ashgate Publishing, Ltd. Dowling, E. 2007. Producing the dining experience: measure, subjectivity and the affective worker. ephemera :117. Downey, A. 2002. How to think like a computer scientist : learning with Python   . Wellsley , Mass: Green Tea Press. Drake, G. 2003. “This place gives me space”: place and creativity in the creative industries. Geoforum 34 (4):511–524. Dropbox. .dropbox-dist « Dropbox Forums. http://forums.dropbox.com/topic.php?   id=4592 (last accessed 22 November 2011). ———. 2011. You back up me but who backs up you? « Dropbox Forums.   http://forums.dropbox.com/topic.php?id=27889 (last accessed 10 October 2011). Dyer-Witheford, Nick. 1999. Cyber-Marx : cycles and circuits of struggle in high-   technology capitalism. Urbana: University of Illinois Press. ———. 2001. Empire, Immaterial Labor, the New Combinations, and the Global Worker. Rethinking Marxism 13 (3):70–80. Dyer-Witheford, Nick, and G. De Peuter. 2009. Games of empire: global capitalism and video games. Minneapolis: Univ Of Minnesota Press. Economist. 2007. Google: Inside the Googleplex. The Economist. http://www.economist.com/displaystory.cfm?story_id=9719610 (last accessed 2 July 2008). Ehrenreich, B. 2008. Nickel and Dimed: On (Not) Getting By in America. Macmillan. English-Lueck, J. A., C. N. Darrah, and A. Saveri. 2002. Trusting Strangers: Work Relationships in Four High-Tech Communities. Information, Communication & Society 5:90–108. Eucalyptus Systems, Inc. 2009. The Eucalyptus Story | Eucalyptus. http://www.eucalyptus.com/about/story (last accessed 13 November 2009). Federici, S. 1975. Wages against housework. London: Power of Women Collective. 355 Feller, J. 2005. Perspectives on Free and Open Source Software. Cambridge Mass: MIT Press. Firth, D. 1995. How to Make Work Fun!: An Alphabet of Possibilities. Brookfield VT: Gower. Fish, A., L. F. R. Murillo, L. Nguyen, A. Panofsky, et al. 2011. Birds of the Internet -- Towards a field guide to the organization and governance of participation. Journal of Cultural Economy 4 (2):157. Flew, T. 2011. The Creative Industries: Culture and Policy. SAGE Publications. Florida, R. L. 2002. The Rise of the Creative Class: And How It’s Transforming Work, Leisure, Community and Everyday Life. Basic Books. Forer, P., and N. Parrott. 1991. Information and urban growth in the periphery of the global village: New Zealand and the international information economy. In Collapsing space and time: geographic aspects of communications and information, 302. Fortunati, L. 2007. Immaterial labor and its machinization. Ephemera. Theory & Politics in Organization 7 (1):139–157. ———. 1995. The arcane of reproduction : housework, prostitution, labor and capital   . Brooklyn, N.Y.: Autonomedia. Foucault, M. 1990a. The history of sexuality: An Introduction. New York: Vintage Books. ———. 1990b. The history of sexuality: An Introduction. New York: Vintage Books. Foucault, M., and Collège de France. 2008. The birth of biopolitics : lectures at the   Collège de France, 1978-79. New York: Palgrave Macmillan. Frey, B. S., and A. Stutzer. 2002. Happiness and Economics: How the Economy and Institutions Affect Human Well-Being. Princeton University Press. Friedman, A. 1989. Computer systems development : history, organization, and   implementation. New York: Wiley. Fuchs, C. 2002. Software Engineering and the Production of Surplus Value. Cultural Logic 4 (3). Fuller, M. 2003. Behind the blip: essays on the culture of software. Autonomedia. Gallaway, T., and D. Kinnear. 2004. Open Source Software, the Wrongs of Copyright, and the Rise of Technology. Journal of Economic Issues 38 (2):467–474. 356 Garnham, N. 2005. From cultural to creative industries: An analysis of the implications of the “creative industries” approach to arts and media policy making in the United Kingdom. International journal of cultural policy 11 (1):15–29. Gell, A. 1998. Art and agency: an anthropological theory. New York NY: Clarendon Press. Ghosh, R. A. 1998. Cooking Pot Markets: An Economic Model for the Trade in Free Goods and Services on the Internet’. Brazilian Electronic Journal of Economics 1 (1). Ghosh, R. A., R. Glott, B. Krieger, and G. Robles. 2002. Free/Libre and Open Source Software: Survey and Study. International Institute of Infonomics, University of Maastricht Free. Gibson-Graham, J. K. 1996. The End of Capitalism (As We Knew It): A Feminist Critique of Political Economy. Oxford: Blackwell. Gill, R., and A. Pratt. 2008. In the Social Factory? Immaterial Labour, Precariousness and Cultural Work. Theory, Culture & Society 25:1. Gilmore, R. 2007. Golden gulag : prisons, surplus, crisis, and opposition in globalizing   California. Berkeley: University of California Press. Glasmeier, A., and M. Howland. 1995. From combines to computers: Rural services and development in the age of information technology. Albany: State University of New York Press. Gonzalez-Barahona, J. M., G. Robles, R. Andradas-Izquierdo, and R. A. Ghosh. 2008. Geographic origin of libre software developers. Information Economics and Policy 20 (4):356–363. Google. 2008. More Google: Inside Google. http://www.google.com/plex/ (last accessed 2 July 2008). Google Wave Developer Preview at Google I/O 2009. 2009. http://www.youtube.com/watch?v=v_UyVmITiYQ&feature=youtube_gdata (last accessed 22 October 2009). Gordon, A. 2007. Ghostly matters : haunting and the sociological imagination   . Minneapolis: University of Minnesota Press. Graham, S. 2005. Software-sorted geographies. Progress in Human Geography 29 (5):562. ———. 2004. The Cybercities Reader. Routledge. 357 Gray, M. 2004. The social construction of the service sector: institutional structures and labour market outcomes. Geoforum 35 (1):23–34. Hall, S. 1996. Stuart Hall: Critical Dialogues in Cultural Studies. New York: Routledge. Hardin, G. 1968. The Tragedy of the Commons. Science 162 (3859):1243–1248. Hardt, M., and A. Negri. 2009. Commonwealth. Cambridge Mass.: Belknap Press of Harvard University Press. ———. 2000. Empire. Cambridge MA: Harvard University Press. ———. 2004. Multitude: war and democracy in the Age of Empire. New York: The Penguin Press. Hars, A., and S. Ou. 2001. Working for Free? - Motivations of Participating in Open Source Projects. In Proceedings of the 34th Annual Hawaii International Conference on System Sciences, 7014. IEEE Computer Society http://portal.acm.org/citation.cfm? id=821962. Harvey, D. 2005. A Brief History of Neoliberalism. New York: Oxford University Press. ———. 2001. Spaces of capital : towards a critical geography   . New York: Routledge. ———. 1999. The Limits to Capital. New York: Verso. Hayden, D. 1997. The power of place: Urban landscapes as public history. The MIT Press. Hayles, N. 1999. How We Became Posthuman: Virtual Bodies in Cybernetics, Literature, and Informatics. Chicago Ill.: University of Chicago Press. Hemsath, D. 1997. 301 Ways to Have Fun at Work 1st ed. San Francisco Calif.: Berrett- Koehler. Hepworth, M. E. 1989. Geography of the information economy. London: Belhaven. Herod, A. 1997. From a Geography of Labor to a Labor Geography: Labor’s Spatial Fix and the Geography of Capitalism. Antipode 29 (1):1–31. Herod, A., and L. L. M. Aguiar. 2006. Introduction: Geographies of Neoliberalism. Antipode 38 (3):435–439. Hertel, G., S. Niedner, and S. Herrmann. 2003. Motivation of software developers in Open Source projects: an Internet-based survey of contributors to the Linux kernel. Research Policy 32 (7):1159–1177. 358 Hesmondhalgh, D. 2007. The cultural industries. Thousand Oaks, Calif: SAGE. ———. 2010. User-generated content, free labour and the cultural industries. Ephemera. Theory & Politics in Organization 10 (3). Hess, C. 2007. Understanding Knowledge as a Commons: From Theory to Practice. Cambridge Mass.: MIT Press. Hill, B. M. 2008. Samir Chopra, Scott D. Dexter, Decoding Liberation: The Promise of Free and Open Source Software. Minds and Machines 18 (2):297–299. Himanen, P. 2001. The hacker ethic, and the spirit of the information age. New York: Random House. von Hippel, Eric. 2005. Democratizing Innovation. Cambridge Mass.: MIT Press. von Hippel, E. 2001. Open Source Shows the Way: Innovation by and for Users–No Manufacturer Required. Sloan Management Review 42 (4):82–86. Hoagland, E. 2006. TIME: Life in the Googleplex Photo Essay. http://www.time.com/time/photoessays/2006/inside_google/ (last accessed 2 July 2008). Hodges, A. 1983. Alan Turing: The Enigma. New York, NY: Simon and Schuster. Howland, M. 1993. Technological change and the spatial restructuring of data entry and processing services. Technological Forecasting and Social Change 43 (2):185–196. Huizinga, J. 1998. Homo Ludens: A Study of the Play-Element in Culture. Routledge. Hyde, L. 2010. Common as Air: Revolution, Art, and Ownership. Macmillan. ———. 2009. In Defense of the Cultural Commons; Presentation at the University of Southern California. ———. 1983. The Gift: Imagination and the Erotic Life of Property. New York, NY: Vintage Books. Indergaard, M. 2004. Silicon Alley: the rise and fall of a new media district. Routledge. Indpendant. 2006. Is this the most fun place to work in Ireland? http://www.independent.ie/opinion/analysis/is-this-the-most-fun-place-to-work-in- ireland-69292.html (last accessed 2 July 2008). Ito, M. 2005. Mobilizing Fun in the Production and Consumption of Children’s Software. Annals of the American Academy of Political and Social Science 597:82–102. Jefferson, T. 2007. The Writings of Thomas Jefferson V13: Co. Gardners Books. 359 Jensen, C., and W. Scacchi. 2010. Governance in Open Source Software Development Projects: A Comparative Multi-level Analysis. Open Source Software: New Horizons : 130–142. Jessop, B. 2000. The state and the contradictions of the knowledge-driven economy. In Knowledge, Space, Economy. Routledge. Johns, J. 2006. Video games production networks: value capture, power relations and embeddedness. Journal of Economic Geography 6 (2):151. Jullien, N., and J. B. Zimmermann. 2006. Free/Libre/Open Source Software (FLOSS): lessons for intellectual property rights management in a knowledge-based economy. Cahier de recherche :8–2006. Junker, H., and C. V . Lang. 2001. Betriebliche Umweltinformatik (BUI), Nachhaltigkeit und Informationsgesellschaft. 2001) Stufen zur Informationsgesellschaft. Festschrift zum 65. Kelty, C. 2006. EMACS, grep, and UNIX: authorship, invention and translation in software. Rice University. ———. 2005. Geeks, Social Imaginaries, and Recursive Publics. Cultural Anthropology 20 (2):185–214. ———. 2008. Two Bits: The Cultural Significance of Free Software. Durham: Duke University Press. Kittler, F. 1999. On the Implementation of Knowledge—Toward a Theory of Hardware. http://hydra.humanities.uci.edu/kittler/implement.html. ———. 1995. There is no software. CTheory.net. www.ctheory.net/articles.aspx?id=74. Kondo, D. 1990. Crafting Selves: Power, Gender, and Discourses of Identity in a Japanese Workplace. Chicago: University of Chicago Press. von Krogh, G., S. Spaeth, and Karim R. Lakhani. 2003. Community, joining, and specialization in open source software innovation: a case study. Research Policy 32 (7):1217–1241. Kücklich, J., and M. C. Fellow. 2004. Play and Playability as Key Concepts in New Media Studies. Dublin: Dublin City University. Lakhani, K. R., and R. G. Wolf. 2005. Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects. In Perspectives on Free and Open Source Software, ed. J. Feller, 30–22. 360 Lancahire, D. 2001. Code, Culture and Cash: The Fading Altruism of Open Source Development. Lashinsky, A. 2007. Working in the Googleplex. http://money.cnn.com/galleries/2007/fortune/0701/gallery.Googleplex_campus/index.htm l (last accessed 2 July 2008). Latour, B. 1993. We have never been modern. Harvard University Press. Leamer, E., and M. Storper. 2001. The Economic Geography of the Internet Age. Journal of International Business Studies 32 (4):641–665. Lefebvre, H. 1991. The production of space. Oxford, OX, UK ; Cambridge, Mass., USA:   Blackwell. Lepper, M. R., D. Greene, and R. E. Nisbett. 1973. Undermining children’s intrinsic interest with extrinsic reward: A test of the “overjustification” hypothesis. Journal of Personality and Social Psychology 28 (1):129–137. Lerner, J., and J. Tirole. 2002. Some Simple Economics of Open Source. Journal of Industrial Economics 50 (2):197–234. ———. 2004. The Economics of Technology Sharing: Open Source and Beyond. NBER Working Paper. ———. 2000. The simple economics of open source. National Bureau of Economic Research Cambridge, Mass., USA. Lessig, L. 1999. Code and Other Laws of Cyberspace. New York: Basic Books. ———. 2004. Free culture: how big media uses technology and the law to lock down culture and control creativity. Penguin. Levy, S. 2011. In the plex : how Google thinks, works, and shapes our lives   . New York: Simon & Schuster. Leyshon, A. 2001. Time-space (and digital) compression: Software formats, musical networks, and the reorganisation of the music industry. Environment and Planning A 33 (1):49–77. Linebaugh, P. 2008. The Magna Carta Manifesto:: The Struggle to Reclaim Liberties and Commons for All. Berkeley: University of California Press. Lloyd, A. 2007. “A system that works for me”: an anthropological analysis of computer hackers’ shared use and development of the Ubuntu Linux system. 361 Lorente, S. 2004. Key issues regarding Domotic applications. In 2004 International Conference on Information and Communication Technologies: From Theory to Applications, 2004. Proceedings, 121– 122. IEEE. Lovink, G. 2005. The principle of notworking: concepts in critical internet culture. HvA Publicaties. ———. 2008. Zero comments : blogging and critical Internet culture   . New York: Routledge. Lovink, G., and N. Rossiter. 2007. MyCreativity Reader: A Critique of Creative Industries. Amsterdam: Institute of Network Culture. Luthiger, B., and C. Jungwirth. 2007. Pervasive fun. First Monday 12 (1). MacErlean, N., and Institute of Personnel and Development. 1998. Get more from work - and more fun. London: Institute of Personnel and Development. Machlup, F. 1977. A history of thought on economic integration. New York: Columbia University Press. MacKenzie, A. 2006. Cutting Code: Software and Sociality. New York: Peter Lang. ———. 1998. Knowing Machines Essays on Technical Change 1st MIT Press pbk. ed. Cambridge Mass.: MIT Press. ———. 2007. Protocols and the Irreducible Traces of Embodiment: The Viterbi Algorithm and the Mocaic of Machine Time. In 24/7: time and temporality in the network society, eds. R. Hassan and R. E. Purser. Stanford University Press. Mako Hill, B. 2005. Financing Volunteer Free Software Projects. Advogato. http://www.advogato.org/article/844.html (last accessed 7 October 2011). Malecki, E. J. 2002. The Economic Geography of the Internet’s Infrastructure. Economic geography 78 (4):399 (26 pages). Man, H. de. 1977. Joy in work. Ayer Publishing. Manovich, L. 2001. The language of new media. Cambridge, Mass.: MIT Press. Marcuse, H. 1970. Five lectures; psychoanalysis, politics, and Utopia. Boston: Beacon Press. Markusen, A. 2006. Urban development and the politics of a creative class: Evidence from a study of artists. Environment and Planning A 38 (10):1921–1940. 362 Marshall, J. 2006. Negri, Hardt, Distributed Governance and Open Source Software. PORTAL Journal of Multidisciplinary International Studies 3 (1). Martin, E. 1994. Flexible Bodies: Tracking Immunity in American Culture from the Days of Polio to the Age of AIDS. Boston: Beacon Press. Marx, K. 1993. Capital: A Critique of Political Economy, Vol. 1. London, U.K.: Penguin Books in association with New Left Review. ———. 1964. Economic and philosophical manuscripts of 1844. New York: International. ———. 1843. Marx to Ruge. http://www.marxists.org/archive/marx/works/1843/letters/43_09.htm (last accessed 26 February 2010). Massey, D. 1994. Space, Place, and Gender. Minneapolis: University of Minnesota Press. Mauss, M. 1967. The Gift: Forms and Functions of Exchange in Archaic Societies. New York: Norton. May, C. 2006. Escaping the TRIPs’ Trap: The Political Economy of Free and Open Source Software in Africa. Political Studies 54 (1):123–146. Mayer, B. 2009. Blue-green coalitions: fighting for safe workplaces and healthy communities. Cornell University Press. McKusick, M. K. 1999. Twenty years of Berkeley Unix: From AT&T-owned to freely redistributable. Open Sources: Voices from the Open Source Revolution. McNally, D. 2011. Global slump : the economics and politics of crisis and resistance   . Oakland CA: PM Press. McRobbie, A. 2002. From Holloway to Hollywood: happiness at work in the new cultural economy. Cultural economy: Cultural analysis and commercial life :97–114. Metz, C. 2010. NASA drops Ubuntu’s Koala food for (real) open source • The Register. http://www.theregister.co.uk/2010/07/20/why_nasa_is_dropping_eucalyptus_from_its_ne bula_cloud/ (last accessed 15 October 2011). Microsoft. 2011. Windows7-Cloud Commercial. http://www.youtube.com/watch? v=jR6xbulUmsg&feature=youtube_gdata_player (last accessed 21 November 2011). Mitchell, D. 1995. The end of public space? People’s Park, definitions of the public, and democracy. Annals of the association of american geographers 85 (1):108–133. 363 Mitchell, W. 1999. e-topia: Urban Life, Jim--but not as we know it. Cambridge: MIT Press. Moglen, E. 1999. Anarchism triumphant: free software and the death of copyright. Rome: Centro di studi e ricerche di diritto comparato e straniero. Moody, G. 2001. Rebel Code: Linux and the Open Source Revolution. New York, NY: Allen Lane. Morgan, T. P. 2010. Shuttleworth heir opens up on Ubuntu biz • The Register. http://www.theregister.co.uk/2010/03/14/canonical_ceo_silber/ (last accessed 25 May 2011). Mosco, V., and C. McKercher. 2008. The Laboring of Communication. Lanham: Lexington Books. Moten, F., and S. Harney. 2004. The University and the Undercommons: Seven Theses. Social Text 22 (2_79):101–115. Muthyala, J. 2008. Whose World is Flat? Mapping the Globalization of Information Technology. New Global Studies 2 (1). Nakamura, L. 2002. Cybertypes: Race, Ethnicity, and Identity on the Internet. New York: Routledge. Negri, A. 1989. The Politics of Subversion: A Manifesto for the Twenty-First Century. Cambridge: Blackwell. ———. 1999. Value and affect. boundary 2 26 (2):77–88. Negroponte, N. 1995. Being Digital 1st ed. New York: Knopf. Nelson, R. S., and R. Shiff. 2003. Critical terms for art history. University of Chicago Press. Nonini, D. M. 2008. Is China Becoming Neoliberal? Critique of Anthropology 28 (2):145–176. (last accessed 3 April 2009). ———. 2007. The global idea of “the commons” Pbk. ed. New York: Berghahn Books. Norcliffe, G., and O. Rendace. 2003. New Geographies of Comic Book Production in North America: The New Artisan, Distancing, and the Periodic Social Economy. Economic Geography 79 (3):241–264. 364 Nunes, M. 2006. Cyberspaces of everyday life. Minneapolis: University of Minnesota Press. http://www.loc.gov/catdir/toc/ecip0615/2006018870.html; http://www.loc.gov/catdir/enhancements/fy0666/2006018870-d.html. O’Gara, M. 2008. Those Heady Days of Sex, Drugs & Linux Are Over. Java Developers Journal. http://java.sys-con.com/read/546617.htm. O’Mahony, S. 2003. Guarding the commons: how community managed software projects protect their work. Research Policy 32 (7):1179–1198. Ong, A. 2007. Neoliberalism as a mobile technology. Transactions of the Institute of British Geographers 32 (1):3–8. Orman, W. H. 2007. Essays on the economics of open-source software. Osborne, T. 2003. Against “creativity”: A philistine rant. Economy and Society 32 (4):507–525. Ostrom, E. 1990. Governing the Commons: The Evolution of Institutions for Collective Action. Cambridge ;;New York: Cambridge University Press.   Patel, R. 2010. The value of nothing: how to reshape market society and redefine democracy. New York, NY: Picador. Peck, J., and A. Tickell. 2002. Neoliberalizing Space. Antipode 34 (3):380–404. Perrons, D. 2004. Understanding social and spatial divisions in the new economy: new media clusters and the digital divide. Economic geography 80 (1):45–61. Peters, S. 2008. Does money kill good motivations? Stormy’s Corner. http://www.stormyscorner.com/2008/11/does-money-kill-good-motivations.html (last accessed 4 June 2009). ———. 2007. Would you do it for free again. Burmingham, UK http://video.google.com/videoplay?docid=-5661144261834801321 (last accessed 4 June 2009). De Peuter, G., and N. Dyer-Witheford. 2005. A playful multitude? Mobilising and counter-mobilising immaterial game labour. fibreculture 5. Pike, A., and J. Pollard. 2010. Economic Geographies of Financialization. Economic Geography 86 (1):29–51. Plant, S. 1997. Zeros and ones: women, cyberspace and the new sexual revolution. Fourth Estate. 365 Poppendieck, M., T. Poppendieck, J. Higsmith, and K. Schwaber. 2003. Lean Software Development: An Agile Toolkit. Addison-Wesley. Power, D. 2002. “Cultural Industries” in Sweden: An Assessment of their Place in the Swedish Economy*. Economic Geography 78 (2):103–127. Pratt, A. 2002. Hot jobs in cool places. The material cultures of new media product spaces: the case of South of the Market, San Francisco. Information, communication and society 5 (1):27–50. ———. 2000. New media, the new economy and new spaces. Geoforum 31 (4):425–436. (last accessed 14 October 2011). Pred, A. 1984. Place as historically contingent process: Structuration and the time- geography of becoming places. Annals of the Association of American Geographers 74 (2):279–297. ———. 1981. Social reproduction and the time-geography of everyday life. Geografiska Annaler. Series B, Human Geography 63 (1):5–22. Ratto, Matt. 2005. “Don’t Fear the Penguins”: Negotiating the Trans local Space of ‐ Linux Development. Current Anthropology 46 (5):827–834. (last accessed 10 May 2011). Ratto, M. 2003. The Pressure of Openness: The Hybrid Work of Linux Free/Open Source Software Developers. Raymond, E. S. 2001. The cathedral and the bazaar : musings on Linux and open source   by an accidental revolutionary. Beijing ; Cambridge Mass.: O’Reilly.   Redman, T., and B. P. Mathews. 2002. Managing services: Should we be having fun? Service Industries Journal 22 (3):51–62. Remnant, S. J. 2011. Leaving Canonical | Scott James Remnant. http://netsplit.com/2011/01/11/leaving-canonical/ (last accessed 17 November 2011). Rheingold, H. 1993. The virtual community : homesteading on the electronic frontier   . New York, NY: HarperPerennial. Rosenberg, D. K. 2000. Open Source: the unauthorized white papers. IDG Books Worldwide. Rosenberg, S. 2007. Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software. Crown Publishing Group New York, NY, USA. Rubin, I. I. 2007. Essays on Marx’s Theory of Value. Aakar Books. 366 Rutsky, R. L., and J. Wyatt. 1990. Serious Pleasures: Cinematic Pleasure and the Notion of Fun. Cinema Journal 30 (1):3–19. Ryan, M.-L. 1999. Cyberspace textuality: computer technology and literary theory. Indiana University Press. Sack, W. et al. 2006. A methodological framework for socio-cognitive analyses of collaborative design of open source software. Computer Supported Cooperative Work (CSCW) 15 (2):229–250. Sadler, D. 1997. The global music business as an information industry: reinterpreting economies of culture. Environment and Planning A 29:1919–1936. Sandage, S. A. 2006. Born Losers: A History of Failure in America. Harvard University Press. Sayer, A., and R. Walker. 1992. The New Social Economy: Reworking the Division of Labor. Wiley-Blackwell. Scacchi, W. 2006. Understanding Open Source Software Evolution. Software Evolution and Feedback: Theory and Practice. ———. 2002. Understanding the requirements for developing open source software systems. In Software, IEE Proceedings-, 24–39. Scacchi, Walt. 2007. Free/Open Source Software Development: Recent Research Results and Methods. In Advances in Computers: Architectural Issues, ed. M. V . Zelkowitz, 342. Academic Press. Schiller, D. 1999. Digital Capitalism: Networking the Global Market System. MIT Press. Schneider, F. 2005. Applied social psychology : understanding and addressing social and   practical problems. London: SAGE. Schoenberger, E. 2004. The Spatial Fix Revisited. Antipode 36 (3):427–433. Schoonmaker, S. 2002. High-tech trade wars : U.S.-Brazilian conflicts in the global   economy. Pittsburgh Pa.: University of Pittsburgh Press. Schwartz, B. 2007. Money for Nothing. The New York Times 2 July. http://www.nytimes.com/2007/07/02/opinion/02schwartz.html? _r=2&ex=1184904000&en=3fbfb0eef920fb83&ei=5070&oref=slogin (last accessed 4 June 2009). Schwartzman, H. B. 1980. Play and Culture. West Point, NY: Leisure Press. 367 Schweik, C. M., R. C. English, M. Kitsing, and S. Haire. 2008. Brooks’ versus Linus’ law: an empirical test of open source projects. In Proceedings of the 2008 international conference on Digital government research, 423–424. Scott, A. J. 1999. The US recorded music industry: On the relations between organization, location, and creativity in the cultural economy. Environment and Planning A 31 (11):1965–1984. Seippel, Ã. 2006. The Meanings of Sport: Fun, Health, Beauty or Community? Sport in Society 9 (1):51–70. Seman, M. 2011. How a music scene functioned as a tool for urban redevelopment: A case study of Omaha’s Slowdown project. City, Culture and Society. Shen, M. 2005. Developing Country Perspectives Software: Intellectual Property and Open Source-A Case Study of Microsoft and Linux in China. International Journal of IT Standards and Standardization Research 3 (1):21–43. Shields, R. 1996. Cultures of Internet: virtual spaces, real histories, living bodies. Sage Publications Ltd. Shuttleworth, M. 2011. MarkShuttleworth - Ubuntu Wiki. Ubuntu Wiki. https://wiki.ubuntu.com/MarkShuttleworth#Why%20are%20you%20funding %20Ubuntu,%20instead%20of%20giving%20the%20money%20to%20Debian (last accessed 7 October 2011). Slashdot.org. 2008. Slashdot | Shuttleworth Calls For Coordinated Release Cycles. http://linux.slashdot.org/linux/08/05/15/1524202.shtml (last accessed 19 May 2008). Smith, M. A., and P. Kollock. 1999. Communities in cyberspace. Psychology Press. Sombart, W. 1902. Socialism and the social movement in the 19th century. Charles H. Kerr. Sport, D. for C. M. and. 2010. Department for Culture Media and Sport - Creative Industries Economic Estimates – December 2010 (Experimental Statistics). Department for Culture, Media and Sport. http://www.culture.gov.uk/publications/7634.aspx (last accessed 9 November 2011). Stallman, R., J. Gay, and Free Software Foundation. 2002. Free software, free society :   selected essays of Richard M. Stallman. Boston, Mass.: Free Software Foundation. Stallman, R. M. 1985. The GNU Manifesto. Boston: Free Software Foundation. 368 Sullivan, C., and S. Lewis. 2001. Home based Telework, Gender, and the ‐ Synchronization of Work and Family: Perspectives of Teleworkers and their Co residents. ‐ Gender, Work & Organization 8 (2):123–145. (last accessed 9 May 2011). Taft, D. 2008. Agile Plus Open Source Equals Developer Success. eweek.com. http://www.eweek.com/c/a/Application-Development/Agile-Plus-Open-Source-Equals- Developer-Success/ (last accessed 10 February 2009). Tang, S., and V . C. Hall. 1995. The Overjustification Effect: A Meta-Analysis. Applied cognitive psychology. 9 (5):365. Taylor, P. 2005. Unruly Complexity: Ecology, Interpretation, Engagement. Chicago: University of Chicago Press. Tech’s overseas cash hoard is growing - Silicon Valley / San Jose Business Journal. 2011. San Jose Business Journal 27 June. http://www.bizjournals.com/sanjose/blog/2011/06/techs-overseas-case-hoard-is- growing.html (last accessed 15 October 2011). Terkel, S. 1974. Working People Talk About What They Do All Day and How They Feel About What They Do [1st ed.]. New York: Pantheon Books. Terranova, T. 2004. Network culture: Politics for the information age. Ann Arbor: Pluto Press. Thomas, D. 2002. Hacker culture. Minneapolis: University of Minnesota Press. Thompson, E. P. 1970. The making of the English working class. IICA. Thompson, P. 2010. The capitalist labour process: Concepts and connections. Capital & Class 34 (1):7. Thrift, N., and S. French. 2002. The automatic production of space. Transactions of the Institute of British Geographers 27 (3):309. Tornqvist, G. 2004. Creativity in time and space. Geografiska Annaler B 86 (4):22–43. Torres, J., and Queen Mary and Westfield College. 1992. On Commons’ Tragedies and Myopic Preemption: The Case of a Fishery. Queen Mary and Westfield College Department of Economics. Torvalds, L., and D. Diamond. 2001. Just for fun : the story of an accidental   revolutionary. New York: HarperBusiness. Traweek, S. 1988. Beamtimes and Lifetimes: The World of High Energy Physicists. Cambridge Mass.: Harvard University Press. 369 Turkle, S. 1995. Life on the screen : identity in the age of the Internet   . Ubuntu Founder Mark Shuttleworth in a Q & A session. 2006. http://video.google.com/videoplay?docid=-1165754797197197496&hl=en (last accessed 17 November 2011). UNCTAD. 2008. Creative Economy Report. www.unctad.org/en/docs/ditc20082cer_en.pdf. U.S. businesses stash 11% more cash, Apple is No. 1 - Silicon Valley / San Jose Business Journal. 2011. San Jose Business Journal 27 July. http://www.bizjournals.com/sanjose/news/2011/07/27/us-businesses-stash-11-more- cash.html (last accessed 15 October 2011). US Department of Labor. 2008. Fact Sheet #17A: Exemption for Executive, Administrative, Professional, Computer & Outside Sales Employees Under the Fair Labor Standards Act (FLSA). Valentine, G. 1996. Children Should be seen and not Heard: The Production and Transgression of Adults’ Public Space. Urban Geography 17 (3):205–220. Vinge, V . 2000. A Deepness in the Sky 1st ed. Tor Books. Wachowski, A., and L. Wachowski. 1999. The Matrix. Wakeford, N. 1999a. Gender and the landscapes of computing in an Internet cafe. In Virtual geographies : bodies, space, and relations   , 178–202. London ; New York:   Routledge. ———. 1999b. Gender and the landscapes of computing in an Internet café. In Virtual geographies : bodies, space, and relations   , 178–202. London ; New York: Routledge.   Walls, C. 2005. Embedded software. Elsevier. Warf, B. 1999. Telecommunications and the changing geographies of knowledge transmission in the late twentieth century. The American cities and technology reader: wilderness to wired city :230. Wark, M. 2004. A Hacker Manifesto. Cambridge: Harvard University Press. Weber, S. 2006. Annenberg Research Seminar: Steven Weber. http://annenberg.usc.edu/Events/2006/event574.aspx (last accessed 17 May 2011). ———. 2000. The Political Economy of Open Source Software. Berkeley Roundtable on the International Economy, University of California, Berkeley. 370 ———. 2004. The success of open source. Cambridge, Mass.: Harvard University Press. Weeks, K. 2007. Life within and against work: Affective labor, feminist critique and post- Fordist politics. Ephemera: Theory and Politics in Organization 7 (1):233Á49. Weheliye, A. G. 2005. Phonographies : grooves in sonic Afro-modernity   . Durham N.C.: Duke University Press. Weinstein, M. 1996. Managing to Have Fun. Ringwood Vic.: Viking. Wiener, N. 1962. Cybernetics, or, Control and communication in the animal and the machine. Cambridge, Mass.: M.I.T. Press. Wikimedia. 2011. Cloud computing - Wikipedia, the free encyclopedia. http://en.wikipedia.org/wiki/Cloud_computing (last accessed 10 October 2011). Williams, P. 1991. The alchemy of race and rights. Cambridge Mass.: Harvard University Press. Wilson, M. W. 2012. Data matter(s): legitimacy, coding, and qualificatios-of-life. Environment and Planning D: Society & Space Forthcoming. Wynants, M., and J. Cornelis. 2008. How open is the future?: economic, social & cultural scenarios inspired by free & open-source software. ASP-VUB Press. Yeo, B. L., L. Liu, and S. Saxena. 2005. When China dances with OSS. Open sources 2.0: the continuing evolution :197. Yerkes, L. 2007. Fun Works: Creating Places Where People Love to Work 2nd ed., updated and expanded. San Francisco: Berrett-Koehler Publishers. Zhou, Y ., Y. H. D. Wei, Y . Sun, and G. C. S. Lin. 2011. De-centering “spatial fix” - patterns of territorialization and regional technological dynamism of ICT. Journal of Economic Geography 11 (1):119. 371 Appendix A: The Ubuntu Code of Conduct (Source: http://www.ubuntu.com/project/about-ubuntu/conduct, 2011) Ubuntu is an African concept of ‛humanity towards others’. This Code of Conduct covers our behaviour as members of the Ubuntu Community, in any forum, mailing list, wiki, web site, IRC channel, install-fest, public meeting or private correspondence. Ubuntu governance bodies are ultimately accountable to the Ubuntu Community Council and will arbitrate in any dispute over the conduct of a member of the community. • Be considerate. Our work will be used by other people, and we in turn will depend on the work of others. Any decision we take will affect users and colleagues, and we should take those consequences into account when making decisions. Ubuntu has millions of users and thousands of contributors. Even if it’s not obvious at the time, our contributions to Ubuntu will impact the work of others. For example, changes to code, infrastructure, policy, documentation, and translations during a release may negatively impact others’ work. • Be respectful. The Ubuntu community and its members treat one another with respect. Everyone can make a valuable contribution to Ubuntu. We may not always agree, but disagreement is no excuse for poor behaviour and poor manners. We might all experience some frustration now and then, but we cannot allow that frustration to turn into a personal attack. It’s important to remember that a community where people feel uncomfortable or threatened is not a productive one. We expect members of the Ubuntu community to be respectful when dealing with other contributors as well as with people outside the Ubuntu project and with users of Ubuntu. • Be collaborative. Collaboration is central to Ubuntu and to the larger free software community. This collaboration involves individuals working with others in teams within Ubuntu, teams working with each other within Ubuntu, and individuals and teams within Ubuntu working with other projects outside. This collaboration reduces redundancy, and improves the quality of our work. Internally and externally, we should always be open to collaboration. Wherever possible, we should work closely with upstream projects and others in the free software community to coordinate our technical, advocacy, documentation, and other work. Our work should be done transparently and we should involve as many interested parties as early as possible. If we decide to take a different approach than others, we will let them know early, document our work and inform others regularly of our progress. • When we disagree, we consult others. Disagreements, both social and technical, happen all the time and the Ubuntu community is no exception. It is important 372 that we resolve disagreements and differing views constructively and with the help of the community and community processes. We have the Technical Board, the Community Council, and a series of other governance bodies which help to decide the right course for Ubuntu. There are also several Project Teams and Team Leaders, who may be able to help us figure out the best direction for Ubuntu. When our goals differ dramatically, we encourage the creation of alternative sets of packages, or derivative distributions, using the Ubuntu Package Management framework, so that the community can test new ideas and contribute to the discussion. • When we are unsure, we ask for help. Nobody knows everything, and nobody is expected to be perfect in the Ubuntu community. Asking questions avoids many problems down the road, and so questions are encouraged. Those who are asked questions should be responsive and helpful. However, when asking a question, care must be taken to do so in an appropriate forum. • Step down considerately. Members of every project come and go and Ubuntu is no different. When somebody leaves or disengages from the project, in whole or in part, we ask that they do so in a way that minimises disruption to the project. This means they should tell people they are leaving and take the proper steps to ensure that others can pick up where they left off. We pride ourselves on building a productive, happy and agile community that can welcome new ideas in a complex field, and foster collaboration between groups with very different needs, interests and goals. We hold our leaders to an even higher standard, in the Leadership Code of Conduct, and arrange the governance of the community to ensure that issues can be raised with leaders who are engaged, interested and competent to help resolve them. Mailing lists and web forums Mailing lists and web forums are an important part of the Ubuntu community platform. This code of conduct applies to your behaviour in those forums too. Please follow these guidelines in addition to the general code of conduct: 1. Please use a valid email address to which direct responses can be made. 2. Please avoid flamewars, trolling, personal attacks, and repetitive arguments. On technical matters, the Technical Review Board can make a final decision. On matters of community governance, the Community Council can make a final decision. 373 Appendix B: Open Week Announcement of Jaunty Ubuntu Open Week for Jaunty. Rock On. Folks, we are really pleased to announce…Ubuntu Open Week! Ubuntu Open Week is a week of IRC tuition and Q+A sessions all about getting involved in the rock-and-roll world that is the Ubuntu community. We organise this week for the beginning of a new release cycle to help new contributors get involved. Thanks to Jorge for helping to get the week together and for everyone who is helping to run sessions. Its going to be a fun week! So, the most important details first – Ubuntu Open Week happens from Mon 3 Nov – Fri 7 Nov and takes place in #ubuntu-classroom on the Freenode IRC network. You can use a program such as XChat-GNOME in Ubuntu to connect and get involved. So which sessions are scheduled? Well, the timetable is available here and the sessions include: Monday • Introduction and Welcome – Jono Bacon, the Ubuntu Community manager, will kick off the week with a short welcome and give you a quick tour of what to expect during OpenWeek. • Ubuntu behind the Scenes – You have some ideas and want to see them included in Ubuntu but don’t know how or just wondered how the ubuntu developers make this awesome distro, this is the right place to know what happens under the hood. • Reporting and Fixing Kernel Bugs – Leann Ogasawara will touch on kernel bug reporting best practices and getting fixes incorporated into the Ubuntu kernel. • Ubuntu on Ultra Mobile PCs – Oliver Grawert will explain the ins and outs of getting Ubuntu on UMPCs • Version Control with Bazaar – The very basics of using Bazaar. Learn how to take “snapshots” of your most important code and files..and how to roll back time to undo those changes. • Bazaar: Beyond The Basics – Following on from Emma Jane Hogbin’s Bzr basics, DavidFutcher guides you through some of the more “advanced” Bzr topics. Tuesday • Edubuntu – Overview of the Edubuntu project, its purpose, and how you can get involved with this small, but vital community. “Do it for the kids” 374 • Packaging 101 – Daniel Holbach, who is very interested in the growth of the Ubuntu Development Community, will talk you through the bare bone essentials of Ubuntu’s source packages. • Debian and Ubuntu – What is Debian? What is the importance of Debian to Ubuntu? How you can contribute to Debian? • An Intrepid journey in Ubuntu Server land – a retrospective of the features that the Ubuntu Server team worked on during the last release cycle and an outlook on what will follow. • Media Prodution on Ubuntu – A look at how Ubuntu can be used for all sorts of media, including photo processing and management, video capture and editing and audio recording and processing. This session will include a Q&A. Wednesday • Polishing a Package – Lots of packages in Ubuntu have outstanding bugs, and outstanding available patches. Emmet Hikory will demonstrate the process of ensuring that a package is the best it can be, including a review of available resources for package improvements. • Ubuntu Netbook Remix Overview – Learn about Ubuntu’s offering for netbooks, with UNR Product Manager Pete Goodall and Engineers Bill Filler and Neil Patel. • Upstreaming Bugs – Ubuntu is a collection of software from a multitude of upstream projects (Like GNOME, KDE, Linux, Xorg) that is put together and released every 6 months. In this talk I will talk about how you can help be a bridge between Ubuntu and these projects by ensuring that bugs, patches, and feedback gets from Ubuntu to them. • Ubuntu Brainstorm Q+A, becoming moderator – You have some question about Ubuntu Brainstorm? You want to become moderator? This will be the right time to ask! Thursday • sabdfl Question and Answer – Mark Shuttleworth, the founder of Ubuntu will take questions from attendees in this two hour block. • Wine – How to help with Wine, converting Windows applications into packages, Integrating Wine into the desktop. • Verifying Stable Update (SRU) bugfixes – Walking through the process of verifying an update for released versions of packages. • Cruft. What is it and why it sucks – An overview of cruft, how it’s made, how it is handled, what NBS is, how to do a removal • Cruft Removal 101 Workshop – A crash course in removing cruft with actual packages staged in a PPA. Learn how to do from the pros. Friday 375 • Fixing a bug in Ubuntu – it’s easier than you think – You want to get involved in Ubuntu, you’d like to fix a few bugs? Excellent, Daniel Holbach will show you how push the right buttons, talk to the right people and be part of the team. • REVU Q+A – Open Q&A about http://revu.ubuntuwire.com (the website where new packages are reviewed for inclusion into Ubuntu). • Translations and Internationalization with Launchpad – MikeRooney – A guide from start (an English-only application) to finish (a translated localized application) using Launchpad to coordinate and gather community translations. • Kernel: From Intrepid to Jaunty – Ben Collins – A review of what the kernel team did different during intrepid’s development cycle, what we learned and what we plan to change in jaunty. • Open Week Questions and Feedback – Jorge Castro – In this session we will get feedback from attendees on things you’d like to see in OpenWeek; what types of topics you would like to see next time and recommendations on how to make OpenWeek better. I look forward to seeing you all there! 376 Appendix C: Mirror List Complete Download Mirror List (2009) Choose a location near you to see a full list of download options, including download links for all supported cd images. Once you choose a location you’ll be able to choose which version of Ubuntu you’d like to download and the correct CD for your platform. • Africa • Botswana TENET (Africa) • Lesotho TENET (Africa) • Mozambique TENET (Africa) • Namibia TENET (Africa) • Namibia Polytechnic of Namibia (Africa) • South Africa TENET (Africa) • South Africa UCT LEG (Africa) • Swaziland TENET (Africa) • Zimbabwe TENET (Africa) • Asia • Armenia ADC (Asia) • China LUPA (Asia) • China Rootguide.org (Asia) • China Sohu (Asia) • China SRT mirror (Asia) • Cyprus Cytanet (Asia) • Georgia Open Consultants (Asia) • India Honesty Net Solutions (I) Pvt Ltd (Asia) • Indonesia PT Telekomunikasi Indonesia (Asia) • Indonesia IndikaNet (Asia) • Indonesia PT Pasifik Satelit Nusantara (Asia) • Indonesia University of Jember (Asia) • Israel Israel internet Association (Asia) • Israel INTERHOST (Asia) • Japan JAIST (Asia) • Japan Information Technology Center, the University of Tokyo. (Asia) • Japan UNIVERSITY OF TOYAMA with Ubuntu Japanese LoCo (Asia) • Japan Yamagata University (Asia) • Japan mithril-linux.org (offered by Debian-JP Project member) (Asia) • Korea, Republic of Kyung Hee University Linux User Group (Asia) • Korea, Republic of Kongju University KNUSOFT (Asia) 377 • Korea, Republic of Korea University (Asia) • Kuwait Qualitynet (Asia) • Malaysia Universiti Putra Malaysia (UPM) (Asia) • Mongolia Mongolian Open Source Initiative NGO (Asia) • Russian Federation Corbina Telecom (Asia) • Russian Federation COMSTAR-Direct (Asia) • Russian Federation Yandex (Asia) • Russian Federation Novosibirsk State University (Asia) • Russian Federation Ftp.chg.ru (Asia) • Saudi Arabia KACST/ISU (Asia) • Sri Lanka SchoolNet - Sri Lanka (under MInistry of Education) (Asia) • Taiwan Chung Hua University (Asia) • Taiwan Providence University , CCI (Asia) • Taiwan ftp.cse.yzu.edu.tw (Asia) • Taiwan TaiChung County Education Network Center (Asia) • Taiwan TKU-TamKangUniversity (Asia) • Taiwan National Center for High-Performance Computing (Asia) • Taiwan National Taitung University (Asia) • Taiwan NCTUCSCC (Asia) • Taiwan Shu-Te University (Asia) • Taiwan National Chi Nan University (Asia) • Taiwan TAIWAN MIRROR (Asia) • Thailand School of Information Technology, KMUTT (Asia) • Turkey Linux Kullanıcıları Derneği (Asia) • Uzbekistan Sharq Telekom (Asia) • Viet Nam FPT Telecom (Asia) • Europe • Austria lagis internet Serviceprovider GmbH (Europe) • Austria Ubuntu.gds.tuwien.ac.at (Europe) • Belgium Linux Belgium (Europe) • Belgium Infogroep (Europe) • Bosnia and Herzegovina BiHnet ISP, BH Telecom (Europe) • Bulgaria OnlineDirect (Europe) • Bulgaria IPACCT (Europe) • Bulgaria Linux-BG.org (Europe) • Bulgaria HITSOL.NET (Europe) • Bulgaria nano-box.net (Europe) • Croatia Faculty of civil engineering, Zagreb (Europe) • Czech Republic Silicon Hill (Europe) • Czech Republic UPC Česká republika, a.s. (Europe) • Czech Republic Ignum, s.r.o. (Europe) 378 • Czech Republic Advokatni kancelar Kindl&Partneri (Europe) • Czech Republic Ubuntu-releases.sh.cvut.cz (Europe) • Denmark KLID (Europe) • Denmark u-soft.dk (Europe) • Denmark Mirrors.dotsrc.org (Europe) • Estonia Elion Enterprises Ltd (Europe) • Finland CSC / Funet (Europe) • France Free (Europe) • France OVH (Europe) • France CRIHAN (Europe) • France Orange Business Services (Europe) • France Université de Nantes (Europe) • France CIRIL (Europe) • France Daupheus.com (Europe) • France Université de Picardie (Europe) • France Florian Entreprise (Europe) • France Ubuntu.florianentreprise.com (Europe) • France Ftp.uvsq.fr (Europe) • Germany De.archive.ubuntu.com-release (Europe) • Germany Esslingen University of Applied Sciences (Europe) • Germany University of Kaiserslautern (Europe) • Germany intergenia AG (Europe) • Germany Freie Universität Berlin (Europe) • Germany RWTH Aachen University (Europe) • Germany RRZN, Leibniz Universität Hannover (Europe) • Germany RRZN (Europe) • Germany StudNet Bonn (Europe) • Germany Universitaet Bayreuth (Europe) • Germany Univerity of Muensters (Europe) • Germany GWDG (Europe) • Germany University of Mannheim (Europe) • Germany IMT-Systems GmbH (Europe) • Germany Ftp-stud.fht-esslingen.de (Europe) • Germany Ftp.tu-chemnitz.de (Europe) • Germany Releases.ubuntu.mirror.at.stealer.net (Europe) • Great Britain (UK) University Of Kent UK Mirror Service (Europe) • Great Britain (UK) XILO Communications Ltd. (Europe) • Great Britain (UK) Oxford University Computing Services (Europe) • Great Britain (UK) Goscomb Technologies Limited (Europe) • Great Britain (UK) Ticklers.Org (Europe) • Great Britain (UK) datahop.it (Europe) 379 • Great Britain (UK) Canonical Ltd (Europe) • Great Britain (UK) The Positive internet Company (Europe) • Great Britain (UK) Virgin Media (Europe) • Greece Democritus University of Thrace (Europe) • Greece National Technical University of Athens (Europe) • Greece OTENET (Europe) • Hungary bitmind.hu (Europe) • Iceland Ubuntu.hugi.is (Europe) • Ireland HEAnet (Europe) • Italy University of Rome - La Sapienza (Europe) • Italy University of Naples Federico II C.S.I. (Europe) • Italy Fastbull (Europe) • Italy GARR/CILEA mirror service (Europe) • Italy ICT Valle Umbra s.r.l. (Europe) • Latvia University of Latvia (Europe) • Latvia Ubuntu.load.lv-release (Europe) • Lithuania mirror.soften.ktu.lt (Europe) • Lithuania Academic and Research Network in Lithuania (LITNET) (Europe) • Netherlands BIT B.V. (Europe) • Netherlands University of Twente (Europe) • Netherlands Telfort (Europe) • Netherlands Technische Universiteit Delft (Europe) • Netherlands Kernel.org (Europe) • Netherlands PCextreme B.V. (Europe) • Netherlands Muntinternet (Europe) • Netherlands Ftpserv.tudelft.nl (Europe) • Norway The Student Society in Trondhjem, Norway (Europe) • Norway University of Bergen (Europe) • Norway Ftp.uninett.no (Europe) • Poland Telekomunikacja Polska (Europe) • Poland Wroclaw Centre for Networking and Supercomputing (Europe) • Poland Vectra (Europe) • Poland Ftp.man.szczecin.pl (Europe) • Poland Piotrkosoft.net - Data Storage Center (Europe) • Poland Ubuntu.task.gda.pl (Europe) • Portugal CeSIUM - Universidade do Minho (Europe) • Portugal Rede das Novas Licenciaturas - Instituto Superior Técnico (Europe) • Portugal nfsi telecom (Europe) • Portugal NEACM - University of Porto (Europe) 380 • Portugal DEIS-ISEC (Europe) • Portugal DEI-FCTUC, University of Coimbra (Europe) • Romania Agency ARNIEC/RoEduNet (Europe) • Romania xServers Romania (Europe) • Romania UPC Romania (Europe) • Romania Ftp.lug.ro (Europe) • Romania ArLUG (Arad Linux Users Group) (Europe) • Slovakia Antik computers & communications s.r.o. (Europe) • Slovakia Energotel, a.s. (Europe) • Slovakia Antik Computer & Communications (Europe) • Slovenia Arnes (Europe) • Spain CICA (Europe) • Spain RedIRIS (Europe) • Spain Universidade da Coruña (Europe) • Spain Ourense Software Libre (Europe) • Spain RedIRIS (Europe) • Spain DAFI-CEUM de la Universidad de Murcia (Europe) • Spain Caliu (Europe) • Spain Delegación de Alumnos de Teleco - ETSIT - UPM (Europe) • Spain Grupo Universitario de Informática (Europe) • Spain GRN Serveis telemàtics (Europe) • Sweden Academic Computer Club, Umeå University (Europe) • Sweden Sunet FTP archive (Europe) • Sweden DF - The Computer Society at Lund University and Lund Institute of Technology. (Europe) • Sweden DatorSektionen, Högskolan i Jönköping (Europe) • Sweden Kernel.org (Europe) • Sweden Ftp.port80.se (Europe) • Switzerland SWITCH (Europe) • Ukraine www.dnepr.com (Europe) • Ukraine Releases.ubuntu.org.ua (Europe) • North America • Canada University of Waterloo Computer Science Club (North America) • Canada iWeb Technologies Inc. (North America) • Canada Shaw Cable (North America) • Canada University of Calgary (North America) • United States Argonne National Laboratory (North America) • United States Portland State University (North America) • United States Northeastern University College of Computer and Information Science (North America) • United States Kernel.org (North America) 381 • United States Login Inc. (North America) • United States Rochester Institute of Technology (North America) • United States Xmission (North America) • United States University of Utah (North America) • United States Walla Walla University (North America) • United States MIT Media Lab (North America) • United States University of Minnesota Ubuntu Releases (North America) • United States Carnegie Mellon Computer Club (North America) • United States Georgia Tech. Software Library (North America) • United States Michigan Tech Linux Users Group (North America) • United States University of Tennessee (North America) • United States University of Idaho (North America) • United States Mirror.vcu.edu-release (North America) • United States JHU ACM (North America) • United States Pavlov Media (North America) • United States Washington State University (North America) • United States OSU Open Source Lab (North America) • United States Clarkson University (North America) • United States Ftp-mirror.internap.com (North America) • United States University of California, Santa Barbara (North America) • United States Ftp.ussg.iu.edu (North America) • United States The University of Texas at Austin (North America) • United States CERIAS, Purdue University (North America) • United States University of Colorado at Boulder (North America) • Oceania/Australia • Australia iiNet (Oceania/Australia) • Australia mirror.aarnet.edu.au-releases (Oceania/Australia) • Australia Optus (Oceania/Australia) • Australia Internode (Oceania/Australia) • Australia Soul Australia (Oceania/Australia) • New Zealand Ftp.citylink.co.nz (Oceania/Australia) • New Zealand ihug (Oceania/Australia) • South America • Brazil Globo.com (South America) • Brazil PoP-SC/RNP (South America) • Brazil PoP-SC/RNP (South America) • Brazil C3SL/UFPR (South America) • Brazil Edugraf - INE - CTC - UFSC (South America) • Brazil LAS-IC-Unicamp (South America) • Chile TECNOERA (South America) 382 • Colombia Universidad Nacional De Colombia Grupo SoLiUN - Makuruma (South America) • Costa Rica Ucr.ac.cr (South America) 383 Appendix D: Manifesto for Fun Through all of the reasonable doubts I have had about analyzing, measuring, understanding, and studying fun I am left with six imperatives of fun. For the reasons that follow (and certainly others), it is worth letting fun take us in directions that might not make ready sense or fit into available explanatory slots in economic, geographic, media or social theory. All of these imperatives are rooted in an ambivalence that rests upon a recognition that fun is simultaneously part of a mode of exploitation and a basis of alternative un-capitalistic systems of exchange. There is a politics of fun. Fun is a struggle over outcomes, rules, and meanings by finding the limits and play with in a system—for better or worse. Specifically, it is important to wonder out loud if there might be something to fun that is about humanizing laboring. In other words, as out of place as it may sound, it is important to wonder if fun is worth struggling for, in any labor process. Through structural economic changes, our relationship to the possibility of fun changes. It is crucial to understand how economic changes—often written in broad, non-human scale strokes—affect experiences of working. To think about how the factory is not always the place of capitalist accumulation (though durable goods manufacturing, agribusiness-related production and raw material procurement and refining remain fundamental) is also to think about the diverse ways that workers have eked out survival strategies and made fun. Fun is common. We usually take it for granted, as this common sense aspect or absence in our daily activities—our cooking, making of things, collaboration, conversations, leisure, transportation and even what we call work may or may not be “fun.” Wondering why this is case, where we chose to and are able to locate fun and what possibilities emerge from taking the pursuit of fun and joy in everyday activities out of the realm of common sense and seeking to understand how they are possible there and not here, for us and not them, at this time and not later is crucial to opening up our understanding of human needs and politics. Fun (or something like it) is a human need. It is not a trans-historical or universal need, but a need that has taken its form out certain material conditions, ideological openings and power relations. To understand something about the human need for fun itself is to think about what material conditions produced this need for fun. Fun is about human experiences of doing work (in the base sense of exerting energy and capacities). Because fun must not presume that any work is inherently fun or not, it can help us assess, unite and/or untie false dichotomies and linkages. This means a critical evaluation of the legacies of 384 divisions of labor and their intellectual explanations that give us normative categories such as the “service sector” or “knowledge worker.” Fun is part of how work to benefit capital accumulation has become diffused into everyday life. Fun often organizes the times, places and divisions of immaterial labor and capital seeks to stabilize and regularize a relationship to fun that enables the extraction of value. Fun is therefore key in understanding and making interventions in the relationships between the control of time, communication and the self-organization of work. 385 Appendix E: Global Bug Jam Guide 2008 386 Appendix F: List of Interviews Not all interviews are used in the text, many provided background information only. The names of all interviewees have been omitted, as per my promise not to reveal interviewees personal identities, unless given express permission to do so. Interviews: 1. California LoCo Team Member, 6/17/08, Culver City, California. 2. Canonical Employee, Mobile Team, 7/22/08, Portland, Oregon. 3. Canonical Employee, Desktop Team Management, 7/23/08, Portland, Oregon. 4. Utah LoCo Member, 7/23/08, Portland, Oregon. 5. Canonical Employee, Community Manager, 8/15/08, San Fransisco, California. 6. Canonical Employee, Server Team Management, 8/16/08, San Fransisco, California. 7. California LoCo Team Member, 7/22/09, San Jose, California. 8. California LoCo Team Member, 7/24/09, San Jose, California. 9. California LoCo Team Member, 7/24/09, San Jose, California. 10. Canonical Employee, Kernel Engineer, 1/8/2010, Taipei, Taiwan. 11. Canonical Employee, Kernel Engineer, 1/8/2010, Taipei, Taiwan. 12. Canonical Employee, Kernel Engineer, 1/8/2010, Taipei, Taiwan. 13. Canonical Employee, 1/9/2010, Taoyuan, Taiwan. 14. Canonical Employee, Mobile Team, 1/10/2010, Taoyuan, Taiwan. 15. Former Canonical Employee, 1/11/2010, Taipei, Taiwan. 16. Canonical Employee, Management, 1/13/2010, Taipei, Taiwan. 17. Former Canonical Employee, 3/17/10, Montreal, Canada. 18. Former Canonical Employee, 3/18/10, Montreal, Canada. 19. Ubuntu Contributor, 3/19/10, Montreal, Canada. 20. Ubuntu Contributor, 3/19/10, Montreal, Canada. 21. Ubuntu Contributor, 3/20/10, Montreal, Canada. 22. Canonical Employee, Corporate Services, 3/21/10, Montreal, Canada. 23. Canonical Employee, Corporate Services, 3/21/10, Montreal, Canada. 24. Canonical Employee, Corporate Services Management, 3/21/10, Montreal, Canada. 25. Canonical Employee, Human Resources, 4/28/10, London, United Kingdom. 26. Canonical Employee, Systems Administration, 4/28/10, London, United Kingdom. 387

Asset Metadata

Creator Peters, Jacob J. (author)

Core Title Coding commons: fun and the Ubuntu labor process

Contributor Electronically uploaded by the author (provenance)

School College of Letters, Arts and Sciences

Degree Doctor of Philosophy

Degree Program Geography

Publication Date 07/30/2012

Defense Date 07/30/2012

Publisher University of Southern California (original), University of Southern California. Libraries (digital)

Tag code,commons,digital,FLOSS,free software,labor geography,OAI-PMH Harvest,spatial fix

Language English

Advisor Gilmore, Ruth Wilson (committee chair), Bar, François (committee member), Hise, Greg (committee member), McKenzie, Roderick (committee member)

Creator Email jjpeters@usc.edu

Permanent Link (DOI) https://doi.org/10.25549/usctheses-c3-76985

Unique identifier UC11289519

Identifier usctheses-c3-76985 (legacy record id)

Legacy Identifier etd-PetersJaco-1065.pdf

Dmrecord 76985

Document Type Dissertation

Rights Peters, Jacob J.

Type texts

Source University of Southern California (contributing entity), University of Southern California Dissertations and Theses (collection)

Access Conditions The author retains rights to his/her dissertation, thesis or other graduate work according to U.S. copyright law. Electronic access is being provided by the USC Libraries in agreement with the a...

Repository Name University of Southern California Digital Library

Repository Location USC Digital Library, University of Southern California, University Park Campus MC 2810, 3434 South Grand Avenue, 2nd Floor, Los Angeles, California 90089-2810, USA

Abstract (if available)

Abstract Coding Commons: Fun and the Ubuntu Labor Process explores what is at stake in how we understand ""digital work"" and builds a theory of code that exposes the dependencies and externalities of code production. This labor geography uses ethnographic research methods to analyze the labor process of Ubuntu, an international software project emblematic of emerging conditions of work and new organizations of productive resources. Ubuntu is a free software project--meaning that the collaborative practices of creating Ubuntu are dedicated to making it freely available to be used and changed by anyone--and it is built by the labor of a few hundred paid contributors and tens of thousands of volunteers. Ubuntu is made via an on-going uneasy negotiation between the capitalist mode of production and a non-capitalist mode of production organized by something coders themselves call ""fun."" My research has revealed that fun is more than an individual motivation or experience: it is a means through which labor is organized. As firms seek to capitalize on our desire for fun--via processes such as ""crowd-sourcing"" or the creation of ""fun"" workplaces--knowing what our fun produces is as important as knowing what our work produces. So, why this fun now? What else does our work and fun produce when part of the commons? What is the nature of the relationship between capitalism and the commons when code is held in common? What is code? Or, to sum all these questions up, how is life breathed into 0s and 1s? I answer these questions though the words and experiences of Ubuntu contributors, all the while working to build a theory of the material life of code. This theory rests on my argument that code is the material with which all things digital are made. Code is metal, plastics, and other material that has a dual nature: it is both something akin to a set of instructions, and in it its use, code is movement and machine. I demonstrate how focusing on this material life allows for tracing the movement of value into the commons and though moments of being put to use for capital--in other words, how it works that capital can seek a spatial fix in a commons of computer code. Capital is dependent upon the commons, and making sense of the form and outcomes of this dependency is crucial to understanding capitalism and its extractive strategies. Dealing with the material life of code and coders leaves us with the challenge of connecting distant people, machines, and labor processes that are all part of creating the computing environment we have before us. Making these connections is a basis for making it common sense to ask: is a more just way of distributing resources is possible? And how can any work--from coding to hand soldering circuit boards--be organized so that it is fun? And how might this fun be part of creating humane and sustainable ways for producing what we need and more justly allocating the surpluses we produce?