Coding Freedom: The Ethics and Aesthetics of Hacking

an ending, the closing of this section will end with a beginning.
    There are a number of events that I could have chosen to illustrate the social metabolism of a crisis in Debian. I have picked this one because of the rich multiplicity of issues it raises, and because I actually witnessed and closely followed its ebb and flow from the instant it began to its current recession.
    Let me provide some background on the project’s status at the time in March 2005. Debian was in the process of choosing a new leader. There were several candidates, and the ideas they brought to the table concerned fundamental questions of governance that could alter the nature of the Debian project leadership, communications issues, the role of women in the project, transparency, a perceived hostile working climate, growing pains, and the uncertain threat of a new Linux project based on Debian (Ubuntu). The project was gearing up to complete a new release, and given this, there was a heightened sense of pressure. It was in this frenetic climate that a single email began the crisis.
    The Debian release manager sent this email to the developer list, announcing the final plans for releasing Debian’s latest distribution. An in-person meeting in mid-March had convened in Vancouver, Canada, bringing together the FTP masters, the release team, and members of the security team to hammer out a plan that offered a concrete vision for Debian’s technical future. In addition to information about the upcoming release, proposals were advanced detailing how to handle the release after that, called “etch.” The participants in the Vancouver meeting had concluded that the era of universal architecture support was over. Debian did not have the technical or human resources to support as well as maintain so many different versions of Debian at the time. These “ports,” as these different versions are called, run on different hardware architectures, ranging from i386 to AMD64:
    The much larger consequence of this meeting, however, has been the crafting of a prospective release plan for etch. The release team and the FTP masters are mutually agreed that it is not sustainable to continue making coordinated releases for as many architectures as Sarge currently contains, let alone for as many new proposed architectures as are waiting in the wings. The reality is that keeping eleven architectures in a releasable state has been a major source of work for the release team, the d-i team, and the kernel team over the past year; not to mention the time spent by the DSA/build admins and the security team. It’s also not clear how much benefit there is from doing stable releases for all of these architectures, because they aren’t necessarily useful to the communities surrounding those ports. Therefore, we’re planning on not releasing most of the minor architectures starting with etch. They will be released with Sarge, with all that implies (including security support until Sarge is archived), but they would no longer be included in testing. This is a very large step, and while we’ve discussed it fairly thoroughly and think we’ve got most of the bugs worked out, we’dappreciate hearing any comments you might have. [ … ]
    Note that this plan makes no changes to the set of supported release architectures for Sarge, but will take effect for testing and unstable immediately after Sarge’s release with the result that testing will contain a greatly reduced set of architectures, according to the following objective criteria:
    —it must first be part of (or at the very least, meet the criteria for) scc.debian.org (see below)
    —the release architecture must be publicly available to buy new
    —the release architecture must have N+1 builds where N is the number required to keep up with the volume of uploaded packages
    —the value of N above must not be > 2 22
    At first glance it may be unclear what in this technical, matter-of-fact email would have led to a crisis. The meeting’s participants included the technical guardians of Debian, and their advice is usually held with respect. But before I explain why such a seemingly benign proposal produced such an event, first let me describe the response, for it was nothing short of monumental—even by Debian standards of crisis. Within the first day there were over five hundred email messages in response, and within three days, there were over nine hundred emails. This text of mailing lists, if taken together,