• Entwicklung/Architektur
  • Methoden
  • Programmiersprachen
• Betrieb
  • Künstliche Intelligenz
    • Ein erster AI-Agent für die Softwarearchitektur: Qualitätsziele im Dialog
  • Datenbanken
  • IT-Security
  • Netzwerke
  • Virtualisierung
  • Verfügbarkeit
• Management und Recht
  • Projektmanagement
  • Digitalisierung
  • IT-Recht
  • IT-Selbständige
  • IT-Karriere
• Aktuelles
• Termine
• IT-Jobs

☰

• Entwicklung/Architektur
• Betrieb
• Management und Recht
• News
• IT-Jobs
• Newsletter

Antonino Zambito 28. Oktober 2026

Open Source ohne Wartung: Wem gehört eigentlich das Risiko?

Abhängig von wenigen

Wenn Maintainer wegfallen

Maintainer bleiben einem Projekt nicht immer erhalten. Interessen ändern sich, andere Aufgaben werden wichtiger oder es fehlt schlichtweg die Zeit. Bei kleinen Projekten kann damit ein großer Teil des Wissens und der Verantwortung wegbrechen. Wie häufig das vorkommt, zeigt die 2025 veröffentlichte Studie "Abandonment and Resilience: Understanding Core Developer Turnover in Open-Source Software“. Dafür untersuchten die Autoren 36.464 Open-Source-Projekte auf GitHub. Bei knapp 90 Prozent fiel mindestens einmal das zuvor ermittelte Kernentwicklerteam für mindestens ein Jahr aus. In 70 Prozent dieser Fälle geschah das bereits innerhalb der ersten drei Jahre. Nur 27 Prozent fanden später wieder einen neuen Entwickler, der eine vergleichbar zentrale Rolle übernahm [2]. 

Wie schwierig eine Nachfolge werden kann, lässt sich bei XZ Utils sehen. Schon 2022 schrieb Lasse Collin auf der Mailingliste des Projekts, dass seine Möglichkeiten, sich um XZ zu kümmern, begrenzt seien. Er bezeichnete XZ als unbezahltes Hobbyprojekt und suchte nach weiteren Maintainern. Wenige Wochen später schrieb Collin, dass sich ein Co-Maintainer oder Nachfolger nicht einfach finden lasse. Die Person müsse die nötigen Fähigkeiten, Zeit und langfristiges Interesse mitbringen [3].

Was passiert, wenn diese Arbeit niemand übernimmt, zeigt Node Sass. Das Projekt verband Node.js mit der Sass-Implementierung LibSass und war lange ein verbreitetes Werkzeug im JavaScript-Umfeld. Im Juli 2024 erklärten die Entwickler Node Sass für beendet. Das letzte Release lag zu diesem Zeitpunkt bereits rund anderthalb Jahre zurück. Die verbliebenen Maintainer hätten nicht mehr genug Zeit, das Projekt weiter zu aktualisieren. Das npm-Paket wurde als veraltet markiert und das Repository archiviert. Anwender sollten auf Dart Sass wechseln [4].

Im Januar 2020 stand die Zukunft des in Rust geschriebenen Webframeworks Actix Web auf der Kippe. Nikolay Kim hatte sich entschieden, die Arbeit daran nicht fortzusetzen. Wenige Tage später schrieb er auf GitHub, dass viele Menschen von Actix abhingen. Die Repositories einfach zu löschen, wäre deshalb unfair. Kim übergab die Projektleitung an Yuki Okushi, der unter dem Namen JohnTitor bereits seit einem Jahr am Projekt mitarbeitete. Seine Hoffnung war, dass sich um Actix eine neue Entwicklergemeinschaft bilden würde. Und tatsächlich ging es mit Actix weiter. Auch 2026 wird das Projekt noch entwickelt, Pull Requests werden bearbeitet und neue Versionen veröffentlicht [5].

