This is the third and last part of our treatment of a landmark book on the governance of online ‘tribes’.

Book: Cyberchiefs. Autonomy and Authority in Online Tribes. Mathieu O’Neil. Macmillan/Pluto Press, 2009.

In this excerpt from Chapter 7, Mathieu O’Neil covers authority and leadership at debian.org :

(the references are listed here)

‘The Cathedral and the Bazaar’ is the title of a famous essay by Eric Raymond. Raymond contrasted the secretive low-frequency-release model of Richard Stallman’s Free Software Foundation’s GNU software to the ‘release early, release often’ model pioneered by Linus Torvalds with Linux. Nicolas Auray has argued that Debian represents an attempt to make the bazaar viable, with norms aiming to reduce tensions, but also moral, with institutions aiming to reduce unequal relations. (1) This represents an evolution for FOSS projects from purely charismatic models such as Linux which are based on a ‘lazy consensus’: if no one makes an objection after three days, then a proposal is accepted. (2)

Debian must reconcile the central notion of each developer’s autonomy, and the respect for difference, with the constraints deriving from the production of a complex system with quality standards of the highest order. This is the main purpose of the modular structure: to give developers full administrative control over their packages or teams, in a mini-cathedral model. This level of personal control is in fact a primary attraction for many FOSS developers, who are then free to work alone if they wish. There is also less chance of being criticised for one’s work if one keeps control over it and only releases finished versions, thereby stopping others from interfering. At the same time, Debian packages all follow strict production guidelines (‘policy’) and can easily become integrated.

The absence of monetary rewards in Debian guarantees that reputation benefits earned by technical excellence (hacker charisma) are the standard for all value. One sign of authority in Debian might therefore be the number of packages any one developer is responsible for: the higher the number, the greater the hacker-charismatic authority? Yet a higher level of administrative authority is required to deal with infrastructure that stretches over different packages. Martin Krafft observes that these core tasks are undertaken ‘by a smallish number of developers that take Debian very seriously’. (3) Studies of other free-software projects have shown that small groups are responsible for the majority of work.

Lerner and Tirole argue that a tiny minority make the largest contributions, their integration into the ‘core group’ of developers representing the ultimate recognition by their peers. (4) A study of the development of Apache showed that out of 400 developers, the top 15 contributed between 83 and 91 per cent of changes, whilst ‘bug’ (or problem) reports were much more evenly distributed. (5)

Krafft notes that since the membership of the security team is seen as prestigious, ‘some people write lengthy emails explaining why they should be picked’. (6) Naturally these requests are never honoured: only those who have contributed are deemed worthy of inclusion.

Highly specialised knowledge of the project’s infrastructure or of the workings of a core team, accumulated over years, risks becoming fossilised. This is the central question for Debian, and indeed for any volunteer project requiring high levels of expertise: how do the tribal elders transmit their wisdom? As will be shown in the next section, this question is largely unresolved.

Supporting new users is a crucial activity if the project is not to wither away. Hacker-charismatic authority can be detected by examining interactions in lists, the project’s primary communication and education tool. FOSS lists are not simply forums for discussion, but are also means for peers to evaluate the quality of code or advice. A question must be useful for everyone, otherwise it risks the indignity of the questioner being directed to documentation such as the FAQ. (7) Studies of patterns of questions and responses on the debian-french user list reveals a tension between a system of massively distributed collective authority in which everyone and anyone authorises themselves to respond to a request on the one hand, and the constitution of an elite based on reciprocal approbation on the other. The selection of who one responds to, as well as how one responds, is crucial: authoritative responses on threads are primarily addressed to previous respondents, rather than to the original questioner. The threaded nature of discussions on lists enables the selection of high-status partners. A mutually responding core emerges, which preserves expert authority in the midst of a dynamic and open system. (8) On developer lists, studies show that the necessary knowledge of all the elements of the distribution, allowing people to foretell problems and remember solutions, is not equally distributed. List archives can be viewed as the minutes of a permanent assembly, which is directly accessible to all at every minute, but only the most experienced members can remember or find their way around the mounds of archived information. The authority of such tribal elders represents the means of moderating the obsessional reference to technical excellence. (9)

Unlike on Daily Kos, where the two variants of online charisma mutually reinforce one another, hacker and index charisma on Debian are fundamentally antinomic. This is because index authority always contains an arbitrary element: the identity of earliest entrants is due to chance, not talent. Since Debian is based on meritocratic skill, it should in theory have no place for the other form of online charisma.

How did the index-authority virus enter the project? As previously mentioned, a key goal for leaders of online tribal projects is to distribute administrative power whilst maintaining quality. Since the autonomous structure makes it very hard to discipline people, the maximum effort must be borne upstream, before recruitment occurs. In practical terms, this boils down to: who can be trusted to access the levers of control? Contrary to weblogs (where administrative power is never fully opened to everyone) and to wikis (where all modifications are instantly reversible, and do not affect the whole project), contributors to Debian really do have the potential to harm the software.

