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

Einzelkämpfer sind out, Teamwork ist in (Abbildung 1). Das gilt seit einigen Jahren auch für das Debian-Projekt: Wo früher Eigenbrötler auf ihren Paketen hockten wie die Glucke auf den Eiern, werkeln heute Gruppen aus zehn und mehr Entwicklern. Dadurch geht es zwar nicht immer schneller voran, aber seit Etch glänzen Debian-Versionen durch immer bessere Qualität. Beispielsweise landen neue Testpakete schneller in Unstable, was ihre Aktualität erhöht.

Abbildung 1: Vom Solisten zum Teamplayer. Seit sechs Jahren heißt es bei Debian: Wenn der eine nicht ins Tor schießt, dann eben der andere.

Debian-Projektleiter Stefan Zacchiroli stellte daher schon als Wahlkämpfer klar: Pakete gehören in die Hände von Maintainer-Gruppen, wenn sie ein einzelner nicht vernünftig pflegt. Mit dem stetigen Wachstum des Projekts, das auch die zu paketierenden Programme immer weiter aufbläht, scheint es sinnvoll, dass Entwickler Arbeiten aufteilen. Was also hat das Projekt getan, um sich von der One-Man-Show zu Maintainer-Gruppen zu wandeln?

Zwei Jahre: Jetzt reicht’s

Wer Debian noch in Version 2.2 (Potato) oder 3.0 (Woody) kennt, weiß, dass die Entwickler sich oft Zeit ließen. Besonders gemächlich wanderten Major-Releases großer Software-Umgebungen wie Gnome, KDE oder GCC in die Distribution. Oft waren sie bei Debians Erscheinen fast unbrauchbar alt. Und oft zeichneten für solche Riesen nur einzelne Personen verantwortlich, zum Beispiel Christopher L. Cheney, der KDE lange allein pflegte. Wenn diese Maintainer andere Dinge zu tun hatten, blieb die Debian-Arbeit liegen. Schließlich drohte die Release-Zeit von Sarge die zwei Jahre von Woody noch zu übertreffen. Das Gefühl, dass etwas geschehen müsse, wuchs.

Im Januar 2004 erhielt zuerst Gnome ein Team. Auch die Pflege von KDE wanderte zu einer neue Gruppe von Qt/KDE-Maintainern. Im Juni 2004 entstand die Debian Perl Group. Die Großen gingen voraus und entfalteten Sogwirkung: Wer sein Paket im Rahmen eines Teams pflegen wollte, änderte den Maintainer-Eintrag in der Datei »debian/control« und machte den Quelltext des Pakets in einem Versionskontrollsystem verfügbar.

Wandel der Mentalität

Der Trend im Projekt hat sich seit 2004 zugunsten von Maintainer-Gruppen entwickelt. Ein Beispiel: In der Debian-Welt galt es als Affront, wenn Entwickler die neue Version eines Pakets hochluden und sich ohne Einverständnis des bisherigen Zuständigen als Maintainer ausgaben. Im Fachjargon heißt das Package Hijack. Was bis 2004 noch böses Blut hervorrief, ist heute oft legitim, wenn die Pflege eines Pakets in den Händen eines Teams ruht: Man hindert den Maintainer nicht an der Arbeit, ermöglicht sie aber auch anderen. Die Vorstellung, Prestige allein durch die Maintainerschaft eines großen und wichtigen Debian-Pakets zu erreichen, ist Geschichte.

2003 war Alioth.debian.org in den Produktivbetrieb gegangen. Das ist eine Art Sourceforge-Klon für Debian, mit Mailinglisten, Versionskontrollsystemen und Webspace für Entwickler- oder Maintainer-Gruppen. Mit dem Team-Boom gewann Alioth schnell an Relevanz und heute erfreut sich der Dienst großer Beliebtheit. Auch intern hat sich vieles verändert: Das Debian-Accountmanagement, das über Jahre hinweg aus genau einer Person bestand – James “Elmo” Troup -, erweiterte sich zum Team. Anthony Towns hängte seinen Posten als Release-Manager an den Nagel und übergab die Versionspflege in die Hände der Debian Release Manager. Heute arbeiten Gruppen, wohin das Auge schaut. Noch immer gründen sich neue.

Kein Projektleiter hat es seither versäumt, ihre Bedeutung für Debian hervorzuheben. Anscheinend liegt in der gemeinsamen Paketpflege der Schlüssel zur Zukunft. So hatte auch der DPL der vorigen Wahlperiode, Steve McIntyre, alle bekannten Debian-Teams über ihre Zufriedenheit und Verbesserungsmöglichkeiten ausgefragt. Und der jetzige Projektleiter Zacchiroli findet: “Teams sollten der Standard sein.” (ake)