Analyse · Veröffentlicht am 23. August 2026

Ihr Open-Source-Fundament hat einen Aufsichtsrat. Niemand prüft ihn.

Bob Boole

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

Linux 6.15 strich eine Unterstützung, auf die sich Unternehmen drei Jahrzehnte lang verlassen hatten, ohne dass die Betroffenen am Tisch saßen. Firmen prüfen jeden kommerziellen Lieferanten akribisch, aber fast nie die Fundamente, auf denen ihre IT tatsächlich steht.

Das Wichtigste

Die Streichung der 486er- und frühen 586er-Unterstützung im Linux-Kernel 6.15 zeigt, wie eine dreißig Jahre alte Kompatibilitätsnorm ohne veröffentlichte Ankündigungsfrist und ohne Wiedergutmachung für betroffene Unternehmen neu bepreist werden kann.
Vorlaufzeit ist Politik, keine Physik: Python-2-Anwender erhielten über ein Jahrzehnt schriftliche Vorwarnung, CentOS 8s zugesagte Laufzeit schrumpfte von 2029 auf Ende 2021, und Node 16 verlor sieben Monate an OpenSSLs Zeitplan.
Abwärtskompatibilität in Open Source ist eine freiwillige Richtlinie, die ein Steward jederzeit rückgängig machen kann, ohne die Abhängigen zu konsultieren.
Wenden Sie auf die Fundamente unter Ihrem Stack dieselbe Governance- und Anreizprüfung an wie auf jeden kommerziellen Lieferanten, beginnend mit der Frage, ob überhaupt eine schriftliche Lebenszyklus-Richtlinie existiert.

Im Mai 2025 erschien Linux-Kernel 6.15 ohne Unterstützung für Intels 486er- und frühe 586er-Prozessoren und beendete damit ein Kompatibilitätsversprechen, das seit den frühen 1990er-Jahren gehalten hatte, ohne je schriftlich fixiert gewesen zu sein. Die offizielle Begründung war pragmatisch: Die Emulationsschicht, die diese Chips brauchten, band Wartungskapazität, die das Projekt anderswo besser eingesetzt sah, und die eigene Mailingliste des Kernels hatte die Streichung seit 2022 offen diskutiert. Für sich genommen nachvollziehbar. Nun die Gegenfrage: Wer wurde gefragt? Die Unternehmen, die diese Prozessoren noch einsetzen, in Industriesteuerungen, Laborgeräten und eingebetteten Systemen, die ihre Hersteller oft überleben, hatten keine Ankündigungsfrist, keinen veröffentlichten Zeitplan und keinen Platz am Tisch. Genau diese Lücke zu schließen ist der Zweck von Open-Source-Diligence, und fast niemand betreibt sie.

Ihr Unternehmen würde keinen Fünfjahresvertrag mit einem Lieferanten unterschreiben, ohne zu prüfen, wem er gehört, wer ihn finanziert und was passiert, wenn sich seine Interessen ändern. Doch genau dieses Unternehmen baut ein Jahrzehnt an Infrastruktur auf einer Open-Source-Plattform auf, ohne der Organisation dahinter auch nur eine Frage zu stellen. Wo überhaupt geprüft wird, endet die Prüfung bei der Lizenzdatei, und die Lizenz regelt nur, was Sie mit dem Code in seiner jetzigen Form tun dürfen. Was der Steward mit dem Code als Nächstes tut, liegt vollständig außerhalb ihrer Reichweite. Niemand stellt eine Rechnung für eine Abkündigung. Die Kostenstelle taucht trotzdem auf.

Schuldet Open Source Ihnen Abwärtskompatibilität?

Nein. Roadmap, Abkündigungspolitik und Plattformunterstützung liegen vollständig im Ermessen des Stewards, Punkt. Bei einem kommerziellen Lieferanten hätten Sie Ankündigungsfristen, Service-Level-Vereinbarungen und Gewährleistungsansprüche; bei einem Upstream-Steward haben Sie Einfluss proportional zu Ihrer Finanzierung und Beteiligung, und die meisten Unternehmen leisten keines von beidem. Governance-technisch sind Sie Kunde eines Lieferanten, der Ihnen nichts schuldet, ohne dafür zu zahlen. Das funktioniert wunderbar, solange die Interessen zufällig übereinstimmen, und der Fehler liegt darin, diese Übereinstimmung für eine Eigenschaft von Open Source zu halten statt für einen Zufall, den man beobachten sollte. Der Steward ist auch keine neutrale Abstraktion: Die Platin-Mitgliedschaft der Linux Foundation liest sich wie ein Namensverzeichnis von Chipherstellern, Cloud-Betreibern und Geräteherstellern, jeder mit eigenen kommerziellen Interessen, und Steward-Organisationen in der gesamten Branche sehen ganz ähnlich aus.

Wie viel Vorlaufzeit geben Open-Source-Abkündigungen tatsächlich?

