Coding Freedom: The Ethics and Aesthetics of Hacking

turn, developers contributed their own views on what would have been the proper way to approach the problem, and others contributed discussions and proposals about how to technically proceed. The release manager and another member of the participating teams were remarkably attentive: they wrote emails and talked to developers on IRCs to appease fears, explained technical details, took into account the recommendations of others, revealed what happened at the meeting, and especially, reaffirmed that nothing was written in stone. In essence, they conformed to the stipulation by Plato (n.d.) that “[the guardians] must be capable of possessing this connection, never forgetting it or allowing themselves to be either forced or bewitched into throwing it over.” In contrast with Plato’s
Republic
, what this crisis shows is how in Debian, anyone can theoretically become a philosopher king so long as they posses the right intent and skill, and so long as the channels for dialogue are kept open. As a result of these often-passionate outpourings, the proposal was transformed into a proposition awaiting further discussion. In the end, although it took a blow, trust was reestablished.
    One participant and member of the FTP team posted the following explanation, which provided a window into the meeting’s organic development and affirmed the proposal’s openness:
    As it happened, James and I were staying at Ryan’s, and after dinner on Friday night (before the meeting proper started, but after we’d met everyone), we chatted about the topic and came to the opinion that removing a bunch of architectures from being release candidates would be necessary—for reasons I hope are adequately explained in the announcement, or that will be on –devel as people ask. As it turned out, when we got to the actual meeting thenext day, this was more or less exactly what Steve was wanting to propose, and he seemed to be expecting most of the objections to come from James, Ryan and/or me. So instead of that, we then spent a fair while discussing criteria for what support architectures would/should receive.
    Hopefully the above provides some useful specifics for people to talk about.
    >As a result, the rest of the project had little input into
    >the decision-making process.
    That’s why it’s posted on the lists now—it [is] never too late to get input into something in Debian; even after we’ve committed to something,
we can almost always change our minds
[emphasis added].
    Due to these outpourings, many of which were wildly passionate, any ambiguity as to the proposal’s status was dispelled, transforming it to an unambiguous proposition waiting to be further explored.
    When the acute phase of the Vancouver crisis was over, energy was diverted back to releasing the subsequent version of Debian: Sarge. Certainly, there remains a tremendous amount of work to be done on the technical problem of architecture support in Debian, and there are many broader questions about governance that this crisis raised. Even if it was affirmed that entrusted members of Debian should consult the entire project before proposing radical changes, there seems to be a growing unease among many developers over the scalability of technical consensus. The rough consensus that so many developers are proud of seems to have gotten rougher with the addition of each new developer, and eventually Debian developers may have to start thinking about novel social solutions to accommodate these changes. For that period, however, the work laid out by the Vancouver prospectus was entrusted to anyone who has a stake in the process. The field had been momentarily leveled despite the hierarchies of power that emerge from a meritocratic system.
    If much of the work performed during this crisis reopened the decision-making process to the whole project, it also allowed developers to collectively affirm that the values they tend to desire from technology (accountability, openness, and access) are those that they also expect from project governance and members of their project, especially those who hold vetted positions of power. Nonetheless, Debian is a dynamic organization. It changes. And through these types of unforeseen conflicts, the door to a reflective process of assessing is frequently opened, allowing developers to revoice their commitment to informal norms of governance and begin the design work to reach new solutions within these norms.
    While the charters codify these