As a result, a central difference between Debian and the other cooperative projects examined in this book is that contributions cannot be anonymous. Online communities are routinely described as having fluid boundaries and shifting members and identities. In contrast, members of FOSS projects who are developing software that is hosted on protected servers connected to the Internet must maintain a distinct and trusted identity, which will enable them to gain access to these protected resources. (10) Since developers are capable of modifying the code, the project has to be protected from Trojans (hidden bugs or viruses) as well as from well-intentioned but unskilled developers.

There are various means by which a digital identity can be authoritatively linked to the entity it claims to represent. The answer for Debian lay in the use of keys (large numbers) that allow data to be encoded and decoded. If the key is secret, and the same key is used to encode and decode a message, sender and recipient cannot exchange a secret key to begin with. A possibility is public key infrastructure, where a centralised certifying authority registers users and delivers certification to them. But autonomous projects require a distributed solution. The aim of securing identities led to the establishment of a private-key cryptography system, whereby a public key encodes data, and a completely different key decodes the data. The authenticity of the communication’s content is guaranteed, but this process does not verify the link between the key and the sender’s identity. Real-world identities must be connected to a given public key. This is achieved when identity certificates (including public keys and owner information) are signed by other users who are themselves known and trusted by the tribe.

The physical act of vouching for the link between a public key and the person or entity listed in the certificate takes place at offline ‘key-signing parties’. Developers bring a copy of their public key and valid photo identification; they meet and certify another’s public key. A key which has been signed can then be placed on a central key server maintained by a keyring coordinator. In social network analysis terms, O’Mahony and Ferraro write that the resulting web of trust rests on the assumption that ‘the more people who have signed each other’s key (the greater is the density of the network), the more reliable is the information authenticated’. (11)

This process contains the hallmarks of a familiar scenario in which entrants who have accumulated many endorsements are advantaged and it is hard for new entrants to break in. O’Mahony and Ferraro have analysed the dating of key-signings and suggest that between 1997 and 2001 the Debian keyring network increasingly conformed to a power-law mode and became centralised. Formalised membership processes, such as a vetting team (the New Maintainer Committee or NMC) and the requirement of sponsorship by an existing developer, encouraged preferential attachment to gatekeepers, as measured by key-signings. O’Mahony and Ferraro’s conclusion, that becoming a central player through physical participation in key-signings ‘enhanced the probability of attaining a gatekeeper position far more than the number of packages maintained’, (12) seems unassailable. However their assertion that preferential attachment influences the ‘structure of the network as well as the design of governance mechanisms’ assimilates recruitment procedures to overall project governance. There is scant evidence that this is the case, beyond the fact that the head of the NMC was elected Debian project leader in 2003. It is arguable, for example, that membership of Debian’s Technical Committee (TC), or of key infrastructure teams, is of greater significance to the project, because these positions are not renewed every year.

The influence of index-charisma is counterbalanced by Debian’s embrace of sovereign authority. An egalitarian or collectivist organisation based on the sovereign will of all participants is the natural format of ‘successful anarchist communities’. (13) This takes a number of institutional forms. The autonomous authority of individual developers over their packages is overridden by the greater good, as expressed in two institutional mechanisms: the General Resolution Protocol and the Technical Committee. Though Debian users can take part in mailing-list discussions, only developers can vote in a general resolution or sit on the TC. Debian Developers (DDs) elect the Debian project leader every year. The DPL in turn appoints or reappoints the chairman of the Technical Committee and the secretary; these three roles must be distinct. The DPL also appoints delegates, such as the FTP master, who controls uploads of packages; release managers, who are in charge of supervising the release process; security team managers, who coordinate security issues with other projects; and Debian account managers or DAMs, a very sensitive position as they maintain Debian accounts and oversee the recruitment of new members, and can also expel or suspend developers. Often delegates are reappointed in their roles for many years.

The TC is a kind of supreme court which is supposed to arbitrate matters of technical policy, decide where developers’ jurisdictions overlap, and, when necessary, overrule developers. The secretary administers, and reports on, the voting process. Secretaries can stand in for the leader (as can the TC chairman) and they adjudicate disputes about interpretations of the constitution. The ultimate authority is the democratic will of all the developers, who can recall leaders, reverse decisions by leaders or delegates, or amend the constitution through a general resolution. In practice however, this is seldom used: in the ten years following the adoption of the Constitution in 1998, there have only been twelve general resolutions.

