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, acquiring, thus, 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.

The Policy, an essential element of the Debian Project, establishes the norms ensuring both the quality of the packages and perfect interoperability of the distribution. Thanks to this Policy, Debian remains consistent despite its gigantic size. This Policy is not fixed in stone, but continuously evolves thanks to proposals formulated on the debian-policy@lists.debian.org mailing list. Amendments that are agreed upon by all interested parties are accepted and applied to the text by a small group of maintainers who have no editorial responsibility (they only include the modifications agreed upon by the Debian developers that are members of the above-mentioned list). You can read current amendment proposals on the bug tracking system:

Le Policy coprono molto bene gli aspetti tecnici della creazione di pacchetti. La dimensione del progetto solleva anche problemi organizzativi; questi vengono trattati dalla Costituzione Debian, che stabilisce la struttura ed i mezzi per il processo decisionale. In altre parole, un sistema formale di governance.

La costituzione definisce un certo numero di ruoli e posizioni, compreso le responsabilità e le autorizzazioni di ognuno. È particolarmente interessante notare che gli sviluppatori Debian dispongono sempre dell'autorità per la decisione finale, potendo votare le risoluzioni generali, in cui per apportare modifiche significative (come quelle che riguardano i documenti fondanti) è necessaria una maggioranza qualificata dei tre quarti (75%) dei voti. Tuttavia, gli sviluppatori annualmente eleggono il «leader» per rappresentarli nelle riunioni, e garantire il coordinamento interno tra i diversi team. Questa elezione è sempre preceduta da un periodo di intense discussioni. Il ruolo di questo leader non è definito formalmente da alcun documento: i candidati a questo ruolo di solito propongono la propria definizione della posizione. In pratica, i ruoli del leader comprendono quello di mantenere i rapporti con i media, il coordinamento «interno» fra i vari team, e l'assegnare un orientamento generale al progetto in cui gli sviluppatori possano riconoscersi: il punto di vista del DPL è implicitamente approvato dalla maggioranza dei membri del progetto.

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, Mehdi Dogguy and Chris Lamb.

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” 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:

Anche se questa costituzione istituisce una parvenza di democrazia, la realtà quotidiana è ben diversa: Debian segue naturalmente le regole del software libero e della do-cracy (democrazia del fare): decide colui che fa. Può essere sprecato un sacco di tempo dibattendo sui rispettivi meriti dei vari metodi per affrontare un problema; la soluzione scelta sarà la prima che è sia funzionale che soddisfacente... onorando il tempo che vi ha dedicato una persona competente.

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.

Se sia rilevante citare gli utenti tra coloro che lavorano all'interno del progetto Debian? Sì: giocano un ruolo critico nel progetto. Lungi dall'essere «passivi», alcuni dei nostri utenti utilizzano versioni di Debian in fase di sviluppo e regolarmente inoltrano le segnalazioni di bug per indicare problemi. Altri vanno anche oltre e presentano idee e miglioramenti, presentando una segnalazione con un livello di gravità "wishlist" (lista dei desideri), o anche presentando correzioni al codice sorgente, dette "patch" (vedi il riquadro FONDAMENTALI Patch, come inviare una correzione).

Additionally, numerous satisfied users of the service offered by Debian like to make a contribution of their own to the project. As not everyone has appropriate levels of expertise in programming, they may choose to assist with the translation and review of documentation. There are language-specific mailing lists to coordinate this work.

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

$ patch -p0 file.vecchio <file.patch

Tutti questi meccanismi sono accentuati dal comportamento degli utenti. Lontani dall'essere isolati, gli utenti compongono una vera comunità all'interno della quale si svolgono numerosi scambi. Notiamo in particolare una attività importante sulla mailing list delle discussioni degli utenti, debian-user@lists.debian.org (Capitolo 7, Risoluzione dei problemi e reperimento delle principali informazioni descrive la cosa in dettaglio).

Non solo gli utenti stessi sono di aiuto su argomenti tecnici che li riguardano direttamente, ma discutono anche relativamente ai modi migliori per contribuire al progetto Debian e aiutarlo a progredire — discussioni che spesso portano a proposte di miglioramento.

Dal momento che Debian non spende fondi per auto-promuoversi con campagne di marketing, i suoi utenti svolgono un ruolo essenziale nella sua diffusione, garantendo la sua fama attraverso il passaparola.

Questo metodo funziona piuttosto bene, dal momento che i fan di Debian si trovano a tutti i livelli della comunità del software libero: a partire dalle feste di installazione (workshop in cui gli utenti esperti assistono i nuovi arrivati nell'installazione del sistema) organizzate dai LUG «Linux User Group» (Gruppi di utenti Linux) locali, fino agli stand di associazioni ai grandi convegni tecnologici che si occupano di Linux, ecc.

Volunteers make posters, brochures, stickers, and other useful promotional materials for the project, which they make available to everyone, and which Debian provides freely on its website and on its wiki:

Debian è organizzata, fin dall'inizio, intorno al concetto di pacchetti sorgenti, ognuno con il suo manutentore o gruppo di manutentori. Nel tempo si sono formati svariati team, che assicurano l'amministrazione delle infrastrutture, la gestione di compiti non specifici di un particolare pacchetto (garanzia della qualità, le Policy Debian, installatore, ecc.), mentre le ultime squadre si sviluppano intorno a sotto-progetti.