Kommentar: Open Source steht laut Prognose vor einer Aufspaltung

Der Autor zeichnet Open Source zunächst als Modell, das lange von Offenheit, Vertrauen und informellen Strukturen geprägt gewesen sei. Diese Phase sei vorbei. Spätestens seit Ereignissen wie SolarWinds und Log4Shell werde Software aus offenen Projekten nicht mehr wie ein unverbindlicher Übungsraum behandelt, sondern als tragende Infrastruktur mit realen Folgen für Systeme, Geld und Menschen. Hinzu komme laut Text ein doppelter Druck: neuartige, verkettete Zero-Days, die durch KI schneller gefunden würden, sowie ein industrialisiertes Malware-Problem, bei dem Distributionskanäle selbst in großem Maßstab vergiftet werden.

Wichtig ist dem Autor die Abgrenzung: Open Source als Definition werde nicht angetastet. Die von der OSI über Jahrzehnte betreute Lizenzauffassung bleibe bestehen. Niemand werde der OSI „nachkommen“, schreibt er sinngemäß. Verändern werde sich stattdessen, was Unternehmen akzeptieren können und in naher Zukunft akzeptieren dürfen. Der Krieg, so die Metapher des Textes, schreibe nicht die Definition um, sondern teile die Landschaft in zwei Gruppen.

Auf der einen Seite sieht der Autor einen Teil von Open Source, der die Bedingungen erfüllt, die Unternehmen benötigen: Projekte müssen erreichbar sein, Patches liefern, Verantwortung erkennen lassen und nachweisen können, dass sie weiterhin betreut werden. Für diesen Teil sagt der Beitrag voraus, dass regulierte Unternehmen die Messlatte in einigen Jahren nicht mehr frei wählen, sondern sie aus Compliance-Gründen einhalten müssen. Auf der anderen Seite stünden alle übrigen Projekte: solche, die diese Anforderungen nicht erfüllen können, nicht erfüllen wollen oder nie dafür gedacht waren. Diese Projekte blieben weiterhin Open Source und verschwänden nicht, könnten für regulierte Unternehmen aber nicht mehr ohne eigenen Plan tragfähig sein.

Der Text betont mehrfach, dass diese Trennung nichts mit der Lizenz selbst zu tun habe. Entscheidend sei, ob „jemand zuhause ist“: ob es einen Offenlegungsweg gibt, ob das Projekt seine Lebendigkeit belegen kann und ob im Ernstfall noch jemand da ist, um die nächste Schwachstelle zu beheben. Der Autor fordert dafür eine Art „Herzschlag“ oder Lebensnachweis: einen fortlaufenden Beleg, dass ein Projekt aktiv betreut wird. Mitgliedschaft in diesem Unternehmens-tauglichen Teil sei kein einmal erworbenes Abzeichen, sondern ein Zustand, der ständig neu bewiesen werden müsse.

Dazu komme die Notwendigkeit eines geordneten Rückzugs. Maintainer brannten aus oder hörten auf; das sei legitim. Als Beispiel für fehlende Übergaben nennt der Text den Maintainer von xz-utils. Deshalb brauche es neben dem Lebensnachweis auch eine Art „Ruhestandsheim“ für Projekte, wenn einzelne Verantwortliche aussteigen, die nachgelagerte Nutzung aber weiterbesteht. Genannt wird hier EmeritOSS als Modell für einen solchen Übergang, bei dem Code weiter betreut wird, ohne Maintainer zu unbegrenzter Arbeit zu verpflichten.

Für Nutzer beschreibt der Beitrag zwei Kostenmodelle. Der freie Weg bleibe offen, betont der Autor: Niemand müsse zwingend Geld bezahlen. Allerdings sei „frei“ nie im Sinn von kostenlos gewesen, sondern mit fortlaufender Arbeit verbunden. Wer ohne Anbieter auskomme, müsse auf dem neuesten Stand bleiben, laufend aktualisieren und bereit sein, Projekte zügig zu ersetzen, wenn sie aus dem beschriebenen Teilbereich herausfallen. Anbieter verkauften in diesem Modell keinen Zugang zur Software, sondern Entlastung: etwa LTS-Zweige, zurückportierte Fixes und Zeitpuffer für Migrationen.

Ein weiterer Kernpunkt ist die Finanzierung. Der Autor widerspricht der Deutung als „Tragödie der Allmende“. Code werde nicht durch Nutzung verbraucht. Das eigentliche Problem sei ein Verteilungsproblem: Die Pflege- und Vertrauensebene unter kritischer Software sei nie in einer Form finanziert und organisiert worden, die zu ihrer tatsächlichen Bedeutung passe. Als Antwort darauf nennt er Aggregation durch Foundations und große Communities, die viele einzelne Projekte unter klare Strukturen und Verantwortlichkeiten fassen können.

Dass Regulierung bereits in diese Richtung weist, belegt der Text mit dem Cyber Resilience Act der EU. Dieser habe mit dem „Steward“ eine Kategorie geschaffen: eine juristische Person, die dauerhafte Unterstützung liefert und die Tragfähigkeit von kommerziell genutztem Open Source sicherstellt. Für den Autor ist das kein neues Konzept, sondern ein Zeichen dafür, dass sich diese Kategorie bereits aus mehreren Richtungen gleichzeitig herausbildet. Offen bleibt für ihn nur der Name. Mehrere Versuche verwirft er selbst, betont aber, dass eine Bezeichnung notwendig sei, weil Benennung der erste Schritt zur ernsthaften Steuerung einer solchen Kategorie sei.