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.

Paketbetreuung ist eine recht straff organisierte Arbeit, sehr stark dokumentiert oder gar reglementiert. Sie muss mit wirklich allen in den Debian-Richtlinien festgelegten Standards übereinstimmen. Zum Glück gibt es zahlreiche Hilfsprogramme, die die Arbeit eines Betreuers erleichtern. So kann sich der Entwickler auf die Besonderheiten seines Pakets und auf komplexere Aufgaben wie die Fehlerbeseitigung konzentrieren.

Die Richtlinien, ein wesentliches Element des Debian-Projekts, legen die Normen fest, die sowohl die Qualität der Pakete sicherstellen als auch die Interoperabilität der Distribution vervollkommnen. Dank dieser Richtlinien bleibt Debian trotz seiner gewaltigen Größe konsistent. Sie sind nicht in Stein gehauen, sondern entwickeln sich aufgrund von Vorschlägen, die in der Mailingliste [email protected] gemacht werden, ständig weiter. Änderungen, denen alle Betroffenen zustimmen, werden von einer kleinen Gruppe von Betreuern, die keine redaktionelle Zuständigkeit haben, entgegengenommen und in den Text eingearbeitet. (Sie nehmen nur die Veränderungen auf, auf die sich die Debian-Entwickler, die Mitglied der oben genannten Liste sind, geeinigt haben.) Sie können die aktuellen Veränderungsvorschläge im Fehlerverfolgungssystem nachlesen:

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.

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, Neill McGovern, Mehdi Dogguy, Chris Lamb, Sam Hartman, and Jonathan Carter.

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” (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.

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.

Man mag sich fragen, ob es wichtig ist, unter denen, die innerhalb des Debian-Projekts arbeiten, auch die Anwender zu erwähnen, doch die Antwort ist definitiv "Ja": sie spielen im Projekt eine lebenswichtige Rolle. Sie sind keineswegs „passiv“, sondern einige Anwender verwenden Entwicklungsversionen von Debian und schicken regelmäßig Fehlerberichte ein, in denen sie auf Probleme hinweisen. Andere gehen noch weiter und reichen Verbesserungsvorschläge ein, indem sie einen Fehlerbericht mit der Schweregradstufe „wishlist“ einschicken oder sogar Korrekturen des Quellcodes, „Patches“ genannt, einreichen (siehe Abschnitt 1.3.2.3, „Senden von Fehlerkorrekturen“).

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

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