Wenn einem Open-Source-Projekt der Leader fehlt

Als Ryan Dahl sich von Node.js zurückzog, überlebte das Projekt, aber es brauchte Jahre der Umstrukturierung der Governance, einen Fork (io.js) und eine Wiedervereinigung, bevor es sich stabilisierte. Als Guido van Rossum als BDFL („Benevolent Dictator For Life“) von Python zurücktrat, verbrachte die Community Monate mit Debatten über Governance-Modelle, bevor man sich auf einen Steering Council einigte. Als das Deno-Projekt eigene Führungsfragen klären musste, bekam jeder Entwickler die Folgen zu spüren, der auf die Runtime gesetzt hatte.

Das sind keine Einzelfälle. Sie sind ein strukturelles Merkmal der Open-Source-Entwicklung. Die meisten bedeutenden Open-Source-Projekte hängen von einer winzigen Anzahl Menschen ab, oft von einer einzigen Person, und zwar weit mehr, als ihre Nutzer ahnen. Verlässt diese Person das Projekt, brennt aus, setzt andere Prioritäten oder trifft eine umstrittene Entscheidung, steht das Projekt vor einer existenziellen Krise, die kein GitHub-Stern verhindern kann.

Das Bus-Faktor-Problem

Der „Bus Factor“, also wie viele Leute von einem Bus erwischt werden müssten, bevor ein Projekt zusammenbricht, ist bei den meisten Open-Source-Projekten erschreckend niedrig. Eine Studie aus dem Jahr 2015 ergab, dass über 60 % der npm-Pakete nur einen Maintainer hatten. Eine neuere Analyse kritischer Open-Source-Infrastruktur zeigte, dass viele Projekte mit Millionen nachgelagerter Abhängigkeiten von ein oder zwei Personen betreut werden, oft als unbezahlte Hobbyarbeit.

Das ist kein hypothetisches Problem. OpenSSL, die Bibliothek, die den Großteil des verschlüsselten Internetverkehrs absicherte, wurde zur Zeit der Heartbleed-Entdeckung hauptsächlich von zwei Leuten in ihrer Freizeit betreut. Left-pad, ein trivialer npm-Paket mit 11 Zeilen, ließ Tausende Builds scheitern, als der Autor es entfernte. Core-js, das über 25 Millionen Mal pro Woche heruntergeladen wird, wird von einem einzigen Entwickler gepflegt, der öffentlich beschrieben hat, dass er sich kaum das Essen leisten kann.

Das Muster ist immer gleich: Ein kritisches Projekt wird von einer begeisterten Einzelperson gestartet, findet Verbreitung, wird zur Infrastruktur, auf die Millionen angewiesen sind, und trotzdem bleibt die Wartungslast bei denselben ein oder zwei Personen. Die Bedeutung des Projekts wächst exponentiell. Die Unterstützung tut es nicht.

Governance-Modelle und ihre Abwägungen

Open-Source-Projekte regeln ihre Governance auf einige unterschiedliche Weisen, jede mit vorhersagbaren Stärken und Schwächen.

Das BDFL-Modell

Eine einzelne Person trifft die endgültigen Entscheidungen. Python (Guido van Rossum), Linux (Linus Torvalds), Ruby (Matz): Die erfolgreichsten Projekte haben oft eine starke technische Führungsfigur, deren Geschmack und Urteilsvermögen das Projekt prägen. Der Vorteil liegt auf der Hand: klare Richtung, konsequente Vision und schnelle Entscheidungen. Der BDFL kann Features ablehnen, die nicht passen, und das Projekt bleibt fokussiert.

Der Fehlermodus ist genauso eindeutig: Der BDFL geht, und es gibt keinen Nachfolgeplan. Pythons Übergang nach Guidos Rücktritt verlief trotz seiner jahrzehntelangen Arbeit am Aufbau der Community holprig. Projekte mit weniger engagierten Communities sterben oft einfach, wenn ihr BDFL weiterzieht.

Das Foundation-Modell

Projekte wie Apache, Eclipse und die Linux Foundation stehen unter gemeinnützigen Stiftungen mit formalen Governance-Strukturen: technische Lenkungsausschüsse, Wahlen für Committer und klar geregelte Entscheidungsprozesse. Das sorgt für institutionelle Kontinuität, denn das Projekt übersteht einzelne Abgänge, weil die Struktur bestehen bleibt.

