Debian ist frei und seine Entwickler sind Kosmopoliten. Das Linux-Magazin berichtet regelmäßig Interna aus der Debian-Entwicklerszene und angrenzenden Projekten .

Abbildung 1: Braver Löwe. Der Debian-Projektleiter hat weitgehende Gestaltungsrechte, die die Amtsträger in der Vergangenheit aber wenig nutzten.

Wie viel Chef darf der Chef tatsächlich sein? Kaum einem Benutzer und selbst vielen Entwicklern ist wohl unbekannt, welche Befugnisse der Debian Project Leader (DPL) hat und wie die Debian-Developer ihrem Leittier gegebenenfalls in die Suppe spucken können.

Wenn dieses Heft am Kiosk liegt, steht der neue DPL bereits fest – seine Amtszeit beginnt am 17. April. Bei Redaktionsschluss gab es allerdings erst drei Wahlvorschläge mit wenig konkretem Inhalt. Ein guter Zeitpunkt also, um mal einen Blick in die Debian-Verfassung zu werfen [1].

Raging Lion …

Sie räumt dem Projektleiter in einem eigenen Kapitel weitgehende Rechte ein. Kapitel 5 erlaubt es ihm zum Beispiel, so genannte Delegates zu ernennen – also Entwickler, die bestimmte Aufgabenbereiche im Projekt per DPL-Direktive exklusiv bearbeiten. Beispiele sind die Debian Account Manager, die die LDAP-Verzeichnisse verwalten. Damit bestimmen sie, wer auf Entwickler-Maschinen zugreifen darf und welche GPG-Keys im offiziellen Debian-Keyring sind – wer also berechtigt ist Pakete für das offizielle Debian-Archiv zu signieren.

Delegates darf der DPL nach Belieben bestellen oder feuern. Auch seine sonstigen Kompetenzen darf der DPL auf andere übertragen, temporär oder dauerhaft. Entscheidungen in Fragen, für die sich sonst niemand verantwortlich fühlt, obliegen ebenfalls dem DPL. Sollte der Fall entstehen, dass bei einer Entwicklerabstimmung ein Gleichstand zwischen zwei Optionen eintritt – was allerdings eher unwahrscheinlich ist -, hat der DPL die entscheidende Stimme.

Der DPL ist also mächtig, obgleich das Projekt selbst basisdemokratisch organisiert ist und sein möchte. Die Erfahrung zeigt, dass ein amtierender Debian-Projektleiter häufig sogar in Kritik gerät, weil er die ihm zugestandene Macht weniger radikal anwendet, als viele Entwickler sich das wünschen (Abbildung 1). Fast alle DPLs waren in den letzten Jahren beispielsweise zaghaft im Umgang mit Personalentscheidungen. Unwillkürlich denken alte Hasen an die über Jahre hinweg unverändert schlechte Situation des Account-Managements, die mehrere DPLs unberührt ließen.

… oder lame Lion?

Selbst wenn er wollte, könnte der DPL dennoch nicht diktatorisch regieren. Punkt 4 der Debian-Verfassung, der die Rechte der Entwickler festschreibt, erlaubt nämlich, Entscheidungen des DPL mit einfacher Mehrheit zu überstimmen. Außerdem können sie ihn jederzeit mit einer entsprechend ausfallenden Generalabstimmung aus dem Amt jagen. Einmal hat es den Versuch schon gegeben: Anthony Towns musste sich 2003 einer Abwahl stellen – das Projekt hat ihm dann aber den Rücken gestärkt.

Verfassungsmäßig hat der DPL viele Rechte, die er allerdings praktisch kaum nutzt und im Zweifelsfall auch nicht durchsetzen kann. Anspruch und Wirklichkeit kollidieren – Debian ist mental viel zu breit aufgestellt, als dass es möglich wäre, Entscheidungen von oben nach unten durchzudrücken. Die Projektleiter haben sich deshalb in den letzten Jahren darauf beschränkt, als eine Art Moderator zu wirken, zwischen einzelnen Gruppen zu vermitteln und die internen Abläufe des Projekts zu verbessern.

Nicht zu vergessen ist ihre Rolle als offizielle Repräsentanten des Projekts nach außen. In den ersten Wochen seiner Amtszeit hat ein DPL üblicherweise alle Hände voll zu tun, um die an ihn herangetragenen Interview-Anfragen abzuarbeiten. Während seiner gesamten Amtszeit ist er gern gesehener Gast bei Diskussionen rund um das Thema Open Source. Mal sehen, ob der neue DPL an dieser Strategie etwas ändert. (ake)