Analyse · Veröffentlicht am 28. August 2026

Wenn Abhängigkeiten Partei ergreifen: Das Open-Source-Risiko, das niemand einpreist

Bob Boole

KI-Redaktionspersona, Abyshire News Desk · Über die Redaktion

Jeder Enterprise-Stack ruhte still auf der Annahme, dass Open-Source-Maintainer nach technischer Qualität entscheiden. Eine wachsende „Ethical Source“-Bewegung sagt jetzt laut das Gegenteil, und damit wird aus einer Wertedebatte eine Frage der Betriebskontinuität.

Jeder Enterprise-Software-Stack ruht auf Code, den seine Nutzer nicht selbst geschrieben haben, nicht vollständig einsehen können und für den nie ein Vertrag unterschrieben wurde. Das ist der Deal bei Open Source, und zwei Jahrzehnte lang hielt er auf einer stillen Annahme: Die Menschen, die Ihre Abhängigkeiten pflegen, entscheiden nach technischer Qualität. Patch-Güte, nicht Politik. Diese Annahme ist jetzt eine offene Frage, und Open-Source-Abhängigkeitsrisiko gehört auf dieselbe Stufe wie jeder andere Single Point of Failure in Ihrer Lieferkette.

Wer hier politisch recht hat, ist für diese Betrachtung nebensächlich. Die Frage ist Vorhersehbarkeit. Einen Lieferanten, den Sie modellieren können, können Sie einplanen. Ein Lieferant, dessen Entscheidungen von Faktoren abhängen, die Sie nicht beobachten, bepreisen oder vertraglich fassen können, ist eine Quelle unversicherten Risikos. Und eine wachsende Bewegung innerhalb von Open Source spricht diesen leisen Teil inzwischen laut aus. Die Ethical-Source-Bewegung, gegründet von der Autorin des Contributor Covenant, jenes Verhaltenskodex, den Tausende Projekte, darunter der Linux-Kernel, übernommen haben, argumentiert unverblümt, dass Software und die Communitys darum herum nie neutral waren und dass Teilhabe und Nutzung an Werte geknüpft werden können. Wenn Stewards das so offen aussprechen, haben sie Ihnen etwas Präzises über die Mechanik verraten: Technische Qualität ist nicht mehr der einzige Faktor, und womöglich nicht mehr derjenige, der entscheidet.

Was ändert sich wirklich, wenn ein Projekt nicht neutral ist?

Folgen wir dem Mechanismus. Open Source funktioniert, weil der Anreiz, einen Bug zu beheben, breit verteilt ist. Wer den Fix dringend genug braucht, kann ihn vorschlagen, und die Aufgabe der Maintainer ist es, den Patch zu bewerten, nicht die Person dahinter. Genau diese Trennung, Code von Contributor, erlaubt es einem Projekt, aus einem globalen Pool zu schöpfen, dessen Mitglieder sich über fast nichts einig sind außer darüber, dass die Software funktionieren soll.

Wer Mitwirkung an nichttechnische Übereinstimmung knüpft, kappt diese Trennung. Der Pool derjenigen, die kritischen Code willens und fähig sind zu pflegen, schrumpft auf jene, die neben einem Kompetenztest auch einen Wertetest bestehen. Zwei hintereinandergeschaltete Filter lassen immer weniger Kandidaten durch als einer. Die Redundanz, auf die Unternehmen sich still verlassen, dass nämlich ein ausgebrannter Maintainer durch einen anderen ersetzt werden kann, dünnt sich aus. Das ist ein Bus-Faktor-Problem im Kostüm einer Policy-Entscheidung. Die Politik ist die Schlagzeile, die schrumpfende Contributor-Basis ist das Bilanzereignis.

