← Alle Beiträge

Digitale Souveränität braucht Geld, nicht nur Einsatz

Auf dieser Seite

Die Europäische Kommission hat eine Aufforderung zur Stellungnahme zu einer neuen „European Open Digital Ecosystems Strategy“ gestartet.1 Die Konsultation läuft bis zum 3. Februar, und schon die Rahmung sagt viel: Open Source als „öffentliches Gut, das frei genutzt, verändert und weitergegeben werden darf“, das die technologische Unabhängigkeit und die Cybersicherheit der EU stärken könnte.2

Das Problem haben sie richtig erkannt. Europäische Regierungen und Unternehmen hängen stark an Softwareanbietern von außerhalb der EU, also Microsoft, Google und Amazon. Das schafft Lieferkettenrisiken in kritischer Infrastruktur. Die Lösung, nach der sie greifen, ist Open Source. Kein Vendor Lock-in. Prüfbarer Code. Die Freiheit, ein Projekt zu forken, wenn es stirbt oder ein Unternehmen gegen deine Interessen umschwenkt.

Ich habe an anderer Stelle geschrieben, wie der US CLOUD Act und das schwindende Vertrauen in den transatlantischen Umgang mit Daten europäische Regierungen schon jetzt dazu bringen, ihre Microsoft-Abhängigkeiten zu lösen. Europas stille Revolte gegen die US-Cloud macht das Souveränitätsrisiko konkret: Eine feindlich gesinnte US-Regierung könnte Anbieter zwingen, Daten zurückzuhalten oder herauszugeben. Europa stünde dann nackt da, solange es seinen Stack nicht selbst kontrolliert.

Der Instinkt ist richtig. Aber es funktioniert nicht, wenn sie nicht bereit sind, dafür zu zahlen.

Open Source ist wirklich das richtige Werkzeug

Eines vorweg: Die EU liegt bei der Technologiewahl nicht falsch. Open Source ist tatsächlich der Weg zu digitaler Souveränität, und die Begründung ist einfach.

Wenn dein Staat auf proprietärer Software läuft, mietest du deine eigene Infrastruktur. Microsoft kann die Lizenzbedingungen ändern. Oracle kann dich in die Knie auditieren. Amazon kann den Managed Service einstellen, auf dem du deine Systeme gebaut hast. Du hast keine Handhabe, weil dir der Code nicht gehört.

Open Source verschiebt die Machtverhältnisse. Du kannst den Code auf Sicherheitslücken und Backdoors prüfen, was bei Behördensystemen entscheidend ist. Du kannst ihn forken, wenn die Maintainer das Projekt in eine Richtung lenken, die dir nicht dient. Du kannst lokale Entwickler einstellen, die ihn auf deine Bedürfnisse zuschneiden. Du hängst nicht an der Roadmap eines einzigen Anbieters.

Das ist nicht theoretisch. München ist bekanntlich auf Linux umgestiegen, dann zurück auf Windows, und überlegt jetzt wieder, Linux zu nehmen.3 Das Hin und Her ist kein Scheitern von Open Source. Es zeigt, dass man die Wahl hat. München konnte wechseln. Versuch das mal mit zehn Jahren Microsoft-365-Integrationen.

Was ich in Open Source erlebt habe

Ich schreibe seit über fünfzehn Jahren professionell Code, und Open Source ist die Grundlage von allem, was ich gebaut habe. Die Produkte, an denen ich gearbeitet habe (Flowstate, Jamie, MimeProtect, Blinq), stehen auf Tausenden Abhängigkeiten, die Menschen pflegen, denen ich nie begegnen werde.

Manche dieser Maintainer sind bei großen Unternehmen angestellt, die als Teil ihres Geschäftsmodells zu Open Source beitragen. Viele nicht. Sie pflegen kritische Infrastruktur in ihrer Freizeit, oft für wenig oder gar kein Geld.

Ich habe dieses Muster immer wieder gesehen: Ein brillanter Entwickler baut eine Bibliothek, die ein schwieriges Problem löst. Sie wird übernommen. Unternehmen bauen Produkte darauf. Die GitHub-Benachrichtigungen des Maintainers werden erdrückend. Er brennt aus. Das Projekt wird entweder aufgegeben oder schleppt sich mit sporadischen Updates dahin.

Am schlimmsten ist es, wenn etwas kaputtgeht. Eine Sicherheitslücke wird veröffentlicht. Der Maintainer, der das alles umsonst macht, oft neben einem Vollzeitjob, bekommt plötzlich vom ganzen Internet einen dringenden Patch abverlangt. Manche gehen damit souverän um. Andere tauchen ab.

Das ist nicht tragfähig. Wir haben die digitale Wirtschaft auf ehrenamtlicher Arbeit gebaut und tun überrascht, wenn den Ehrenamtlichen die Kraft ausgeht.

Das Problem der Wertabschöpfung

Die EU-Konsultation räumt ein, dass ein Großteil des Werts, den europäische Open-Source-Projekte schaffen, bei großen internationalen Tech-Konzernen landet, statt der EU-Wirtschaft zu nützen.4

Europäische Entwickler bauen Werkzeuge. Sie veröffentlichen sie als Open Source. Amazon nimmt diese Werkzeuge, verpackt sie in Managed Services und verkauft sie an europäische Unternehmen zurück. Elastic, Redis, MongoDB: Das Muster ist gut dokumentiert. Die Urheber bauen, die Hyperscaler kassieren.

Genau dieses Souveränitätsleck will die EU stopfen. Aber du löst es nicht, indem du einfach mehr Open Source nutzt. Wenn europäische Regierungen Open Source einsetzen, die Entwickler hinter diesen Projekten aber ihre Miete nicht zahlen können, hast du deine Abhängigkeit nur von Microsoft auf unbezahlte Ehrenamtliche verlagert.