So viel, wie die Steward-Richtlinie vorsieht, und keinen Tag mehr. Der Vergleich lohnt sich, denn die Bandbreite ist enorm. Am großzügigen Ende steht Python. PEP 373, veröffentlicht 2008, setzte das Ende von Python 2.7 für 2015 an, und als klar wurde, dass das Ökosystem nicht bereit war, verschob das Projekt den Termin auf den 1. Januar 2020. Das ist mehr als ein Jahrzehnt schriftlicher, öffentlicher Vorlaufzeit, einmal korrigiert, zugunsten der Anwender.

Am anderen Ende steht CentOS. Unternehmen setzten 2019 auf CentOS 8, gestützt auf einen veröffentlichten Lebenszyklus parallel zu Red Hat Enterprise Linux, mit einem Support-Ende 2029. Im Dezember 2020 kündigte das Projekt an, dass CentOS Linux 8 stattdessen bereits Ende 2021 auslaufen würde, während die Arbeit zu CentOS Stream verlagert wurde. Eine Laufzeit, die Anwender auf fast ein Jahrzehnt kalkuliert hatten, schrumpfte auf rund zwölf Monate Vorlauf, und jeder darauf aufgebaute Migrationsplan wurde sieben Jahre zu früh fällig.

Node.js liegt dazwischen und lehrt die feinere Lektion. Node 16 hatte laut Release-Plan ein Support-Ende im April 2024, und das Projekt zog diesen Termin um sieben Monate vor, auf den 11. September 2023, weil die darunterliegende Bibliothek OpenSSL 1.1.1 zuerst aus dem Support fiel und niemand eine Laufzeitumgebung mit ungepatchter Kryptografie ausliefern wollte. Der Zeitplan war real, und der Steward hielt sich an sein eigenes Verfahren. Anwender verloren trotzdem sieben Monate, weil die Uhr eines fremden Stewards abgelaufen war.

Stellt man diese Fälle neben den des Kernels, ist das Muster klar: Vorlaufzeit ist Politik, keine Naturgesetzlichkeit. Sie reicht von einem Jahrzehnt bis zu einem Jahr, veröffentlichte Termine verschieben sich in beide Richtungen, und Ihre tatsächliche Vorwarnung ist das kürzeste Ankündigungsfenster in Ihrer gesamten Abhängigkeitskette. Die Streichung der 486er-Unterstützung ist kein Skandal, sie ist der Datenpunkt am unteren Ende der Bandbreite. Für die Hardware-Unterstützung im Kernel gab es kein Lebenszyklus-Dokument, also war die einzig verfügbare Ankündigung eine Mailingliste-Debatte, die kaum ein Einkaufsteam der Welt mitgelesen hat.

Wenn die Aktenlage das Problem selbst erzeugt

Ein weiteres Risiko entsteht gerade, und es sei ausdrücklich gesagt: Bei der 486er-Entscheidung spielte es keine Rolle, die wurde jahrelang offen und aus technischen Gründen diskutiert. Das Risiko: Belege für „Wartungslast" lassen sich inzwischen auf Bestellung erzeugen. Ein Codeabschnitt läuft jahrelang produktiv, ohne dass ein Mensch sich beschwert; ein automatisiertes Scan-Tool erzeugt einen plausibel klingenden, aber theoretischen Fehlerbericht; der Bericht landet im Tracker; der Code trägt nun offene Vorgänge, und seine Entfernung liest sich als Hygiene, nicht als Abkündigung. Das curl-Projekt erlebt gerade die Frühphase davon. Maintainer Daniel Stenberg warnte bereits im Januar 2024 vor KI-gestützten Sicherheitsmeldungen, und im Juli 2025 berichtete er, dass rund ein Fünftel der eingehenden Sicherheitsmeldungen bei curl KI-generierter Unsinn sei, bislang ohne einen einzigen validen Bericht mit KI-Unterstützung, aber mit erheblichem Zeitverlust für erfahrene Prüfer bei jeder einzelnen Meldung. Löschung per Aktenlage ist eine reale Möglichkeit für jedes Projekt, dessen Triage nicht zwischen maschinell erzeugter Spekulation und einem tatsächlich aufgetretenen Fehler unterscheiden kann.

Begegnen Sie dem Argument „wegen KI" in Scope-Debatten mit besonderem Misstrauen: Dieselbe Prämisse wird im einen Argument als Kapazität verkauft (weniger Maintainer bewältigen mehr Code) und im nächsten als Last (generierter Unsinn überflutet den Tracker), und eine Prämisse, die eine Schlussfolgerung und ihr Gegenteil stützt, leistet keine analytische Arbeit.

Wie sieht Open-Source-Diligence in der Praxis aus?

Wie Lieferantenprüfung, nur eine Ebene tiefer angesetzt, und der Vergleich oben liefert die Fragen direkt mit.

