Apache Software Foundation: Ein Blick hinter die Kulissen

Schon mal mit dem Gedanken gespielt, ein Teil der Open-Source-Community zu werden? Die Apache Software Foundation (ASF) ist in dem Fall eine von vielen möglichen Anlaufstellen. Aber auf was lässt man sich da ein? Wir sprachen mit jemandem, der sich damit auskennt: Benedikt Ritter ist selbst in der ASF aktiv und steht uns im Gespräch Rede und Antwort.

Das folgende Interview erschien ursprünglich im Softwerker Ausgabe 01/15.

Was macht die Apache Software Foundation aus deiner Sicht aus?

Es gibt eine Reihe von Prinzipien, die die ASF ausmachen. Da ist zum einen das Prinzip “Community over Code”. Es soll zum Ausdruck bringen, dass eine lebendige, freundliche Community wichtiger ist, als der Code selbst. Dahinter steckt der Gedanke, dass eine gute Community schlechten Code kontinuierlich verbessern kann. Ohne Community wird sich aber selbst der beste Code nicht weiterentwickeln.
Des Weiteren ist die ASF eine Meritokratie (engl. „meritocracy“). Das bedeutet, dass jeder seine Fähigkeiten unter Beweis stellen muss, um mehr Mitspracherecht zu bekommen. Sobald dieser Beweis erbracht ist, kann das Mitspracherecht nicht mehr entzogen werden. Eng damit verknüpft ist der Begriff „do-ocracy“ (zu deutsch etwa „Tu-okratie“). Das bedeutet, dass diejenigen entscheiden dürfen, die etwas tun. Soll heißen, es ist besser eine Änderung zu machen, die 90% der Use Cases abdeckt, als nichts zu tun.
Mir persönlich gefällt außerdem, dass die ASF sehr unpolitisch ist. Es gibt keine großen Unternehmen, die eine Agenda verfolgen.

Wie bist du auf die ASF gestoßen?

Jeder, der sich mit IT beschäftigt, kommt früher oder später mit dem Apache httpd Webserver in Berührung. Apache httpd ist wohl das am weitesten verbreitete Produkt der ASF. Als ich während des Studiums zum ersten Mal mit einem LAMP Stack gearbeitet habe, war mir aber noch nicht klar, was eigentlich dahinter steckt.

Apropos httpd – das ist nicht nur das am weitesten verbreitete sondern auch das Ursprungsprojekt, aus dem die ASF erst entstanden ist, oder?

Ja das ist richtig. Gegründet wurde die ASF von einer Gruppe von Entwicklern, die sich Mitte der Neunziger zusammen geschlossen hatten, um Patches für den NSCA public domain HTTP Daemon zu entwickeln. Im April 1995 veröffentlichte diese Gruppe die Version 0.6.2 von Apache httpd. 1999 gründeten die Mitglieder der Apache Group dann die Apache Software Foundation. Aus dieser Zeit stammt übrigens auch die Legende, dass der Name „Apache“ die Qualität von Apache httpd beschreibt („a patchy webserver“). Richtig ist, dass der Name zu Ehren der amerikanischen Urvölker gewählt wurde .

Kommen wir zurück zu deiner Antwort, wie du zur ASF gestoßen bist…

Später im Studium habe ich dann als Werksstudent in einem Unternehmen Software entwickelt. Frisch von der Uni kommend hatte ich häufig den Impuls, die Lösung zu jedem Problem selbst zu implementieren. Mein damaliger Teamleiter hat zu mir gesagt: „Bevor du anfängst zu programmieren, schaust du erstmal, ob es das nicht schon irgendwo gibt“. Er hat mir dann auch Apache Commons gezeigt und ich fand es damals einfach beeindruckend, was es dort an fertigen Software-Lösungen gibt.
Irgendwann habe ich mich auf der Apache-CommonsMailingliste angemeldet, weil ich wissen wollte, wie das alles funktioniert. Ich habe angefangen mitzudiskutieren und Patches zu schreiben. An einem Samstag morgen bekam ich dann eine E-Mail vom Apache Commons PMC (Projekt Management Committee) mit der Frage, ob ich Committer werden möchte. Das war für mich ein großartiger Moment, weil ich andere durch meine gute Arbeit von meinen Fähigkeiten überzeugen konnte. Mittlerweile gehöre ich selbst zum PMC und verschicke solche E-Mails an andere Leute, die mich durch ihre gute Arbeit von ihren Fähigkeiten überzeugt haben.

