by Morgan Currie, Christopher Kelty, Luis Felipe Rosado Murillo, University of California, Los Angeles*

Introduction

By looking at the history of long-lasting and successful Free and Open Source Software (FOSS) projects, one can observe a common trajectory: they tend to start with a few core developers, then increase in code base size, complexity, and number of contributors and users, then finally find it necessary to create a formal organization to help coordinate the development efforts, maintain hosting infrastructure, secure funding, manage donations, seek partnerships, and protect its members from patent and copyright disputes. The question we discuss in this paper is “what are the characteristics of participation in those projects that do not describe this common trajectory?”

In order to respond to this question, we will compare projects with different trajectories: both those which were initially sponsored by a company and then created a community around them, and those that never constituted (or refused to constitute) a formal organization. By addressing this question, we will highlight fundamental differences and similarities between projects: what makes them grow or fail to attract and foster collaboration and public participation. In order to establish parameters for comparison, five dimensions of FOSS projects will be compared and discussed: 1) project genealogy; 2) tasks (how are they defined, described, and distributed?); 3) alliances (who are the partners? Are they from the public sector, private sector, or both?); 4) governance (is there a formal procedure for decision-making? If not, how are decisions made?) 5) availability (which licenses are used? What is the rationale behind the decision of using a particular license?). We will explore the following projects in order to respond to the questions above: Dyne.org, Debian, Android, and Xara Extreme Linux.

This article is based on research data from the project “Birds of the Internet”, sponsored by National Science Foundation (NSF), and hosted at the Center for Society and Genetics at UCLA. The project uses interpretative social science methods to explore and compare features of participation across a wide range of projects (not limited to Free and Open Source projects). By using comparative analysis, the project seeks to further concept development in the general domain of Internet public participation.

Free and Open Source Software Trajectories

For more than three decades Free and Open Source Software (FOSS) has generated an intense and intricate dispersion of technical objects and practices based on global collective efforts. Recent anthropological and sociological accounts of Free Software as a political, technical, and cultural practice further investigated the ongoing dispute regarding individual property over intangible goods and the opposition created by FOSS to the advancement of the transnational intellectual property regime (Coleman 2005; Kelty 2008; Leach 2009; Weber 2005). FOSS offered viable alternatives for remote coordination, distribution, and innovation in software development, made possible by the virtue of its licensing schemes: the constant rebuilding effort over a set of public software licenses which allowed (re)distribution, free use and adaptation of software code. The resulting sociocultural phenomena are situated in between, at least, two major registers: the general reciprocity oriented towards the free circulation of software as public good, and the market economy in which computer technicians offer their computing expertise for remuneration.

From an anthropological standpoint, FOSS is curiously made up by boundary practices in a multitude of social ties and sociotechnical arrangements, bringing together persons, associations, and technical objects: it is a form of craft that is hard to analyze without problematizing the boundaries of established categories and oppositions, such as individual/society, material/immaterial, discourse/practice, private/public, gift/market, persons/objects, work/leisure, and code/expression. In this sense, Free Software is better approached as a quasi-object (Serres 2007) assuming different forms but mainly organized around intersecting recursive publics (Kelty 2008). Public administrators, for instance, may advocate for FOSS as tool for social change, given its potential to foster digital inclusion. Among computer hackers, it is often defined as a highly valued expression of oneself and his/her technical competence. For artists and free culture activists, it is construed as a set of tools to empower cultural production. In the past decade we experienced an implosion of FOSS, currently being practiced under the new rubric of “Open Access”, “Open Data”, and “Open Source Hardware”.

This article analyzes FOSS projects’ participatory structures with informally negotiated or legally formalized aspects that relate to their growth over time. As pointed out by Coleman (2005), “most FOSS projects in their infancy, including Debian, operated without formal procedures of governance and instead were guided by the technical judgments of a small group of participants” (Coleman 2005, p. 325). Formalization typically comes about to address issues of scale and management. Riehle and Deshpande (2006) demonstrated that FOSS projects increased in size exponentially between 1998 and 2006, since “the total amount of source code and the total number of projects double about every 14 months” (Riehle and Deshpande 2006, p.11). As projects scale up, more is at stake beyond the purported division between FOSS and proprietary development models (Lakhani 2007; West 2009). As FOSS projects grow, they tend to organize their activities into businesses, NGOs, and foundations to coordinate software development work and manage intellectual property rights, profit and fund-raising purposes. Spontaneous gatherings of half a dozen hackers become formal organizations over time, transforming substantially the very social fabric which constitutes software development projects.

In our analysis of Internet-based participatory projects more generally (Fish et al. 2011) we proposed two distinct entities which are generally present: first is the “Formal Social Enterprise” (FSE) – legal organizations with formal decision-making procedures that are composed of at least one contractually obligated employee. On the other end of the spectrum are the “Organized Publics” (OP), or the community of participants whose relation to the FSE is informal, voluntary, impermanent, and often financially uncompensated. In the case of Linux, for instance, the Linux Foundation is a legal entity, an FSE, while the Linux kernel hackers form its OP base. The foundation is responsible for managing the Linux trademark, general Intellectual Property disputes, conferences, and training sessions across key global cities (such as San Francisco, Tokyo, and Sao Paulo) and meetings with sponsors and partners. On the other hand, the OP is technically and structurally connected to the FSE in various ways (such as by being board members), but are not contractual members of it – they can usually come and go as they like. As we have pointed out, most FOSS projects start with a small OP and over time develop a FSE, but there are cases of the opposite trajectory: a company launches a FOSS project and then gathers a thriving OP over time. Also, the correlation of power within and between these two formations is not a foregone conclusion in any particular instance: the FSE for one FOSS project could be a hierarchical conglomerate, with its OP structured by decentralized, horizontal communication, and corporate partnerships, while alternatively a not-for-profit FSE could be composed of a handful of people who make little distinction between their efforts and the project’s OP.

Table 1. Non-exhaustive list of FOSS projects’ trajectories:

OP → X	OP → FSE	FSE → OP	FSE → X
Dyne.org SPIP Gimp	Debian Linux Ourproject.org GNOME Apache KDE Python PostgreSQL Drupal PHP Inkscape Tor	Android Mozilla Redhat MySQL OpenOffice Ubuntu SugarCRM Kaltura Eclipse Blender	Xaraxtreme Symbian OpenSolaris OpenMoko

