Peer projects do not operate in strict hierarchies of command and control, but rather in heterarchies; they operate “in a much looser [environment] which…allows for the existence of multiple teams of participants working simultaneously in a variety of possibly opposing directions” (Bruns, 2008, p. 26). According to Bruns (2008) peer projects’ heterarchies are not simply adhocracies, but ad hoc meritocracies which, however, are at risk of transforming themselves into more inflexible hierarchies. In a nutshell, peer governance’s main characteristics are the equipotentiality, i.e. the fact that in a peer project all the participants have an equal ability to contribute, although that not all the participants have the same skills and abilities (Bauwens, 2005a, and 2005b); the heterarchy as a form of community; and the holoptism i.e. the ability for any part to know the whole (Deleuze, 1986).
Stadler (2008) submits that leadership in peer projects is not egalitarian, but meritocratic: “Everyone is free, indeed, to propose a contribution, but the people who run the project are equally free to reject the contribution outright”, as “the core task of managing a Commons is to ensure not just the production of resources, but also to prevent its degradation from the addition of low quality material”. Further, benevolent dictatorships are common in peer projects (Bauwens, 2005a, and 2005b; Malcolm, 2008). For instance, these can be found in Linux project where Linus Torvalds is the benevolent dictator (Malcolm, 2008) or in Wikipedia where Jimmy Wales is also the benevolent dictator. Coffin (2006) refers to the necessity for a benevolent dictator (who typically is one of the founders of the project) adding that the foundation developers and the early adopters set the project ethos, as well. The founder, along with the first members, upholds the right to fork out. Axel Bruns (interview with Bruns, 2009) defines the benevolent dictators “as ones of several heterarchical leaders of the community, who have risen to their positions through consistent constructive contribution and stand and fall with the quality of their further performance”. It is obvious that through such leadership roles, they may gain the ability to push through unpopular decisions. So, as Bruns notes, “if they abuse that power, theirs become a malicious leadership” and what we should expect at this point is “a substantial exodus of community members”. Therefore, following Bruns’ narrative, “the continued existence of the project at that moment would depend very much on whether the number of exiting members can be made up for in both quality and quantity by incoming new participants”.
In addition, Coffin (2006) mentions some characteristics of the peer governance of successful open source communities. The membership is open and widespread premised on participation. The collaboration among the members of the project is geographically dispersed, asynchronous and organized in networks. Moreover, the project is transparent and the dialogues among the participants are recorded, and the materials of the project are subjected to open review. There is a mechanism for institutional history, as well as the setting of a compelling foundational artifact around which the production and the participation will be organized is crucial.