computerwoche.de

Archiv

Software-Engineering/Auch freie Projekte folgen festen Regeln

Open Source: Chaos oder strukturierte Entwicklung?

09.03.2001
Freier Software wird oftmals angelastet, dass ihre Entwicklung chaotisch abläuft und jeder nach Lust und Laune am Quellcode herumexperimentieren darf. Doch schaut man sich ein Open-Source-Projekt wie "Apache" genauer an, so stellt sich heraus, dass es hier auch feste Strukturen und Regeln gibt. Von Lars Eilebrecht*

Der Open-Source-Vordenker Eric Raymond beschreibt in seinem Aufsatz "Homesteading the Noosphere" (http://www.tuxedo.org/esr/writings/homesteading) verschiedene Arten von Projektstrukturen bei der Open-Source-Entwicklung. Als typischen Fall nimmt er jenen an, wo ein Projektleiter als eine Art "Diktator" in letzter Instanz Entscheidungen bezüglich des Projektes treffen kann. Gerade einige größere Open-Source-Teams organisieren sich jedoch anders, beispielsweise das Perl-Projekt, bei dem es rotierende Projektleiter gibt. Ein anderes Beispiel ist das Apache-Team, bei dem überhaupt kein Projektleiter existiert, sondern Entscheidungen immer gemeinschaftlich von den Kernentwicklern getroffen werden. Eric Raymond geht aber davon aus, dass solche Strukturen zu kompliziert und instabil seien.

Regelwerk ohne klassische Projektstrukturen

Das Gegenteil beweist jedoch das Web-Server-Projekt von Apache, denn dessen Erfolg zeigt, dass bei Open Source nicht unbedingt klassische Projektstrukturen notwendig sind. Das Projekt wurde 1995 von acht Entwicklern ins Leben gerufen, mittlerweile liegt der Apache Web-Server mit einem Marktanteil von 60 Prozent deutlich vor den Konkurrenz.

Wie in anderen freien Projekten dient auch bei Apache E-Mail als das wichtigste Kommunikationsmedium. In eine öffentliche Entwicklungsliste kann sich jeder Interessierte eintragen. Müssen indes Dinge diskutiert werden, die nicht an die Öftentlichkeit gelangen sollen, wie beispielsweise Sicherheitslücken, so nutzen die Kernentwickler, das so genannte Core-Team, eine private Liste. Der Quellcode wird, wie bei den meisten anderen Projekten auch, auf einem zentralen Concurrent-Versions-System-(CVS-)Server verwaltet.

Beitragen kann zum Projekt prinzipiell jeder, doch nur wer dies über eine längere Zeit tut und entsprechendes Interesse an der weiteren Entwicklung des Apache zeigt, wird eingeladen, Mitglied des Core-Teams zu werden. Damit verbunden ist das Privileg des direkten Zugriffs auf den CVS-Server und dadurch die Möglichkeit, Quellcodeänderungen (Patches) direkt einzuspeisen. Gelegentlich wurde der Zugriff auf den CVS-Server jedoch Beitragenden eingeräumt, die nicht Mitglied des Core-Teams sind oder waren.

Gegenüber anderen Open-Source-Projekten weist das Apache-Projekt jedoch einige Unterschiede und Besonderheiten auf, die insbesondere die Struktur und Regeln betreffen, wann und wie Quellcodeänderungen integriert werden. Wie bereits zuvor erwähnt, gibt es beim Apache-Projekt keinen dedizierten Projektleiter, der alleine den Ton angibt. Entscheidungen werden immer gemeinschaftlich getroffen, wobei die entsprechenden Regeln bereits sehr früh nach Projektbeginn festgelegt wurden.

Größere Freiheit bei Beta-Versionen

Je nachdem ob gerade an einer Release- oder einer Betaversion gearbeitet wird, unterscheidet das Team zwischen zwei Arbeitsmodi: "review-then-commit" und "commit-then-review". Im ersten Fall wird ein Patch - unabhängig davon, wer ihn vorgeschlagen hat - nur dann eingebunden, wenn mindestens drei Kernentwickler damit einverstanden sind. Jedes Mitglied des Core-Teams kann aber dagegen ein Veto einlegen, wobei dann typischerweise eine entsprechend ausführliche Begründung oder ein Verbesserungsvorschlag mitgeliefert werden muss. Um Missverständnisse zu vermeiden, gibt es entsprechende Abstimmungsrichtlinien. Wurde ein Patch bereits inspiziert und für gut befunden, so machen die Entwickler dies durch die Abkürzung "+1" in einer Mail kenntlich. Ein Veto äußert sich durch ein "-1", "0" gilt als Enthaltung.

Befindet sich die Entwicklung im "commit-then-review"-Modus, so kann ein Patch direkt von einem Entwickler eingebunden werden. Hierbei wird implizit davon ausgegangen, dass nachträglich andere Entwickler diesen Code überprüfen. Sollte einer von ihnen ein Veto einlegen, so wird der Patch wieder entfernt oder erkannte Fehler durch einen neuen Patch behoben.

Grundsatzentscheidungen benötigen Mehrheit

Kommt es bei der Diskussion über die "richtige" Lösung zu Konflikten oder herrscht bei sonstigen Entscheidungen Uneinigkeit, dann muss eine Mehrheitsentscheidung Klarheit schaffen. Damit jedoch solche Abstimmungen nicht zu aufwändig geraten, ist nicht eine Mehrheit bezogen auf die gesamte Anzahl der Kernentwickler notwendig, sondern es reicht hierzu die Mehrheit unter den Entwicklern aus, die sich an der Abstimmung beteiligen ("small-quorum-consensus"). Dadurch wird sichergestellt, dass das Core-Team immer handlungsfähig ist und Entscheidungen auch kurzfristig getroffen werden können, wenn dies erforderlich ist.

Doch kommen wir wieder zurück zur eigentlichen Entwicklung. Abgesehen davon, dass beim Apache-Projekt kein Projektleiter amtiert, gibt es auch keine fest zugeordneten Aufgaben oder Zuständigkeiten bezüglich der Software. Ein Entwickler kann selbst entscheiden, an welchem Teil der Software er arbeiten möchte. Um die Konsistenz und Lesbarkeit des Quellcodes zu erhalten, wurde bereits sehr früh ein Coding Styleguide entworfen, der den Entwicklern entsprechende Vorgaben macht.

Um zu vermeiden, dass zwei oder mehr Entwickler den gleichen Teil des Quellcodes bearbeiten, gibt es die Regel, dass sie besonders umfangreiche Änderungen zuvor auf der Mailing-Liste angekündigen. Hierdurch wird doppelte Arbeit vermieden und den anderen Mitgliedern die Möglichkeit gegeben, sich kritisch zu den vorgeschlagenen Änderungen und Konzepten zu äußern.

Um bei den vielen Änderungen, die für den Apache Web-Server geplant sind oder bereits realisiert wurden, den Überblick zu behalten, existiert eine Statusdatei, in der jeder Entwickler einen Eintrag vornehmen muss, wenn er einen Patch zur Abstimmung an die Liste geschickt hat. In der Statusdatei wird dann der Stand der Abstimmung festgehalten. Weiterhin werden dort noch offene Probleme und bekannte Fehler notiert, die behoben werden müssen. Für schwerwiegende Fehler, die so genannten Showstopper, sieht die Statusdatei einen eigenen Abschnitt vor. Ein neues Release gelangt nur dann zu den Anwendern, wenn alle dort angeführten, gravierenden Mängel behoben wurden.

Keine festen Update-Zyklen

Neue Versionen des Apache erscheinen in unregelmässigen Abständen, denn fest definierte Freigabetermine gibt es nicht. Die Planung eines neuen Release beginnt immer dann, wenn hinreichend viele Fehlerkorrekturen und neue Funktionen eingearbeitet wurden und auf der Mailing-Liste ein entsprechender Vorschlag von einem Entwickler gemacht wurde. Als erstes bestimmt dann das Team einen so genannten Release-Manager, der die Verantwortung für die jeweilige Version übernimmt. Für diese Aufgabe kommt jeder Kernentwickler in Frage. Der Release-Manager muss dafür Sorge tragen, dass alle Showstopper behoben und alle angenommenen Patches auch korrekt eingearbeitet werden. Zu gegebener Zeit spricht er einen "Code-Freeze" aus, das heißt, nur der Release-Manager darf dann noch Änderungen am Quellcode vornehmen und bei Bedarf Patches wieder entfernen, wenn er eine Gefahr für die Stabilität des Apache sieht. Zudem muss er die neue Version zumindest grundlegend testen. Dies wird übrigens generell von jedem Kernentwickler erwartet.

Zwischen der Bekanntgabe der Version und der eigentlichen Fertigstellung liegen in der Regel mindestens drei Tage, um auch noch Zeit für Tests der neuen Version zu gewinnen. Tritt hierbei ein Fehler auf, wird der Freigabetermin in der Regel verschoben und ein komplett neues Release herausgebracht.

Dachorganisation fördert Teams

Erst wenn die Tests abgeschlossen sind, können Interessierte die neue Apache-Version herunterladen. Das Team kündigt die Verfügbarkeit über die Announcement-Mailing-Liste und in den relevanten News-Gruppen an.

Das Apache-Web-Server-Projekt unterscheidet sich jedoch noch durch einen weiteren Punkt von den meisten anderen Projekten. Im Sommer 1999 wurde von den damaligen Projektmitgliedern die Apache Software Foundation (ASF) gegründet, eine mitgliederbasierte, Not-for-profit-Corporation mit Sitz in Delaware, USA. Die ASF ist eine Dachorganisation, unter deren Schirmherrschaft sich mehrere Open-Source-Projekte befinden. Inbesondere handelt es sich dabei um das Apache-Web-Server-Projekt und solche, die in der Regel entweder etwas mit dem HTTP-Server oder dem Web im Allgemeinen zu tun haben. Ziel der ASF ist es, organisatorische, rechtliche und auch finanzielle Unterstützung für die darunter zusammengefassten Projekte zu leisten. Wie jede Firma in den USA hat auch die ASF ein Board of Directors, das jährlich von allen Mitgliedern neu gewählt wird. Daneben wird für jedes Projekt ein Vice President benannt, der als Schnittstelle zwischen dem jeweiligen Projekt und dem Board of Directors fungiert. Die ASF mischt sich jedoch grundsätzlich nicht in Projekte ein. Innovation ist nur dann möglich, wenn jeder Beitragende seine Ideen nach den eigenen Vorstellungen umsetzen kann. Die Apache Software Foundation soll nur sicherstellen, dass die ASF-Projekte dauerhaft Bestand haben, auch, wenn die ursprünglichen Gründer sich nicht mehr daran beteiligen.

Wer mehr über die Apache Software Foundation erfahren will, kann dies über die Website tun (http://www.apache.org) oder eine der Apache-Konferenzen (http://www.apachecon.com) besuchen, die alle sechs Monate ausgerichtet werden. Die nächste findet vom 4. bis 6. April im kalifornischen Santa Clara statt.

*Lars Eilebrecht ist Mitglied der Apache Software Foundation und arbeitet als Director Product Management bei der Cyber Solutions GmbH in München.

Abb: Organisation der Apache-Entwicklung

Das Organisationsdiagramm von Apache vermittelt den Eindruck einer stark hierarchischen Struktur. Tatsächlich arbeiten die Projektteams aber weitgehend autonom. (Quelle: Apache Software Foundation)