Why do initially informal FOSS Organized Publics (OP) tend towards formalization into Formal Social Enterprises (FSEs)? In some cases foundations formalize the managerial and decision-making level, often in efforts to broker commercial deals or tackle legal issues. In the discussion of the role of foundations in the FOSS context, O’Mahony (2005) points out that the foundation often emerges when projects become commercially relevant and profitable from the perspective of the industry, delivering software as service; foundations facilitate the interaction between community projects and corporations. O’Mahony cites a Fortune-100 executive who once questioned: “How do I make a deal with a webpage?” (O’Mahony 2005, p. 396) concerning the legal status of the Apache project and its possibilities of establishing contracts with corporations. Formalization as a for-profit company or 501(c)3 generally also allows projects to accept donations and sponsorship, apply for grants, and centralize management of internal conflicts or intellectual property rights disputes. But what about exceptions to this transformation towards formalization of Free Software projects?

Below we introduce techniques to analyze both typical cases as well as three other trajectories that FOSS projects can take as they develop (or fail to do so). We propose five dimensions of comparison between these trajectories that place them along a normative continuum of strong vs. weak participation, to better describe and visualize how their formation over time might affect the levels of participation. Before we move on to outline our research techniques, we offer a theoretical approach for analyzing participants’ social, legal, and technical capacities to engage with these projects by turning to historic definitions in order to inform an analysis of participation as it occurs today.

The Problem of Participation

“Online participation” has been scrutinized recently in scholarly and journalistic accounts seeking to understand why communities form around blogs, file sharing, software development, Internet forums, independent news portals, etc. The popular conception of this “new wave” of participation is that it is caused by the Internet, and that it generally involves a shared resource used by a highly cooperative group of individuals putting in significant free time with no monetary gain. Ubiquitous proofs used in these accounts are Wikipedia and Linux, which are often taken to be ideal types of this kind of participation.

But participation has many and varied traditions, only some of which are brought directly to bear in any given contemporary case. The limits and possibilities of participation are structured economically, legally, and sociotechnically in different projects, but most analyses suggest that the nature and quality of participation is obvious. For instance, it is rarely made explicit what counts as good and what counts as bad participation. In our research we have compiled a richer array of normative “switches” that might account for good and bad participation – issues such as whether participation includes an educative dividend, whether it comprises participation in the design of both goals and tasks, whether it facilitates “exit” and “voice” (Hirschman 1970), and so forth.

These switches are not our invention, however, but drawn from the heterogeneous literature on participation. We briefly explore here some of the diverse historical instances of participation and how they have measured the value and effect of participation. Little attention to this history has been paid by contemporary analysts of “new wave” participation (see eg. Carpentier 2011), hence we review – necessarily cursorily – some key moments for the US context: democratic political theory, the practice of participatory democracy in the 1960s, and Industrial democracy – or worker participation – from the 19^th century to the present.

In classical democratic theory, the standard debate over strong or weak participation concerns the issue of representation. Should citizens elect leaders whose job it is to make decisions on their behalf, or should citizens make these choices about their society by participating directly in governance? The 20^th century has seen the pendulum swing between strong “elite” understandings of democracy (such as those of Robert Michels or Joseph Schumpeter) and strong “participatory” theories of democracy (such as Arnold Kaufman, C.B. Macpherson, and Carole Pateman). Some of these debates hinge on definitions of “human nature” as when Kaufman, writing in 1960, critiqued Joseph Schumpeter’s view that people can’t sift intelligently through information or know what is in their best interest. Schumpeter, along with others like Walter Lippman, remained suspicious of crowd behavior and chaotic voices of mass democracy, and instead favored representation by elected, learned leaders. According to Kaufman, Schumpeter failed to provide a framework for how these leaders should be formed, and Kaufman’s alternative was direct democracy as the mechanism needed to produce these rational leaders. Kaufman’s approach was classically Rousseauian: crucial to his strong interpretation of participatory democracy was the claim that deliberation must occur, allowing each participant an equal say in the matter and so allowing them to accrue critical skills through meaningful debate. For “it is only when [men/women] acquire direct responsibility for a certain range of decisions that social imagination breaks through its parochial barriers and envisages larger possibilities.” (189) In this schema, while all voices will be considered of equal value, Kaufman also makes room for more or less influential voices – a person who “has special knowledge about a problem or… thinks more clearly or more imaginatively about certain issues” can have larger sway. (192)

Kaufman was far from the only theorist of participatory democracy in this period, and the differences within the debate are too extensive to cover here. The key point however, is that Kaufman and others insisted on particular features of participation – it’s “educative potential” which would transform citizens from passive observers into engaged members of a direct democracy, and ultimately allow for individual human expression to emerge. The 1960s witnessed a flowering of attempts to strengthen or instantiate participatory democracy (PD) along these lines. The term itself first appears with the Students for Democratic Society (SDS) in their 1962 Port Huron statement, where they proposed two critical ideas to be tested on the ground during the Civil Rights struggles in the US. Like Kaufman, the SDS believed individuals must have a say in the decisions that determine their choices and quality of life. Also crucial is that societal structures are set up, from the beginning, to encourage critical thinking and help individuals comfortably express themselves when they enter into political discussion. Just as important, society must provide the media platforms citizens need for self-expression. In keeping with these ideas, SDS projects in the North modified their own organizations by abolishing central offices, rotating leaders, and allowing executive committees to be checked by staff meetings. Equal say among citizens, not the decisions of a charismatic individual or representative middle person, should set the agenda.

At the time, Staughton Lynd pointed out that, as these new institutions remained separate from the mainstream political process, their lack of formalization prevented them from addressing such basic needs as feeding people and raising them from poverty – they did not yet form the bases of substantive governance of the population, only he formal expression of dissent and deliberation. But he takes comfort in the ideal of parallelism implicit in participatory democracy: in the 1960s, its radical structures operated alongside older, more conservative institutions. PD formed a challenge from within by building an alternate, steady enclave of critique that rejected conventional coalition politics. (6) As such, PD can at least make change by increments through their suggestion of wider possibilities, as their more radical social constructions slowly transform the norms of the existing institutions they operate alongside (as many FOSS projects claim to do today, and as the example of the Occupy movement also suggests).

A loosely related area of the theory and practice of participation is in so-called “Industrial Democracy” (ID) of the late 19th and 20th centuries. Industrial Democracy comes in many variants – from an American version that was the beating heart of Americanized socialism from the 1890s to the 1960s (especially in the League of Industrial Democracy, direct ancestor of the SDS), a British Fabian socialist version with roots in the political traditions of Rousseau, John Stuart Mill, and G. D. H. Cole, and a Scandinavian tradition that re-emerged with particular force under the label of “Participatory Design” in the 1960s and 1970s (and which provides some of the direct critiques occasionally adopted by FOSS supporters). In all cases however, ID was focused on worker participation in industrial capitalism – primarily but not exclusively on the shop floor. Early debates (as in the work of Sidney and Beatrice Webb) focused more or less exclusively on the formation of trade unions and their political organization in an era before their formal legal inclusion in the economy. But alongside the growth of unions, ID also represented a constant but minor tradition which sought a transformation of management and worker autonomy – for instance, concepts and tools that could modify the traditional relationship between goal-setting and task-performance. Out of the theory and experiments came various approaches – the “human relations in industry” school of Elton Mayo and Fritz Roethlisberger, the British “socio-technical” systems analyses at the Tavistock institute, and later participatory design – each with different political commitments and contextual constraints.