Ein Projekt muss nicht dauerhaft von einer einzelnen Person abhängen. Bei größeren Projekten können feste Governance-Strukturen regeln, wer Entscheidungen trifft, wie neue Maintainer hinzukommen und was passiert, wenn jemand seine Rolle abgibt. Die Cloud Native Computing Foundation, kurz CNCF, verlangt von ihren Graduated Projects dokumentierte Governance-Strukturen. Dazu gehören auch Wege, über die Contributor zu Committern oder Maintainern werden können. Die Projekte verwalten sich weiterhin selbst. Die CNCF ersetzt also nicht die Entwickler, bietet ihnen aber einen neutralen organisatorischen Rahmen und verschiedene Dienste für den Betrieb des Projekts [6].

Was die Wartungslücke bedeutet

Software verschwindet nicht, nur weil sie nicht mehr gepflegt wird. Sie läuft weiter und bleibt Bestandteil der Systeme, in denen sie eingesetzt wird. Gleichzeitig verändert sich ihre Umgebung. Eine Komponente, die heute problemlos funktioniert, kann deshalb irgendwann Anpassungen benötigen. Bleibt die Wartung aus, fehlen diese. Bei Sicherheitslücken wird das schnell kritisch. Wird eine Schwachstelle entdeckt, braucht es jemanden, der die Meldung entgegennimmt, sie bewertet und eine Korrektur entwickelt. Der Patch muss geprüft und als neue Version veröffentlicht werden. NIST weist darauf hin, dass Herkunft, Integrität, Support und Wartung vieler Open-Source-Projekte schwer einzuschätzen sind und sich von Projekt zu Projekt unterscheiden [7]. 

Soll das Projekt weitergeführt werden, müssen Zugriffs- und Veröffentlichungsrechte weitergegeben werden. Wie wichtig Vertrauen dabei ist, zeigte 2018 das npm-Paket event-stream. Ein neuer Maintainer übernahm die Pflege des weit verbreiteten Projekts und fügte später flatmap-stream als Abhängigkeit hinzu. Darin befand sich Schadcode, der gezielt die Bitcoin Wallet Copay angriff. npm beschrieb den Vorfall später als Social-Engineering-Angriff, bei dem der Angreifer die Maintainer-Rolle übernommen hatte [8].

Vom Projektproblem zum Unternehmensrisiko

Unternehmen bauen Open-Source-Komponenten in ihre Anwendungen und Infrastrukturen ein und übernehmen damit auch deren Abhängigkeiten. Endet die Wartung eines Projekts, stehen sie vor einem Problem. Eine Anwendung verwendet beispielsweise Framework A. Das benötigt Bibliothek B, die wiederum Bibliothek C einbindet. Bibliothek C ist damit eine indirekte Abhängigkeit. Endet die Wartung einer solchen Komponente, bleiben im Wesentlichen zwei Möglichkeiten: Die Komponente wird ersetzt oder die Wartung wird anders organisiert. Das kann durch eigene Patches geschehen oder durch einen externen Anbieter [9].

Red Hat macht das beispielsweise bei Paketen in Red Hat Enterprise Linux. Sicherheitskorrekturen aus neueren Upstream-Versionen werden teilweise auf ältere Versionen zurückportiert. Das kann auch dann geschehen, wenn die entsprechende Version vom ursprünglichen Projekt bereits nicht mehr unterstützt wird. Red Hat nennt als Beispiel PHP 5.3. Nachdem dessen Upstream Support 2014 ausgelaufen war, übernahm Red Hat einen später veröffentlichten Sicherheitsfix für die weiterhin ausgelieferten PHP-5.3-Pakete [10]. 

Dafür muss man allerdings erst einmal wissen, welche Komponenten im eigenen System stecken. Eine Software Bill of Materials, kurz SBOM, erfasst die Bestandteile einer Software und deren Beziehungen untereinander. Damit lassen sich auch Abhängigkeiten erkennen, die die eigene Anwendung nicht direkt verwendet [11]. Eine SBOM hilft dabei, Schwachstellen den betroffenen Komponenten zuzuordnen. Sie zeigt aber nicht, ob ein Projekt noch gepflegt wird, wie viele Maintainer daran arbeiten oder ob weitere Sicherheitsupdates erscheinen. Hinweise liefert unter anderem der OpenSSF Scorecard. Sein Check "Maintained" berücksichtigt, ob ein Repository archiviert wurde, wie regelmäßig in den vergangenen 90 Tagen Commits erfolgten und ob Maintainer oder andere Projektverantwortliche auf Meldungen reagieren [12]. Ein niedriger Wert bedeutet allerdings nicht automatisch, dass ein Projekt aufgegeben wurde. Manche Bibliotheken benötigen über längere Zeit schlicht keine Änderungen.

