The Handbook of Peer Production

Rules, social norms, as well as basic understandings and values constitute an essential element in the governance of peer production. Governance can be understood, following Markus (2007), as “the means of achieving the direction, control, and coordination of wholly or partially autonomous individuals” (p. 152). In peer production, governance does not preclude autonomy, but presupposes free will and a non‐contractual nature of cooperation. On this note, O’Mahony (2007) defined it as a “community‐managed governance model” (p. 144). Governance manifests in the independence from commercial organizations, a pluralism of interests and solutions, decentralized decision‐making, and the prospect of autonomous choice.

For free and open source software, governance includes the free licensing of the software provided and usually of the technological infrastructure used for collaboration. It also encompasses the signaling and allocation of tasks to be completed, the inspection and selection of contributions, and the control of release versions (Markus, 2007). Besides written rules and normative creeds, governance rests on code features such as the concurrent versions system (CVS) used to keep track of changes to a file. The source code management system therefore helps to control software revisions. Developers also check the file transfer protocol (FTP) for the transmission of files between clients and servers on a computer network. Governance also covers the communication among project members in chats, via mailing lists, or forums. It deals, for instance, with bug reports, votes, or the communicative sanctioning of troublemakers like flaming, shunning, or kill‐filing, that is, automatically discarding posts from particular users.

A core concern of peer production governance are hierarchies. Despite their egalitarian ambitions, structures of authority and influence have loomed in most projects (Dahlander & O’Mahony, 2011; de Laat, 2007; O’Neil, 2009; Weber, 2004). They frequently rest on seniority and thus on the length of continuous participation, as well as on the volume of engagement. Along these criteria, many ventures exhibit a loose onion‐like segmentation into core contributors, regular or occasional contributors, and users or beta‐testers (Raymond, 1999). Peer production relies on voluntary support and personal commitment so that “heavy‐handed control can deter participation” (Shah, 2006, p. 108). In other words, leadership does not rest on formal command positions. Rather, authority is a matter of meritocratic achievement and acceptance (von Krogh, Spaeth, & Lakhani, 2003; Stewart, 2005). It presupposes a number of qualities such as communicative skills, the ability to recognize valuable contributions as well as the competence to set goals, control tasks, and motivate fellow users.

The role model for this type of “benevolent dictator” (Weber, 2004, p. 89f.) is Linus Torvalds who founded Linux. In the project, he assumed a gatekeeper position from which he was able to monitor the release of official versions of the software. Being aware that his authority depended on the goodwill and appreciation of participants, he “never orders anyone to do anything and even his suggestions are mild‐mannered” (Moon & Sproull, 2000). Such attitude and diligence are, however, precarious and nothing that can be taken for granted. Hence, Torvalds himself has been criticized for departing from this ideal by becoming more restrictive and imperious over time.

In their survey of governance styles in free and open source software, Shaikh and Henfridsson (2017) call this kind of governance autocratic clearing. “Autocratic clearing,” they explicate with the example of the Linux kernel, “is a system of management with singular coordinating points that obliges other actors to channel all work and decisions through a central ‘clearing house’ before accomplishment” (p. 124). Other modes of ordering they examined involved a more stratified regime of decision‐making and peer review of segments contributed to the Linux code. Next to such “oligarchic recursion” (p. 125) they found evidence for a more autonomous form of self‐governance where branches broke away from the main project. Yet another type of governance process embodied the negotiation of mutually agreed decisions considering divergent viewpoints, what Shaikh & Henfridsson (2017) have named “meritocratic idea‐testing” (p. 127).

The governance arrangements organizing cooperation in peer production and its outcomes are not fixed but evolve over a project’s life‐cycle. This change reflects the influx of new users and the growth of the project. It also indicates transformations in the institutional environment of a project and in the relations between contributors (Mateos‐García & Steinmueller, 2008). For Debian, O’Mahony and Ferraro (2007) describe four phases of governance. Initially, the collective enterprise was organized by de facto governance. It was based on autocratic rule without any consistent involvement of the contributors. In the next phase of designing governance, a hierarchy of positions was devised that should exist apart from the actual people assuming a certain role. This plan was then set to work in the phase of implementing governance. It demanded that the execution of positional powers had to rest on the commission of fellow developers. The final stage of a stabilizing governance was achieved when elections were successfully held in order to transfer a mandate from one user to another (Schweik & Englisch, 2012).

Along these steps, Debian as a mature free and open source software project has established a “Social Contract” that codifies key principles of cooperation and the normative expectations undergirding the users’ collaboration. The responsibilities and the structural relationships of project governance are furthermore defined in a Debian Constitution and there are elections for project leadership. The many consecutive versions of this document show that it is not locked up but is an element of ongoing debate, and subject to amendments (Sadowski et al., 2008).

In Wikipedia, what has been devised as a fluid and transparent process risks petrifying into quite rigid bureaucratic configurations with counter‐productive consequences. Instead of facilitating cooperation, standardization and hierarchization block new users and hinder user retention. They complicate decision‐making procedures, promote elitism, and lead to an organizational deadlock that defies the ideas of openness and inclusivity. These implications of bureaucratization as more of a burden than a driver of peer production have especially been studied for Wikipedia (Butler et al., 2008; Carr, 2011; Halfaker et al., 2013). Despite early accounts of an ad hoc form of non‐hierarchical governance (Konieczny, 2009, 2010), in many language versions hierarchies have tended to become more pronounced (Shaw & Hill, 2014). In line with this finding, the number of links to policy pages in Wikipedia discussions has increased, in particular in reference to the rules about signing individual posts, the use of reliable published sources, and the neutral point of view (Beschastnikh et al., 2008). While the citation of policies has risen, their creation slowed down (Forte & Bruckman, 2008). The attention towards existing rules thus went hand‐in‐hand with the diminishing flexibility to change these rules and declining revision activity (Keegan & Fiesler, 2017).

The organization and governance of peer production projects has to balance the independence of individual contributors and the interdependence of a collective endeavor. In‐between the promise of autonomy and the implementation of due process, peer production projects struggle with the suitable level of provision and tolerance (Kostakis, 2010). Initiatives have fed on principles of free choice and increasing individual agency. Yet they are challenged by the reality of an increasingly vast and pervasive texture of rules and requirements which should secure the accuracy and value of the resource and respond to societal expectations.