Berlin hat Ende 2025/Anfang 2026 eine Open-Source-Strategie öffentlich gemacht bzw. beschlossen – mit dem Anspruch, digitale Souveränität und Innovationskraft der Verwaltung spürbar zu stärken. Das ist politisch und organisatorisch ein wichtiges Signal: Open Source soll nicht länger „Nice-to-have“ sein, sondern als strategisches Gestaltungsinstrument wirken. Gleichzeitig zeigt ein Blick in die reale IKT-Architektur des Landes (Stichwort BerlinPC) sehr klar: Mit der Strategie allein entsteht noch kein grundlegender Systemwechsel, solange zentrale Standardentscheidungen und Betriebslogiken – insbesondere beim standardisierten Arbeitsplatz – weiterhin eine Microsoft-zentrierte Welt voraussetzen oder Open Source nur als Sonderfall zulassen.
Teil 1: Was die Open-Source-Strategie Berlins vorsieht
1) Zielbild: Souveränität, Resilienz, weniger Lock-in
Im Kern beschreibt die Strategie eine klassische Souveränitätslogik: Abhängigkeiten von wenigen proprietären Anbietern sollen sinken, Resilienz steigen, Open Source und offene Standards sollen systematisch nutzbar werden. Das Dokument ist ausdrücklich als „lernende Strategie“ angelegt, die iterativ weiterentwickelt und in ihrer Wirksamkeit überprüft wird.
Auch die Senatskommunikation betont drei Stoßrichtungen: offene IT-Landschaft, Open-Source-Kultur in der Verwaltung, bessere digitale Services – Open Source also nicht nur als Technologie, sondern als Hebel für Effizienz, Transparenz und Unabhängigkeit.
2) Sieben strategische Maßnahmen als „Handlungspfad“
Die Strategie bündelt ihre Operationalisierung in sieben Maßnahmenfeldern (im Dokument als Steckbriefe ausgearbeitet):
- Aufbau von Open-Source-Kompetenzen (Schulungen, Curricula, Akzeptanzaufbau)
- Engagement im Open-Source-Ökosystem (sichtbar werden, beitragen, Community-Fähigkeit)
- Governance & Kommunikation (klare Rollen, Steuerung, interne/öffentliche Kommunikation)
- Identifikation kritischer Softwareabhängigkeiten (Kritikalität, Risiko, Konzentrationsrisiken)
- Stärkung von Open Source in der IT-Landschaft (SAM-Transparenz, Prototyping/Sandboxing, Standardisierung, Interoperabilität)
- Optimierung von Beschaffung & Vergabe (OSS-spezifische Kriterien, rechtssichere EVB-IT-Handhabung, Auftraggeberkompetenz)
- ITDZ Berlin als OSPO (Open Source Program Office: Beratung, Scouting, Lizenz-/Compliancefragen, Betriebs-/Beschaffungsunterstützung)
3) Messgrößen: ambitioniert auf dem Papier
Zwei Zielmarken sind besonders prägnant:
- Bis 2032 sollen 70 % des Software-Stacks des IKT-Arbeitsplatzes auf Open Source umgestellt sein (Strategie und begleitende Berichte nennen das als zentrale Erfolgskennzahl).
- Bis 2029 sollen 50 % der genutzten proprietären Softwareprodukte auf Open-Source-Substitute untersucht und Ablösepläne erstellt sein.
Das ist als Zielsystem nicht trivial – und zeigt: Berlin denkt nicht nur an einzelne Tools, sondern an den Stack und an Migrationslogik.
4) „Public Money, Public Code“, openCode und Markt-/Lösungs-Scouting
Berlin verankert das Prinzip „Public Money, Public Code“ und die Rolle von openCode als zentraler Bezugspunkt (inkl. frühzeitiger Entwicklung/Initiierung auf der Plattform, nicht erst am Ende „abladen“).
Dazu passt die Strategieidee eines systematischen Scouting und einer besseren Wiederverwendung statt Parallelentwicklungen.
5) Sehr konkret: Testumgebungen und ein Linux-Client – aber zunächst als „Notfallarbeitsplatz“
Spannend ist, dass der Diskurs nicht abstrakt bleibt: Laut Berichterstattung soll das ITDZ eine Testumgebung aufsetzen, um Open-Source-Lösungen kontrolliert auszuprobieren, Abhängigkeiten/Kompatibilitäten zu prüfen und Einbindungsaufwände realistischer zu schätzen.
Und: Es wird ein Linux/Opendesk-basierter Client als Notfallarbeitsplatz genannt – geprüft auf mehreren Ebenen (Betriebssystem, Virtualisierung, Citrix-Workspace, Anwendungen).
Teil 2: Warum das (noch) keinen grundlegenden Systemwechsel ermöglicht
Hier kommt der zentrale Punkt deiner Kritik: Strategie kann Rahmen setzen – aber Systemwechsel braucht Entscheidungen an den “harten” Architektur- und Standardisierungsstellen. Und genau dort steht Berlin sich aktuell strukturell selbst im Weg.
1) Der BerlinPC ist zugleich Hebel und Bremsklotz
Der BerlinPC ist als standardisierter, zentral im ITDZ-Rechenzentrum betriebener Desktop konzipiert: einheitliche Hardware, zentral verwaltete Software/Daten, gleiche Basisprogramme, zentrale Updates – mit dem erklärten Ziel, Kompatibilitätsprobleme zu vermeiden.
Das ist aus Betriebs- und Sicherheitslogik verständlich. Aber es bedeutet auch:
Wenn der Standardarbeitsplatz als Produktlinie auf Homogenität, zentrale Paketierung und definierte Basis-Programme gebaut ist, dann wird Open Source schnell zum „Sonderfall“, der sich erst beweisen muss – statt zur Default-Option.
Noch deutlicher wird die kulturelle/operative Seite in ITDZ-Publikationen: Dort heißt es sinngemäß, man teste aus Gründen von Standardisierung und Zukunftsfähigkeit ausschließlich auf der BerlinPC-Umgebung.
Das ist konsequent – aber es setzt zugleich den Frame: „Kompatibel ist, was BerlinPC-kompatibel ist.“ Genau so entstehen strukturelle Eintrittsbarrieren für alternative Desktop-Stacks.
2) Faktische Abhängigkeit: Windows-Migration und „Microsoft-Client“-Zwang der Fachverfahren
Die Berliner Datenschutzbeauftragte benennt das Problem extrem klar: Trotz politischer Beschlüsse und Open-Source-Kompetenzzentrum gebe es keine sichtbaren Fortschritte beim angekündigten „Open Source BerlinPC“. Stattdessen laufe wegen Support-Ende Windows 10 die Migration auf Windows 11, und viele Fachverfahren seien weiterhin auf einen Microsoft Client angewiesen.
Auch parlamentarische Antworten zeigen: Der BerlinPC wird als zentraler Hebel gesehen, um Rollouts wie Windows 11 landesweit sicherzustellen.
Das ist der Kern der „Systemwechsel“-Hürde:
Solange Fachverfahren und der Standardarbeitsplatz im Alltag implizit Microsoft-Client-Kompatibilität als Grundannahme haben, bleibt Open Source in vielen Bereichen additiv (Tools hier, Pilot da), aber nicht transformativ.
3) Die Strategie erkennt die Bremsen – aber löst sie nicht automatisch
Die Strategie benennt selbst typische Blockaden: unvollständige Software-Übersichten, langlaufende Lizenzverträge, Change-Management-Aufwände, notwendige Standardisierung.
Das ist ehrlich – aber es ersetzt nicht die eigentliche Transformationsentscheidung: Welche Standards gelten künftig wirklich? Wer entscheidet Konflikte zwischen „Betriebsstabilität des BerlinPC“ und „Open-Source-first“?
4) Linux als „Krisenarbeitsplatz“ ist sinnvoll – aber politisch auch ein Eingeständnis
Ein Linux/Opendesk-Client als Notfallarbeitsplatz ist klug für Resilienz.
Aber als Transformationsmotor ist es ambivalent: Wenn Linux primär als „Krisenmodus“ gedacht wird, bleibt die Botschaft im Normalbetrieb: „Im Alltag bleibt alles wie gehabt, nur für den Ausnahmefall gibt’s Open Source.“ Das ist eben kein systematischer Umstieg, sondern Business-Continuity-Absicherung.
5) Ohne „Desktop-Entkopplung“ wird Open Source zum Integrationsprojekt des ITDZ – nicht zur Verwaltungsrealität
Praktisch heißt das: Open Source muss sich in Berlin häufig in die BerlinPC-Logik integrieren (Paketierung, Citrix/VDI-Schichten, Standardfreigaben, Testsets, Supportkonzepte). Das kann funktionieren – aber es verschiebt den Flaschenhals:
Nicht die Fachlichkeit entscheidet, sondern die Integrationsfähigkeit in die Standardumgebung. Und damit wird Open Source weniger „Breitenstandard“, sondern eher „zulässige Ausnahme nach Aufwandsschätzung“.
Was aus meiner Sicht fehlt: eine Systemwechsel-Architektur mit verbindlichen Standards
Wenn Berlin wirklich vom „Open-Source-Enablement“ zum „Systemwechsel“ will, braucht es zusätzlich zur Strategie ein paar harte Leitplanken, die direkt am BerlinPC und an den Fachverfahren ansetzen:
- Verbindliche Open-Standards-Policy (Dokumentformate, Schnittstellen, Identität, Kollaboration) als Mindeststandard – nicht optional.
- Roadmap zur Entkopplung von Fachverfahren vom Microsoft-Client: webfähige Oberflächen, Container/RemoteApp-Modelle, Standard-APIs.
- Zwei Referenzplattformen statt eine Monokultur: BerlinPC als stabiler Standard + „Open Source BerlinPC“ nicht als Ankündigung, sondern als produktiver, supporteter Arbeitsplatzpfad. (Gerade weil „Open Source BerlinPC“ als Idee immer wieder auftaucht, aber Fortschritt unklar bleibt.)
- Beschaffung mit Exit-Pflichten: Jede neue proprietäre Bindung braucht einen Ausstiegsplan (Datenportabilität, offene Formate, Schnittstellen, Alternativen).
- ITDZ-Rolle neu austarieren: OSPO/Enablement ist richtig – aber ohne Mandat, Standards wirklich durchzusetzen, bleibt es Beratung statt Transformation.
- Migrationsbudget & Change-Design: Schulung ja – aber auch Prozess-Redesign, Supportketten, Multiplikatoren, Betriebsmodelle.