Many ID proponents expressed ideas that fall on a strong-to-weak continuum of participation. Carol Pateman’s (1970) analysis of this movement (which focuses primarily on the British and Yugoslavian cases, but ignores participatory design in Scandinavia) spells out these distinctions by calling attention to the levels of power allocation among workers and management. She distinguishes ID entirely from “pseudo participation,” merely a persuasive style of management that gains workers support for decisions already made. Many so-called ID “participation” experiments, claims Pateman, took this spurious form. With partial democracy, in contrast, Pateman describes how workers have “influence” but not equal power to make final decisions, both over what goes on on the shop floor, and over the enterprise as a whole (such as matters of investment, marketing, etc.). Finally, with full participation, workers are part of “a process where each individual member of a decision-making body has equal power to determine the outcome of decisions.” (71) Pateman finds examples of this system at work only at the lower shop-floor level, in the collective contracts found in mining and car industries, where workers operated in unsupervised, self-regulating groups to determine their everyday work environments. A fully socialized form of ID at the level of administration “implies the opportunity for full higher level participation by employees in the formal organization,” though this ideal is never realized. (71)

These theories of participation do not graft directly onto the distributed labor of coders in contemporary societies, but they do provide a series of switches, or normative criteria which can easily be used to assess the formation, trajectory, and success of FOSS projects: the degrees between partial and full participation present a spectrum of possibilities allowing participants autonomy, share in resources, and political efficacy. Below, we propose a set of metrics that define the spectrum of weak vs. strong participation in the online forms it takes today, by considering issues such as goal-setting, governance, and the availability of resources.

Table 2. Weak versus strong forms of participation:

Variable	Strong	Pseudo or Weak
Tasks vs. Goals	Decision making in goals, not only tasks	Solely in tasks designed or framed elsewhere
Governance	Capacity to exercise both exit (without penalty) and voice (without fear) vis-à-vis a known and addressable entity	No capacity to exercise both voice, or a risk of loss of some kind upon exit
Availability	Collective control and/or individual access to the resource produced by participation	Expropriation and/or private ownership of resource produced

With this spectrum of possibilities, we expect to gain a deeper understanding of what is at stake beyond issues of intellectual property or individual motivation that typically consume analyses of FOSS projects. Conceptions of full participation – where participants take part in goal setting, governance decisions, and have full availability of the resources generated by the project – serve as a standard for strong participatory projects. Whether these standards bear on the project’s success and development, as well as influence the structures it takes, we hope to illuminate in the following case studies.

Methods

For the analysis of participation in FOSS projects, we created a corpus of qualitative data composed of hypertext documents, mailing-list archives, video and audio interviews, presentations, and scholarly publications for four projects: Dyne.org, Debian, Android, and Xaraextreme. Part of our empirical data also come participant observation conducted at FOSS conferences, IRC channels, and informal face-to-face meetings in United States, Japan, and Brazil.

For our purposes, the FSE/OP distinction was used to select cases representing four trajectories of FOSS projects. To establish parameters of comparison which highlight how public participation occurs across these projects, we consider five variables. The first two are genealogical, the remaining three account for patterns of social relationship and collective action:

a. Project Formation: a genealogical description of the project’s origins and major shifts in its composition up to the present day.

b. Alliances: who are the partners and/or sponsors? Are they from the public sector, private sector, or both? Do these alliances have any formal or informal role in the FSE?

The following variables bear directly on the political dynamics of participation in FOSS projects and aim to distinguish the levels of privilege and types of roles granted to OPs by the FSE. These dimensions can be placed on a normative continuum of “weak to strong” structures of participation, as defined on Table 2.

c. Tasks and Goals: how are tasks defined, described, and distributed? Does the OP participate in goals, not only tasks? Can participants engage in discussion with leaders, managers, or administrators about what tasks should be pursued, how they should be structured, or how they should be measured? An instance of strong participation would at least grant publics access to the decisions made by FSEs through representation, if not veto power, direct voice and/or vote. It would also consider educative dividend: by participating in the tasks and/or goals, do participants learn what their own interests are? Do they develop civic virtue, a sense of responsibility, or a refined sense of liberty by being directly involved?

d. Governance: Is there a formal procedure for decision-making? If not, how are decisions made? Do participants have the capacity to exercise both exit (without penalty) and voice (without fear of reprimand) vis-à-vis a known and addressable entity (Hirschman 1970)?What constitutes having a real voice, and how does it manifest in discussion forums, face-to-face meetings, and financial donations? Can participants leave without losing something, or protest and expect to be heard? What can you not exit from, such as formal or technical commitments to a website, a platform, an account, etc.?

e. Availability: The range of licenses and legal restrictions in these projects is considerable, from GNU General Public License toCreative Commons licenses to moral economies where no formal legal structure exists, to direct corporate expropriation, where participants knowingly carry out free or underpaid labor and indirect expropriation, as when participants often unwittingly offer up their data for commercial usage. Whichlicensesareused?Whatistherationalebehindthedecisionofusingaparticularlicense? Is there collective control and/or individual access to the resource produced by participation? Can participants trust that what they give to a project will be returned to them in some form (credit and authorship, legal rights, access to resources)?

We set out as a primary goal to collect data on particular cases and compare between them. In the next four sections, we will present and analyze FOSS trajectories in order to provide a preliminary sketch of a continuum of public participation.

FOSS Cases

Project Formation and Alliances

One of the most important community-based Free Software projects, the Debian Project has more than a thousand volunteer developers working on almost twenty thousand software packages. The project’s formation follows one typical of successful FOSS projects, beginning as an OP then quickly developing into an FSE. Debian was created in 1993 by Ian Murdock, a computer scientist, during the early period of commercialization of GNU/Linux in which several companies started Free Software distribution projects. From 1994 to 1995, Debian was sponsored by the Free Software Foundation, which guaranteed funding for Murdock to dedicate himself full time to the project. Bruce Perens, the successor of Murdock as the Debian Project Leader (DPL), founded the NGO “Software in Public Interest” in 1997 (with Tim Sailer and Ian Murdock) as a non-profit “umbrella organization for projects from the community” handling donations to Debian.¹ Perens also wrote up Debian’s “Social Contract” based on a months-long discussion on Debian mailing-lists, and included in it the “Debian Free Software Guidelines” to establish the project’s moral and technical commitments. Debian core developers had ties with the IT industry in companies such as Silicon Graphics and HP, and these connections helped the project obtain necessary hardware infrastructure as well as monetary support. Currently, Debian remains an independent, decentralized organization with a formal decision-making process and appointed project leader, managing a complete operating system release of over 29,000 software packages for a handful of computer architectures. “Software in Public Interest” is still the main foundation behind Debian – as well as behind several other Free Software projects –, providing money for conferences, accepting donations, and giving donations to Debian Developers for traveling to the annual Debian Conference, which takes place in different parts of the world where Debian has local volunteer developers.

