Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is traditionally generally responsible for at least one package, but according to their available time and desire, they are free to become involved in numerous teams and projects, thus acquiring more responsibilities within the project.

Package maintenance is a relatively regimented activity, very documented, or even regulated. It must, in effect, comply with all the standards established by the Debian Policy. Fortunately, there are many tools that facilitate the maintainer's work. The developer can, thus, focus on the specifics of their package and on more complex tasks, such as “squashing“ bugs.

Riktlinjerna, en viktig del av Debianprojektet, etablerar de normer som försäkrar distributionens paketkvalitet och interoperabilitet. Tack vare dessa riktlinjer fortsätter Debian, trots dess omfattning, att vara samstämmigt. Riktlinjerna är inte skrivna i sten utan fortsätter att utvecklas kontinuerligt tack vare förslag som skickats in via sändlistan debian-policy@lists.debian.org. Tillägg som ges bifall av alla intresserade parter accepteras och tillämpas texten av en liten grupp ansvariga för underhåll som inte har någon befogenhet att editera (de inkluderar endbart ändringar som bifallits av Debian-utvecklarna som också är medlemmar i den nämnda sändlistan). Du kan läsa om aktuella ändringsförslag i felrapporteringssystemet:

The Policy provides considerable coverage of the technical aspects of packaging. The size of the project also raises organizational problems; these are dealt with by the Debian Constitution, which establishes a structure and means for decision making. In other words, a formal governance system.

This constitution defines a certain number of roles and positions, plus responsibilities and authorities for each. It is particularly worth noting that Debian developers always have ultimate decision making authority by a vote of general resolution, wherein a qualified majority of three quarters (75%) of votes is required for significant alterations to be made (such as those with an impact on the Foundation Documents). However, developers annually elect a “leader” to represent them in meetings, and ensure internal coordination between varying teams. This election is always a period of intense discussions. The Debian Project leader's (DPL) role is not formally defined by any document: candidates for this post usually propose their own definition of the position. In practice, the leader's roles include serving as a representative to the media, coordinating between “internal” teams, and providing overall guidance to the project, within which the developers can relate: the views of the DPL are implicitly approved by the majority of project members.

Ledaren har ett starkt mandat; deras röst avgör jämna röster; de kan ta vilket beslut som helst som inte redan är under någon annans ansvar och de kan delegera vidare delar av sitt ansvar.

Since its inception, the project has been successively led by Ian Murdock, Bruce Perens, Ian Jackson, Wichert Akkerman, Ben Collins, Bdale Garbee, Martin Michlmayr, Branden Robinson, Anthony Towns, Sam Hocevar, Steve McIntyre, Stefano Zacchiroli, Lucas Nussbaum, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, Jonathan Carter, and Andreas Tille.

Författningen definierar också en ”teknisk kommitté”. Kommitténs essentiella roll är att bestämma om tekniska spörsmål när de involverade utvecklarna inte har kommer fram till en kompromiss. Kommittén har också en rådgörande roll till utvecklare som misslyckas med att ta ett beslut för vilka de är ansvariga. Observera att de endast blir involverade när de bjuds in av en av parterna i fråga.

Slutligen definierar författningen rollen ”projektsekreterare” som ansvarar för organisationen av röster relaterat till de olika valen och allmänna resultaten.

The “general resolution” (GR) procedure is fully detailed in the constitution, from the initial discussion period to the final counting of votes. The most interesting aspect of that process is that when it comes to an actual vote, developers have to rank the different ballot options between them and the winner is selected with a Condorcet method (more specifically, the Schulze method). For further details see:

Even if this constitution establishes a semblance of democracy, the daily reality is quite different: Debian naturally follows the free software rules of the do-ocracy: the one who does things gets to decide how to do them. A lot of time can be wasted debating the respective merits of various ways to approach a problem; the chosen solution will be the first one that is both functional and satisfying… which will come out of the time that a competent person puts into it.

Det enklaste sättet att få erkännande är att göra något nyttigt och visa att man har utfört arbeta. Många ”administrativa” Debian-team sköts genom samarbeten, och de föredrar volontärer som redan har bidragit effektivt och visat sin kompetens. Den naturliga öppenheten i dessa teams arbete gör det möjligt för nya volontärer att observera och börja hjälpa till utan speciella privilegium. Det är därför Debian ofta beskrivs som en ”meritokrati”.

This effective operational method guarantees the quality of contributors in the “key” Debian teams. This method is by no means perfect, and occasionally there are those who do not accept this way of operating. The selection of developers accepted in the teams may appear a bit arbitrary, or even unfair. Furthermore, not everybody has the same definition of the service expected from these teams. For some, it is unacceptable to have to wait eight days for inclusion of a new Debian package, while others will wait patiently for three weeks without a problem. As such, there are regular complaints from the disgruntled about the “quality of service” from some teams.

Är det relevant att nämna användarna bland de som jobbar inom Debianprojektet? - svaret är ett rungande ja: de spelar en kritisk roll i projektet. De är långt ifrån ”passiva”, en del användare testar utvecklingsversioner av Debian, och skapa felrapporter för att uppmärksamma problem. Andra går längre och skickar in ideer för förbättringar genom att skriva in felrapporter med nivån ”whishlist”, eller till och med genom att skicka in ”programfixar”, det vill säga rättningar till källkoden, (se Avsnitt 1.3.2.3, ”Skicka rättningar”).

$ diff -u fil.gammal fil.nya >fil.patch

$ patch -p0 fil.gammal <fil.patch

From the start, Debian has been organized around the concept of source packages, each with its maintainer or group of maintainers. Many work teams have emerged over time, ensuring administration of the infrastructure, management of tasks not specific to any package in particular (quality assurance, Debian Policy, installer, etc.), with the latest series of teams growing up around sub-projects and blends.