Open-Source-Förderung wird ideologisch: Ihr Stack wurde nicht gefragt
Wer die Basissoftware Ihres Unternehmens am Leben hält, verfolgt zunehmend eine eigene Agenda. Das macht aus Förderung einen Forking-Mechanismus, und die Frage „Auf welchem Zweig stehe ich eigentlich?“ kommt in keinem Risikoregister vor.
Die gefährlichste Annahme in Ihrem Stack ist, dass die langweiligen Teile für immer feststehen. In den vergangenen drei Jahren haben sich die Cache-Schicht, der Suchindex und das Infrastructure-as-Code-Werkzeug, Komponenten, auf die ganze Unternehmen sich verlassen haben, gerade weil sie unerschütterlich wirkten, jeweils in rivalisierende, separat finanzierte Zweige aufgespalten. Open-Source-Förderung galt lange als zu trocken, um sie zu hinterfragen. Heute entscheidet sie, welcher Zweig der eigenen Plattform überlebt, und niemand hat der Einkaufsabteilung Bescheid gegeben.
Zuerst die Infrastrukturschicht. Im August 2023 wechselte HashiCorp Terraform und seine übrigen Flaggschiff-Tools von der offenen Mozilla Public License zur Business Source License, die Wettbewerbern den Produktiveinsatz untersagt. Innerhalb weniger Tage veröffentlichten Firmen, deren Produkte auf Terraform aufbauen, das OpenTofu-Manifest, und im September fand der Fork ein Zuhause bei der Linux Foundation, deren Träger sich verpflichteten, mindestens fünf Jahre lang Vollzeit-Entwickler dafür abzustellen. Terraforms Lizenz und Terraforms Community residieren jetzt in unterschiedlichen Häusern.
Beim Cache lief dasselbe Spiel schneller ab. Im März 2024 gab Redis die permissive BSD-Lizenz auf, die seit der allerersten Version galt, zugunsten dualer Source-Available-Bedingungen. Innerhalb weniger Tage kündigte die Linux Foundation Valkey an, einen Fork des letzten BSD-Releases, mit AWS, Google Cloud und Oracle unter den Trägern. Vierzehn Monate später fügte Redis 8 die AGPLv3 wieder hinzu, eine von der OSI anerkannte offene Lizenz.
Der Suchindex durchlief den vollständigen Bogen als Erster. Elastic relizenzierte Elasticsearch und Kibana weg von Apache 2.0, im Januar 2021, ein Schritt, der gezielt gegen AWS gerichtet war. AWS reagierte, indem es beide als OpenSearch forkte, heute untergebracht in einer eigenen Foundation unter dem Dach der Linux Foundation. Im August 2024 fügte Elastic die AGPLv3 hinzu und erklärte: Elasticsearch ist wieder Open Source.
Der Rückzug ist der eigentliche Hinweis. Gleich zweimal hat ein relizenziertes Original seine offene Lizenz wiederhergestellt, nachdem sein Fork institutionelles Geld gefunden hatte. Keines der beiden Unternehmen bezeichnet diese Abfolge als Kapitulation, und der kausale Zusammenhang ist eine Schlussfolgerung dieser Redaktion, nicht etwas, das in einer Mitteilung stünde. Doch wenn geförderte Forks nicht als Druckmittel funktioniert hätten, ist schwer zu sagen, wofür diese Kehrtwenden sonst gut gewesen sein sollen.
Woher kommt Open-Source-Förderung heute eigentlich?
Die alte Antwort deckt weiterhin den Großteil des Geldes ab: Hersteller, die Maintainer fest anstellen, und Foundations, die Unternehmensbeiträge bündeln, beides belohnt grob kommerzielle Relevanz. Das neue Geld ist nicht einheitlich. Mindestens drei unterschiedliche Motivationen schreiben inzwischen Schecks, und sie wollen jeweils eine andere Welt.
Erstens: defensives Konsortialgeld. Unternehmen finanzieren einen Fork, weil ihre eigenen Produkte auf Bedingungen angewiesen sind, die das Original aufgegeben hat. Genau das ist Valkeys Trägerliste, und das sind OpenTofus Fünf-Jahres-Zusagen für Entwicklerkapazität. Hier braucht es keine Interpretation, die Foundation-Ankündigungen nennen das Motiv unverblümt. Die Geldgeber schützen ihre eigene Versorgungskette.
Zweitens: staatliche Souveränitätsprogramme. Die Sovereign Tech Agency, finanziert über das Bundesministerium für Wirtschaft und Klimaschutz, bezahlt die Pflege von Komponenten, für die sonst kaum jemand aufkommt. Ihr veröffentlichtes Investitionsportfolio wies Anfang 2025 mehr als 23 Millionen Euro aus, verteilt auf über 60 grundlegende Technologien seit Beginn der Förderung Ende 2022, darunter curl und WireGuard, ausdrücklich im Namen der europäischen digitalen Souveränität. Eine Geldgeberklasse, die es vor fünf Jahren noch nicht gab, weist mittlerweile achtstellige Ausgaben aus, und sie kommt, für deutsche Leser durchaus bemerkenswert, aus dem eigenen Haushalt.
Drittens: Werte-Patronage, älter als beide anderen Formen und meist kleiner dimensioniert. Devuan pflegt einen systemd-freien Debian-Fork, seit Debians technisches Komitee 2014 systemd einführte, getragen von Spenden, um die es genau für diese Unabhängigkeit wirbt. XLibre forkte im Juni 2025 den X.Org-Display-Server und positioniert sich gegenüber Freiwilligen und Förderern als Zuflucht vor der Upstream-Governance. Und die GPL-lizenzierten GNU Coreutils, seit den frühen 1990ern im GNU-Projekt beheimatet, konkurrieren heute mit uutils, einer MIT-lizenzierten Rust-Neuimplementierung, 2013 begonnen und heute geleitet von Sylvestre Ledru, die Ubuntu 25.10 im vergangenen Oktober als Standard auslieferte. Ob die Geldgeber dieser Projekte Governance-Widerspruch finanzieren oder schlicht die Software bevorzugen, lässt sich mangels Spenderbefragung nicht belegen, ihre eigenen Aufrufe argumentieren mit Prinzipien, und diese Redaktion liest das Geld entsprechend, als Vermutung, nicht als Beleg.
Bemerkenswert: Die drei Geldgeberklassen teilen keine gemeinsame Wunschzukunft. Konsortialgeld will Kontinuität der Bedingungen. Souveränitätsgeld will weniger, dafür besser gepflegte gemeinsame Komponenten. Patronage-Geld hält Widerspruch am Leben. Sie ziehen in unvereinbare Richtungen, jede bereit, ihre Richtung auf unbestimmte Zeit zu finanzieren, und von „Open-Source-Förderung“ zu sprechen, als handle es sich um einen einzigen Geldstrom, ist genau die Stelle, an der sich das Risiko versteckt.
Warum werden relizenzierte Projekte immer wieder geforkt?
Weil die Forks nicht mehr verhungern. Solange Geld dem kommerziellen Nutzen folgte, fehlte der unterlegenen Seite einer Spaltung meist die Kapitalausstattung, um zu bestehen, sodass sich Streitfragen von selbst erledigten. Heute findet ein glaubwürdiger Fork womöglich einen Förderer, dessen Interesse einzig darin besteht, dass der Fork existiert, sei es ein Hyperscaler, der einen Managed Service absichert, oder eine Spenderbasis, die für Unabhängigkeit zahlt. Devuan belegt seit über einem Jahrzehnt, wie beständig kleine Patronage sein kann, Valkey hat innerhalb von zwei Wochen gezeigt, wie schnell große Patronage wirkt. Die Überlebensfähigkeit eines Forks war früher eine Frage der Entwicklungskapazität. Nach der Lesart dieser Redaktion wird sie zunehmend zu einer Frage, wer bereit ist zu zahlen, und warum.
Daraus ergibt sich eine Kontinuitätsfrage, die kaum eine Einkaufs-Checkliste enthält: Auf welchem geförderten Zweig einer Komponente stehen wir eigentlich, und wer hat das entschieden? Sie haben Ihren Zweig vermutlich nicht selbst gewählt. Ihre Distribution oder Ihr Cloud-Anbieter hat ihn für Sie gewählt, und diese wechseln die Seiten: Der Coreutils-Wechsel bei Ubuntu stand in einer Release-Ankündigung, nicht in Ihrem Change-Log.
Was sollte Ihre Due-Diligence jetzt fragen?
Behandeln Sie den geförderten Zweig, nicht den Projektnamen, als Analyseeinheit. Für jede tragende Komponente: Auf welchem Zweig stehen wir, und aufgrund wessen Entscheidung? Wer finanziert ihn, und was will diese Partei? Was passiert, wenn der Hauptförderer sich zurückzieht oder die Lizenz erneut wechselt? Fließen Sicherheitskorrekturen zwischen den Zweigen, und wie schnell? Und was würde ein Wechsel auf den Geschwisterzweig kosten, sollte unsere Seite des Forks den Kürzeren ziehen?
Nichts davon steht in einer Software Bill of Materials, die verzeichnet, was Sie einsetzen, nicht wer dafür bezahlt, dass es weiterexistiert. Das nachzuzeichnen ist unglamouröse Abhängigkeitsarbeit, genau das, wofür eine bewusste technische Strategie gedacht ist, bevor daraus ein Vorfall wird, und etwas, das eine unabhängige Prüfung schneller aufdeckt als ein internes Team, das die Basisschicht immer für das Problem von jemand anderem gehalten hat.
Die Allmende, auf der Ihr Unternehmen aufbaut, gibt es noch. Sie ist nur längst nicht mehr eine einzige Sache, und wer für ihre Teile bezahlt, will nicht mehr dieselbe Zukunft. Finden Sie heraus, wessen Zukunft Sie standardmäßig finanzieren. Und entscheiden Sie dann, ob Sie das wirklich wollen.
Häufige Fragen
Wie finde ich heraus, wer ein Open-Source-Projekt finanziert, von dem mein Unternehmen abhängt?
Beginnen Sie bei der Governance-Seite des Projekts, seiner Foundation-Mitgliedschaft und einer eventuell veröffentlichten Sponsorenliste, prüfen Sie dann, wer die aktivsten Maintainer beschäftigt, denn Anstellung ist die stillste Form der Förderung. Lässt sich das nicht klären, gehört diese Intransparenz selbst auf Ihr Risikoregister.
Ist es riskant, sich auf einen Fork eines Open-Source-Projekts zu verlassen?
Nicht grundsätzlich. Ein Fork mit verlässlicher Finanzierung, mehreren aktiven Maintainern und einem funktionierenden Sicherheitsprozess kann sicherer sein als ein vernachlässigtes Original. Das eigentliche Risiko liegt in Übergangsphasen, wenn Korrekturen in einem Zweig landen und den anderen langsam oder gar nicht erreichen. Beurteilen Sie deshalb jeden Zweig nach seiner operativen Praxis, nicht danach, auf welcher Seite der Debatte er steht.
Sollte mein Unternehmen die Open-Source-Software finanziell fördern, die es einsetzt?
Wenn der Ausfall einer Komponente Ihr Produkt lahmlegen würde, ist die Finanzierung ihrer Maintainer keine Wohltätigkeit, sondern günstige Absicherung. Ein kleiner Anteil des Umsatzes, der stromaufwärts fließt, kauft Frühwarnung, Einfluss und Wohlwollen. Nur sollten Sie wissen: In der aktuellen Lage ist Ihr Geld auch eine Stimme für ein bestimmtes Governance-Modell, ob Sie das beabsichtigen oder nicht.
Verwandte Artikel
- Epic gegen Google: Die App-Katalog-Klausel, die Google seinen Rivalen den Burggraben schenkt
- Speicherpreise haben gedreht: Verhandeln Sie den Liefervertrag neu, bevor der nächste Refresh ansteht
- Wie KI schlechte Chefs noch schlimmer macht: Die Ja-Sager-Maschine im Chefbüro
- Digital Business
Verfasst von einer KI-Redaktionspersona des proprietären Redaktionssystems von Abyshire und von unserem Team geprüft.