Based on ethnographic data and a corpus of qualitative data, O’Mahony and Ferraro (2007) identified four successive phases in the development of Debian that highlight the change in the orientation towards authority of the DPL: 1) authority exercised by the Debian founder (1993-97); 2) problem of succession and centralization of decisions about the future of Debian led the project to draft and ratify a constitution (1997-99); 3) with the approval of the constitution, the project implemented the new formal model of governance (1999-2003); 4) the stabilization of the formal process with the dispute for authority based on platforms for the future of the project (2003-2006). Auray (2003), Coleman (2005), and O’Neil (2009) provided in-depth analyses of the internal regulation of Debian and the maintenance of its boundaries. As a form of control over growth and technical quality of the project, the Debian community created a formal process for admitting new developers called “New Member Process” (NMP), which stands as a solution for the problem of integration and trust among remote international collaborators. Coleman (2005) demonstrates that, by engaging in the process, newcomers incorporate the technical skills and cultivate the ethical values demanded from Debian Developers.

In contrast to Debian, Dyne’s formation began as an OP that has resisted forming any FSE. The project is carried out by a radically decentralized group of self-identified hackers and activists who engage in Free Software development, Internet activism, digital inclusion, and electronic art projects. A self-described “nomadic network” born as a protest against hierarchical institutions (Jaromil 2009), they refused to crystallize into a Formal Social Enterprise (FSE). As a loose software forge, they recently obtained legal status in the form of a Dutch Stichting (non-profit), and are affiliated with the “Nederlands Instituut voor MediaKunst”, which has provided their server space, but they have no formal contractual structure of attributions such as board members, paid staff, and meetings. Over the years the project has also received support from the Free Software Foundation.

Founded in 2000 by Dennis Rojo Jaromil and Tatiana de la O, the project evolved out of the online Spanish language-based network Hackmeeting.org, a forum composed of political and human rights activists and hackers. The project first centered around a Linux distribution dedicated for multimedia, Dyne:bolic. Dyne then evolved into a set of applications for FOSS multimedia, including a highly-encrypted OS that could be used by political activists working in repressive societies or contexts of potential surveillance, as well as for VJing and projects devoted to issues of the “digital divide”. Dynebolic was designed to allow these software projects to run on older computers as a form of tactical opposition to consumerist approaches which require frequent software coupled with hardware upgrades. Dyne also organizes projects around changing the legal structures of copyright more broadly, such as allowing legal modification of the chips of formerly closed game consoles (Jaromil 2009).

Currently, Dyne website receives around 500 unique hits a day and has grown particularly in India and Brazil. However, according to Jaromil² the initiative is not self-sustaining, and its homepage now includes commercial advertisement to pay the basic costs of running the infrastructure. Though the project has grown over the years, growth is now steady. Regarding its success as a FOSS project, Jaromil claims he does not know if Dyne is a success, “or if a network should be a success. It is beyond this rhetoric of success and failure… also, exponential growth can be destructive.” More important than growth, according to Jaromil, is that a community still orbits around the project as “an effort to write a collective history.” The emphasis is instead on transparency of process, and on seeing participation in the project as a political and ideological stance in itself. If someone no longer wants to be connected to the project, he or she can still keep their work, and developers can leave anytime and rejoin if they want. Many in the current network are individuals who have applied the skills they learned in early hacker collectives to find jobs at other FOSS projects that can provide them salaries, including Android and Mozilla, but who collaborate together in Dyne’s parallel community of sharing and openness. The motivation to stay a member of Dyne is clearly not commercial, but political.

The Android case represents a third kind of formation: a FOSS constructed to mediate between FSEs and an OP.Android Inc. was created in late 2003 by Andy Rubin, Rich Miner, Nick Sears, and Chris White to develop a location-aware mobile device, later acquired by Google Inc. in 2005. The Android project was launched via the Open Handset Alliance (OHA) in 2007, a coalition composed of multi-national companies in the telephony, semiconductor, and software industries. As one of the biggest smartphone platforms worldwide, Android is also considered by the FOSS community as one of the most “closed” Open Source projects (see, for instance, “Open Governance Index” 2011). This observation is not only puzzling, but it captures adequately what is at stake in respect to public participation in Android: the fact that it integrates various Free and Open Source software projects while having a strong hold on high-level decisions, and, in doing so, lagging behind in FOSS practices of transparency and openness. The controversy is related to process, more than product. The Android Open Source Project (AOSP) is composed of a software stack, combining different technologies which are released under different licenses, corresponding to different FOSS and non-FOSS development communities with and without FSE management.

For instance, Google only releases source code of completed versions, maintaining the company’s complete control over the technological specifications that Android partners must, then, follow (Spreeuwenberg and Poell 2010). Google also provides “early access” to the source code of new versions of the OS to specific third parties, allowing it to govern its relationship with manufactures, members of the OHA. As Spreeuwenberg and Poell (2012) have pointed out, Google additionally deploys its Android Compatibility Program, defined by the Compatibility Definition Document (CDD), to determine which hardware features can be allowed, so directing industry partners’ production process in hardware development. Android’s position towards public participation also affects more than the development side: users are asking for the right to own administrator rights over their Android devices (which to this date need to be modified to allow full access to the system and its functions). One of the major consequences of this lack of control is that users do not share ownership of the metadata collected by Google nor have privileged access to implement enhanced security measurements.

Finally, Xara Extremeon Linux, a vector graphics and photo editing software, represents a fourth type of formation: an FSE that never developed an OP. The open source version of Xara Xtreme, originally released in 1992 under the name “Artworks,” was released for Linux by its owner Xara Ltd in 2006 at the inaugural Libre Graphics Meeting in Lyon, France. However, the port from Windows to Linux immediately stalled when Xara refused to release a central piece of the code as Open Source, namely the application’s core rendering library CDraw – a situation that failed to attract volunteer developers. In 2007, Xara Ltd sold to new owners Magix, who similarly worried about developers compiling an open source Windows version. Later that year the company announced it was pulling its own developers off the open source version, to concentrate on the release of its next Windows product. Currently, the project is called “Xara Xtreme for Linux” and the port still has not been completed.³