Der Preis dafür sind Bürokratie und politische Dynamiken. Stiftungs-Governance kann langsam, streitlustig und von Unternehmensinteressen vereinnahmt sein. Manche Entwickler empfinden den Komitee-Prozess als erstickend, verglichen mit der Beweglichkeit eines BDFL-geführten Projekts. Der schlimmste Fall: eine Stiftung, in der es mehr um Organisationspolitik geht als um technische Qualität.

Das Modell des Unternehmenssponsors

React (Meta), Go (Google), Rust (ursprünglich Mozilla, heute eine eigene Stiftung), TypeScript (Microsoft): Viele große Projekte werden von Unternehmen gesponsert, die die Kernmaintainer beschäftigen. Das löst das Finanzierungsproblem. Maintainer werden bezahlt, können in Vollzeit arbeiten, und das Projekt profitiert von unternehmerischen Engineering-Ressourcen.

Das Risiko liegt in der Ausrichtung. Unternehmensprioritäten ändern sich. Mozilla hat das Rust-Team entlassen. Google hat Open-Source-Projekte zurückgestuft und unterfinanziert, als sich der Geschäftsfokus verschob. Wenn die strategischen Interessen eines Unternehmens von denen der Community abweichen, sind Reibungen unvermeidlich. Der jüngste Trend, dass Unternehmenssponsoren die Lizenzen von Open-Source-Projekten ändern (Redis, Terraform, Elastic), zeigt, wie wackelig dieses Modell sein kann.

Wann Forks gesund sind

Ein Fork, also eine konkurrierende Kopie eines Projekts, gilt oft als Zeichen des Scheiterns. Dabei ist er in der Open-Source-Welt das ultimative Sicherheitsventil. Wenn die Führung versagt, kann die Community ohne die ursprünglichen Maintainer weitermachen.

Der io.js-Fork von Node.js drängte Node in Richtung eines offeneren Governance-Modells und schnellerer Release-Zyklen. Als die Projekte wieder zusammenfanden, profitierte Node davon. LibreOffice, abgespalten von OpenOffice.org, rettete das Projekt vor dem schwindenden Interesse von Sun/Oracle. MariaDB, nach der Übernahme durch Oracle von MySQL abgespalten, lebt als community-getriebene Alternative weiter.

In jüngerer Zeit haben Lizenzänderungen produktive Forks ausgelöst. Als Elastic die Lizenz von Elasticsearch änderte, forkte Amazon es als OpenSearch. Als HashiCorp die Lizenz von Terraform änderte, forkte die Community es als OpenTofu unter der Linux Foundation. Diese Forks existieren, weil das Recht zu forken die letzte Kontrollinstanz der Community gegenüber der Projektführung ist.

Entscheidend ist, dass Forks am besten funktionieren, wenn sich die Community sauber aufteilt, nicht nur der Code. Ein Fork mit aktiven Maintainern und Rückhalt in der Community gedeiht. Ein Fork eines einzelnen frustrierten Entwicklers, dem niemand folgt, stiftet nur Verwirrung.

Die Burnout-Spirale

Die meisten Führungskrisen in Open-Source-Projekten beginnen nicht mit einem dramatischen Abgang. Sie beginnen mit Burnout, der langsamen Erosion der Kapazität und Begeisterung eines Maintainers unter dem Gewicht von Issues, Pull Requests, Feature-Wünschen und anspruchsvollen Nutzern.

Die Dynamik ist vorhersagbar. Ein Maintainer baut etwas Nützliches. Nutzer kommen. Mit ihnen kommen Bug-Reports, Feature-Wünsche, Supportfragen und Forderungen. Der Maintainer, der sich verantwortlich fühlt, versucht, auf alles zu antworten. Das Volumen übersteigt seine Kapazität. Er fängt an, vor seinen Benachrichtigungen zu grauen. Er antwortet langsamer, dann knapper, dann gar nicht mehr. Irgendwann verschwindet er, und das Projekt geht in eine Phase der Zombie-Wartung über: technisch noch am Leben, praktisch verlassen.

Burnout bei Open-Source-Maintainern ist kein persönliches Versagen. Es ist ein strukturelles Problem: Projekte erzeugen eine unbegrenzte Nachfrage nach der Zeit und Aufmerksamkeit einer begrenzten Zahl von Menschen, ohne eingebauten Mechanismus, diese Nachfrage zu steuern.