Schriftliche Lebenszyklus-Richtlinie. Veröffentlicht der Steward überhaupt eine? Pythons Jahrzehnt an Vorlaufzeit existierte, weil PEP 373 existierte. Der Kernel hat kein vergleichbares Dokument für Hardware-Unterstützung, was im Voraus zeigte, dass die Vorlaufzeit das sein würde, was die Mailingliste entschied.

Historie und Richtung. Wenn dieser Steward schon einmal einen Termin verschoben hat, in welche Richtung? Python korrigierte zugunsten der Anwender, CentOS gegen sie, um fast ein Jahrzehnt. Die letzte Korrektur eines Stewards ist die beste verfügbare Prognose für die nächste.

Transitive Vorlaufzeit. Ihr Warnfenster ist das Minimum über die gesamte Kette, nicht die Zahl auf der Verpackung. Node 16s Zeitplan hielt, bis OpenSSLs Uhr ablief. Kartieren Sie, welche vorgelagerten Uhren Ihre Plattformen erben.

Governance und Geld. Wer finanziert den Steward, und profitieren diese Geldgeber davon, wenn Sie zu Hardware-Erneuerung oder Migration gezwungen werden?

Exposure und Ausstieg. Wissen Sie, welche Funktionen, Plattformen und Hardware-Generationen in Ihrem Bestand plausibel in die „Legacy"-Zone rutschen könnten, und kalkulieren Sie Fork, Pinning oder Migration jetzt, in Ruhe, statt in dem Quartal, in dem die Abkündigung tatsächlich eintrifft. Ein bereits kalkulierter Ausstieg ist der einzige, der Ihre Verhandlungsposition stärkt.

Nichts davon ist exotisch. Es ist dieselbe Analyse von Anreizen und Governance, die wir in technologischen Strategie-Reviews anwenden, nur gerichtet auf eine Gegenpartei, die die meisten Organisationen nie geprüft haben, und sie gehört in denselben Lebenszyklusplan wie die Plattformen, auf denen Ihr Unternehmen steht. Sie passt auch zu einer Disziplin, für die wir im Zusammenhang mit KI-Readiness plädiert haben: Behauptungen werden geprüft, bevor jemand danach handelt, egal von wem sie stammen, aus dem Upstream oder aus dem eigenen Vorstand. Die Fundamente unter Ihrem Stack sind Lieferanten ohne die Pflichten eines Lieferanten. Prüfen Sie Ihre Steward-Organisationen wie Lieferanten. Sie können ihre Meinung ändern, und die Kosten tragen Sie.

Häufige Fragen

Wie erkenne ich, ob ein Upstream-Open-Source-Projekt eine Unterstützung streichen könnte, auf die ich angewiesen bin?

Beobachten Sie den Steward, nicht nur den Code. Das Fehlen einer schriftlichen Lebenszyklus-Richtlinie, eine Finanzierung und Gremienbesetzung, die sich in Richtung neuer kommerzieller Prioritäten verschiebt, Abkündigungsdiskussionen, die als „Reduzierung der Wartungslast" gerahmt werden, sowie eine dünne Maintainer-Abdeckung genau der Codepfade, die Sie nutzen, sind alles Frühindikatoren. Die 486er-Streichung wurde in Kernel-Diskussionen fast drei Jahre im Voraus angekündigt. Behandeln Sie die Governance-Threads eines Projekts wie die Telefonkonferenzen eines Lieferanten zur Quartalsbilanz: unspektakulär, öffentlich und voller Signale.

Sind KI-generierte Fehlermeldungen ein reales Risiko für stabile Software?

Ja, und die Erfahrung des curl-Projekts zeigt die Form: Ein großer Teil der eingehenden Sicherheitsmeldungen entsteht inzwischen maschinell, und praktisch keine hat sich als valide erwiesen. Die Gefahr liegt in der Triage. Ein theoretischer, maschinell erzeugter Fehler ist ein schwächerer Beleg als ein Fehler, den ein realer Nutzer produktiv erlebt hat, und ein Projekt, das beide gleich behandelt, wird funktionierenden Code schrittweise als Last neu einstufen. Prüfen Sie bei einer Abhängigkeit, ob deren Triage-Prozess zwischen maschinell erzeugter Spekulation und menschlich gemeldeten Fehlern unterscheidet.

Was sollte ein Open-Source-Governance-Review abdecken?

Vier Dinge: ob der Steward eine Lebenszyklus-Richtlinie veröffentlicht und wie er Termine bisher eingehalten oder verschoben hat (die Bandbreite reicht von Python 2s Jahrzehnt an Vorlaufzeit bis zu CentOS 8s Absturz von 2029 auf 2021); wer den Steward kontrolliert und finanziert und wohin dessen Einnahmen tendieren; eine Karte, welche Ihrer Systeme von Funktionen abhängen, die plausibel als Legacy eingestuft werden könnten, einschließlich vorgelagerter Vorlauffenster; und eine kalkulierte Ausstiegsroute (Fork, Pinning oder Migration). Aktualisieren Sie das jährlich, denn die Anreize der Steward-Organisationen ändern sich schneller als die Erneuerungszyklen.