Wie definiert sich ein Project Management Committee?

Jedes Projekt bei der ASF hat ein Project Mangement Committee. Das PMC hat die Verantwortung über das Projekt und seine Weiterentwicklung. PMC-Mitglieder können neue Committer (und neue PMC-Mitglieder) vorschlagen, die dann im Rahmen eines geheimen Votums entweder zugelassen oder abgelehnt werden. Generell sind nur die Stimmen von PMC-Mitglieder bindend, sofern es zu einer Abstimmung kommt. Wenn beispielsweise ein neues Release veröffentlicht werden soll, stellt der Release Manager einen Release Candidate (RC) zum Review bereit. Jeder ist dann eingeladen diesen RC zu prüfen und seine Meinung darüber auf die Mailingliste zu schreiben. Zur Veröffentlichung eines Releases benötigt der Release Manager aber in jedem Fall drei Stimmen von PMC-Mitgliedern. Alle anderen Stimmen können ein Release nicht verhindern oder beschleunigen. Natürlich ist es unwahrscheinlich, dass der Release Manager ein Release veröffentlicht, wenn es drei PMC-Stimmen dafür, aber zehn andere Stimmen dagegen gibt. Formal gesehen wäre dies aber ein gültiger Abstimmungsprozess nach den Regeln der ASF.
Außerdem ist es Aufgabe des PMC vierteljährlich einen Bericht an das Board of Directors zu verfassen und über den Zustand des Projektes zu informieren. Dort stehen Informationen über neue Committer und PMC-Mitglieder, veröffentlichte Releases, und andere wichtige Neuigkeiten drin. Außerdem gibt der Report die Möglichkeit das Board of Directors um Hilfe zu bitten, wenn das Projekt in Schwierigkeiten ist. Das kann z.B. Handlungsunfähigkeit aufgrund fehlender aktiver Community oder wegen projektinternen Konflikten sein, welche die Projektmitglieder alleine nicht lösen können. So eine Sitatution habe ich bisher allerdings noch nicht erlebt.

Du hast jetzt einige Begriffe genannt, die vielleicht nicht jeder kennt: Committer, Release Manager, Release Candidate, Board of Directors. Kannst du das etwas näher erläutern?

Gerne! Grundsätzlich unterscheiden wir bei der ASF zwischen Contributor und Committer. Contributor wird man ganz einfach, indem man etwas zum Projekt beiträgt. So gilt schon das Einstellen eines Bugtickets als Contribution. Contributions können aber auch Diskussionsbeiträge auf den Mailinglisten, Verbesserungen der Dokumentation und natürlich Patches für offene Tickets im Bugtracker sein. Patches kann man bei den meisten Projekten in der From von SVN bzw. Git Diffs einreichen oder seit einiger Zeit auch als Pull Request über die GitHub Mirrors der Apache Software Foundation . Die Patches werden dann von den Committern begutachtet und hinsichtlich Relevanz, Coding Style und Qualität bewertet. Dabei entsteht dann häufig eine Diskussion, was am Patch noch verbessert werden muss, damit er dem Source Code hinzugefügt werden kann. Wenn ein Patch die gewünschte Reife erreicht hat, wird er von einem Committer zum Source Code hinzugefügt. Bei jedem Commit wird das Diff an eine separate Mailingliste verschickt und kann so durch die anderen Projektbeteiligten (Committer, wie Contributor) reviewt werden. Wenn jemand Bedenken bei einer Änderung hat, kann er diese einfach auf der Mailingliste äußern und der Autor der Änderung hat Gelegenheit die Änderung zu erklären oder zu rechtfertigen. So soll sicher gestellt werden, dass die Qualität möglichst hoch bleibt.

