Interview: Freie Software neigt zu Qualitätsproblemen

Golem.de: Du hast zusammen mit Francis Hunt und David Probert Methoden zur Qualitätssicherung in Open-Source-Projekten(öffnet im neuen Fenster) und bei freier Software untersucht. Welche Probleme konnten dabei identifiziert werden?
In Interviews mit Entwicklern, die an freier Software und Open Source arbeiten, habe ich einige Probleme identifizert. So gibt es Probleme damit, bestimmte Funktionen zu unterstützen. Oft kommt jemand mit einer besonderen Anforderung und steuert einen Patch bei, der in die Software integriert wird. Dann werden Änderungen am Code durchgesehen und es stellt sich die Frage, ob diese Funktion noch arbeitet. Leider ist mittlerweile der ursprüngliche Entwickler verschwunden und es lässt sich kein anderer Freiwilliger finden. Sobald man aber eine Funktion entfernen will, erscheinen plötzlich Benutzer, die ohne diese Funktion nicht leben können.
Sicherheits-Updates sind auch ein Problem. Oft erscheinen Patches innerhalb von Stunden, aber es gibt auch eine große Anzahl von Fällen, in denen nach Wochen oder Monaten noch immer kein Fix erhältlich ist. Die Varianz ist sehr groß.
Golem.de: Freie Software basiert meist auf der Arbeit Freiwilliger, ohne die viele Projekte nicht denkbar wären. Vor welche besonderen Schwierigkeiten stellt dies aber die Projekte?
Michlmayr: Die Natur von freier Software hat zwei wichtige Charakteristika: Erstens basiert die Entwicklung auf Beteiligten, die auf der ganzen Welt verteilt sind. Zweitens sind die meisten Beteiligten Freiwillige. Dies führt zu einigen Qualitätsproblemen, die nur – oder zumindest vermehrt – in freier Software und Open Source auftreten. Wir müssen diese Probleme erkennen und dann gemeinsam Lösungen entwickeln.
Golem.de: Wie wirkt sich die Beteiligung Freiwilliger auf die veröffentlichte Software und die Projekte denn konkret aus?
Michlmayr: Die Beteiligung von Freiwilligen ist zum einen sehr schwer im Voraus abzuschätzen. Manchmal werden Freiwillige zahlreiche Stunden in ein Projekt investieren, aber in anderen Perioden, wie zum Beispiel im Prüfungsstress, verschwinden sie plötzlich. Das macht die Planung viel schwieriger und führt zum Beispiel im Release-Management zu Verspätungen.
Zum anderen ist die Varianz der Qualität viel größer, wie zuvor erwähnt. Manchmal bekommt man Patches innerhalb von Stunden, aber in anderen Fällen stehen Bug Reports für Jahre offen. Ein großes Anliegen der traditionellen Qualitätssicherung ist es, die Varianz möglichst gering zu halten. Dies ist für Firmen gut, die genau wissen wollen, wann ein Fix oder ein Release erhältlich sein wird.
Häufig wird an diesen traditionellen Systemen kritisiert, dass sie nicht wirklich für hohe, sondern nur für konstante Qualität sorgen – sie mag zwar gering sein, aber zumindest ist sie konstant. Eigentlich muss das Ziel jedoch sein, die Qualität hoch zu halten – aber konstant hoch. Die Qualität darf nicht einbrechen, nur weil einige Freiwillige gerade im Urlaub sind.
Golem.de: Wie lassen sich "inaktive Mitglieder" in großen, verteilten Projekten identifizieren, wie geht Debian mit einer solchen Situation um?
Michlmayr: In Debian haben wir das Problem, dass für die meisten Softwarepakete nur ein Maintainer verantwortlich ist. Da Freiwillige oft ausfallen, kann das zu Qualitätseinbußen in deren Paketen führen. Ich habe dieses Problem vor ein paar Jahren erkannt und gezielt nach solchen inaktiven Maintainern gesucht. Diese Aufgabe gestaltet sich aber sehr schwierig, da die Entwickler in der ganzen Welt verteilt sind.
In einer Firma ist es offensichtlich, wenn jemand für ein paar Tage nicht auf der Arbeit erscheint. In einem verteilten Projekt, das auf Freiwilligen basiert, ist es jedoch sehr schwer zu entscheiden, ob jemand für immer verschwunden oder nur im Urlaub ist.
Es gibt jedoch einige Informationsquellen, die man verwenden kann, um den Status herauszufinden. Wenn ich davon überzeugt bin, dass jemand wirklich nicht mehr aktiv ist, kann man dann das Paket wegnehmen und an andere Entwickler geben.
Golem.de: Welche Ansätze schlägst du vor, um mit veränderten Prozessen die Qualität von freier und Open-Source-Software zu verbessern?
Michlmayr: Am Beispiel der inaktiven Mitglieder ist zu sehen, dass eine höhere Redundanz zu vielen Verbesserungen führen kann. Wir sind in Debian auch dabei, mehr Maintainer-Teams einzuführen, aber das führt natürlich zu anderen Problemen: Die Kommunikationsanforderungen steigen und es müssen sich Führungsstrukturen innerhalb der Teams bilden.
Im Allgemeinen können Projekte von mehr Planung profitieren. Die Prozesse müssen zudem so angepasst werden, dass Probleme vorherzusehen sind und Mechanismen bereitstehen, um mit diesen Problemen umzugehen. Das Wichtige dabei ist, dass die Qualitätsprozesse fest im Entwicklungsprozess integriert sind und in einer Weise ablaufen, die die Leute motiviert, die Arbeit auch machen zu wollen.
Wenn die Prozesse zu umfangreich und mühsam sind, wird sich keiner daran halten. Die Arbeit muss natürlich Spaß machen – und ganz nebenbei zu hoher Qualität führen.
Golem.de: Inwiefern können Probleme entstehen, wenn einzelne Entwickler direkt für ihre Arbeit am Projekt bezahlt werden?
Michlmayr: Ich befasse mich in meiner Forschung primär mit Freiwilligen, da die Koordination von Freiwilligen eine große Herausforderung ist, die mich interessiert und da ich selbst als Freiwilliger in einigen Projekten aktiv bin.
Durch den Erfolg von freier Software und Open Source gibt es jedoch vermehrt bezahlte Entwickler. Das hat gute und schlechte Seiten: Auf der einen Seite führt es bestimmt zu mehr freier Software, auf der anderen Seite ist es jedoch möglich, dass die bezahlten Entwickler nicht die gleiche Motivation wie die Freiwilligen zeigen und das negative Auswirkungen auf die Qualität der Software hat.
Golem.de: Du hast dich auch mit den kritischen Erfolgsfaktoren freier Softwareprojekte auseinander gesetzt und dabei vor allem den Übergang von einer kleinen Startgruppe zu einer größeren Entwicklergemeinschaft als kritischen Punkt identifiziert. Welchen Herausforderungen müssen sich Projekte konkret stellen, um diese Phase erfolgreich zu meistern?
Michlmayr: Raymonds Artikel "The Cathedral and the Bazaar" wird oft als das Modell von Open Source dargestellt. In Wirklichkeit befinden sich jedoch nur eine geringe Anzahl von Projekten im Bazaar, in dem Patches von einer großen Anzahl von Freiwilligen beigesteuert und überprüft werden. Viele Projekte haben jedoch nur einen Entwickler oder ein kleines Team – keine Tausende von Leuten, die Patches beitragen.
Diese Projekte würden natürlich von mehr Freiwilligen profitieren, doch zuerst ist eine Migration von der Cathedral zum Bazaar erforderlich. Diese Migration benötigt große Veränderungen im Management des Projekts, da man das Projekt plötzlich öffnen und Beiträge von anderen akzeptieren muss. Ich glaube jedoch, dass viele Leute, die ein Projekt starten, zwar gute Entwickler sind, aber schlechte Manager abgeben und somit verhindern, dass ein großer Bazaar entsteht.
Martin Michlmayr ist seit rund zehn Jahren an diversen freien Softwareprojekten beteiligt. Er koordinierte unter anderem das Projekt GNUstep und arbeitete als öffentlicher Direktor für Linux International. Seit 2000 gehört er dem Debian-Projekt an und leitete dieses von April 2003 bis April 2005 als "Debian Project Leader".
Er hat Philosophie und Psychologie an der Leopold-Franzens-Universität Innsbruck(öffnet im neuen Fenster) sowie Software Engineering an der Universität Melbourne(öffnet im neuen Fenster) studiert und forscht(öffnet im neuen Fenster) im Rahmen seines PhD-Studiums am Centre for Technology Management(öffnet im neuen Fenster) der Universität Cambridge über das Thema Qualitäts-Management in freien Softwareprojekten. Im ersten Teil dieses Interviews sprach Michlmayer über Gegenwart und Zukunft des Debian-Projekts .



