Common Ground : For a Sociology of Code

Software development is a highly technical, but also exceedingly collective, process. A thorough understanding of this process might, therefore, benefit from a sociological analysis of actors, artifacts, and activities. This was the premise of a set of studies that we conducted on development processes of Free/Open Source Software (F/OSS). In this narrative essay, we provide a reflective account of those studies, focusing on the various ways in which social theory contributed to the inquiry. In particular, we illustrate how a range of ideas, theories, and insights from sociologies of art, science, and economics helped us, respectively, make sense of our vast amount of data, develop novel conceptualizations of software artifacts, and understand the character of collective activities involved in F/OSS. Based on these reflections, we draw lessons on how these ideas can be expanded to other computational artifacts and activities. Prelude “They don’t listen,” bemoaned a computer science colleague, who felt that his ideas went unnoticed, unappreciated, and simply ignored by the geographers who attended the two-day NSF workshop. Ironically, he is a computer scientist who works on social policy, and the geographers are Geographical Information Systems (GIS) experts with a knack for understanding technology and building computer models — perhaps why they all both invited to the same workshop. The workshop aimed to bridge knowledge across several quite different communities – GIS modelers and social scientists, geographers and computer scientists, academics and businesspeople, Europeans and North Americans, and so forth. With this context in mind, I expressed some sympathy with my colleague’s lament, I responded, “You’re right," but added, "and neither do we. ” In a sense, this essay is a reflection on such exchanges. In it, we report on what can happen if and when computer scientists, IS researchers, and IT professionals — we — converse deeply with social scientists and take social theory seriously. We write about important gaps we found in techno-centric accounts of hard technology problems, specifically large software systems: how they come about, and how they are managed over long periods of time. We expose our routes to discovering, adopting, integrating, and eventually extending these social theories as rich and, we think, essential underpinnings, for understanding these complex technical artifacts, complementary to purely technical theory and practice. Over decades, computer science has developed a particular disciplinary understanding of its core concepts, which in the realm of software system development (the subject matter of the present inquiry) include notions such as “software,” “requirement,” “design,” “test” “module,” “specification,” “bug,” “patch,” and so on. As constructs, concepts like these manifest a high degree of persistence, having been sustained and linked together over years of mainly unquestioned application in the ontological machinery of the computing world. As Smith (1996) has argued, however, these concepts and theories do not do justice to computation in the wild: “that eruptive body of practices, techniques, networks, machines, and behavior that has so palpably revolutionized late-twentieth-century life” (and after! ) In this essay, we want to demonstrate how social theory has helped us develop concepts and understandings that may do greater justice to computational practice. By "do greater justice" here we mean that in the end we expect to provide added structure to several observable, examined, data-founded paradoxes central to some existing conceptual machinery of the theory and practice of large-scale systems development. We will try to place a more solid social theory-derived armature inside some floating islands of abstraction circulating commonly in the computing world. By exploring the uncharted territory where computing and social theory interact, we hope to map out a wider area of common ground. An Engineering Question Sticks its Head Out Computer software development is a multi-billion-dollar industry that is central to both the basic functioning and the international economy of the modern world. Yet software development is a tedious, costly, and complex process. Surprisingly, as a whole, current development practice still results in expensive, untimely, and unreliable products. For nearly half a century, software engineers have been trying to improve these circumstances by developing tools, techniques, models, and procedures that streamline development processes, optimize resources, and reduce expenses. Compared to the magnitude of these improvement efforts, however, the relative gains have been minimal. According to several sources of statistics circa 2006, roughly 25% of software projects run over budget, another 25% do not finish on time, and almost 45% get cancelled altogether. This leaves us with a basic question: Why does software development is so inefficient, expensive, and unreliable? A Sociological Question Emerges Beyond the cognitive, skill-based, and tool-supported practices of individual designers and programmers, software development is principally a collective activity. Software systems both large and small are designed, built, used, and maintained in a distributed way by groups and communities involving small numbers to thousands of contributors and tens of millions of users. Nowhere has this become more visible than through the rapid rise of "free/open-source software" (F/OSS) development communities. F/OSS projects range from simple programs (single function, hundreds of lines of code, rarely changing) to the extremely complex suites whose components change constantly and asynchronously (full operating systems with suites of affiliated applications and system libraries; complete office-processing, web-management/browsing, and program-development tool suites; high-performance analysis tools for physics, astronomy, and biology; enterprise resource management (ERP) systems; and more). These efforts represent active distributed collectives of designers, developers, maintainers, and "users", both organizational and individual. As one indication of some of the social complexity involved, the New York Times recently reported that the Mozilla Firefox web browser project has 75 to 100 million users, while "Some 1,000 to 2,000 people have contributed code to Firefox, according to the Mozilla Foundation. An estimated 10,000 people act as testers for the program, and an estimated 80,000 help spread the word. Similarly, by 2007, some 1,682 people have reported bugs against the Fedora Core 6 Linux operating system project. These observations suggest that one big part of the answer to the engineering question posed above may indeed lie in the social organization of software development. This point is taken quite seriously by many F/OSS proponents. Based on credos and principles distinct from those of the commercial software, F/OSS proponents attribute its success to the social processes of software development that allow the production of artifacts which are purportedly faster, cheaper, and more reliable. In regards to reliability, for instance, the proponents of F/OSS claim that the active participation of multitudes of volunteers brings about a high degree of quality assurance that is not attainable in commercial software. This claim is best expressed in what has come to be known as Linus’s Theorem: "Given enough eyeballs, all bugs are shallow. " Whether we agree with claims like this or not, the F/OSS model has provided a viable alternative to the rival proprietary model by the sheer fact that it “works. ” In so doing, F/OSS shifts the original engineering question towards a sociological one: How can large distributed collectives of experts and nonexperts produce artifacts that are comparable in quality to those created by conventionally-organized teams of experts? Recognizing the sociological nature of this question, several years ago we began a study of the social processes of problem management in software developed by an open source community centered around what has now become the Mozilla Foundation. This software, the original "Mozilla application suite," comprised the Mozilla web browser, an associated email/news reader, and a web page composer. Work on it was supported by several development tools, most notably for our studies the problem-reporting and tracking database tool called Bugzilla (see Figure 1). 1 Since the 1980s large software projects have used a widening array of tools to ease the management of knowledge for software development and maintenance. Modern tools such as mailing lists, wikis, blogs, bug reporting/analysis databases, and workflow tools have been integrated into software processes in both F/OSS and commercial development practices for many years now. These systems serve as media for representing ideas, designing, discussing, planning, developing strategy, coordinating, fighting, storytelling, and humor. They embody fullfledged social and organizational environments. Our goal in studying Bugzilla was to understand the social processes involved in fixing bugs and, more generally, in the development of software. We were working with hypotheses that linked variation in social processes (such as seeking/providing information, negotiating, resolving conflicts, establishing priorities, selecting lines of attack on problems, and making evaluations) to variation in outcomes (such as time to repair problems, quality of problem solutions, long-term robustness of repairs, and participant reputations). As we worked toward a clear, empiricallygrounded model of social processes in software maintenance, our first task was naturally to examine the Bugzilla data to find instances of bugs and of social processes, map their associations, and establish correspondences, and find correlations. But how? The “data” involved here consists of hundreds of thousands of