Open-Source-Software beschränkt sich nicht auf zugänglichen Code. Es ist ein Produktionsmodell, das die technische Macht zwischen Organisationen, Entwicklern und Nutzern umverteilt. Um die Vorteile zu verstehen, ist es notwendig, die konkreten Mechanismen zu untersuchen, die es strukturell von proprietärer Software unterscheiden.
Cyber Resilience Act und Open Source: Was die europäische Verordnung 2024/2847 ändert
Die europäische Verordnung 2024/2847 (Cyber Resilience Act) trat am 10. Dezember 2024 in Kraft. Ihre Hauptverpflichtungen gelten ab dem 11. Dezember 2027, mit bestimmten Meldepflichten bereits ab dem 11. September 2026. Dieser regulatorische Rahmen definiert die Verantwortlichkeiten rund um Softwarekomponenten, einschließlich Open Source, neu.
Der technische Punkt, den man sich merken sollte: Open-Source-Software, die außerhalb einer kommerziellen Tätigkeit bereitgestellt wird, profitiert von einem erleichterten Regime. Ein ehrenamtlicher Maintainer, der eine Bibliothek in einem öffentlichen Repository veröffentlicht, unterliegt nicht denselben Anforderungen wie ein Herausgeber. Im Gegensatz dazu trägt das Unternehmen, das diese Komponente in ein kommerzielles Produkt integriert, die Verantwortung für die Einhaltung.
Diese Unterscheidung hat direkte Auswirkungen auf die Softwarearchitekturentscheidungen. Die technischen Teams müssen die Open-Source-Abhängigkeiten ihrer Produkte genau kartieren, den Wartungsgrad jeder Komponente bewerten und die Verantwortungskette dokumentieren. Der CRA drängt Organisationen dazu, ihre Open-Source-Abhängigkeiten wie industrielle Komponenten zu behandeln, mit einer formalen Überwachung von Schwachstellen.
Initiativen wie die auf mondelibre.org dokumentierten tragen dazu bei, Praktiken und Ressourcen zu verbreiten, die es den französischsprachigen Akteuren ermöglichen, sich in diesem sich wandelnden regulatorischen Umfeld zurechtzufinden.
Digitale Souveränität: Öffentliche Finanzierung von Open-Source-Komponenten
Wir beobachten einen strategischen Wandel in der Art und Weise, wie Staaten Open-Source-Software betrachten. Deutschland hat über den 2022 ins Leben gerufenen Sovereign Tech Fund über 24 Millionen Euro in rund sechzig strukturierende Projekte investiert: cURL, FreeBSD, GNOME, OpenSSL, PHP. Diese Komponenten sind keine marginalen Softwarelösungen. Sie bilden die unsichtbare Infrastruktur, auf der ganze Bereiche des Webs und öffentlicher Informationssysteme beruhen.
Das Argument geht über Kostensenkungen hinaus. Direkt die Maintainer von Open-Source-Projekten zu finanzieren, bedeutet, den Code als Infrastruktur von allgemeinem Interesse zu behandeln, ähnlich wie ein Straßennetz oder ein Wasserversorgungssystem. Ohne diese Finanzierung beruht die Wartung auf einigen ehrenamtlichen Entwicklern, was systemische Ausfallpunkte schafft.
Dieser Ansatz adressiert auch ein Souveränitätsproblem. Von einem einzigen proprietären Anbieter für eine strategische Funktion (Verschlüsselung, Webserver, Identitätsmanagement) abhängig zu sein, birgt geopolitische und kommerzielle Risiken. Öffentlich finanziertes Open Source verringert die Abhängigkeit von einem einzigen Anbieter und erhält gleichzeitig die Möglichkeit zur Codeprüfung durch unabhängige Dritte.
Kommerzielles Open Source: Ein eigenständiges Geschäftsmodell
Open Source ist nicht der Feind des Geschäftsmodells. Der Bericht State of Commercial Open Source 2025, der auf dem Open Source Summit Europe 2025 vorgestellt wurde, schätzt die von kommerziellen Open-Source-Start-ups im Jahr 2024 eingesammelten Mittel auf 26,4 Milliarden Dollar. Dieser Betrag bestätigt, dass offener Code als Grundlage für Unternehmen dient, die durch Risikokapital finanziert werden.
Die Einnahmemodelle basieren auf Support, Managed Hosting oder Premium-Funktionen. Der Mechanismus ist präzise. Ein Unternehmen veröffentlicht den Kern seiner Software unter einer Open-Source-Lizenz, was die Akzeptanz und das Vertrauen der Entwickler beschleunigt. Die Einnahmen stammen dann aus Mehrwertdiensten, die professionelle Nutzer bereit sind zu bezahlen: hohe Verfügbarkeit, regulatorische Konformität, Integration mit bestehenden Systemen.
Dieses Modell schafft einen positiven Kreislauf. Je mehr das Open-Source-Projekt angenommen wird, desto mehr trägt die Community zu seiner Qualität bei, und desto glaubwürdiger wird das begleitende kommerzielle Angebot. Unternehmen, die Open-Source-Lösungen für ihr ERP, ihr Datenmanagement oder ihre Cloud-Infrastruktur einsetzen, profitieren von einem wettbewerbsfähigen Ökosystem, in dem mehrere Anbieter tätig werden können, was einen Anbieter-Lock-in vermeidet.
Sicherheit von Open-Source-Code: Kollektives Audit gegen proprietäre Intransparenz
Die Transparenz des Quellcodes ist ein struktureller Vorteil für die Sicherheit, keine automatische Garantie. Die Unterscheidung ist grundlegend. Proprietäre Software basiert auf Sicherheit durch Intransparenz: Nur der Herausgeber kennt die potenziellen Schwachstellen. Open-Source-Software ermöglicht es jedem kompetenten Auditor, den Code zu inspizieren, eine Schwachstelle zu melden und einen Fix vorzuschlagen.
Wir empfehlen, “offenen Code” nicht mit “auditiertem Code” zu verwechseln. Ein wenig gewartetes Open-Source-Projekt mit nur einem aktiven Mitwirkenden birgt reale Risiken. Angriffe durch Kompromittierung von Maintainers (Supply Chain Attacks) zielen genau auf diese verwaisten Projekte ab. Die Herausforderung für Organisationen besteht darin, aktiv gewartete Komponenten auszuwählen, mit einer vielfältigen Community von Mitwirkenden und formalen Code-Review-Prozessen.
Die Kriterien, die vor der Integration einer Open-Source-Komponente in ein professionelles Projekt überprüft werden sollten:
- Häufigkeit von Commits und Releases in den letzten zwölf Monaten, die das tatsächliche Aktivitätsniveau des Projekts anzeigt
- Anzahl der verschiedenen Mitwirkenden, da ein Projekt, das auf einer einzigen Person beruht, ein operationelles Risiko darstellt
- Existenz einer Sicherheitsrichtlinie zur Offenlegung von Schwachstellen und durchschnittliche Zeit zur Behebung gemeldeter Schwachstellen
- Kompatibilität der Lizenz mit dem rechtlichen Rahmen des Endprodukts, insbesondere für Copyleft-Lizenzen wie die GPL
Diese Überprüfungen sind nicht optional. Mit dem schrittweisen Inkrafttreten des Cyber Resilience Act wird die Dokumentation der Open-Source-Abhängigkeiten zu einer regulatorischen Verpflichtung für jedes vernetzte Produkt, das in der Europäischen Union vermarktet wird.
Offene Innovation: Warum Open-Source-Projekte schneller vorankommen
Die Open-Source-Entwicklung konzentriert Beiträge von Organisationen mit unterschiedlichen Bedürfnissen. Ein Projekt wie ein Linux-Kernel oder ein Webserver erhält Patches von konkurrierenden Unternehmen, die ein gemeinsames Interesse an der Zuverlässigkeit der technischen Komponente teilen. Diese Dynamik produziert Software, die in viel vielfältigeren Nutzungskontexten getestet wird als ein Produkt, das intern von einem einzigen Team entwickelt wurde.
Der Effekt auf die Innovationsgeschwindigkeit ist in der Praxis messbar. Die Entwicklungszyklen von Open Source ermöglichen es einem Entwickler, einen Fix oder eine Funktion einzureichen, ohne einen kommerziellen Prozess durchlaufen zu müssen. Die Eintrittsbarriere für Beiträge ist technisch, nicht vertraglich.
Für Unternehmen, die ihre Management-, Entwicklungs- oder Sicherheitswerkzeuge bewerten, bietet Open Source einen Anpassungshebel, den proprietäre Software nicht erreichen kann. Ein Open-Source-ERP zu modifizieren, um es an einen spezifischen Geschäftsprozess anzupassen, bleibt möglich, ohne vom Zeitplan des Herausgebers abhängig zu sein. Diese technische Freiheit schlägt sich direkt in operative Agilität nieder.
Das Open-Source-Modell eignet sich nicht für alle Kontexte. In den Bereichen Infrastruktur, Sicherheit und Datenverarbeitung stellt es die widerstandsfähigste und auditierbarste technische Grundlage dar, die heute verfügbar ist.