Tasks vs. Goals

Active members of Debian are generically identified with three basic titles that determine task, skill, and responsibility levels: Debian contributors, who are Free Software packagers; Debian Developers (DD), who are socialized through the New Member Process and responsible for the quality of the packages that are included in the system; and Debian Maintainers, who dedicate less time to the project but help with debugging and packaging software. Maintainers have control over their own packages, which are increasingly co-maintained; they help to manage the upstream source code version of FOSS projects and submit for packaging and quality assurance on Debian. Other tasks are usually handled by the domain of smaller, more collaborative groups of developers who performtranslation and internationalization work, upkeep of the IT infrastructure (software repositories, content delivery networks, IRC servers, mailing servers), and documentation. Developers, having a prestigious position within the FOSS community, make independent decisions regarding their own work, but generally request comments, suggestions, and help from other members of the project. Within a project, roles are self-assigned or submitted to the voting system (in the case of the election for DPL, Debian Project Leader). Maintenance of packages is done by task self-attribution, and can also occur through the list of orphan packages (packages that are abandoned by their former Debian maintainers and are up for grabs by volunteers).

At the software development level, Debian’s Developer OP is involved in goal setting through both representation by the Project Leader and majority vote (which is computed using the Condorcet Method). Articulation of goals and conflict resolution can also be reached informally on one of the project’s many listservs. At the broader level, developers take part in goal setting through elections, and by making proposals as well as voting on General Resolutions and Foundational Documents. We describe the mechanisms for goal-setting in greater detail in the governance section, below.

Similar to Debian, Dyne developers have a role not only in tasks but also goal-setting. At a basic level, tasks concern system administration, such as making sure the infrastructure runs, software development, bug fixing, documentation and support, participating in existing projects or forking, adapting and translating them. Dyne has no systematized user support, but it has a core team of around 20 dedicated people, composed mostly of Italian developers (corresponding with its origins in Southern Italy), who respond to emergencies. According to Jaromil, this decentralization might mean that Dyne is less efficient, but efficiency is less valued than maintaining transparency, cooperation, and a personable spirit of exchange.

While tasks and goal-setting are shared among the community, Dyne is drastically unlike Debian for having no formal documents or roles to structure the goal-setting process. According to Dyne’s founder, Jaromil, the project’s decentralized structure is a political mirroring of the potential network structure of software projects themselves: “We do not want to have an institutional role. We are a network.” (Jaromil, 2009) The website accordingly contains no information specifying formalization of goal-setting. Communication on the project is instead done through listservs, meetings, wikis, and forums, which currently have 1000 subscribers and about 400 active users. All tasks and goal-setting are self-initiated, collaborative, and ad-hoc: whoever takes an initiative can also set goals, though often community consensus inspires goal setting.In this setting, tasks and goals are intertwined, as administrators share goal setting with others using the infrastructure, depending on whoever is involved at any particular time.

In contrast to our first two cases, the extent of participation in Android’s software development is primarily determined by a contributor’s place within a hierarchy managed by Google, rather than a more or less structured rough consensus. Within the project, goal-setting by contributors is restricted to specific parts of the Android platform. AOSP separates tasks between “contributors” who work on the Android source code, and “developers”, engineers who write applications that run on Android devices. Higher up are “verifiers” who test change requests. They are invited to this position and must have submitted a significant amount of high-quality code to the project. Still higher are “approvers”, who decide whether to include or exclude a change. At the top of this pyramid are “project leads”: senior contributors who oversee the engineering for individual Android projects and often work for Google. Once submitted, changes must be accepted by a designated approver, typically a Google employee. If a change is not approved, it is considered to be technically incompatible to the Android platform.⁴

Our final case, Xara Extreme, is an example of very limited tasks and goal-setting by developers. The main tasks of the project involved porting XaraXtreme for GNU/Linux. The stated goals are “to create a new cross-platform industry standard, to change the graphics landscape forever, to create the best drawing, vector graphics software that has ever existed. At the same time, create a genuinely useful, general-purpose graphics tool for everyone”⁵. The FSE Magix sets the developmental goals for the project. Given its unsuccessful attempt to develop a structure for collaboration and build trust with members of the FOSS community, the project was not advanced. According to the journalist Nathan Willis (2009), Xara will “begin to suffer from bit-rot as core system libraries evolve. It will stop working at some point, and become just like the thousands of other abandoned applications still available through SourceForge.net and other project hosting services.”

Governance

Debian has a hybrid mode of governance, composed by democratic majoritarian rule, meritocracy, and ad-hoc process of rough consensus. The project’s formalized process of membership acquisition is also one of the most structured FOSS community projects, with a very clear process of collective governance and training of its novice participants. As it is the case for most FOSS projects, Debian developers have the strong backing of a wide array of collaborators, those who provide bug reports, bug fixes and documentation (as well as translation and internationalization work). Collaborators who have an active role in the community gain recognition, which is the first step to apply for membership in the Debian project. To become a developer it is necessary to ask for sponsorship from another Debian Developer and to participate in his or her web of trust (reinforced through GPG key signing – sharing of ‘fingerprints’ for personal identification and future exchange of data in secure, encrypted form). An active Debian Developer also has to meet the person face-to-face and vouch for his or her membership application. Sponsors are important agents in the NMP (New Member Process), given that they must ensure newcomers learn how to work the way Debian Developers are supposed to work with others.

Once they become official member of the community, Debian Developers take part in governance by 1) proposing or sponsoring draft General Resolutions; 2) proposing themselves as a Project Leader candidates in elections; and 3) voting on General Resolutions and in Leadership elections. By crafting the General Resolution, developers also have a voice in several other governance variables: the appointment of the Project Leader, amendments to the constitution provided they agree with a 3:1 majority, decisions authorizing the powers of the Project Leader or Delegate as well as the Technical Committee, proposals and amendments for nontechnical policy documents and statements, and, in case of a conflict, the secretary appointment. With such a hybrid mode of governance, Coleman (2005) argues that most of the conflicts and crises within the project emerge from this hybridity.

The observance of ethical standards, and the technical skills of individuals are also mediated by three important community documents: the Debian Constitution, which describes the organizational structure for formal decision-making within the project and enumerates the powers and responsibilities of the Debian Project Leader (DPL), the Debian Project Secretary, and the Debian Developers generally; the Social Contract; and the Debian Free Software Guidelines (DFSG). These three documents codify the notion of freedom in the scope of the Debian project and perform a public display of commitment between technical advancement and “software freedom”; they also spell out Debian’s goal to build a solid, community-developed operating system.⁶