Der Release Manager hat seinen Einsatz etwas später im Entwicklungsprozess. Zu irgend einem Zeitpunkt kann ein Committer sich bereit erklären ein neues Release für ein Projekt bereit zu stellen. In der Regel gibt es dann eine kurze Ankündigung á là „Es ist einige Zeit vergangen, seit wir foo 1.1 veröffentlich haben. Ich habe vor in Kürze das Release 1.2 von foo vorzubereiten. Wenn ihr noch Dinge fixen wollt, tut dies bitte bald“. Zur Veröffentlichung eines Releases bereitet der Release Manager einen Release Candidate vor und schickt eine Benachrichtigung an die Mailingliste . Der Release Candidate besteht aus mehreren Teilen: Ein SVN/git Tag des Quellcode-Stands, der veröffentlicht werden soll, Binär- und Quellcode-Archive, Artefakte, die nach Maven Central veröffentlich werden sollen, Release Notes, die Projektwebsite, sowie einige Reports. Der Release Candidate bedeutet so viel wie „wenn wir uns dafür entscheiden Release 1.2 von foo zu veröffentlichen, dann würde das genau so aussehen“. Sofern die Abstimmung über den Release Candidate erfolgreich ist, wird dieser als Release veröffentlicht. Andernfalls wird der Code verbessert und der Release Manager erstellt einen weiteren Release Candidate.

Um die Rolle des Board of Directors zu erläutern, muss ich ein bisschen weiter ausholen und ein wenig auf die Organisationsstruktur der ASF im Allgemeinen eingehen. Der englische Begriff „Foundation“ bedeutet auf Deutsch so viel wie „Stiftung“. Trotzdem entspricht die Apache Software Foundation nach deutschem Recht aber eher einem Verein. Es gibt also Mitglieder in diesem Verein (die sog. „Member“). Member wird man – nach dem meritokratischen Prinzip – indem man den anderen Membern durch seine Arbeit zeigt, dass einem an der ASF gelegen ist. Die Member bestimmen aus ihren Reihen jährlich ein „Board of Directors“, das die ASF in allen Bereichen steuert. Es gibt dort eigene „Officers“ für diverse Bereiche wie bspw. Spendenmangement, Marketing, Markenschutz, Infrastruktur, etc. Dies ist die organisatorische Schicht auf die ASF (vgl. Abbildung 1). Die PMCs kümmern sich um die technische Seite und berichten dem Board of Directors durch die Reports. Wenn neue Projekte gestartet werden, werden diese durch das Board of Directors initiiert.

Kannst du den Weg beschreiben, den ein OpenSource-Projekt in der ASF durchläuft?

Es gibt im Wesentlichen zwei Möglichkeiten, wie Projekte gestartet werden können:

• Ein vorhandenes Projekt möchte in die ASF aufgenommen werden. Beispiele hierfür sind Apache SVN oder Apache OpenOffice.
• Ein neues Projekt wird aus der ASF heraus initiiert. Ein Beispiel hierfür ist Apache BatchEE , welches aus dem Dunstkreis von TomEE hervorgegangen ist.

Unabhängig davon, auf welchem Weg ein Projekt eingebracht wird – der Startpunkt bei der Apache Software Foundation ist immer der Incubator . Der Incubator hat verschiedene Aufgaben, von denen eine der wichtigsten ist, Fragen hinsichtlich der Urheberschaft zu klären. Aller Code bei der ASF muss unter der Apache License 2.0 veröffentlich werden. Hier kann es bei bestehenden Projekten, die in die ASF aufgenommen werden wollen, verschiedene „Probleme“ geben:

1. Der Code des Projekts steht unter einer inkompatiblen Lizenz (bspw. GPL). In diesem Fall können die Urheberrechtsinhaber natürlich die Lizenz ändern.
2. Das Projekt steht unter einer inkompatiblen Lizenz und enthält Code, dessen Urheberrecht die Projektmitglieder nicht haben. In diesem Fall müssen diese Teile neu implementiert werden.
3. Das Projekt hat Abhängigkeiten auf Bibliotheken, die unter einen inkompatiblen Lizenz stehen. In diesem Fall muss die Abhängigkeit ausgetauscht oder neu implementiert werden.