Der Wert muss im Ökosystem bleiben. Das heißt, die Menschen zu bezahlen, die die Software bauen und pflegen.

Fördermittel sind nicht die Antwort

Die EU weiß, wie man Dinge finanziert. Horizon Europe, Digital Europe, nationale Innovationsprogramme: An Förderinstrumenten fehlt es nicht. Aber Fördermittel lösen das falsche Problem.

Fördermittel sind zielorientiert. Du beantragst Geld, um etwas Neues zu bauen. Du erreichst Meilensteine. Du lieferst einen Abschlussbericht. Das Projekt endet.

Open-Source-Infrastruktur funktioniert so nicht. Die Bibliothek OpenSSL, die den Großteil des Internets absichert, war nicht unterfinanziert, weil niemand eine neue TLS-Implementierung bezahlt hat. Sie war unterfinanziert, weil niemand die laufende Pflege einer bestehenden bezahlt hat. Als 2014 Heartbleed zuschlug, merkte die Welt, dass kritische Verschlüsselungsinfrastruktur von einer Handvoll Entwicklern in Teilzeit gepflegt wurde.5

Bei Log4j war es dieselbe Geschichte. Eine Logging-Bibliothek, die fast jede Java-Anwendung auf dem Planeten nutzt, gepflegt von Ehrenamtlichen. Als die Log4Shell-Lücke auftauchte, mussten diese Ehrenamtlichen hektisch einen kritischen Fehler beheben, der Milliarden Systeme betraf, und das unbezahlt.6

Du kannst dir keine Infrastruktur zusammenfördern. Fördermittel finanzieren Projekte, Infrastruktur braucht Betrieb. Der Unterschied zählt.

Wie echte Finanzierung aussieht

Die EU-Konsultation nennt „tragfähige Vergütungsmodelle für Entwickler“, und Branchenvertreter haben eine Roadmap mit 70 Punkten zu Investitionsmechanismen eingereicht.7 Das sind die richtigen Gespräche.

Echte Finanzierung für Open Source sieht so aus:

Betriebsbudgets statt Projektförderung. Bezahl Maintainern ein Gehalt, damit sie kritische Infrastruktur sicher und aktuell halten. Finanzier die langweilige Arbeit: Sicherheitspatches, Dependency-Updates, Dokumentation, Community-Management.

Bevorzugung bei der öffentlichen Beschaffung. Wenn europäische Regierungen Milliarden für Software ausgeben, soll dieses Geld Open-Source-Lösungen mit europäischen Maintainern bevorzugen. Jeder Euro für Microsoft-Lizenzen ist ein Euro, der nicht in souveräne Alternativen fließt.

Infrastrukturunterstützung. Baut und betreibt Dienste, die Open-Source-Projekte brauchen: CI/CD, Paketregister, Dokumentationshosting. Die Linux Foundation und die Apache Foundation leisten einen Teil davon, aber für europäische Pendants ist Platz.

Technisches Schreiben und Barrierefreiheit. Gute Dokumentation macht Projekte nutzbar. Finanzier technische Redakteure, damit Open-Source-Werkzeuge für Behörden-IT-Teams zugänglich werden, die womöglich nicht das Wissen haben, allein mit dem Quellcode zu arbeiten.

Das Feedback zur Konsultation zeigt, dass die Community das versteht.8 Die Frage ist, ob die EU das Budget bereitstellt.

Souveränität ist eine Ausgabenentscheidung

Die EU gibt enorme Summen für Software aus. Behörden in ganz Europa zahlen Microsoft, Google und Amazon Lizenzgebühren, die zusammen jährlich in die Milliarden gehen. Ein Teil dieser Ausgaben ist unvermeidbar, denn Windows ersetzt du nicht über Nacht.

Aber jede Beschaffung ist eine Entscheidung. Mit jeder Verlängerung eines Enterprise Agreement fließt Geld, das souveräne Alternativen finanzieren könnte.

Digitale Souveränität ist keine Technologiewahl. Sie ist ein Posten im Haushalt.

Die EU hat richtig erkannt, dass Open Source das Werkzeug ist. Aber ein Werkzeug im Schuppen baut nichts. Du brauchst Menschen, die es benutzen, pflegen und verbessern. Und diese Menschen müssen ihre Miete zahlen.

Open Source rettet Europa nicht aus der technologischen Abhängigkeit, wenn Europa nicht dafür bezahlt. Nicht mit Fördergeld für glänzende neue Projekte, sondern mit Betriebsmitteln für die Infrastruktur, auf die wir schon heute angewiesen sind. Nicht mit Innovationsprogrammen, sondern mit Beschaffungsregeln, die Geld zu europäischen Maintainern lenken.

Die Konsultation endet am 3. Februar. Die Frage ist nicht, ob die EU das Problem versteht, das tut sie offensichtlich. Die Frage ist, ob sie die Schecks ausstellt.


Footnotes

  1. EU launches call for evidence on European open digital ecosystems – Linuxiac ↩

  2. European Open Source Strategy: Key Takeaways – LWN.net ↩

  3. Munich considers Linux, again – ZDNet ↩

  4. The Linuxiac article notes that “much value generated by European open-source projects is captured by large international tech companies rather than benefiting the EU economy.” ↩

  5. The Heartbleed Bug and Open Source Security – OpenSSL Security Advisory, 2014 ↩

  6. The Log4j vulnerability and the importance of open source security – CISA ↩

  7. Der LWN.net-Artikel verweist auf eine Roadmap mit 70 Punkten von Branchenvertretern zu technologischer Entwicklung, Weiterbildung, Beschaffungspraxis, Investitionsmechanismen und Governance-Rahmen. ↩

  8. Have your say: European Open Source Strategy – European Commission ↩