Manche Maintainer haben Wege gefunden, damit umzugehen: klare Grenzen für Antwortzeiten, die Delegation der Triage an Community-Mitglieder, bezahlte Wartung über GitHub Sponsors oder Open Collective oder einfach die Bereitschaft, längere Antwortzeiten in Kauf zu nehmen. Das erfordert allerdings, dem Druck bewusst zu widerstehen, ständig erreichbar zu sein, und das widerspricht der Kultur vieler Open-Source-Communities.

Wie eine gesunde Nachfolge aussieht

Ein paar Projekte haben Führungswechsel gut gemeistert, und sie teilen gemeinsame Muster.

• Verteiltes Wissen, nicht nur verteilter Code. Das „Stammeswissen“ des Projekts, also warum bestimmte Entscheidungen getroffen wurden, welche Alternativen geprüft wurden und welche Designprinzipien gelten, wird dokumentiert und steckt nicht nur im Kopf einer Person. Architecture Decision Records (ADRs) und ausführliche RFCs dienen diesem Zweck.
• Mehrere Personen mit Commit-Rechten und Release-Befugnis. Wenn nur eine Person einen Release schneiden kann, ist diese Person ein Single Point of Failure. Gesunde Projekte haben mindestens 3–5 Leute, die unabhängig neue Versionen veröffentlichen können.
• Explizite Governance-Dokumente. Wie werden Entscheidungen getroffen? Wer hat in welchem Bereich das Sagen? Wie werden neue Maintainer aufgenommen? Projekte, die diese Fragen vor einer Krise beantworten, bewältigen Nachfolge besser als solche, die improvisieren.
• Schrittweise Übergänge statt plötzlicher Abgänge. Die besten Führungswechsel passieren, wenn die scheidende Führungsperson ihr Engagement über Monate bewusst reduziert, Nachfolger coacht und Verantwortung ausdrücklich übergibt. Abrupte Abgänge, auch gut gemeinte, hinterlassen Lücken.
• Finanzielle Nachhaltigkeit. Projekte mit verlässlicher Finanzierung (über Stiftungen, Unternehmenssponsoren oder Community-Förderung) überstehen Übergänge besser, weil neue Maintainer für ihre Zeit bezahlt werden können. Jemandem einen unbezahlten Vollzeitjob zu übergeben, ist ein schwieriger Verkauf.

Was Nutzer und Unternehmen tun sollten

Wenn Ihr Geschäft von Open-Source-Software abhängt, und das tut es, haben Sie ein Interesse an der Gesundheit der Projekte, auf die Sie sich verlassen. Ein paar praktische Schritte:

1. Prüfen Sie Ihren Bus Factor bei Abhängigkeiten. Schauen Sie sich die kritischen Open-Source-Projekte in Ihrem Stack an. Wie viele aktive Maintainer haben sie? Wann war der letzte Release? Wie schnell werden Sicherheitslücken behoben? Ein Projekt mit einem Maintainer und einer sechs Monate alten Sicherheitslücke ist ein Risiko, von dem Sie wissen sollten.
2. Finanzieren Sie, was Sie nutzen. Wenn ein Projekt für Ihr Geschäft entscheidend ist, unterstützen Sie seine Finanzierung. GitHub Sponsors, Open Collective und Tidelift bieten dafür Mechanismen. Die Kosten für einen bezahlten Maintainer sind verschwindend gering verglichen mit den Kosten, wenn eine kritische Abhängigkeit unbetreut wird.
3. Beitragen Sie upstream. Bugfixes, Verbesserungen der Dokumentation und Issue-Triage entlasten die Maintainer und verschaffen Ihrem Team Vertrautheit mit der Codebasis. Falls das Projekt jemals neue Maintainer braucht, sind Sie bestens positioniert, einzuspringen.
4. Haben Sie einen Notfallplan. Wissen Sie bei kritischen Abhängigkeiten, was Sie tun würden, wenn das Projekt aufgegeben wird? Können Sie es forken und selbst pflegen? Gibt es eine Alternative, zu der Sie migrieren könnten? Die Zeit, diese Fragen zu beantworten, ist, bevor Sie sie brauchen.

Open-Source-Governance ist keine glamouröse Arbeit. Sie bringt keine Schlagzeilen und keine GitHub-Sterne. Doch der Unterschied zwischen einem Projekt, das den Abgang seines Gründers übersteht, und einem, das es nicht tut, liegt fast immer in der Governance: der unscheinbaren, strukturellen Arbeit, Entscheidungen zu dokumentieren, Verantwortung zu verteilen und die Nachfolge zu planen. Die Projekte, die bleiben, sind die, die Institutionen aufbauen, nicht nur Software.