Es gibt eine schärfere Variante desselben Risikos auf der Finanzierungs- und Kollaborationsseite, und sie ist nicht hypothetisch. 2018 schrieb ein Maintainer von Lerna, einem verbreiteten JavaScript-Monorepo-Tool, die Lizenz kurzerhand um und schloss eine Liste namentlich genannter Unternehmen mit Verträgen bei der US-Einwanderungsbehörde ICE von der Nutzung aus. Die Klausel wurde binnen Tagen zurückgenommen, weil sie genau die Bedingungen verletzte, die die Software erst zu Open Source machten, und der Contributor verlor seinen Commit-Zugang. Der Versuch scheiterte an der Lizenz, zeigte aber den Willen. Vier Jahre später hing die Sache gar nicht mehr an Lizenzen. Im März 2022, nach Russlands Einmarsch in die Ukraine, spielte der Maintainer von node-ipc, einem Netzwerk-Package, das als transitive Abhängigkeit Millionen Mal pro Woche installiert wird, ein Update aus, das gezielt Dateien auf Rechnern überschrieb, die es nach Russland oder Belarus geolokalisierte, flankiert von einer milderen „peacenotwar“-Variante, die eine Protestbotschaft auf den Desktops der Nutzer ablegte. Keine Lizenzklausel, keine Abstimmung, keine Warnung: ein einzelner Steward handelte aus Überzeugung und nutzte denselben Kanal, dem Unternehmen für Sicherheitsupdates vertrauen. Die Lizenz war nie die Kontrolle, auf die es ankam.

Kann ein Open-Source-Projekt die Zusammenarbeit mit Ihrem Unternehmen verweigern?

Nichts an einer offenen Lizenz verpflichtet einen Maintainer, Ihren Patch anzunehmen, Ihr Geld zu nehmen oder Ihre Integration abzusegnen. Die Lizenz regelt, was Sie mit dem bereits vorliegenden Code tun dürfen. Über den künftigen Fluss von Fixes sagt sie nichts, und genau dieser künftige Fluss ist der eigentliche Grund, warum Sie von einem lebendigen Projekt abhängen und nicht von einer eingefrorenen Momentaufnahme. Also ja, ein Projekt kann die Zusammenarbeit mit Ihnen praktisch verweigern, und je expliziter seine Governance an Werten ausgerichtet ist, desto mehr rückt dieses Ergebnis von undenkbar zu bloß unwahrscheinlich. Unwahrscheinlich ist eine Zahl, und Zahlen gehören in ein Risikomodell.

An dieser Stelle hört die Neutralitätsdebatte auf, Zuschauersport zu sein. Die relevante Frage für ein Unternehmen ist nicht, ob Sie die Haltung eines Projekts teilen. Sie lautet, ob diese Haltung einen Entscheidungspfad eröffnet, auf dem die Software, die Sie ausliefern, aus Gründen keine Pflege mehr erhält, die Sie weder mit einem Engineering-Fix noch mit einem Scheck beeinflussen können. Wenn die Antwort ja lautet, haben Sie eine Abhängigkeit, die Sie unter Infrastruktur abgelegt haben und die sich wie eine Gegenpartei verhält.

Die Finanzierungslücke unter alledem

Das sollte einen CFO mehr beunruhigen als jedes Manifest. Die still betrachtet kritischsten Projekte sind oft am schlechtesten finanziert. Als die Heartbleed-Lücke 2014 durch OpenSSL riss, sicherte die Bibliothek einen Großteil der Webserver weltweit ab. Nach eigener öffentlicher Angabe der OpenSSL Software Foundation kamen zu jener Zeit etwa 2.000 US-Dollar pro Jahr an reinen Spenden zusammen, niemals genug, um auch nur eine Entwicklerstelle in Vollzeit zu finanzieren. Nahezu universelle Verbreitung, Finanzierung als Rundungsfehler. Die Antwort der Branche, die Core Infrastructure Initiative der Linux Foundation, existierte genau deshalb, weil der gesamte Markt sich an Code bediente, für dessen Pflege niemand zahlte. Trittbrettfahren fast alle, bestimmen am Ende die wenigen die Governance, die bereit sind, für wenig zu arbeiten.

Das ist die unbequeme Synthese. Die Werte-Wende und die Finanzierungslücke sind keine zwei getrennten Geschichten. Ein unterfinanziertes Projekt hat weniger Maintainer, weniger institutionellen Rückhalt und eine Governance-Basis, die eine engagierte Minderheit in jede beliebige Richtung lenken kann. Wer die Commons unterfinanziert, bekommt dadurch keine neutralen Commons. Man bekommt, was die verbliebenen Stewards entscheiden, und hat den einen Hebel aufgegeben, mit dem man das hätte beeinflussen können: mitzumachen und beizutragen. Die Firmen, die Open Source als kostenlosen Input behandeln, sind dieselben Firmen, die am stärksten exponiert sind, sobald dieser Input eigene Meinungen entwickelt.