Es ist enorm wichtig für die ASF, dass diese rechtlichen Fragen geklärt werden, weil die ASF dafür einsteht, dass ihre Produkte gefahrlos im Unternehmenskontext eingesetzt werden können.
Außerdem soll der Incubator dafür sorgen, dass kein Projekt als Rohrkreprierer startet, z.B. weil die Community nicht groß genug ist. Deshalb wird zu verschiedenen Zeitpunkten während des Incubator-Prozess geprüft, ob das Projekt aktiv ist. Darüber hinaus sollen ASF-Neulinge im Incubator den „Apache Way“ kennen lernen.

Zum „Apache Way“ gehören neben den eingangs erwähnten Prinzipien vor allen Dingen die Art und Weise, wie am Projekt gearbeitet wird. Es gibt bei der ASF (mit ganz wenigen Ausnahmen) keine Geheimniskrämerei. Alle Entscheidungen werden öffentlich diskutiert und können auch später noch in den Mailinglist-Archiven nachvollzogen werden. Darüber hinaus erfolgt die Entwicklung in der Regel per Commit-then-Review. Diesen Prozess hatte ich ja bereits beschrieben. Er soll dafür sorgen, dass die Qualität hoch bleibt. Ein positiver Nebeneffekt ist, dass man sich mit der Zeit eine extrem ordentliche Arbeitsweise angewöhnt. Die Commits werden sehr klein, sodass sie einfach zu reviewen sind. Außerdem enthalten sie nur die Änderungen die wirklich zu dem Bugfix oder Feature gehören und keine CodeReformatierungen an Stellen, die nichts damit zu tun haben. Das hilft mir auch bei meiner „richtigen“ Arbeit im Projekt, ordentliche Ergebnisse abzuliefern.

Was ist für dich der Benefit an der Arbeit bei Apache?

Ich kann durch meine Arbeit eine ganze Reihe mitnehmen. Dadurch, dass meine Arbeit ständig von fähigen Leuten reviewt wird, kann man eine ganze Menge lernen. Natürlich macht mir als Committer auch die Zusammenarbeit mit den Contributorn Spaß. Auch durch das Reviewen von Patches und Commits lernt man ständig dazu. Darüber hinaus kommt man mit Leuten von der ganzen Welt in Kontakt. Briten verhalten sich und kommunizieren z.B. ganz anders als Italiener. Dass die gesamte Kommunikation über Mailinglisten läuft, macht es natürlich nicht einfacher. Ich bin auch immer wieder überrascht, mit wem ich durch meine Arbeit so zu tun bekomme. Von Apache Commons kenne ich z.B. Henri Yandell. Er ist verantwortlich für den Bereich Open Source bei Amazon. Phil Steitz war CTO bei American Express und Gary Gregory ist Autor von „JUnit in Action“ und „Hibernate in Action“. Den Namen Roy Fielding hat wahrscheinlich jeder schon mal gehört… Zu guter Letzt ist es ein tolles Gefühl, wenn man von einem User hört „Danke für diese Bibliothek, ihr habt mir einen Haufen Arbeit erspart“.

Kannst du Neulingen Tipps geben, die sich mit der ASF beschäftigen wollen?

Das wichtigste ist „Nur Mut, einfach mitmachen“. Ich habe mich anfangs kaum an Diskussionen auf Mailinglisten beteiligt, aus Angst etwas „Blödes“ zu schreiben. Aber nur wer fragt, dem kann geholfen werden. Außerdem muss man ein wenig Frusttoleranz mitbringen. Nur die wenigsten Patches werden direkt beim ersten Wurf angenommen. Es ist ganz normal, dass man sich erst an den Style von ASF-Projekten gewöhnen muss. Man sollte sich davon nicht frustrieren lassen, sondern die Diskussion um Patches immer als Chance sehen etwas zu lernen. Ganz konkrete Hilfestellungen gibt es natürlich auch auf den Websites der ASF . Die wahrscheinlich wichtigsten Regeln für Patches sind:

• Jede Datei muss einen Apache License Header haben.
• Spaces statt Tabs für Einrückung.

Danke für deine Zeit, Benedikt. Nächstes Mal möchte ich dann mehr über Apache Commons erfahren!