Dompteur im Entwickler-Zirkus

Linux-Distributionen gibt es wie Sand am Meer, doch kaum eine Distribution vertritt dermassen stark die reine Lehre der freien Software wie Debian GNU/Linux. Das Projekt, das von unzähligen Freiwilligen vorangetrieben wird, bringt seit Jahren eine der beliebtesten Distributionen auf den Markt, die nicht nur als Basis von Linspire oder Ubuntu dient, sondern demnächst auch auf den 14'000 Rechnern der Stadt München installiert wird. Martin Michlmayr war während zweier Jahre Chef des Debian-Projekts und hat damit massgeblich die Entwicklung beeinflusst. Wir sprachen mit ihm in zwei Teilen über freie Software, die Community, Quality Management und weshalb Debian die Desktops der Stadt München erobern konnte.

InfoWeek: Während zweier Jahre haben Sie die Position des Debian Project Leaders bekleidet, eine ziemlich einzigartige Position in
der Welt der Linux-Distributionen. Für alle «Nicht-Debianer»: Worin bestand Ihre Aufgabe?

Martin Michlmayr: Die Aufgaben des Projektsleiters sind grob in zwei Bereiche gegliedert. Die externen Funktionen umfassen die Repräsentation von Debian nach aussen, beispielsweise durch Vorträge auf Konferenzen sowie das Pflegen guter Beziehungen mit Firmen. Die internen Funktionen umfassen Motivation, Koordination und Führung innerhalb des Projekts.
So muss man dafür sorgen, dass im Rahmen des Projekts alles reibungslos abläuft und dass andere Freiwillige ihre Funktionen erfolgreich ausführen können. Diese Arbeit geschieht oft hinter den Kulissen und es fällt nur auf, wenn die Arbeit nicht läuft. Natürlich muss der Projektleiter auch Führung an den Tag legen und dem Projekt eine Richtung geben.

Diese Aufgabe haben Sie wohl gut erledigt, immerhin haben die Projekt-Mitglieder Sie im letzten Frühling für eine zweite Amtszeit gewählt. Was motiviert Sie dazu, einen unbezahlten Job in Ihrer Freizeit auszufüllen, für den so manch anderer Distributor
ein gut bezahltes Management engagiert hat?

Ich glaube an das Prinzip, das hinter freier Software steht und habe selber sehr von dem profitiert, was die Open-Source-Gemeinschaft geschaffen hat. Deshalb will ich auch etwas zurückgeben. Ich bin nun seit über zehn Jahren an Open-Source-Projekten beteiligt, und im Gegensatz zu den meisten anderen Freiwilligen haben mich immer Koordination und Management interessiert und nicht das Programmieren. Das Debian-Projekt ist in diesem Bereich aufgrund seiner Grösse eine besondere Herausforderung. Bei über 1000 Beteiligten und 10'000 Paketen fällt viel Koordinationsarbeit an, und diese macht mir Spass.

Dazu passt Ihr Engagement im Bereich des Quality Management. Welche Erfahrungen konnten Sie diesbezüglich bei Debian sammeln?

Manche Leute behaupten, dass es bei Open-Source-Projekten kein Management gibt und dass alles von selbst läuft. Obwohl sich Management in Open-Source-Projekten sehr von dem im traditionellen Umfeld unterscheidet, sind die Management-Funktionen unerlässlich. Man kann beobachten, dass Koordination und Management einen grossen Einfluss auf den Erfolg eines Projekts haben. In Bezug auf Quality Management interessiert mich die Frage, wie man die Qualität in Open-Source-Projekten konstant hoch halten kann. Freiwillige fallen oft für Tage oder Wochen aus und das kann zu Qualitätseinbussen führen. Open-Source-Projekte müssen deshalb Mechanismen implementieren, mit deren Hilfe die Qualität konstant gehalten werden kann. In meiner Forschung an der Universität Cambridge untersuche ich gerade das Release Management in Open-Source-Projekten und die Bedeutung davon auf die Qualität der Software. Dies ist eine sehr spannende Frage und ich hoffe, damit die Qualität von freier Software noch weiter erhöhen zu können.