In contrast to Debian, Dyne has no formal governing structures but instead operates as a hub connecting different groups that are geographically dispersed – from free radio to Internet radio, software development groups, artists and independent journalists. Its software development group has a clear political agenda of distributed labor among a community of artists and activists in the anti-corporate globalization movement. Most of the software contributors also have experience with radical political collectives and the Dutch squatter movement; the projects’ internal procedures reflect these beliefs in cooperation rather than competition as a philosophical critique of capitalism. The word “dyne” itself comes from the Greek word dynamis, meaning power or self-generated motion, and conveys a leaderless effort whose direction will be determined by the sum of contributions of everyone involved. The mission statement is also pointedly political: “to promote the idea and practice of Open Source knowledge sharing within civil society; to open the participation to on-line and on-site communities, leveraging the democratic and horizontal access to technology, lowering the economical requisites to its accessibility; to foster employment of FOSS in artistic creation: exploring new forms of expression and interaction, disseminating new languages that can be freely adopted and re-elaborated by everyone, insuring the long term conservation of digital artworks; being software a socially relevant media it should not be invented and maintained only on the basis of its merchantability”.⁷ A lack of hierarchical organizational structure complies with the anarchist orientations of Dyne.org members, who see Free Software as inextricably linked to social justice activism, gift economy, and free speech.

Regarding Xara’s governing structure, the company Magix’s top-down approach gave developers no voice in the matter of its withheld code or in determining the quality and shape of the product. According to their website’s FAQs, they are “going to manage the official version. Anything branded Xara will be the official version that has our direct backing, undergone our fanatical quality control to ensure not just they are as reliable and as fast, but that they continue to provide the slick ease of use that Xara are renowned for. Assuming we continue to manage the project, and develop the product as the user community want, to the high standard we have in the past, we would hope to have an active and critical role in the future direction of the product⁸”.

Availability

Like most FOSS projects, Debian, Dyne, and Xara Xtreme’s licenses put these projects under collective control and allow individual access to code. Debian and Xara employ GPL (GNU Public License) version 2. Dyne embraces the general orientation of the GPL license, allowing modification, redistribution, and commodification, given that the derivative piece also carries the same injunction to software freedom. Articulating this on Dyne’s website is the clause: “Verbatim copying and distribution is permitted in any medium, provided this notice is preserved.”⁹ Android, in contrast, is available under a myriad of licenses, which attests to its complexity and to its effort of integration and mediation not only between FSEs from the information and communication technologies industries, but also from community-based FOSS projects. Android uses Apache Software license 2.0, allowing corporate partners from the telephony and embedded systems industry to close-source their add-ons to the platform. To exemplify this feature to render Android close-source, Aaron Williamson – from Software Freedom Law Center – in his OSCON conference talk in 2010 demonstrated that, if all the proprietary software were to be removed from his HTC Android-compatible phone, he would lose the ability to use the built-in GPS, camera, wifi, motion sensor, and bluetooth. In respect to the Free Software that is shipped with the platform, the Linux kernel and the library layer of the Android stack are licensed under the GNU Public License and Lesser GNU Public License version 2 respectively. Other key technologies on Android are protected by a mixture of proprietary and Free Software licenses, such as variants of BSD and MIT. Most of the public participation in the project is concentrated on the top application layer of the platform, where independent developers and companies can use the software development kit to build applications for Android. Interest and attention has been drawn to Android via “developer challenge” programs and “hackathons” in which independent developers are awarded with large sums of cash for creating applications for the platform.

Summary of Cases

Based on our schema for public participation, Debian describes a strong level of participation, particularly at the level of software development and project management. Developers are allowed a say in the structure and goals of the project as a whole, not only in their individual and collective tasks. Its governance structure provides a mechanism for participants to move up within the organizational hierarchy in order to exercise a voice in high-level decisions, and participants can exit without penalty. Volunteer developers not only gain technical skill and cultivate moral values, but they also are encouraged to further develop technical capacities and foster collaborative relationships the more tightly involved they become with the project.

As an OP against an FSE, Dyne.org has created infrastructure for reinforced horizontal participation. Developers engage in tasks as well as goal setting, and the resource is collectively available provided its distribution remains copyleft. Governance is formally decentralized and given no written specifications. It involves gathering an educative dividend both by developing the technology and finding solidarity in activist networks. For Dyne, growth is not a metric for its success. Rather, it values self-reflexive exploration of the affordances of Free Software and liberated spaces for economic alternatives to capitalism.

In contrast to the above cases, weaker forms of public participation in Android derive in part from the project’s derivation from a for-profit business and project management model, which supplies much of the labor pool, rather than an originally unaffiliated Organized Public, which is the case for Debian and Dyne. 


Finally, Xara Extreme is yet another example discussed in the FOSS literature (Schach 2009; Koch 2009) of the large proportion of FOSS projects that failed to attract public participation – “failures” because they could not foster an organized public necessary to take its development further. What is clear from the onset, participation in Xara was weak: participants did not take part in goal setting and had no means to participate in certain parts of the project (task definition and goal setting). By reading the mailing list archives, one is able to see how the interactions between Xara employees and members of FOSS projects: the latter, demanding access to code and suggesting widely shared FOSS tools (source code management tools, bug tracker systems) to conduct a more transparent and open development process. The resource at hand was not opened to the extend of becoming a public good: ten percent of the project, a small but central part, was withheld from developers of the public. In terms of governance, participants’ voices were ignored. Very limited number of channels for communication between the FSE and the OP were available, and very little traffic in the mailing lists were generated. Finally, there was little to gain for the OP, given the lack of development activity around the codebase. We can see that a weak approach to participation had a detrimental effect on the attempt of Xara to foster an OP and develop a FOSS project.

Discussion

This paper aimed to provide a tentative framing of public participation within a variety of FOSS projects. The cases we introduced describe a variety of trajectories in which participation assumes different forms with some overlapping characteristics. In the table below, we offer a systematic evaluation of our cases, comparing them along the five variables we discussed in section 4:

Variable/Project	Dyne.org	Debian	Android	Xaraextreme
Trajectory	OP against FSE	Strong OP which formed one FSE	Mediation between FSEs to constitute one OP	FSE without OP
Project Demographics	Free Software development for artistic and political purposes. Hacker activists, Tactical Media Artists, small number of active contributors	Free Software development by professional and hobbyist programmers, large number of active members, entirely based on volunteer work	ICT companies’ software developers and engineers, freelance programmers, mobile phone application developers	Professional Programmers employed by the FSE; small number of contributors, sporadic participation, all active members are paid employees
Alliances	Self-funded and sponsored with donations from the Dutch government; partners with Free Software projects and hacktivist groups	Donations from IT corporations and companies	Close to one hundred big ICT industry partners	None
Tasks and Goals	Tasks and goals are consensually defined and performed	Tasks are defined by developers, maintainers, and collaborators, and discussed actively in mailing lists; do-ocracy and meritocracy count in the definition of goals and tasks	Tasks are defined by the top engineers of FSEs (which are part of the Open Handheld Consortium) and distributed down to contributors (OP), who have the ability to submit patches, but not have commit rights	Contributions in software development for certain parts of the program (not allowed in others). No commit rights and privileges to members of the OP, only to the members of the FSE
Governance	Consensus driven and meritocracy combined. No formal procedure, ad-hoc decision making, authority based on technical expertise and political trajectory	Meritocracy combined with representative democracy. The most active and skilled members of the OP can apply to become leaders of the project. Formal political structures and procedures are defined and coded in the legal documents of the community	Control and coordination between one central FSE and several other FSEs to foster and advance the project. Members of the public have the ability to participate by developing applications to the platform. Few contributions of the public make to the official codebase of the project	Corporate control over the Open Source project, no accountability
Availability	Free Software Licenses (GPL version 2 and 3). Intellectual Property Rights are kept by the contributors	Free and Open Source Licenses which comply to the DFSG (Debian Free Software Guidelines). Contributions are kept as intellectual property of the contributors	Mixed licensing: Apache 2.0 (preferred), variants of BSD, GPL v2 (Linux Kernel), plus proprietary licenses. Contributions become part of Android, owned by the principal FSE and the partner FSEs	Mixed licensing: proprietary and GPL version 2

The comparison among these four representative cases reveals important differences in how participation is structured. To be clear, this approach does not reveal much about individual motivations or trajectories, but it does offer the outlines of a theory of participation that might help us understand the development of a project based on their relationship (or not) to a formalized entity.

Participation is never a neutral experience – it comes with cultivation of values and implies a sense of worth and an understanding of the context of collaborative work. Generations of scholars have explored the role of worker participation in corporations and factories in order to understand how participation affects everything from worker’s perceptions and well-being to raw productivity and shareholder returns. FOSS projects, however, provide a unique experiment in the reconstruction of organizational forms. The specific trajectory of different projects can be analyzed in order to understand the key features in the table above.

The two features that are most illuminating in this study are the tasks and goals of these projects and their availability of resources. Participation in goals as well as tasks creates a stronger sense of belonging, a more robust sense of deliberative or participatory decision-making, and a sense of obligation that is otherwise absent when participation in tasks is the only option. This can be seen both in the explicit politicization of this aspect by Dyne, but also in the different attitudes and forms of engagement present in Debian versus those in Android and Xara. Another key aspect is related to the attribution of tasks to teams of skilled volunteers, a common practice in FOSS and well documented by Dafermos (2012) in his logitudinal analysis of authority, modularity, and coordination in the FreeBSD project. According to the author, formalization of attribution of tasks “attests that there is a contingent relationship between the governance structure and the scale and maturity of a FOSS project”.

Availability is another important dimension, corroborated by the analysis of Santos Jr. et Al (2011) of attraction to FOSS projects, which suggests how closely participation is correlated with licensing decisions. Participation in decision-making processes is conditioned upon how a resource is managed and maintained, as well as on its legal availability. This difference is most stark in the case of Android, which must walk a fine and complex line between legal availability, managerial and strategic control with obvious implications for the level and kind of participation the product and the project can expect (and manage).

There are important aspects of FOSS projects that were left out of our exposition and should be incorporated in a future version of our study. The temporal dimension of our model (mostly OP to FSE, but also FSE to OP and, sometimes, only OP and FSE without further transformation) is more complex than the relation between these two types of organizational spheres (FSE and OP), given their internal variability and patterns of alliance with other entities that are not FOSS-based. On a larger scale, the distinction OP and FSE captures well the formation and transformation of organizational spheres within FOSS projects. On a micro sociological scale, important questions of trust (Antikainen et al. 2007), moral and political orientation (Leach 2009; O’Neil 2009) for engagement in collaborative projects should be taken further into account. Also, questions of informal, skill-based authority and legitimacy deserves more attention, as a fundamental aspect of voice in decision-making processes of FOSS projects.

Our conclusions here do not settle the question of how to increase participation, or improve the outcomes of FOSS projects – rather they decompose the notion of participation into its component parts in order to ask how one might distinguish between strong and weak participation and for whom. Free Software or Open Source are too often taken to imply a valued form of participation – but this is an unwarranted implication. Rather, it is necessary to explore why participation is valuable, how it has succeeded or failed in the past, and what forms of organization, technology, and politics are giving it a new lease on life.

 

Endnotes

 

 

 

 

 

 

 

 

Android Open Source Project, 2011. “Android Compatibility.”, accessed on 03/08/2012, available at: http://source.android.com/compatibility/index.html

Antikainen, M., Aaltonen, T., Vaisanen, J., Feller, J., Fitzgerald, B., Schcchi, W. and Silitti, A., 2007. “The Role of Trust in OSS Communities—A Case Linux Kernel community.” In Open Source Development, Adoption and Innovation, 223–228. New York: Springer

Antoniades, I.P., Samoladas, I., Stamelos, I., Angelis, L. and Bleris, G.L., 2004. “Dynamical simulation models of the Open Source Development process,” in Koch, S. (ed.), Free/Open Source Software Development, Hershey, PA: Idea Group Publishing, 174-202.

Auray, N., 2003. “Communautes epistemiques d’innovation – La regulation de la connaissance : arbitrage sur la taille et gestion aux frontieres dans la communaute Debian,” Revue d’économie politique. 11: 161.

Barcellini, F., Détienne, F., Burkhardt, J.M. and Sack, W., 2005. “A Study of Online Discussions in an Open-Source Software Community,” in Communities and Technologies, 320, 301.

Browne, C B., 1998. “Linux and Decentralized Development,” First Monday 3, no. 3, available at: http://www.firstmonday.org/issues/issue3_3/browne/index.html.

Coleman, G., 2005. The Social Construction of Freedom in the Free and Open Source Software: Hackers, Ethics, and the Liberal Tradition. Dissertation, University of Chicago, 2005.

Coleman, G. and B. Hill, 2004. “The Social Production of Ethics in Debian and Free Software Communities: Anthropological Lessons for Vocational Ethic,” in Koch, S. (ed.), Free/Open Source Software Development, Hershey, PA: Idea Group Publishing, 273-295.

Crowston, K. and Howison, J., 2006. “Hierarchy and centralization in free and open source software team communications,” Knowledge, Technology & Policy 18, no. 4: 65-85.

Dafermos, G., 2012. “Authority in Peer Production: The Emergence of Governance in the FreeBSD Project”. Journal of Peer Production, 1, no.1.

Debian.org. “Debian 6.0 ‘Squeeze’ released”. February 6th, 2011. accessed on 01/20/2013, available at: http://www.debian.org/News/2011/20110205a.

