Coding Freedom: The Ethics and Aesthetics of Hacking
procedures that could systematically ensure the trustworthiness of new members as members of the community.
The procedure developed was Debian’s NMP. First presented in October 17, 1999, as a proposal on a mailing list, its preamble (quoted below)indicates that the “growing pains” Debian had been experiencing were not merely technical but also ethical. A small group of developers had been clamoring to loosen the commitment to free software and integrate nonfree software in order to be competitive with commercial distributions whose ethical commitments were less stringent. Even though the constitutional charter was already established, the spirit of free software was seemingly losing its potency with the addition of each new wave of developers. The Debian project leader listed the following criteria by which to select new members, and note that the first line is intentionally repeated:
—needs to have a *strong* oppinion [
sic
] for free software
—needs to have a *strong* oppinion [
sic
] for free software
—he needs to be able+willing to make long distance phone calls [for an interview]
—He needs to know what he’s doing, that new people need some guidance,
we have to prevent ourselves from trojans etc.
—we need to trust him—more than we trust *any* other active person
—He *has to* understand that new-maintainer is *more* than just creating dumb accounts on n [n being a numerical variable] machines
Out of this initial proposal and the establishment of an NMP team, the NMP created a standard that all developers must meet. The NMP is structured not only as a test but also as a process for learning, mentoring, and integrating prospective developers into the project by making them work on packaging a piece of software closely with at least one older, “trusted,” project member.
Before prospective developers formally enter the NMP, they are first asked to identify the contributions they plan to make to Debian. They are encouraged to demonstrate their commitment to the project, express why they want to join, and display some level of technical proficiency. For most developers, this involves making a software package and—because only existing developers can integrate a piece of software into the larger GNU/Linux distribution—finding an existing developer to “sponsor” their work. New maintainers work closely with their sponsors, who check their work for common errors and take partial responsibility for the new maintainer. This supervision is important, because in addition to gaining technical skills, the new volunteer begins to participate in the project’s social sphere. Prospective developers are encouraged to join mailing lists and IRC channels that provide the medium for technical as well as social communication.
A new maintainer’s sponsor often acts as the new applicant’s advocate when the maintainer applies for project membership. Advocates are existing developers who vouch for new developers along their history of and potential for contributions to the community. Early in the NMP, the issueof establishing trust is crucial. After the applicant’s advocacy has been approved, that person officially becomes part of the NMP, and then an application manager is assigned to guide the new developer through the remainder of the process. It is this manager who handles the rest of the process by acting simultaneously as a mentor, examiner, and evaluator. While it is certainly the case, as phrased condescendingly by one Debian developer, that a “village idiot can’t join Debian,” this mentorship is the NMP’s implicit concession to the limits of a meritocratic imperative that would otherwise require a person to prove their worth entirely on their own.
The NMP includes three steps and requires considerable work on the part of applicants. The process is used to confirm the new maintainers’ identity, knowledge and position on free software philosophy, and proficiency with the established Debian policies and procedures as well as their overall technical expertise and knowledge. 20
The identify verification is accomplished by obtaining
the cryptographic signature
of at least one existing Debian developer on their personal GNU privacy guard key. This key is encrypted with a pass phrase that is known only to the person holding that key. When properly unlocked with the pass phrase, a signature can be generated, and that signature can then in turn be attached to a particular email
Weitere Kostenlose Bücher