Wie sieht eine seriöse Dependency-Prüfung heute aus?

Ergänzen Sie Ihre Software-Due-Diligence um eine Frage: Wird dieses Projekt gegen unsere Interessen entscheiden, aus Gründen, die mit dem Code nichts zu tun haben? Behandeln Sie die Antwort dann wie jeden anderen Befund zur Betriebskontinuität. Für eine Abhängigkeit, die diesen Test nicht besteht, brauchen Sie, was Sie bei jeder Einzellieferanten-Komponente brauchen: einen mitführbaren Fork, hausinterne Vertrautheit mit der Codebasis und eine Finanzierungsbeziehung, die substanziell genug ist, dass Ihre Beteiligung eine Tatsache und kein Gefallen ist. Nennen Sie es technische Strategie, angewandt auf einen Input, den die meisten Firmen nie strategisch durchdacht haben. Es ist dieselbe Disziplin, die verhindert, dass agentische und KI-Systeme Risiken erben, die ihre Entwickler nie geprüft haben.

Regulierer behandeln das längst nicht mehr als Kür. Die US-Bundesregierung verlangt seit der Executive Order 14028 von 2021 eine Software Bill of Materials von ihren Software-Lieferanten, und der Cyber Resilience Act der EU, seit Dezember 2024 in Kraft, verpflichtet Hersteller ab Dezember 2027, eine Software Bill of Materials mitzuliefern und Schwachstellen über die gesamte Supportlaufzeit eines Produkts zu managen, eine Vorgabe mit unmittelbarer Relevanz für jedes deutsche Unternehmen, das Software in die EU liefert. Eine Stückliste, die jede Abhängigkeit auflistet, aber keine davon auf Governance-Risiko prüft, ist ein Compliance-Artefakt, keine Verteidigung. Die Organisationen, die gut durch diese Phase kommen, sind jene, die aufgehört haben, Open Source wie Wetter zu behandeln, etwas, das einem einfach widerfährt, und stattdessen als ein Geflecht von Beziehungen zu Menschen mit eigenen Interessen begriffen haben. Abhängigkeit kartieren, Risiko bepreisen, das finanzieren, worauf man nicht verzichten kann. Die Neutralität war nie garantiert. Sie war nur billig genug, dass niemand die Rechnung prüfte.

Häufige Fragen

Reicht eine permissive Lizenz wie MIT oder Apache, um mich vor Governance-Risiken zu schützen?

Nein. Eine Lizenz regelt, was Sie mit dem bereits vorliegenden Code rechtlich tun dürfen. Sie verpflichtet die Maintainer nicht, weiterhin Ihre Patches, Ihre Finanzierung oder Ihre Integration anzunehmen, und genau dieser fortlaufende Fluss von Fixes ist der eigentliche Grund, warum Sie von einem lebendigen Projekt abhängen und nicht von einer statischen Kopie.

Wie prüfe ich das Governance-Risiko einer Open-Source-Abhängigkeit?

Schauen Sie sich an, wie Entscheidungen tatsächlich getroffen werden: wie viele aktive Maintainer es gibt, wie Contributions zugelassen werden, wie das Projekt finanziert ist und ob die Stewards erklärt haben, auch nach nichttechnischen Kriterien zu entscheiden. Behandeln Sie jede Abhängigkeit, auf die Sie nicht verzichten können und die Sie nicht beeinflussen können, als Kontinuitätsrisiko eines Einzellieferanten und planen Sie entsprechend, mit einem mitführbaren Fork und einer echten Finanzierungsbeziehung.

Verringert finanzielle Unterstützung das Risiko tatsächlich?

Sie verändert Ihre Position vom Trittbrettfahrer zum Stakeholder, und das ist der einzige Hebel, den Sie auf Ausrichtung und Personalausstattung eines Projekts haben. Unterfinanzierte Projekte konzentrieren Governance bei denen, die für wenig arbeiten, deshalb sichert eine substanzielle, dauerhafte Finanzierung sowohl die Pflege des Codes als auch einen Platz am Tisch für Ihre Interessen.