Debian Bug report logs. “Debian Bug report logs – #354622. Uses Mozilla Firefox trademark without permission” 27 February 2006. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=354622.

Dinh-Trong, T T and J M Bieman, 2005. “The FreeBSD Project: A Replication Case Study of Open Source Development,” IEEE Trans. Softw. Eng. 31, no. 6: 481-494.

Fielding, R T., 1999. “Shared Leadership in the Apache Project,” Communications of the ACM 42, no. 4: 42-43.

Fish, A., C. Kelty, L. Murillo, L. Nguyen and A. Panofsky. “Birds of the Internet: A Field Guide to Understanding Action, Organization, and the Governance of Participation,” Journal of Cultural Economy 4, no. 2 (2011): 157-187.

Franke, N. and E. Von Hippel, 2003. “Satisfying Heterogenous User Needs via Innovation Toolkits: The Case of Apache Security Software,” Research Policy 32, no. 7: 1199-1215.

Gonzalez-Barahona, J., Robles, G., Ortuno-Perez, M., Rodero-Merino, L., Centeno-Gonzalez, J., Matellan-Olivera, V., Castro-Barbero E. and de-las-Heras-Quirós, P., 2004. “Analyzing the anatomy of GNU/Linux distributions: methodology and case studies (Red Hat and Debian),” in Koch, S. (ed.), Free/Open Source Software Development, Hershey, PA: Idea Group Publishing, 27-58.

Gonzalez-Barahona, J., Robles, G., Amor, J.J. and German, D.M., 2009. “Macro-level software evolution: a case study of a large software compilation,” Empirical Software Engineering 14, no. 3: 262-285.

Hamerly, J, T Paquin, and S Walton, 1999. “Freeing the Source: The Story of Mozilla,” in C DiBona, S Ockman, and M Stone (eds.) Open Sources: Voices from the Open Source Revolution. Cambridge, Massachusetts: O’Reilly and Associates.

Hirschman, Albert O., 1970. Exit, Voice and Loyalty: Responses to Decline in Firms, Organizatins, Ans States. Harvard University Press.

Holck, J. and N Jorgensen, 2004. “Do not Check in on Red: Control Meets Anarchy in Two Open Source Projects,” in Koch, S. (ed.), Free/Open Source Software Development, Hershey, PA: Idea Group Publishing,1-26.

Jaromil, 2009. “Interview with Jaromil (dyne.org) by Soenke Zehle.” Posted by the Institute of Network Cultures. 3 March 2009. http://vimeo.com/4165209.

Jorgensen, N., 2001. “Putting it All in the Trunk: Incremental Software Engineering in the FreeBSD Open Source Project,” Information Systems Journal 11, no. 4 (2001): 322.

Kaufman, A. S., 1969. “Human Nature and Participatory Democracy: Ten Years Later.” In The Bias of Pluralism ed. William E. Connolly. New York: Atherton Press, pp. 178-200.

Leach, J., 2009. “Freedom Imagined: Morality and Aesthetics in Open Source Software Design.” Ethnos 74 (1) (March 1): 51–71.

Lakhani, K. and E V Hippel, 2003. “How Open Source Software Works: Free User-to-User Assistance,” RESEARCH POLICY 32: 923—943.

Lynd, S., 1965. The New Radicals and “Participatory Democracy.” Printed for Students for a Democratic Society. Reprinted from DISSENT, Summer.

Mateos-Garcia, J. and W E Steinmueller, 2008. “The institutions of open source software: Examining the Debian community,” Information Economics and Policy 20, no. 4 (December): 333-344.

Matthew, R., 2003. The Pressure of Openness: the hybrid work of the Linux Free/Open Source Kernel Developers. Dissertation, University of California, San Diego.

McKusick, M K., 1999. “Twenty Years of Berkeley Unix: From AT&T-Owned to Freely Redistributable,” in Open Sources: Voices from the Open Source Revolution, ed. C DiBona, S Ockman, and M Stone. Cambridge, Massachusetts: O’Reilly and Associates.

Mockus, A, R Fielding, and J Herbsleb, 2002. “A Case Study of Open Source Software Development: The Apache Server,” in Proceedings of the 22nd International Conference on Software Engineering (ICSE 2000), 263-272.

Mozilla.org, 2008, “Mozilla Foundation Reorganization.” 21 April. http://www-archive.mozilla.org/reorganization.

O’Mahony, S., 2005. Nonprofit foundations and their role in community-firm software collaboration. In Perspectives on free and open source software, edited by J. Feller, B. Fitzgerald, S. A. Hissam, and K. R. Lakhani, 393-413. Cambridge, MA: MIT Press.

O’Mahony and Ferraro, 2007. The emergence of governance in an open source community. Academy of Management Journal, Vol. 50, No. 5, pp. 1079-1106.

O’Neil, M. 2009. Cyberchiefs: Autonomy and Authority in Online Tribes. London: Pluto Press.

O’Neill, D., n.d.. “Xara Xtreme History.” Digitalred.com, http://www.digitalred.com/oldsite/xara-xtreme-history.php.

Pateman, C., 1970. Participation and Democratic Theory. Cambridge: Cambridge University Press.

Robles, G., J Gonzalez-Barahona, and J Merelo, 2006. “Beyond source code: The importance of other artifacts in software development (a case study),” Journal of Systems and Software 79, no. 9: 1233-1248.

Santos,Jr., Carlos Denner, Marcos Bonci Cavalca, Fabio Kon, Julio Singer, Victor Ritter, Damaris Regina, and Tamy Tsujimoto, 2011. “Intellectual Property Policy and Attractiveness: a Longitudinal Study of Free and Open Source Software Projects.” In Proceedings of the ACM 2011 Conference on Computer Supported Cooperative Work, 705–708. CSCW’11. New York, NY, USA: ACM.

Serres, M., 2007. The Parasite (Posthumanities). Minneapolis: University of Minnesota Press.

Smith, A. and Jones, B., 1999. On the complexity of computing. In Advances in Computer Science, pages 555–566. Publishing Press.

Toral, S., 2009. “Virtual communities as a resource for the development of OSS projects: the case of Linux ports to embedded processors,” Behaviour & Information Technology 28, no. 5: 405-419.

VisionMobile, 2011. “Open Governance Index”, accessed on 09/11/2012, available at: http://www.visionmobile.com/product/open-governance-index/

Willis, N., 2007. “Lessons learned from open source Xara’s failure.” Linux.com, 13 October. http://archive09.linux.com/feature/119790.

*Research for this paper was carried out under National Science Foundation (NSF) grant #1025569. Support was provided by the Center for Society and Genetics (UCLA). Authors are listed in alphabetical order.