Der Drupal 8 Entwicklungszyklus - Mut zur Struktur

zu-viele-meinungen.png

Der Drupal 8 Entwicklungszyklus kommt langsam in das letzte Drittel. Zeit, einen Blick auf die Methode zu werfen, wie dieses große Open Source Projekt versucht, Innovation und Stabilität unter einen Hut zu bringen.
Drupal hat über tausend Entwickler, die am Kernsystem ("Core") mitarbeiten. Die genaue Zahl ist schwer zu ermitteln und auch etwas irreführend, da in dieser Statistik jeder mitgezählt wird, der nur einen einzigen Patch soweit gebracht hat, daß er committet wird.

In Drupal 7 war es so, daß über 80% des Codes trotz einer ähnlichen Gesamtzahl von 25 Personen beigesteuert wurde. Gefühlt hat sich das in Drupal 8 allerdings etwas verbreitert. So oder so sind es eine Menge Leute, die zudem geografisch weit über die Welt verteilt sind. Der Project-Tracker auf drupal.org hat bekannte Schwächen, als Strukturierung bieten sich eigentlich nur nach Tags und Subsystem ordenbare Listen.

Wo ist denn hier der Überblick

Größere Patches erleben nicht selten mehr als 300 Kommentareund zahllose "Rerolls", d.h. Veränderung und Verbesserung des Patches, bis er _endlich_ committet wird. In Drupal 7 gab es zwei Core-Maintainer (Personen, die committen dürfen), und ansonsten kaum klar definierte "Machtbefugnisse". Es gab zwar Verantwortliche für verschiedene Subsysteme wie z.B. das Datenbanksystem, diese hatten aber kaum formale Rechte, was verschiedentlich bemängelt wurde.

Es führte dazu, daß die beiden Hauptmaintainer kaum hinterherkamen, die ganzen vorgeschlagenen Verbesserungen und Bugfixes zu bewerten und zu entscheiden, ob diese reif für den Core waren. Zudem ist es quasi unmöglich selbst für Angie Byron und Dries Buytaert (die D7 Maintainer zu dieser Zeit), sich in sämtlichen Ecken von Drupal so gut auszukennen, um das ohne Rat einzuholen, bewerten zu können.

Abteilungsleiter aus Leidenschaft

Um den Entwicklungsprozeß also weiter zu dezentralisieren und besser zu strukturieren, entschloss man sich für Drupal 8 dazu, die sogenannten "Core Initiatives" einzuführen. Verschiedene große Funktionsbereiche, wie HTML5, Mehrsprachigkeit, Konfigationsmanagement usw. bekamen einen Bereichsverantwortllichen. Diese arbeiten mit ihrem jeweiligen Team zunächst einer Sandbox (Eigener Branch des Kernsystems). Die ganzen Initiative Leads treffen sich regelmäßig mit den Core Maintainern, deren Zahl sich mittlerweile auf drei erhöht hat, um die Fortschritte zu besprechen.

Zudem schreiben die Initiative Leads regelmäßig Berichte über den Stand der Arbeiten ihrem Bereich. Idealerweise entscheidet zunächst ein Initiative Lead, welche Funktionalität verwendet wird und welcher Pfad weitergegangen wird. Da Drupal aber prinzipiell basisdemokratisch organisiert ist, setzen auch die Initiative Leads auf das Finden eines Konsens, statt autoritär aufzutreten. Zum letzten Mittel des "Ich entscheide das jetzt!" greifen sie nur, wenn die Diskussion sich gar zu sehr verzettelt und es einfach nicht vorwärts geht.

Der entscheidende Punkt jedoch ist, daß dieser tägliche Kleinkrieg zunächst einmal nicht das Eingreifen der Core Maintainer braucht. Die Leute, die mitarbeiten, aber nicht Initiative Lead sind, haben Ansprechpersonen, an denen sie sich ggf. abarbeiten können. Eigentlich sind das ganz normale Strukturen, die jede größere Firma braucht, wenn sie nicht im Chaos versinken will. Nur in Open Source Projekten ist das oft nicht üblich, da man klassische Hierarchien als ideologisch fragwürdig ansieht. Wie oben beschrieben, geht es nicht allzu klassisch zu, dazu sind wir dann doch zu sehr Open Source.

Entscheidend ist aufm Platz

Und was kommt am Ende dabei raus? Von der schieren Menge und der Tiefgreifendheit (das maln Wort) der Änderungen ist es gigantisch. Man kann nur Angst bekommen, daß die Cleanup Phase, in der die ganzen kritischen Bugs gefixt werden müssen, doch wieder wesentlich länger dauert als geplant und sich das Release verzögert. Die Wette Frühjahr 2014 gehe ich aber trotzdem noch gerne ein. Welche Änderungen und Neuerungen Drupal 8 im einzelnen bringt, darauf werde ich in einem weiteren Blogpost eingehen.