Wer trägt die Verantwortung?

Wer bezahlt die Wartung?

SUSE, dessen deutsche Gesellschaft ihren Sitz in Nürnberg hat, bietet für den SUSE Linux Enterprise Server, kurz SLES, den Long Term Service Pack Support. Damit können Unternehmen einzelne Service Packs bis zu drei Jahre über den regulären Wartungszeitraum hinaus einsetzen. SUSE liefert in dieser Zeit weiterhin Sicherheitsupdates und Fehlerkorrekturen. Unternehmen kaufen damit nicht einfach nur Unterstützung bei Problemen, sondern bezahlen dafür, dass eine bestimmte Softwarebasis für einen festgelegten Zeitraum weiter gepflegt wird. Denn die ursprünglichen Open-Source-Projekte können einzelne der enthaltenen Versionen zu diesem Zeitpunkt bereits aufgegeben haben [17]. Ähnliche Modelle gibt es auch bei anderen Enterprise-Distributionen wie Red Hat oder Ubuntu. 

Die Sovereign Tech Agency wird vom Bundesministerium für Digitales und Staatsmodernisierung finanziert und investiert in grundlegende Open-Source-Technologien. 2025 startete sie zusätzlich ein einjähriges Fellowship für Maintainer. Sechs Maintainer wurden dabei finanziell unterstützt und arbeiteten an 18 kritischen Basistechnologien. 2026 wurde das Programm fortgesetzt und erweitert. Neben Maintainern können sich inzwischen auch Community Manager und Technical Writer bewerben [18]. Unternehmen können ebenfalls versuchen, die vorhandene Wartung zu erhalten, bevor sie ausfällt. Das kann Geld bedeuten, aber genauso Entwicklerzeit, Tests, Dokumentation oder Beiträge zum Projekt. Ein Patch, der upstream aufgenommen wird, muss nicht dauerhaft nur im eigenen Fork gepflegt werden. Ein Maintainer, der für seine Arbeit bezahlt wird, hat möglicherweise mehr Zeit für das Projekt. Professioneller Support kann die Verantwortung für bestimmte Aufgaben vertraglich regeln. 

Ein freiwilliges Modell dafür ist der Open Source Pledge. Mitgliedsunternehmen verpflichten sich, jährlich mindestens 2.000 US-Dollar pro beschäftigtem Vollzeitentwickler direkt an Open-Source-Maintainer oder Foundations zu zahlen [19]. Welche Projekte sie unterstützen, dürfen die Unternehmen selbst entscheiden. Einmal im Jahr veröffentlichen sie, wie viele Entwickler sie beschäftigen, wie viel sie gezahlt haben und an wen das Geld ging. Der Open Source Pledge verwaltet die Zahlungen nicht. Die finanzielle Hilfe geht direkt an die ausgewählten Maintainer oder Organisationen. Eine direkte Verbindung zwischen der Zahlung und den eigenen Abhängigkeiten verlangt der Pledge nicht. Ein Unternehmen kann also auch Projekte unterstützen, die nichts mit seinen eigenen Produkten zu tun haben [19].

Fazit

Open Source verpflichtet niemanden dazu, ein Projekt für immer zu pflegen. Ein Unternehmen kann aber auch nicht voraussetzen, dass andere diese Arbeit für immer übernehmen. Spätestens wenn eine Komponente für den eigenen Betrieb unverzichtbar wird, wird aus dem Problem des Projekts ein eigenes Risiko. Wer eine Komponente langfristig braucht, muss sich deshalb auch damit beschäftigen, wer sie langfristig pflegt.

Autor