Da dürften Sie mit Debian das ideale Objekt für Feldversuche gefunden haben. Debian GNU/Linux ist ja bekannt dafür, sehr stabil und ausgereift, allerdings auch ziemlich altbacken zu sein. Auf der anderen Seite existieren «moderne» Distributionen mit sehr hohen Release-Zyklen, die allerdings mit einer schlechteren Qualität erkauft werden. Ist es überhaupt möglich, eine Synthese dieser beiden Extreme zu erzeugen, ohne dass man entweder auf Qualität oder eine aktuelle Softwareauswahl verzichten muss?

Dies ist eine Frage, die verstärkt an Bedeutung gewinnt. Mit dem Erfolg von freier Software ist die Entwicklung in den letzten Jahren wesentlich rasanter geworden. Gnome hat vor einigen Releases einen Zyklus von nur sechs Monaten eingeführt und andere Projekte wollen diesem Modell folgen. So schnelle Zyklen werfen einige Fragen auf: Bleibt genug Zeit um richtig zu testen? Wollen die Benutzer überhaupt so oft auf neue Software umsteigen? Viele technisch orientierte Anwender verlangen ständig nach neuer Software, aber die Masse der Anwender sowie Firmen benötigen eine Plattform, die eine gewisse Kontinuität bietet. Auf der anderen Seite sind rasche Zyklen oft besser vorhersagbar, und das verringert das Problem, dass Anwender nicht planen können, weil sie nicht wissen, wann eine neue Version erscheint. Zudem scheinen rasche Zyklen zu mehr Motivation bei den Programmierern zu führen, da diese sehen, dass ihre Beiträge tatsächlich eingesetzt werden. Diese erhöhte Motivation kann einen positiven Effekt auf die Qualität der Software haben.

Inwiefern erwarten Sie eine höhere Qualität? Nehmen wir den Linux-Kernel. Seitdem es keinen Entwickler-Kernel mehr gibt, ist die Entwicklung aussergewöhnlich lebendig, allerdings häufen sich auch die Fehler. Da erwartet man bei höheren Release-Zyklen als Aussenstehender eher Bananensoftware.

Die jüngsten Entwicklungen rund um den Linux-Kernel zeigen meiner Meinung nach gut die Probleme, die resultieren, wenn man den End-Anwender komplett aus den Augen verliert und Software nur für Entwickler schreibt. Die Ursache ist dabei nicht der rasche Zyklus, sondern das Vorgehen, alle konventionellen Weisheiten, wie die Unterscheidung zwischen instabilen und stabilen Versionen, über Bord zu werfen. Das führt dazu, dass der Entwicklungsprozess weniger geplant und systematisch ist. Somit gibt es weniger Zeit zum Testen und keiner weiss mehr, welche Version genau als «stabil» anzusehen ist. Die Lösung ist in diesem Fall, mit mehr Systematik an die Entwicklung heranzugehen und eine Testphase fest in den Entwicklungszyklus einzuplanen.
Im Allgemeinen muss der Entwicklungs-Zyklus natürlich auf die Anforderungen der Anwender und die Entwicklung abgestimmt werden. Es gibt kein Gesetz, das besagt, ob schneller oder langsamer der bessere Weg sei. Debian ist ein Beispiel, das die Nachteile von veralteter Software aufzeigt, während der rasante und ungeplante Prozess vom Kernel zwar zu einer sehr aktuellen, aber zugleich instabilen Software führt. Man muss einen guten Mittelweg finden, wobei Hinweise existieren, dass schnellere Zyklen zu einem besseren Feedback von Benutzern und zu mehr Motivation bei Entwicklern führen.

Wird dies auch Einfluss auf Debian haben? Es fordern ja bereits seit einiger Zeit Entwickler wie Andreas Barth häufigere Releases.

