Coding Freedom: The Ethics and Aesthetics of Hacking

highest order,” as Mathieu O’Neil (2009, 134) has so aptly put it. Most of the time, these jokes are playful. They work like a safety valve to diffuse tension, and are used as a creative and oblique reminder to those in positions of authority that their intentions must be transparent for them to receive the continued trust of the developer population.
    At other times, developers couch discussions of the cabal as accusations, seeking more trustworthy behavior from meritocrats, which is usually expressed in claims for greater transparency, accountability, and accessibility. In the recent Debian project leader debate, for example, one developer wrangled with an FTP master over what could be done to increase the project’s transparency and equalize the access conditions. The developer invoked the specter of the cabal:
    I see Debian as a meritocracy, and the way to receive privileges is to contribute and be pro-active. However, it cannot be the goal to expect from willing users to figure out everything about a job all by themselves prior to being able to gain recognition for the contributions they make—if they are lucky enough to be considered useful by current holders of the position strived for. If this is actually intended, then it is highly inefficient. If it is not intended, then maybe Debian wants to do something about it, and if not only to stop cold those rumours about an alleged cabal. 13
    This developer felt that Debian developers could do more to increase transparency in order to facilitate and encourage participation from new members. Many of the developers he was arguing with (those in positions of power) disagreed, saying that there was enough transparency and that it was incumbent on interested members to take responsibility for their ownself-education, independent of the help of others. This is conveyed in the email below, where one FTP master responded to the claim that Debian policy and organization is too obscure:
    > What you fail to see is that there is something daunting about
    > a project of this size and complexity to those who are trying to
    > understand it top-down, rather than having been part of building it
    > bottom-up.
    What you fail to see is that the bits are available and that you “only” have to build the large picture. If you’re too lazy to do so, it’s not the job of the people working on essential corners of the project to educate every random Johnny Sixpack for the sake of it. 14
    Even when there is pressure to equalize the conditions for access, which is manifested in jokes about the cabal, equalization within a meritocracy, as I discussed in chapter 3 , must proceed by specific methods. Many (though not all) developers feel that if too much help is given to newcomers, it will undercut their ability to prove their worth and intelligence within a group that values precisely this sort of performance of self-reliance. The line between the equalization of conditions and too much assistance is constantly being negotiated in Debian, and perhaps more so than in other projects because of its populist bent.
    Debian’s meritocratic guardians find themselves in a paradoxical position with respect to hackers who accord tremendous weight to liberal individualism, especially constant acts of technical self-fashioning and the open-ended process of nonpartisan technical debate. Granted the authority to act without the community’s prior consent, the guardians rarely can do so without displaying good and pure intentions. In this way, these developers, much like the early natural philosophers of Britain’s Royal Society studied by Steven Shapin (1994), must constantly garner the trust of peers through the performance of character virtues and other related acts.
    If the natural philosophers of the Royal Society displayed good faith through a combination of humility, detachment, generosity, and civility, how do the meritocratic guardians of Debian perform their good intentions and navigate this dilemma? Delegates and teams manifest their pure technical intentions through a wide range of practices (and humility is not always one of those, although it certainly can be). Many can display their intentions simply through ongoing technical work—a form of labor that speaks to their unwavering commitment to the project. They are supposed to communicate openly with developers, and in some periods, developers voiced their dissatisfaction by clamoring for more transparency and accountability from