Debian developers have various responsibilities, and as official project members, they have great influence on the direction the project takes. A Debian developer is 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.

La manutenzione dei pacchetti è un'attività molto documentata e regolamentata. Devono, infatti, essere rispettate tutte le norme stabilite dalla Debian Policy. Fortunatamente, sono disponibili molti strumenti che agevolano il lavoro dei manutentori. Lo sviluppatore può quindi concentrarsi sulle specifiche del proprio pacchetto e su compiti più complessi, come la correzione degli errori.

Le Policy, un elemento essenziale del progetto Debian, stabiliscono le norme che garantiscono la qualità dei pacchetti e la loro perfetta interoperabilità con il resto della distribuzione. Grazie a queste politiche, Debian rimane coerente nonostante le sue dimensioni gigantesche. Queste Policy non sono scritte sulla pietra, ma sono in continua evoluzione grazie alle proposte formulate sulla mailing list debian-policy@lists.debian.org. Gli emendamenti che sono stati approvati da tutti sono accettati e applicati al testo da un piccolo gruppo di manutentori che non hanno responsabilità editoriale (loro includono solamente le modifiche concordate dagli sviluppatori Debian che sono membri della suddetta lista). È possibile consultare le attuali proposte di modifica sul sistema di tracciamento dei bug:

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.

In particolare, i leader hanno un potere reale: i loro voti risolvono le votazioni in pareggio, loro possono prendere ogni decisione che non sia già assegnata ad un'altra autorità e possono delegare parte delle proprie responsabilità.

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, and Jonathan Carter.

La costituzione definisce anche il "comitato tecnico". Il principale ruolo di questo comitato è quello di derimere dispute in materia tecnica quando gli sviluppatori interessati non hanno raggiunto un accordo tra di loro. Oltre a ciò, questo comitato svolge un ruolo consultivo per qualsiasi sviluppatore che non riesce a prendere una decisione di cui è responsabile. È importante notare che deve essere comunque interpellato da una delle parti in questione.

Infine, la costituzione definisce la posizione del "segretario del progetto", che si occupa dell'organizzazione delle votazioni relative alle varie elezioni e risoluzioni generali.

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 put into it.

Questo è l'unico modo per guadagnarsi i galloni: fare qualcosa di utile e dimostrare di aver lavorato bene. Molti team "amministrativi" di Debian operano per designazione, preferendo i volontari che hanno già contribuito ed efficacemente dimostrato la loro competenza. Questo metodo è pratico, perché la maggior parte del lavoro fatto da questi team è pubblico, quindi accessibile a tutti gli sviluppatori interessati. Questo è il motivo per cui Debian è descritta come una "meritocrazia".

Questa efficace modalità operativa garantisce la qualità dei contributi forniti dai team Debian «chiave». Questo non è un metodo perfetto e di tanto in tanto qualcuno non accetta questo modo di operare. La scelta degli sviluppatori accolti nei team può apparire un po' arbitraria, o addirittura sleale. Inoltre, non tutti hanno la stessa idea sul servizio richiesto a questi team. Per alcuni, è inaccettabile dover aspettare otto giorni per l'inclusione di un nuovo pacchetto Debian, mentre altri aspettano pazientemente senza problemi anche per tre settimane. Di conseguenza capita spesso ci siano lamentele dagli scontenti sulla «qualità del servizio» di alcuni team.

Ci si potrebbe chiedere se sia rilevante citare gli utenti tra coloro che lavorano all'interno del progetto Debian e la risposta è, definitivamente, si: svolgono un ruolo fondamentale nel progetto. Lungi dall'essere «passivi», alcuni dei nostri utenti utilizzano versioni di Debian in fase di sviluppo inviando, regolarmente, segnalazioni di bug e problemi. Altri vanno anche oltre e propongono idee e miglioramenti, presentando una segnalazione con un livello di gravità "wishlist" (lista dei desideri) o inoltrando correzioni al codice sorgente, dette "patch" (vedi Sezione 1.3.2.3, «Invio di correzioni»).

$ diff -u file.vecchio file.nuovo >file.patch

$ patch -p0 file.vecchio <file.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.