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

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:

Die Richtlinien decken die technischen Aspekte des Paketierens sehr gut ab. Aus der Größe des Projekts ergeben sich jedoch auch organisatorische Probleme; mit diesen beschäftigt sich die Debian-Verfassung, die eine Struktur und ein Verfahren für die Entscheidungsfindung festlegt. Mit anderen Worten, ein formales System für das Projektmanagement.

Diese Verfassung definiert eine bestimmte Anzahl von Rollen und Positionen sowie für jede die Verantwortlichkeiten und Befugnisse. Es ist insbesondere beachtenswert, dass Debian-Entwickler stets eine abschließende Entscheidungsbefugnis durch einen allgemeinen Beschluss haben, bei dem eine qualifizierte Mehrheit von drei Vierteln (75%) der Stimmen erforderlich ist, um wesentliche Änderungen vorzunehmen (wie zum Beispiel solche mit Auswirkung auf die Grundlagendokumente). Indes wählen die Entwickler jedes Jahr einen „Leiter“, der sie in Sitzungen repräsentiert und der die interne Koordination zwischen den verschiedenen Teams sicherstellt. Diese Wahl ist immer eine Zeit erbitterter Diskussionen. Die Rolle dieses Leiters ist in keinem Dokument ausdrücklich definiert: Kandidaten für diese Stelle schlagen gewöhnlich ihre eigene Definition dieser Position vor. In der Praxis bestehen die Rollen des Leiters unter anderem darin, gegenüber den Medien als Repräsentant aufzutreten, „interne“ Teams zu koordinieren und dem Projekt allgemeine Orientierungshilfen anzubieten, auf die sich die Entwickler beziehen können: Die Ansichten des DPL werden stillschweigend von der Mehrheit der Projektmitglieder anerkannt.

Im Besonderen haben die Leiter wirkliche Autorität; Ihre Stimme entscheidet bei Stimmengleichheit; sie können jede Entscheidung treffen, die nicht bereits unter die Zuständigkeit eines anderen fällt, und sie können ihre Verpflichtungen teilweise delegieren.

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, Chris Lamb and Sam Hartman.

Die Verfassung sieht auch ein „technisches Komitee“ vor. Die wesentliche Rolle dieses Komitees besteht darin, in technischen Fragen zu entscheiden, wenn die beteiligten Entwickler untereinander kein Einvernehmen erzielt haben. Daneben spielt dieser Ausschuss eine beratende Rolle für jeden Entwickler, der eine Entscheidung, für die er verantwortlich ist, nicht trifft. Man sollte beachten, dass das Komitee sich erst dann einmischt, wenn es hierzu von einer der beteiligten Parteien aufgefordert wird.

Schließlich bestimmt die Verfassung die Position eines „Projekt-Schriftführers“, dessen Aufgabe darin besteht, die Abstimmungen im Zusammenhang mit den verschiedenen Wahlen und allgemeinen Beschlüssen zu organisieren.

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:

Auch wenn diese Verfassung einen demokratischen Anschein erweckt, sieht die tägliche Wirklichkeit ziemlich anders aus: Natürlich folgt Debian den Regeln der Freien Software, der „Tu-okratie“: Wer etwas tut, entscheidet auch. Viel Zeit kann darauf verschwendet werden, die jeweiligen Vorteile verschiedener Lösungswege für ein Problem zu diskutieren; am Ende wird die Lösung gewählt, die als erste funktioniert und zufriedenstellend ist ... das ergibt sich aus der Zeit, die eine sachkundige Person darin investiert hat.

Dies ist der einzige Weg, sich Sporen zu verdienen: Etwas Nützliches zu tun und zu zeigen, dass man gut gearbeitet hat. Bei Debian agieren viele „Verwaltungsteams“ aufgrund einer Kootation (Wahl von Mitgliedern durch die übrigen Mitglieder) unter Bevorzugung von Freiwilligen, die bereits erfolgreich mitgewirkt und ihre Sachkenntnis bewiesen haben. Die Arbeitsweise dieser Teams ermöglicht es interessierten Entwicklen direkt mitzuwirken ohne erweiterte Rechte haben zu müssen. Deshalb wird Debian häufig als „Meritokratie“ bezeichnet.

Diese effektive Arbeitsweise gewährleistet die Qualität der Mitwirkenden in den zentralen Debian-Teams. Diese Methode ist keineswegs perfekt und gelegentlich finden sich auch Leute, die diese Arbeitsweise nicht akzeptieren. Die Auswahl von Entwicklern für die Teams mag ein wenig willkürlich oder sogar unfair erscheinen. Außerdem hat nicht jeder dieselbe Auffassung von der Leistung, die von diesen Teams erwartet wird. Für einige ist es nicht akzeptabel, acht Tage auf das Einfügen eines neuen Debian-Pakets warten zu müssen, während andere problemlos drei Wochen lang geduldig warten. Daher gibt es regelmäßig Beschwerden der Unzufriedenen über die „Arbeitsqualität“ mancher Teams.

One might wonder if it is relevant to mention the users among those who work within the Debian project, but the answer is a definite yes: they play a critical role in the project. Far from being “passive”, some users run development versions of Debian and regularly file bug reports to indicate problems. Others go even further and submit ideas for improvements, by filing a bug report with a severity level of “wishlist”, or even submit corrections to the source code, called “patches” (see Abschnitt 1.3.2.3, „Sending fixes“).

$ diff -u file.old file.new >file.patch

$ patch -p0 file.alt <file.patch

Debian war von Beginn an um das Konzept der Quellpakete herum organisiert, jedes mit seinem Betreuer oder seiner Gruppe von Betreuern. Zahlreiche Arbeitsteams haben sich im Laufe der Zeit gebildet, die die Verwaltung der Infrastruktur und das Management von Aufgaben, die keinem bestimmten Paket zugeordnet werden können (Qualitätssicherung, Debian-Richtlinien, Installationsprogramm usw.) sicherstellen, wobei die jüngsten Teams rings um Unterprojekte heranwachsen.