gustavofrazao - stock.adobe.com
Warum Open-Source-Software mehr Unterstützung benötigt
Open-Source-Software bildet die Grundlage für Unternehmenssysteme, doch eine unzureichende Finanzierung gefährden deren Stabilität. IT-Verantwortliche müssen hier handeln.
Open Source ist noch nie so stark in Unternehmenssystemen verankert gewesen wie heute.
Sie läuft in Entwickler-Tools, Deployment-POipelines, Datenverarbeitungs-Stacks, Ingress-Schichten und internen Plattformen. Diese Abhängigkeit ist nicht neu. Was sich geändert hat, ist die zunehmende Belastung, die dadurch auf die Menschen hinter den Projekten lastet.
In diesem Artikel untersuchen wir die Herausforderungen, denen Open-Source-Projekte gegenüberstehen, sowie die Frage, wie Unternehmen, die auf diese Projekte angewiesen sind, sich besser vorbereiten und verantwortungsbewusster mit Open Source umgehen können.
Open Source hat ein Nutzungsproblem. Ein Großteil der Open-Source-Nutzung in Unternehmen ist nach wie vor eine einseitige Transaktion. Unternehmen laden Pakete herunter, entwickeln kommerzielle Produkte und melden Probleme. Von den Maintainern wird dann erwartet, dass sie die Support-Last für wenig oder gar kein Geld bewältigen. Viele äußerst beliebte Projekte werden nach wie vor in der Freizeit von Freiwilligen gepflegt. Abgesehen von der Frage der Fairness ist dies auch ein großes Risiko für Unternehmen, die für ihre kommerziellen Produkte auf diese Projekte angewiesen sind.
Eine Geschichte von drei Open-Source-Projekten
In den letzten zwei Jahren wurde Ingress-Nginx, ein bedeutendes Kubernetes-Projekt, eingestellt, FFmpeg gab bekannt, dass der Sovereign Tech Fund die Aufrechterhaltung der Wartung übernimmt, und Flux zeigte, dass ein Projekt wieder Fuß fassen kann, wenn Unternehmen einspringen. Diese Beispiele zeigen, dass es beim Open-Source-Risiko nicht nur um Codequalität oder häufige Sicherheitslücken und Schwachstellen geht, sondern auch um die Menschen hinter dem Code und darum, ob sie die Arbeit weiterhin leisten können.
1. Ingress-Nginx wird nicht mehr gepflegt
Ingress-Nginx gilt in vielen Cloud-nativen Umgebungen als unverzichtbare Infrastruktur. Die CNCF gab im November 2025 bekannt, dass die Best-Effort-Wartung nur noch bis März 2026 fortgesetzt werde; danach werde es keine Releases, Bugfixes oder Sicherheitsupdates mehr geben. In dem Post zur Einstellung von Ingress-Nginx wird erwähnt, dass das Projekt nur zwei Personen hatte, die in ihrer Freizeit nach der Arbeit und an den Wochenenden Entwicklungsarbeit leisteten. Dies ist kein Einzelfall. Es ist ein Versagen in der Governance und Personalpolitik.
„Es gab zwei Personen, die für die Wartung von etwas verantwortlich waren, auf das 50 Prozent der Cloud-nativen Umgebungen direkt angewiesen sind, und niemand wollte ihnen helfen“, sagt Cosgrove.
2. FFmpeg erhält neue Unterstützung
FFmpeg ist ein Projekt, auf das sich viele große Organisationen verlassen, um täglich Milliarden von Menschen mit Audio- und Videodaten zu versorgen. Im Jahr 2024 verlangsamte sich die Entwicklung des Projekts kurzzeitig, da die Maintainer warnten, dass die laufende Arbeit nicht nachhaltig sei. Bald darauf gaben sie bekannt, dass der deutsche Sovereign Tech Fund der erste staatliche Sponsor des Projekts geworden war. Das war eine knappe Sache, und in der Entwicklerdokumentation von FFmpeg werden die Nutzer nach wie vor gebeten, die Projekte zu unterstützen, auf die sie sich verlassen, damit diese Projekte weiterhin gepflegt und weiterentwickelt werden.
„Wir sind sehr gut in der Analyse von Lieferketten geworden. Ich denke, es muss etwas Ähnliches für die Frage geben, wer diese Projekte finanziert. Gedeihen sie? Überleben sie? Haben sie eine Zukunft oder nicht?“, sagt Morgan.
3. Flux erhält konkrete Unterstützung aus der Industrie und verbessert seine Nachhaltigkeit
Im Januar 2024 gab Weaveworks, der Entwickler von Flux, bekannt, dass das Unternehmen den Betrieb einstellen werde, wodurch die Zukunft des Flux-Projekts in Gefahr geriet. Im März kündigte Flux jedoch eine verstärkte Unterstützung durch engagierte Unternehmen an, die sich zur weiteren Wartung und Entwicklung verpflichtet haben. Am 24. Februar 2026 veröffentlichte das Projekt Flux 2.8. Die Release-Notes verweisen Nutzer, die eine umfassendere Abwärtskompatibilität oder Unternehmensunterstützung benötigen, an Anbieter wie ControlPlane.
Das bedeutet nicht, dass die wirtschaftlichen Probleme für immer gelöst sind. Es zeigt jedoch, dass sich Projekte erholen können, wenn die Maintainer Unterstützung, Kontinuität bei den Releases und einen kommerziellen Weg rund um die Upstream-Codebasis haben.
„Jedes verantwortungsbewusste Unternehmen sollte sich aktiv mit dem Zustand der Open-Source-Projekte befassen, auf die es sich stützt. Wenn eine dieser Abhängigkeiten ungesund erscheint oder sich in diese Richtung entwickelt, sollte man ein oder zwei Entwickler ein paar Stunden pro Woche damit beauftragen, zu helfen“, sagte Cosgrove.
Sicherheitstransparenz allein reicht nicht aus
Unternehmen haben ihre Fähigkeit verbessert, Risiken in der Softwarelieferkette zu bewerten. Die OpenSSF Scorecard bietet eine automatisierte Sicherheitsbewertung für Open-Source-Projekte. Die OpenSSF Scorecard identifiziert, welche Projekte für das breitere Ökosystem am wichtigsten sind. Supply-Chain Levels for Software Artifacts (SLSA) definiert Kontrollen rund um die Integrität von Artefakten, und OpenSSF vertritt die Auffassung, dass Bescheinigungen eine zuverlässigere Herkunftsnachweisbarkeit und Validierung bieten als eine Software Bill of Materials (SBOM).
Doch diese Tools beantworten keine Fragen wie:
- Wer finanziert das Projekt?
- Wie viele Maintainer sind derzeit aktiv?
- Trägt ein einzelnes Unternehmen den gesamten Release-Prozess?
- Wird das Projekt noch in einem gesunden Rhythmus veröffentlicht?
- Gibt es einen Support-Plan, falls das Upstream-Team ausbrennt?
Unternehmen benötigen neben ihrer Sicherheitsüberprüfung auch eine Überprüfung des Projektzustands. Der Sinn dieser Maßnahme besteht darin, Schwachstellen früh genug zu erkennen, um handeln zu können, solange das Projekt noch reparabel ist.
Eine einfache interne Überprüfung kann mit einer kurzen Reihe von Checks für jedes verwendete Open-Source-Projekt beginnen:
- Anzahl der Maintainer und Vielfalt der Unternehmen.
- Release-Rhythmus in den letzten zwölf Monaten.
- Zeit bis zur Behebung wichtiger Bugs und Sicherheitsprobleme.
- Klarheit in der Governance und Verantwortung für die Roadmap.
- Verfügbarkeit von kommerziellem Support, Spenden oder Unterstützung durch eine Stiftung.
- Migrationsaufwand, falls das Projekt ins Stocken gerät oder eingestellt wird.
Entwickeln Sie einen Aktionsplan für das Management von Open Source
Führungskräfte müssen nicht jede Abhängigkeit gleichermaßen finanzieren. Sie benötigen jedoch eine klarere Strategie, als nur darauf zu hoffen, dass sich das Ökosystem von selbst regelt.
Ein sinnvoller Plan sieht so aus:
- Ordnen Sie Open-Source-Abhängigkeiten nach operativer Bedeutung, nicht nach der Anzahl der Pakete.
- Fügen Sie Projektzustandsprüfungen in denselben Überprüfungsprozess ein, der für Sicherheits- und Lizenzrisiken verwendet wird.
- Reservieren Sie Entwicklungszeit für Upstream-Korrekturen bei Projekten, die in engem Zusammenhang mit Umsatz, Verfügbarkeit oder Kundendaten stehen.
- Planen Sie Mittel für Support-Abonnements oder direkte Finanzierung ein, wenn stabile Releases und langfristige Wartung wichtig sind.
- Erstellen Sie frühzeitig Migrationspläne für Projekte, die bereits Anzeichen von Schwäche zeigen, insbesondere wenn der Ersatz kein einfacher Austausch ist.
Der Zustand von Open Source ist entscheidend
Früher war es in Unternehmen üblich, Open Source als kostenloses Inventar zu betrachten. Das lässt sich immer schwerer rechtfertigen. Einige Projekte bleiben stabil, weil Stiftungen, Anbieter und Mitwirkende die Arbeit am Laufen halten. Andere benötigen direktere Unterstützung. Wieder andere werden auslaufen, und die Kosten für die Migration werden bei den Organisationen landen, die davon ausgegangen sind, dass jemand anderes das Projekt am Leben erhält.
Die eigentliche Frage ist, ob Unternehmen verstehen, welche Projekte gesund sind, welche ins Abseits geraten und wo sie bereit sind, zu zahlen, Beiträge zu leisten oder zu migrieren, bevor aus der Warnung ein Ausfall wird.
Dieser Artikel ist im Original in englischer Sprache auf Search App Architecture erschienen.