As for DPLs, their authority is qualified. The constitution states that, just like a traditional tribal chief, ‘the Project Leader should attempt to make decisions which are consistent with the consensus of the opinions of the Developers’. (14) Leaders make decisions for which no one else has responsibility, but should ‘avoid overemphasising their own point of view when making decisions in their capacity as leader’. (15) How can project leaders enforce their decisions? Their compliance arsenal is limited, as demonstrated when the DPL, in an effort to compel a recalcitrant developer to report on what he was up to, published an open letter to the developer in an attempt to shame him into action. (16) Because of the delays in processing new applicants, the status of Debian maintainer, situated between developers and users, was created in 2007. This authority level would be for users who had been maintaining a package for some time; they would be allowed to upload without going through maintainers. However, they would not have voting rights, nor would they have access to the debian-private mailing list or the Debian infrastructure. (17)

As has frequently been noted, external enemies serve to coalesce boundaries of exclusion and inclusion. The originating enemies of all free-software project, which motivate and sustain their existence, are entities which restrict hacker autonomy. Lehmann writes that such enemies include ‘anything and anyone which is perceived as prohibiting access, including copyrights, patents, and secret source codes, but also mechanisms that encourage dependence’. (18)

Richard Stallman once declared that persecuting the unauthorised redistribution of knowledge by robot guards, harsh punishments, legal responsibility of ISPs and propaganda is ‘reminiscent of Soviet totalitarianism, when the unauthorised copying and redistribution of samizdat was prohibited’. (19) This kind of outburst is rare. Hackers in general, and Debian developers in particular, do not as a rule disparage proprietary software; its inferiority is taken for granted, not dwelt upon. This is because, as in the blogosphere, conflicts with the ‘same’ far outweigh in intensity those against the ‘other’.

A prime candidate for the role is a rival software distribution named Ubuntu. Financed by Mark Shuttleworth, a dot-boom entrepreneur, and his firm Canonical, Ubuntu’s strongpoint is the clockwork regularity of its releases: every six months, Ubuntu developers ‘freeze’ Debian, make a selection amongst the myriad Debian packages, and release them as an integrated system. Ubuntu’s ease of installation and its successful generation of a community network of support and development, complete with mailing lists, have proved popular. Debian’s original founder, Ian Murdock, who left the project, commented that Debian had ‘brought this fork on itself with its glacial pace’. (20) The Ubuntu website states (emphasis added) that ‘the Ubuntu project attempts to work with Debian to address the issues that keep many users from using Debian.’ (21) A developer justified leaving Debian for Ubuntu because he was tired of the frequent flame wars and because ‘having one person who can make arbitrary decisions and whose word is effectively law probably helps in many cases’. (22)

Conversely, some Debian users affirmed their distinction as true free-software aficionados: ‘most people who use Ubuntu (Not to insult them) are teenagers who want to use Linux in the same way “hip” people use Macs’. (23) Sometimes the hostility moved offline, for example at the annual Debian development conference debconf6 where someone ‘was attacked for wearing an Ubuntu T-shirt … while someone else was applauded for wearing a “Fuck Ubuntu” t-shirt’. (24)

In contrast to Debian, Ubuntu’s updates had a clockwork regularity; and it was disturbing for volunteers to see others being paid for what they themselves were doing for nothing. (25) The rise of Ubuntu also risked turning Debian into a supermarket of components with little work being done on the crucial elements that work across packages. (26) But the biggest problem was the perception that as Ubuntu grew, it was effectively leeching off Debian, but not paying Debian back in the coin of the realm: improvements to the software.

The Ubuntu website declares that bugs listed on the Debian Bug Tracking System (BTS) and fixed in Ubuntu are automatically communicated back to the BTS. Yet in 2008 a former Debian project leader declared that developers were unhappy about the relationship with Canonical, who they believed was not actively contributing back to Debian: ‘They’re not giving back as much as they claim to do.’ (27) In breaking the development code, Ubuntu was not behaving honourably.

What is the role of honour in Debian? Nicolas Auray argues that the ethic of the Debian project is a form of ‘moral heroism’ or ‘civic totalitarianism’ required by the participants’ constant mobilisation via the mailing lists. This generated a specific Debian ‘netiquette’.

Members of the tribe have to demonstrate perfect self-control, temper their emotions and follow norms of humility. (28) That inventors require norms of humility to moderate an intense focus on originality and priority had been posited by Robert Merton in his sociology of the scientific field. (29) In Debian, humility serves to temper not priority, but authority over packages. Yet it is debatable whether humility really influences behaviour in an environment predicated on technical excellence, and which clearly constitutes a continuation of the confrontations of Usenet, as evidenced by countless references to ‘flame wars’ and ‘killfiles’ (and their distinctive *plonk* noise). In this context the threat of dishonour allows the lack of observance of the humility norm. Honour is less a bug in system than a fallback mechanism, an (archaic) justification for autonomous conflictuality. When a French user dared to criticise the lack of responsiveness of developers to user needs, a developer replied: ‘What am I, your servant? We are volunteers who have better things to do than listen to the inept ramblings of a minority of users who know better than us what they want to do.’ And the next day another developer added, speaking to the same user: ‘Contrarily to you, we don’t just watch, we play’. (30) The developer’s honour is rooted in being active and autonomous.”