Dem Release-Team sowie den meisten Entwicklern ist klar, dass es so nicht weitergehen kann und dass Debian häufigere und berechenbare Releases braucht. Ich hoffe sehr, dass meine Forschung einen direkten Einfluss auf das Projekt haben und zu Verbesserungen führen wird. In der Tat ist Debian eines der Projekte, an dem ich die Ideen meiner Forschung testen will. Durch meine Involvierung in Debian wird es mir möglich sein, die Erkenntnisse meiner Forschung direkt in die Praxis umzusetzen.
Das Release-Team strebt periodische Releases an und macht sich Gedanken darüber, welcher Zyklus am Besten geeignet ist. Während manche Desktop-Benutzer sehr häufige Releases in der Grössenordnung von 6 Monaten sehen wollen, haben Serveradministratoren ganz andere Anforderungen. Zur Zeit ist ein Modell in Diskussion, bei dem alle 12-18 Monate ein Release freigegeben wird. Dies ist für Server gut geeignet und sollte viele Desktop-Anwender zufriedenstellen. Wer aktuellere Software benötigt, kann unser «Testing»-System verwenden, in dem getestete Software ständig aktualisiert wird. Wir arbeiten auch an der Implementierung von Security-Updates für Testing, so dass dieses System eine wirkliche Alternative zum jeweils letzten Stable Release darstellt.

Wie wichtig ist dabei die Verringerung der unterstützten Plattformen von 11 auf 4, wie es Mitte März am Release-Team-Meeting in Vancouver beschlossen wurde?

Das Release-Team hat den Vorschlag gemacht, um dadurch häufigere Releases zu ermöglichen. Dieser Vorschlag ist sehr kontrovers und hat zu sehr langen Diskussionen geführt. Ein grosses Problem bestand in der Präsentation des Vorschlags. Das Release Team hat die Idee privat in Vancouver diskutiert, ohne über dieses Treffen vorher zu informieren. Zudem wurde der Vorschlag als beschlossene Sache präsentiert statt als Anstoss zur Diskussion.
Ich persönlich finde es unfair, so eine grosse Entscheidung zu treffen beziehungsweise Überlegung anzukündigen, ohne zuvor mit den für die Ports zuständigen Personen zu sprechen. Die Unterstützung von 11 Architekturen (wobei noch mehr in Arbeit sind) ist natürlich sehr komplex und braucht viel Arbeit, doch vielen war nicht klar, wo genau die Probleme liegen und wie man helfen kann. Ich denke, das Gute, das die Diskussion ausgelöst hat, ist ein besseres Verständnis der Arbeit, die hinter den Ports steckt. Wenn jemand will, dass die Ports unterstützt bleiben, dann muss man auch bereit dazu sein, Arbeit hineinzustecken. Das Release-Team kann auch einen fixen Termin setzen, zu dem bewertet wird, ob eine Architektur bereit für einen Release ist. Dafür muss es Richtlinien geben, die allen bekannt sind. Allerdings hoffe ich, dass die Diskussion zu mehr Freiwilligen führt, die sich auf unsere Ports konzentrieren und sich das Problem so in Luft auflöst.

Sollte sich das Release-Team mit seinem Vorschlag durchsetzen und die Unterstützung für die meisten Plattformen absägen: Würde damit nicht einer der Hauptvorteile von Debian im Vergleich zu anderen Linux-Distributionen verlorengehen?

Auf jeden Fall! Ich selbst bin am MIPS-Port beteiligt und stehe in engem Kontakt mit den Leuten, die an der Unterstützung für ARM arbeiten. Beide Plattformen sind sehr wichtig im Embedded-Umfeld und Debian ist hier sehr populär, da wir ausgezeichnete Unterstützung anbieten und sich unser System sehr gut an verschiedene Anforderungen anpassen lässt. Auch im Server-Umfeld ist die Unterstützung von verschiedenen Architekturen ein Vorteil, weil man auf allen Plattformen die gleiche Software-Umgebung einsetzen kann. Wie gesagt hoffe ich, dass die Diskussion zur Verringerung der unterstützten Architekturen zu mehr Freiwilligen führt und somit die ganze Debatte überflüssig wird.

Voschau auf InfoWeek 11

Den zweiten Teil des Interviews mit Martin Michlmayr, der sich um den Einfluss von Firmen auf freie Software und Debians Marsch in Münchens Amtsstuben dreht, lesen Sie in 14 Tagen in der nächsten Ausgabe von InfoWeek.