Wer bezahlt Ihre Open-Source-Maintainer? Die Lieferketten-Frage, die der Einkauf nie stellt
Jeden kommerziellen Anbieter prüfen Sie akribisch. Die Finanzierung der Open-Source-Bibliotheken, auf denen Ihr gesamter Stack ruht, prüfen Sie gar nicht. Diese Lücke wird teurer.
Ihr Einkauf kann Ihnen sagen, wem Ihr CRM-Anbieter gehört, wo dessen Daten liegen und was mit Ihrem Vertrag passiert, falls das Unternehmen übernommen wird. Fragen Sie dasselbe Team, wer den Maintainer einer kleinen Parser-Bibliothek bezahlt, die drei Ebenen tief in Ihrem Build vergraben ist, und Sie ernten ratlose Blicke. Stellen Sie sich diese eine Bibliothek stellvertretend für die Dutzenden vor, die Sie ausliefern, ohne je darüber nachzudenken. Keine Bestellung, keine Unterschrift, kein Kundenbetreuer. Sie kam kostenlos, also bekam sie nie eine Zeile in der Risikomatrix.
Das ist der Fehler. Die Bibliothek ist für Sie kostenlos und für die Herstellung teuer. Jemand verbringt seine Abende, zunehmend auch seine bezahlten Werktage damit, sie am Leben zu halten. Folgen Sie diesem Gehalt, und Sie stoßen auf die eigentliche Frage, die sich hinter Ihrem Abhängigkeitsbaum verbirgt.
Warum ist die Finanzierung eines Open-Source-Projekts ein Lieferkettenrisiko?
Das übliche Modell von Open-Source-Risiko dreht sich um Code. Gibt es eine bekannte Schwachstelle? Ist die Lizenz kompatibel? Ist das Projekt verwaist? Alles berechtigte Fragen, alle mit einem Scanner zu beantworten. Sie teilen eine Annahme: Die Gefahr steckt im Artefakt, das Sie bereits haben.
Die Gefahr, die ein Scanner übersieht, steckt in den Menschen, die entscheiden, was die nächste Version enthält. Eine Abhängigkeit ist ein Strom künftiger Entscheidungen derjenigen, die Commit-Rechte halten, und diese Entscheidungen haben Einflussfaktoren. Einer der größten: wer die Person bezahlt, die sie trifft.
Jahrelang lautete die ehrliche Antwort auf „Wer bezahlt“ schlicht „Niemand, und man sieht es.“ Ein einzelner unbezahlter Maintainer, ausgebrannt, flickt eine Bibliothek, auf der das halbe Internet läuft. Das war ein Ressourcenproblem mit einer naheliegenden Lösung: diese Leute endlich bezahlen.
Sie werden inzwischen bezahlt, nur nicht von Ihnen. Das verlagert das Problem, statt es zu lösen.
Wenn der Geldgeber nicht der Nutzer ist
So funktioniert der Mechanismus. Kommt das Einkommen eines Maintainers von den Nutzern, die auf die Software angewiesen sind, zeigt der Anreiz auf Stabilität. Wer kaputt macht, worauf diese Nutzer sich verlassen, dem versiegt das Geld. Die Rückkopplungsschleife ist eng und begünstigt diejenigen, die den Code produktiv betreiben.
Kommt das Einkommen von einer Stiftung, einem Unternehmensprogramm oder einem staatlich finanzierten Stipendium, wird diese Schleife umgeleitet. Wer den Scheck ausstellt, hat Prioritäten, und die stehen ihm zu: Sicherheit, Nachhaltigkeit, Community-Gesundheit, digitale Souveränität, was auch immer das Mandat vorsieht. Diese Prioritäten werden zum Roadmap-Input für eine Abhängigkeit, auf der tausende Unternehmen aufbauen, und keines dieser Unternehmen wurde gefragt, weil keines mehr Kunde ist.
Das sind reale Institutionen mit veröffentlichten Mandaten, und es lohnt sich, sie zu lesen. Der deutsche Sovereign Tech Fund, gefördert vom Bundeswirtschaftsministerium, investiert im öffentlichen Interesse in offene digitale Infrastruktur und hat unter anderem in curl, OpenSSL, GnuPG, PHP, systemd und Teile des Rust-Ökosystems investiert. Alpha-Omega, ein Projekt der OpenSSF unter dem Dach der Linux Foundation, finanziert von Microsoft, Google und Amazon, will die Sicherheitslage kritischer Projekte verbessern und hat die Python Software Foundation, die Rust Foundation, Node.js und die Eclipse Foundation gefördert. Legt man beide Mandate nebeneinander, ist das Muster klar: Sicherheit, Resilienz, Souveränität. Alles vernünftige Ziele. Es sind aber auch die Ziele von jemandem, nicht Ihre, und sie hängen an genau den Bibliotheken am Boden Ihres Stacks.
Institutionelle Finanzierung von Maintainern ist unterm Strich eine gute Entwicklung. Unterbezahlte kritische Infrastruktur ist ein schlechterer Weltzustand als finanzierte kritische Infrastruktur. Doch wer bezahlt, bestimmt die Agenda, und sobald der Geldgeber nicht mehr der Nutzer ist, driftet die Agenda weg von der Betriebszeit des Nutzers hin zum Mandat des Geldgebers, ganz gleich, wie gut dieser es meint. Diese Drift taucht in keinem Dependency-Scan auf. Auch das gehört zur Ehrlichkeit: Es handelt sich um einen Mechanismus, den man antizipieren sollte, hergeleitet aus Anreizen, nicht aus einer bereits vorliegenden Akte, die Sie einem Skeptiker in die Hand drücken könnten. Der Grund, ihn im Blick zu behalten, ist simpel: Die Anreize laufen bereits in diese Richtung.
Gab es schon einmal eine Prioritätsverschiebung im Upstream, die Downstream-Teams getroffen hat?
Ja, oder zumindest liest sich eine Episode so, und OpenSSL ist dafür die schärfste Illustration, als Illustration gemeint, nicht als Beweis. Nachdem der Heartbleed-Bug 2014 offenlegte, wie dünn die Bibliothek ausgestattet war, floss über die Core Infrastructure Initiative der Linux Foundation, getragen unter anderem von Amazon, Google, IBM, Intel und Microsoft, ernsthaftes institutionelles Geld hinein. Finanziert und neu aufgestellt, verfolgte das Projekt eine grundlegende Neuarchitektur, die 2021 als OpenSSL 3.0 erschien, komplett mit einem neuen „Providers“-System und einem FIPS-Modul, das gezielt auf compliance-getriebene Nutzer zielte. Das Upgrade strich zudem eine lange Liste von APIs und brachte Performance-Regressionen mit, an deren Diagnose und Umgehung nachgelagerte Projekte monatelang arbeiteten. Niemand handelte böswillig. Der Ablauf ist dokumentiert; dass Geldgeber-Prioritäten ihn geprägt haben, ist meine Lesart, nicht die der Akte. Ein compliance-orientierter Funktionsumfang, der zeitgleich mit einer finanzierten Neuorganisation auftaucht, ist mit dieser Lesart zumindest vereinbar, und die Migrationsrechnung zahlten alle nachgelagerten Teams.
Vom Ad-hoc-Zuschuss zum systemischen Einflussfaktor
Ausmaß und Struktur sind der Grund, das jetzt zur Sprache zu bringen. Früher war die Finanzierung von Maintainern gelegentlich und persönlich: ein Trinkgeld-Button, eine einmalige Zuwendung, ein Unternehmen, das das eigene Tool sponsert, auf das sein Team angewiesen ist. Gelegentliche Finanzierung kauft gelegentlichen Einfluss, und das ist Rauschen, das Sie ignorieren können.
Das Geld ändert seinen Charakter. Unternehmensprogramme, philanthropische Stiftungen und staatlich unterstützte Initiativen behandeln zentrale Bibliotheken zunehmend als öffentliche Infrastruktur, die eine mehrjährige Förderung wert ist. Die wahrscheinliche Entwicklung, und das ist eine Projektion, keine feststehende Tatsache, richtet strukturiertes Geld genau auf die Maintainer grundlegender Ökosysteme: die Laufzeitumgebungen und Standardbibliotheken, auf denen alles andere aufbaut. Erreicht das Geld die Basis des Stacks statt nur seine Ränder, hört das Mandat eines Geldgebers auf, Rauschen zu sein, und beginnt, sich nach oben durch alles fortzupflanzen, was darauf aufbaut.
Je länger Sie vorhaben, Ihren heutigen Stack zu betreiben, desto mehr setzen Sie auf Upstream-Prioritäten, die in den kommenden Jahren von Leuten festgelegt werden, deren Anreize Sie nie geprüft haben.
Wie führt man Due Diligence für eine Abhängigkeit durch, die man nie eingekauft hat?
Ein Open-Source-Projekt lässt sich nicht wie einen Lieferanten prüfen. Es gibt keinen Vertrag, keinen Kundenbetreuer, keine Gutschrift, wenn etwas schiefgeht. Ein fehlender Vertrag spricht aber für eine andere Art von Sorgfalt, nicht für gar keine.
Beginnen Sie bei den Maintainern Ihrer wirklich tragenden Abhängigkeiten, der Handvoll, deren plötzlicher Richtungswechsel tatsächlich wehtun würde. Stellen Sie für jede drei einfache Fragen. Wer finanziert derzeit die wichtigsten Maintainer? Was ist das erklärte Mandat dieses Geldgebers? Und was ist Ihr Ausweichplan, falls Mandat und eigener Bedarf auseinanderlaufen: ein Fork, den Sie selbst pflegen könnten, eine vendorisierte Kopie, die Sie einfrieren könnten, eine kommerzielle Alternative, die Sie kaufen könnten? Eine klare Landkarte Ihrer kritischen Abhängigkeiten und deren Governance aufzubauen ist mühsam, und sie wirkt nur so lange verzichtbar, bis zu der Woche, in der sie es nicht mehr ist.
Dieselbe Disziplin beißt härter zu, sobald Ihre Systeme beginnen, eigenständig zu handeln. Sobald agentische Systeme reale Handlungsvollmacht übernehmen, erben die Open-Source-Komponenten darin jedes Governance-Risiko, das hinter ihren Maintainern steht, und sie erben es in Maschinengeschwindigkeit. Eine Prioritätsverschiebung, die Sie früher von Hand hätten abfedern können, wird zu einer, die Ihre Automatisierung durchreicht, bevor jemand das Changelog liest.
Nichts davon spricht dagegen, finanzierten Open-Source-Code zu nutzen; finanziert schlägt verwaist. Der richtige Schritt ist, ein Risiko zu bepreisen, das Sie derzeit kostenlos tragen. Code war nie das gesamte Risiko. Die Richtung bestimmt der Anreiz des Menschen, der ihn schreibt, und dieser Anreiz unterliegt inzwischen einem Geldgeber, den Sie nie getroffen haben.
Häufige Fragen
Sollten wir auf Open-Source-Projekte verzichten, die staatliche oder Unternehmensförderung annehmen?
Nein. Finanzierte Pflege ist in der Regel sicherer als unbezahlte, ausgebrannte Pflege. Entscheidend ist das Bewusstsein: Wissen Sie, wer Ihre tragenden Abhängigkeiten finanziert, und halten Sie einen Ausweichplan bereit für den Tag, an dem die Prioritäten des Geldgebers nicht mehr zu Ihren passen.
Wie finden wir heraus, wer einen bestimmten Open-Source-Maintainer finanziert?
Beginnen Sie bei den Förder- und Sponsoring-Seiten des Projekts selbst, seiner Trägerstiftung, falls vorhanden, sowie veröffentlichten Stipendien- oder Zuschussdaten. Gleichen Sie das mit den Maintainern ab, die tatsächlich Änderungen mergen. Wo das intransparent bleibt, behandeln Sie die Intransparenz selbst als Risikosignal.
Was unterscheidet Open-Source-Code-Risiko von Governance-Risiko?
Code-Risiko betrifft das Artefakt, das Sie bereits haben: Schwachstellen, Lizenzen, ob das Projekt gepflegt wird. Governance-Risiko betrifft künftige Entscheidungen: wer Commit-Rechte hält, wer diese Person bezahlt, und wessen Prioritäten die nächste Version formen. Scanner erfassen Ersteres und sind für Zweiteres blind.
Verwandte Artikel
- Auf Ubuntu 26.04 LTS ist das coreutils, von dem Ihr Build abhängt, nicht mehr GNU
- Die Souveränitätsprämie: Warum souveräne KI-Lösungen für Unternehmen nicht wegen Tempo gewinnen, sondern wegen Zugriffssicherheit
- Der Streit ums Geschäftsgeheimnis ist entschieden, lange bevor jemand kündigt. Fragen Sie Faccenda Chicken.
- Security & Trust
Verfasst von einer KI-Redaktionspersona des proprietären Redaktionssystems von Abyshire und von unserem Team geprüft.