Coding Freedom: The Ethics and Aesthetics of Hacking

a few of the delegates. These arguments follow a predictable arc: some developers complain about a lack of transparency among the guardians; on the other hand, the guardians feel suffocated under the weight of theirobligations, so that the work necessary to communicate and increase the transparency of the role becomes an impossible, unnecessary additional burden; then the developers will offer to help share the workload; and typically the guardians’ exasperated response is that integrating and training new people would require more work than they can take on, or the developers need to take the initiative themselves.
    Nonetheless, there are some established routines for increasing the visibility and transparency of different working groups, including emails sent out to all developers on the debian-devel-announce mailing list (a required subscription for developers) that summarize the most recent activities of the different technical teams. These informal updates are sent periodically to project members and forge a connection with the body politic of Debian. One former FTP master, James Troup, known more for his technical prowess and dedication than for his communicative access, once sent such a status report titled “Bits from the FTP Master Team” after there had been several months of debate on the mailing lists about the opacity of the FTP master’s exact role and complaints that the FTP masters were becoming roadblocks to the project in failing to fulfill their duties. His email, drafted by a number of team members, announced the addition of new members to the team and provided some clarification over the exact responsibilities of each member. Following this information, Troup and the other FTP masters ended the email with a humorous, bitingly sarcastic remark that asserted their goodwill while discounting the complaints as overblown: “We hope this has made your day more pleasant, and your nights less filled with the keening wails of the soulless undead.” 15 Its ironic and sardonic subtext is clear: Troup has heard and registered the complaints, is humored that people thought that the situation was so hellishly torturous, and is revealing that there is nothing to worry about, because he is acting in good faith and this unnecessary email serves as his merciful act of grace releasing souls from the unbearable suffering that they were experiencing.
    Along with consistent communication, delegate technical proposals must be carefully framed to reflect project and not personal goals. In many instances, it is imperative to let certain decisions be made through an ad hoc, consensual process in which the merit of the outcome emerges via a processes of collective debate rather than as a mandate from those with vested authority (even if the outcome falls entirely within their purview).
    An interesting site to examine is the committee invested with the greatest technical power: the Technical Committee. Its role is defined in the Constitution as “the body which makes the final decision on technical disputes in the Debian project,” and its members perform their good intentions largely by way of inaction. 16 In the period during which I followed Debian (2000–2005), for instance, this committee rarely exercised its authority.
    A hands-off approach is thus how committee members establish their good intentions toward the very process that afforded them the right tobecome part of the Technical Committee. It reflects the general ideal that those in authority should first defer to the developer community so that differences of opinions can be solved through debate and consensus. The Technical Committee Web site enunciates this notion clearly under the heading “Some Caveats about Contacting the Committee”: “A sound and vigorous debate is important to ensure that all the aspects of an issue are fully explored. When discussing technical questions with other developers you should be ready to be challenged. You should also be prepared to be convinced! There is no shame in seeing the merit of good arguments.” 17
    The argumentative consensus advocated by the Technical Committee is the third mode of governance in Debian—a mode that is understood as a form of self-governance because it stems from the debate, contributions, and actions of independent-minded, consenting individuals. A tremendous faith is placed in the power of what might be called “technical rhetoric” to convince others of the logic of decisions that