# Berlin vs. Bund ## Einleitung: Die Souveränitätsillusion und das Erwachen der Realpolitik Deutschland steht im Jahr 2026 an einem historischen Scheideweg seiner technologischen Entwicklung. Was in den frühen 2020er Jahren als ambitionierter Aufbruch unter dem Schlagwort „Digitale Souveränität“ begann, droht in der Mitte des Jahrzehnts im Dickicht aus bürokratischer Trägheit, aggressiver Lobbyarbeit globaler Tech-Monopolisten und einer kurzsichtigen Austeritätspolitik zu ersticken. Dieser Bericht, verfasst für die „Digitale Politik Revolution“ (DPR) , unterzieht die aktuelle Lage der deutschen Verwaltungsdigitalisierung einer schonungslosen, evidenzbasierten Analyse. Er kontrastiert das zögerliche, oft widersprüchliche Handeln der Bundesregierung mit der vergleichsweise progressiven, wenn auch nicht unproblematischen Strategie des Landes Berlin. Wir bewerten diese Entwicklungen strikt anhand der Grundprinzipien des DPR-Manifests: **Transparenz ** (die Nachvollziehbarkeit staatlichen Handelns und technischer Systeme) , **Evidenz ** (Entscheidungen auf Basis von Fakten statt Marketingversprechen) und **Pluralität ** (die Förderung eines vielfältigen Ökosystems statt monokultureller Abhängigkeit) . Die vorliegende Untersuchung ist weit mehr als eine Bestandsaufnahme; sie ist eine forensische Zerlegung des politischen Versagens auf Bundesebene und eine detaillierte Exegese des Berliner „Hoffnungsschimmers“. Sie stützt sich auf eine Vielzahl aktueller Quellen, technischer Berichte und Haushaltsdaten, um ein Bild der Lage zu zeichnen, das an Dringlichkeit kaum zu überbieten ist. ### Die Definition der Krise: Was bedeutet Digitale Souveränität wirklich? Bevor wir in die Niederungen der Haushaltsdebatten und Versionsnummern absteigen, müssen wir den Begriff der Digitalen Souveränität schärfen. In der politischen Sonntagsrede oft zur Floskel verkommen, beschreibt er im Kern die Fähigkeit des Staates, selbstbestimmt über seine digitale Infrastruktur, seine Daten und seine Prozesse zu verfügen. Es geht um die Vermeidung von einseitigen Abhängigkeiten (Vendor Lock-in) , die den Staat erpressbar machen – sei es durch Preiserhöhungen, Lizenzänderungen oder, im schlimmsten Fall, durch die Abschaltung kritischer Dienste aus geopolitischen Gründen. Souveränität ist dabei kein binärer Zustand (souverän vs. abhängig) , sondern ein Kontinuum, das sich auf drei Ebenen abspielt: - **Die Datenebene: **Wer hat Zugriff auf die Daten der Bürger und der Verwaltung? Wo liegen sie physisch und rechtlich? - **Die Softwareebene: **Können wir nachvollziehen, was der Code tut? Können wir ihn ändern, wenn sich gesetzliche oder prozessuale Anforderungen ändern? - **Die Hardware- und Infrastrukturebene: **Kontrollieren wir die Rechenzentren und Netzwerke, oder mieten wir Kapazitäten in Black-Box-Umgebungen an? Die Analyse zeigt, dass Deutschland auf fast allen Ebenen massive Defizite aufweist. Die Abhängigkeit von Microsoft-Produkten (Office, Exchange, Windows, Azure) hat ein Ausmaß erreicht, das vom Bundesamt für Sicherheit in der Informationstechnik (BSI) zunehmend als Sicherheitsrisiko eingestuft wird. Während die Bundesregierung in ihrer Rhetorik die Wichtigkeit von Open Source betont, sprechen die Haushaltszahlen und die faktische Beschaffungspolitik eine diametral entgegengesetzte Sprache. ### Der Status Quo 2026: Ein Panorama der Widersprüche Das Jahr 2026 markiert einen Tiefpunkt in der Glaubwürdigkeit der digitalen Bundespolitik. Während die Bedrohungslage im Cyberraum exponentiell wächst – getrieben durch automatisierte Angriffe, Ransomware und staatliche Akteure –, entzieht der Bund den Instrumenten, die zur Abwehr dieser Gefahren und zur Stärkung der Unabhängigkeit geschaffen wurden, die finanzielle Grundlage. Das Zentrum für Digitale Souveränität (ZenDiS) , einst als Leuchtturmprojekt gefeiert, wurde im Haushalt 2025 finanziell derart beschnitten, dass seine Handlungsfähigkeit massiv in Frage steht. Gleichzeitig prescht das Land Berlin mit einer „Open Source Strategie“ vor, die bis zum Jahr 2032 eine Quote von 70% Open-Source-Software in der Verwaltung vorsieht. Dieser Föderale Flickenteppich ist symptomatisch für das deutsche Digital-Dilemma: Während einzelne Akteure mutige Schritte wagen, fehlt auf Bundesebene die kohärente Führung. Dieser Bericht wird im Folgenden detailliert aufzeigen, wie es zu dieser Divergenz kam. Wir werden die technischen Spezifikationen des „Souveränen Arbeitsplatzes“ (openDesk) analysieren, die ökonomischen und sicherheitstechnischen Implikationen des Microsoft-Monopols beleuchten und schließlich darlegen, wie die Zivilgesellschaft durch Kampagnen wie „Public Money? Public Code!“ versucht, das Ruder herumzureißen. ## Der Bund: Ankündigungsweltmeister und Umsetzungszwerg – Eine Analyse des Scheiterns Die Geschichte der Digitalpolitik der Bundesregierung in der Legislaturperiode bis 2025 ist eine Geschichte der enttäuschten Hoffnungen. Der Koalitionsvertrag der Ampel-Regierung las sich bei seinem Erscheinen wie ein Wunschzettel der Open-Source-Community: Digitale Souveränität sollte das Leitmotiv sein, offene Standards die Norm, proprietäre Software die begründungspflichtige Ausnahme. Die Realität, die wir heute vorfinden, ist eine ernüchternde Abkehr von diesen Prinzipien. ### Das ZenDiS-Debakel: Austerität gegen Souveränität Das Zentrum für Digitale Souveränität der Öffentlichen Verwaltung (ZenDiS) wurde gegründet, um die Fragmentierung der öffentlichen IT zu überwinden. Seine Aufgabe war herkulisch, aber klar definiert: Die Bündelung der Nachfrage der öffentlichen Hand, die Entwicklung und Pflege souveräner Softwarelösungen wie openDesk und openCode, und die Schaffung einer Alternative zu den Angeboten der US-Hyperscaler. Doch eine Institution kann nur so effektiv sein wie ihre finanzielle Ausstattung. ### Die Anatomie der Kürzungen Die Haushaltsberatungen für das Jahr 2025 offenbarten eine erschreckende Diskrepanz zwischen strategischer Notwendigkeit und fiskalischer Realität. Experten und Interessenverbände hatten berechnet, dass das ZenDiS ein jährliches Budget von mindestens **30 Millionen Euro **benötigt, um seine Kernaufgaben zu erfüllen, die Weiterentwicklung der Software-Stacks zu garantieren und die notwendige Marktdurchdringung zu erreichen. Was der Haushaltsausschuss schließlich vorlegte, glich einer Bankrotterklärung: - **Haushaltsansatz 2025: **Lediglich **2,6 Millionen Euro **wurden fest eingeplant. - **Vergleichszahlen: **Im Vorjahr 2024 waren die Mittel bereits von knapp 50 Millionen auf 24,7 Millionen Euro halbiert worden. Diese Zahlen sind nicht einfach nur Ausdruck eines Sparzwangs; sie sind ein politisches Statement. Ein Budget von 2,6 Millionen Euro für die zentrale Digitalagentur der größten Volkswirtschaft Europas ist im Kontext von IT-Budgets, die in die Milliarden gehen, faktisch nicht existent. Es reicht kaum, um die Gehälter des Kernpersonals zu zahlen, geschweige denn komplexe Softwareprojekte zu steuern oder Marketingkampagnen für den Rollout zu finanzieren. Die Folgen dieser Unterfinanzierung sind fatal und wirken sich direkt auf die Prinzipien der **Pluralität **und **Evidenz **aus: - **Projektstopps: **Geplante Weiterentwicklungen an openCode und openDesk mussten verschoben oder gestreckt werden. Das angekündigte Vertriebspartnerprogramm für openDesk verzögerte sich bis ins erste Quartal 2026. - **Vertrauensverlust: **Welcher IT-Dienstleister investiert in den Aufbau von Kompetenzen rund um den „Souveränen Arbeitsplatz“, wenn der Bund als Hauptsponsor signalisiert, dass er das Projekt finanziell austrocknet? - **Signalwirkung: **Es sendet das fatale Signal an den Markt, dass die Bundesregierung nicht ernsthaft an einer Ablösung proprietärer Software interessiert ist. ### Das institutionelle Gezerre: BMI vs. Haushaltsausschuss Besonders aufschlussreich für die interne Blockade ist der Blick hinter die Kulissen des parlamentarischen Betriebs. Dokumente aus dem Haushaltsausschuss belegen, dass im November 2024 – also kurz vor Ende des Haushaltsjahres – noch immer um die Freigabe von Mitteln aus dem Vorjahr gerungen wurde. Der Ausschuss forderte das Bundesministerium des Innern und für Heimat (BMI) explizit auf, Ausgabereste in Höhe von **34 Millionen Euro **aus dem Jahr 2023 „unverzüglich und vollumfänglich“ an die ZenDiS GmbH zu übertragen. Dass das Parlament die Exekutive per Beschluss zwingen muss, bereits bewilligte Gelder für den vorgesehenen Zweck freizugeben, deutet auf massive interne Widerstände oder administrative Inkompetenz im BMI hin. Es wirft die Frage auf: Wer im Ministerium hat ein Interesse daran, das ZenDiS am kurzen Zügel zu halten? Hier mangelt es eklatant an **Transparenz ** . Die Prozesse, die zu diesen Verzögerungen führten, bleiben der Öffentlichkeit verborgen, während die Zeit für eine souveräne IT davonläuft. ### Der „Deutschland-Stack“: Nationale Hybris statt europäischer Kooperation Parallel zur Demontage des ZenDiS lancierte die Bundesregierung das Projekt „Deutschland-Stack“. Die Idee: Eine standardisierte, cloudbasierte Architektur für die gesamte deutsche Verwaltung, definiert durch klare Schnittstellen und Basiskomponenten. Theoretisch ein sinnvolles Unterfangen, um die Interoperabilität zwischen Bund, Ländern und Kommunen zu sichern. Doch die Umsetzung steht in fundamentalem Widerspruch zu den Warnungen der Experten-Community. Statt sich in bestehende europäische Initiativen einzuklinken und gemeinsam mit Partnern in Frankreich oder den Niederlanden an einem „European Stack“ zu arbeiten, wählt Deutschland den nationalen Alleingang. Die Free Software Foundation Europe (FSFE) kritisierte diesen Ansatz scharf als „Irrweg“. Die Kritikpunkte sind gravierend: - **Mangelnde Einbindung: **Die Entwicklung findet weitgehend hinter verschlossenen Türen statt. Zivilgesellschaftliche Akteure und die breite Open-Source-Community wurden erst spät und unzureichend konsultiert. Dies verletzt das Prinzip der **Pluralität ** , da das Wissen und die Innovationskraft des breiten Ökosystems ignoriert werden. - **Technokratischer Ansatz: **Der Fokus liegt stark auf technischer Architektur, vernachlässigt aber die Governance-Strukturen und die kulturellen Aspekte der Verwaltungsdigitalisierung. - **Redundanz: **Es droht die Gefahr, das Rad neu zu erfinden, anstatt bewährte Komponenten zu nutzen und zu skalieren. Ein „Deutschland-Stack“, der nicht radikal auf Open Source basiert und nicht von Anfang an als europäisches Projekt gedacht wird, läuft Gefahr, ein weiteres Milliardengrab zu werden – eine proprietäre oder semi-proprietäre Insel, die im globalen Kontext bedeutungslos bleibt. ### Die Bilanz der Digitalstrategie: Warme Worte, kalte Dusche Zusammenfassend lässt sich die Bilanz des Bundes im Jahr 2026 als verheerend beschreiben. Die Digitalstrategie, die einst angetreten war, um Deutschland an die Spitze der digitalen Souveränität zu führen, ist in den Mühlen der Realpolitik zerrieben worden. | Anspruch (Koalitionsvertrag) | Realität (2025/2026) | DPR-Bewertung | | --- | --- | --- | | * ***Open Source als Standard **** | Proprietäre Software dominiert weiterhin die Beschaffung; Ausnahmeregelungen sind die Norm. | **Ungenügend. **Keine Evidenz für Strategiewechsel. | | * ***Stärkung ZenDiS **** | Finanzielle Ausblutung (2,6 Mio. € Budgetansatz) . | **Katastrophal. **Sabotage der eigenen Institution. | | * ***Cloud-Souveränität **** | Zunehmende Abhängigkeit von Microsoft Azure / Delos Cloud Konstrukten. | **Mangelhaft. **Pseudo-Souveränität durch Treuhänder-Modelle. | | * ***Transparenz **** | „Deutschland-Stack“ Entwicklung intransparent; Mittelabflüsse unklar. | **Ungenügend. **Verstoß gegen Transparenz-Prinzip. | Der Bund agiert hier nicht als strategischer Gestalter, sondern als Getriebener – getrieben von Haushaltsnöten und der Lobbyarbeit der großen Tech-Konzerne, die ihre Pfründe erfolgreich verteidigen. ## Berlin: Das gallische Dorf der Pinguine? – Eine Analyse der Landesstrategie Während der Bund im Stillstand verharrt, wagt das Land Berlin den Ausbruch. Die „Open Source Strategie für das Land Berlin“ ist das wohl ambitionierteste digitalpolitische Dokument, das eine deutsche Landesregierung je verabschiedet hat. Es ist ein Versuch, die Prinzipien der digitalen Souveränität nicht nur zu predigen, sondern administrativ zu operationalisieren. ### Die Strategie im Detail: 70 Prozent bis 2032 Kernstück der Berliner Strategie ist eine quantifizierbare Zielvorgabe: Bis zum Jahr 2032 sollen **70 Prozent der Arbeitsplatz-Software **in der Berliner Verwaltung auf Open Source umgestellt sein. Warum 70 Prozent und nicht 100? Kritiker aus der fundamentalistischen Open-Source-Ecke bemängeln dies als halbherzig. Doch aus Sicht der **Evidenz **ist diese Zahl ein Zeichen von Realismus. Die Berliner Verwaltung nutzt – wie alle Verwaltungen – hunderte von hochspezialisierten Fachverfahren (für Bauämter, Sozialämter, Polizei etc.) , die oft seit Jahrzehnten im Einsatz sind und zwingend proprietäre Betriebssysteme (meist Windows) voraussetzen. Eine Migration dieser Fachverfahren ist ein Generationenprojekt. Die 70 Prozent beziehen sich daher primär auf die Standard-Software (Office, Browser, Kollaboration, E-Mail) , die den Großteil der Lizenzen und Kosten ausmacht. Dieses Ziel ist messbar. Es zwingt die Verwaltung dazu, Rechenschaft abzulegen. Es schafft einen Druck, der bei vagen Absichtserklärungen („wir wollen mehr Open Source“) völlig fehlt. ### Die sieben strategischen Säulen der Umsetzung Berlin verlässt sich nicht auf das Prinzip Hoffnung, sondern hat einen detaillierten Maßnahmenplan entwickelt, der sieben Bereiche umfasst. Diese Maßnahmen zeugen von einem tiefen Verständnis der Probleme vergangener Migrationen (wie dem gescheiterten LiMux-Projekt in München) : - **Aufbau von Open-Source-Kompetenzen: **Die Erkenntnis, dass Software-Migration zu 80% ein Menschen-Thema ist. Bis 2028 sollen alle relevanten Mitarbeitenden der Berliner Verwaltung geschult sein. Das ist Change Management par excellence. - **Engagement im Open-Source-Ökosystem: **Berlin will nicht nur Trittbrettfahrer sein, sondern aktiv Code beisteuern (“Public Code”) . Dies stärkt die **Pluralität ** , da Berlin Teil einer globalen Community wird. - **Governance und Kommunikation: **Klare Regeln, wer was darf und wie kommuniziert wird. - **Identifikation kritischer Abhängigkeiten: **Eine Inventur der Software-Landschaft, um Klumpenrisiken zu erkennen. Ein direkter Beitrag zur **Transparenz ** . - **Stärkung von Open Source in der IT-Landschaft: **Technische Integration in bestehende Rechenzentren. - **Optimierung der Beschaffung: **Das Vergaberecht wird so ausgelegt, dass Open Source nicht mehr benachteiligt wird (z.B. durch die Berücksichtigung von Lebenszykluskosten statt nur Lizenzkosten) . - **Das ITDZ Berlin als OSPO: **Die Institutionalisierung der Verantwortung. ### Die Rolle des ITDZ: Vom Dienstleister zum Gestalter Zentraler Akteur dieser Strategie ist das IT-Dienstleistungszentrum Berlin (ITDZ) . Es fungiert als das „Open Source Program Office“ (OSPO) des Landes. Damit folgt Berlin dem Best-Practice-Beispiel großer Technologieunternehmen, die ebenfalls OSPOs eingerichtet haben, um ihren Umgang mit Open Source zu professionalisieren. Das ITDZ hat damit eine Doppelrolle: Es ist operativer Betreiber der Rechenzentren und gleichzeitig strategischer Treiber der Migration. Dies birgt Chancen, aber auch Risiken. Die Chance liegt in der direkten Durchgriffsmacht auf die Infrastruktur. Das Risiko liegt in der Überlastung einer Behörde, die ohnehin mit dem Tagesgeschäft kämpft. Dennoch ist dieser Ansatz dem des Bundes (ZenDiS als externe GmbH, die um Budget betteln muss) strukturell überlegen. Das ITDZ ist fest im Berliner Haushalt verankert und Teil der administrativen DNA der Stadt. ### Berlin vs. Bund: Ein Systemvergleich Der direkte Vergleich offenbart die qualitativen Unterschiede in der Herangehensweise: | Merkmal | Bund (Digitalstrategie) | Berlin (Open Source Strategie) | | --- | --- | --- | | * ***Zielsetzung **** | Vage Absichtserklärungen (“Souveränität stärken”) | Konkrete Quote: **70% bis 2032 ** | | * ***Zeitrahmen **** | Projektbasiert, oft kurzfristig (Haushaltsjahr) | Langfristige Roadmap (Meilensteine 2028, 2032) | | * ***Institution **** | ZenDiS (extern, prekär finanziert) | ITDZ als OSPO (integriert, mandatierte Rolle) | | * ***Kultur **** | Top-Down, technokratisch (“Deutschland-Stack”) | Ökosystem-orientiert (“Engagement in Community”) | | * ***Transparenz **** | Gering (Haushaltsmanöver) | Hoch (Veröffentlichte Strategie und Zeitpläne) | Berlin beweist, dass digitale Souveränität auf Landesebene kein Ding der Unmöglichkeit ist. Es ist ein mühsamer Weg der kleinen Schritte, aber er folgt einer klaren Richtung. Der Bund hingegen dreht sich im Kreis. ## Die technische Frontlinie: openDesk vs. Microsoft 365 – Architektur der Freiheit Um die Tragweite der politischen Entscheidungen zu verstehen, müssen wir die technische Ebene betrachten. Die Debatte um „Open Source vs. Proprietär“ wird oft abstrakt geführt. Doch mit **openDesk ** (dem Souveränen Arbeitsplatz) liegt eine konkrete, greifbare Alternative vor, die technisch analysiert werden kann. ### Die Architektur von openDesk: Modularität als Prinzip openDesk ist kein monolithischer Block wie Microsoft Office, sondern eine Orchestrierung der besten verfügbaren Open-Source-Komponenten, die durch eine einheitliche Oberfläche und ein zentrales Identitätsmanagement verbunden sind. Die Kernkomponenten sind: - **Kollaboration & Dateimanagement: ****Nextcloud ** . Der de-facto Standard für selbstgehosteten Datenaustausch. Bietet volle Kontrolle über den Speicherort der Dateien. - **Projektmanagement: ****OpenProject ** . Eine mächtige Lösung für klassisches und agiles Projektmanagement, die in Version 15.5 massive funktionale Erweiterungen erhalten hat. - **Office & Real-Time Editing: ****Collabora Online / XWiki ** . Ermöglicht das gemeinsame Bearbeiten von Dokumenten im Browser. Die Kompatibilität zu MS-Formaten (DOCX, XLSX) wurde in Version 24.04 signifikant verbessert. - **Kommunikation: ****Element (Matrix) **für Chat und **Open-Xchange (OX) **für E-Mail und Kalender. Matrix bietet Ende-zu-Ende-Verschlüsselung und Föderation – ein massiver Sicherheitsgewinn gegenüber zentralen Servern. - **Identitätsmanagement (IAM) : **Basierend auf **Univention Corporate Server (Nubus / Keycloak) ** . Dies ist der Schlüssel zur Souveränität: Die Verwaltung der digitalen Identitäten (Wer darf was?) bleibt in eigener Hand und liegt nicht im Azure Active Directory. Technisch setzt openDesk konsequent auf **Containerisierung (Kubernetes / Helm Charts) ** . Das bedeutet, die Software ist „Cloud Native“. Sie kann im eigenen Rechenzentrum, bei einem kommunalen Provider oder theoretisch sogar in einer Public Cloud laufen – aber eben zu den Bedingungen des Nutzers, nicht des Anbieters. Dies garantiert die Portabilität und verhindert den Vendor Lock-in auf Infrastrukturebene. ### Status Quo der Entwicklung (2025/2026) Entgegen der oft gehörten Kritik, Open Source sei „Bastelware“, zeigt die Release-Historie von openDesk eine professionelle Entwicklung : - **Version 1.3 (Ende 2025) : **Einführung eines monatlichen Update-Zyklus. Dies beweist, dass openDesk “Enterprise-Ready” ist und Sicherheitsupdates zeitnah ausliefern kann. - **Sicherheits-Fokus: **Die Versionen 1.10 und 1.11 (Anfang 2026) konzentrierten sich auf das Schließen von Schwachstellen und die Härtung der Architektur. Dies steht im Kontrast zu Microsofts Ansatz, wo Nutzer oft Monate auf Patches warten müssen. - **Integration: **Die Verbesserung der Keycloak-Integration ermöglicht flexiblere Single-Sign-On Szenarien, was für komplexe Behördenstrukturen essenziell ist. ### Der Funktionsvergleich: Evidenz statt Marketing Wie schlägt sich openDesk im direkten Vergleich mit dem Marktführer Microsoft 365? Eine ehrliche, evidenzbasierte Analyse zeigt Stärken und Schwächen. | Kriterium | openDesk (Souveräner Arbeitsplatz) | Microsoft 365 (Public Cloud) | | --- | --- | --- | | * ***Datenschutz (DSGVO) * *** | **Exzellent. **Daten bleiben im Hoheitsgebiet. Keine Telemetrie-Abflüsse. | **Kritisch. **US Cloud Act ermöglicht Zugriff durch US-Behörden. Telemetriedaten fließen ab. | | * ***Souveränität **** | **Vollständig. **Quellcode auditierbar. Unabhängig von Anbieter-Launen. | **Nicht existent. **Vollständige Abhängigkeit. “Friss oder stirb”. | | * ***Funktionalität (Standard) * *** | **Gut. **Text, Tabellen, Mail, Chat funktionieren zuverlässig und intuitiv. | **Sehr gut. **Industriestandard, an den Nutzer gewöhnt sind. | | * ***Funktionalität (Advanced) * *** | **Mittel. **Spezialfunktionen fehlen teilweise, KI-Integration noch im Aufbau. | **Exzellent. **Tiefe Integration von KI (Copilot) , PowerBI etc. | | * ***Interoperabilität **** | **Hoch. **Basiert auf offenen Standards. | **Mittel. **Proprietäre Formate dominieren, Lock-in erwünscht. | | * ***Kostenstruktur **** | Investition in eigenen Betrieb/Support. Geld bleibt im lokalen Wirtschaftskreislauf. | Laufende Abo-Gebühren (OpEx) . Geld fließt in die USA. Preiserhöhungsrisiko. | | * ***Sicherheit **** | “Security by Design”. Auditierbar durch BSI. | “Security by Obscurity”. Nutzer muss dem Anbieter blind vertrauen. | **Fazit der Analyse: **Für 90% der Arbeitsplätze in der Verwaltung, die Standardaufgaben (Schreiben, Rechnen, Mailen, Organisieren) erledigen, ist openDesk funktional absolut ausreichend und sicherheitstechnisch massiv überlegen. Das Argument der fehlenden “Advanced Features” betrifft nur eine kleine Gruppe von Power-Usern und rechtfertigt nicht die pauschale Abhängigkeit der gesamten Verwaltung. ## Die Sicherheitskrise: Wenn der Support endet – Ein Szenario der Verwundbarkeit Die Diskussion um digitale Souveränität ist keine abstrakte technologische Debatte. Sie ist eine Frage der nationalen Sicherheit. Dies wurde im Jahr 2025 auf dramatische Weise deutlich, als das Support-Ende (End of Life – EOL) für weit verbreitete Microsoft-Produkte eine Krise in deutschen Amtsstuben auslöste. ### Die Exchange-Krise: Eine Zeitbombe in den Serverräumen Im Oktober 2025 erreichte die Warnstufe des BSI einen neuen Höhepunkt. Der Support für **Microsoft Exchange Server 2016 und 2019 **lief aus. Exchange ist das Rückgrat der E-Mail-Kommunikation in fast allen deutschen Behörden. “Support-Ende” klingt harmlos, ist aber in der IT-Sicherheit fatal. Es bedeutet: - Keine Sicherheitsupdates mehr für neu entdeckte Lücken. - Keine Patches für kritische Fehler. - Freie Bahn für Angreifer. Das BSI warnte davor, dass zehntausende Server in der Verwaltung und kritischen Infrastrukturen (Kritis) ungeschützt im Netz hingen. Angreifer scannen das Internet automatisiert nach solchen “Zombie-Servern”. Sobald eine neue Schwachstelle bekannt wird (ein sogenannter Zero-Day-Exploit) , können diese Server innerhalb von Minuten übernommen, Daten gestohlen und Netzwerke mit Ransomware verschlüsselt werden. Die Reaktion vieler Behörden offenbarte die Falle, in der sie saßen: Eine Migration auf die Nachfolgeversion (Exchange Subscription Edition) war teuer und komplex. Der “leichte” Ausweg, den Microsoft anbot, war der Gang in die Cloud (Exchange Online / M365) . Dies ist das perfekte Beispiel für erzwungene Migration: Der Hersteller diktiert durch Obsoleszenz den Weg in sein neues Geschäftsmodell (Cloud-Abo) . Der Staat hat keine Wahl, da er das Produkt nicht selbst warten (“patchen”) kann – der Code ist geschlossen ( **Transparenz **= Null) . ### Die Bedrohungslage: Ransomware und Spionage Die Warnungen des BSI basieren auf harten Fakten. Der Lagebericht 2024/2025 zeigte einen Anstieg neuer Schadprogramm-Varianten um 26% auf täglich 250.000. Besonders alarmierend: - **Windows-Schwachstellen: **Angriffe auf 64-Bit-Windows-Systeme nahmen um **256% **zu. Dies zeigt, dass die Monokultur Windows das primäre Ziel globaler Cyberkrimineller ist. - **Schwachstellen in Cloud-Produkten: **Auch die vermeintlich sicheren Cloud-Lösungen waren betroffen. Schwachstellen in Microsoft Dynamics 365 und SharePoint ermöglichten Angreifern die Offenlegung sensibler Informationen. Die These, die Cloud sei per se sicherer (“Microsoft hat mehr Security-Leute als wir”) , wurde durch die Realität widerlegt. Wenn die Cloud brennt, brennt sie global. ### Die Fragilität der Cloud: Physische und systemische Risiken Neben Software-Fehlern zeigte das Jahr 2025 auch die physische Verwundbarkeit zentralisierter Cloud-Modelle. - **Seekabel-Schäden: **Beschädigungen von Unterseekabeln im Roten Meer führten zu massiven Latenzen und Ausfällen bei Microsoft Azure in Europa. Dies demonstriert, dass “die Cloud” physisch existiert und von geopolitischen Krisenherden abhängig ist. Eine Verwaltung, deren Akten in Dublin oder Amsterdam liegen und nur über intakte Seekabel erreichbar sind, ist im Krisenfall (Krieg, Sabotage) handlungsunfähig. - **Der Crowdstrike-Vorfall: **Die weltweiten IT-Ausfälle, ausgelöst durch ein fehlerhaftes Update der Sicherheitsfirma Crowdstrike auf Windows-Systemen, legten Flughäfen, Krankenhäuser und Behörden lahm. Dies war ein Weckruf: Die tiefe Verzahnung proprietärer Systeme schafft Kaskadeneffekte. Ein Fehler an einer Stelle lässt das globale System kollabieren. **DPR-Analyse: **Ein souveräner Staat darf seine kritische Infrastruktur nicht auf einem Fundament bauen, das er nicht kontrolliert und das bei einem Kabelbruch im Roten Meer oder einem fehlerhaften Update aus dem Silicon Valley zusammenbricht. Das Prinzip der **Evidenz **gebietet hier eine Dezentralisierung und Diversifizierung der IT – also genau das, was openDesk bietet. ## Das Schlachtfeld der Interessen: Lobbyismus, Zivilgesellschaft und die Macht des Geldes Warum geschieht trotz dieser erdrückenden Beweislage so wenig? Warum wird das ZenDiS ausgehungert, während Berlin vorangeht? Die Antwort liegt im politischen Raum, wo Interessen aufeinanderprallen. ### “Public Money? Public Code!” – Der Ruf der Zivilgesellschaft Die Kampagne “Public Money? Public Code!” der Free Software Foundation Europe (FSFE) hat sich zur Speerspitze der Bewegung entwickelt. Ihre Forderung ist so simpel wie logisch und entspricht vollumfänglich dem **Transparenz ** -Ideal der DPR: **Software, die mit öffentlichen Geldern finanziert wird, muss unter einer freien Lizenz der Öffentlichkeit zur Verfügung stehen. ** Warum sollten Steuerzahler für die Entwicklung von Software bezahlen, die dann einem Unternehmen gehört (“Private Code”) oder die sie nicht nutzen dürfen? Die Kampagne hat im Vorfeld der Wahl 2025 massiv an Fahrt aufgenommen. Über 200 Organisationen unterstützen die Kernforderungen : - **Gesetzliche Verankerung: **Das Prinzip muss Gesetz werden (ähnlich dem Schweizer Modell) . - **Sichere Finanzierung: **Dauerhafte Budgets für die Pflege von Open Source (Wartung ist wichtiger als Neuentwicklung) . - **Transparenz: **Statistiken über den Fortschritt (Monitoring) . In der Schweiz wurde mit dem “EMBAG” (Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben) genau das erreicht: Eine “Open by Default”-Regelung ist dort nun Gesetz. Deutschland hinkt hier beschämend hinterher. ### Der Widerstand der Monopolisten: Lobbying gegen Souveränität Dass ein solches Gesetz in Deutschland fehlt, ist kein Zufall. Die Lobbykraft der großen US-Tech-Konzerne in Berlin ist legendär. Die Narrative, die in Hintergrundgesprächen und “Expertisen” gestreut werden, sind immer gleich (FUD – Fear, Uncertainty, Doubt) : - _“Open Source ist unsicher, weil jeder den Code lesen kann.” _ (Widerlegt durch “Many Eyes Principle” und BSI-Praxis) . - _“Es gibt keinen professionellen Support.” _ (Widerlegt durch Firmen wie Univention, Nextcloud, Dataport, Bechtle) . - _“Die Umstellung ist zu teuer.” _ (Ignoriert die langfristigen Kosten des Lock-ins und Lizenzmieten) . Besonders perfide ist das “Open-Washing”: Konzerne geben sich offen, spenden an Open-Source-Projekte, aber der Kern ihrer Produkte, die Cash-Cow, bleibt geschlossen. Die Blockade des ZenDiS-Budgets trägt die Handschrift jener Kräfte, die verhindern wollen, dass eine staatliche Stelle Marktmacht entwickelt und echte Alternativen etabliert. Ein schwaches ZenDiS nützt nur einem: Dem Marktführer Microsoft. ### Die Rolle der Verbände: OSBA als Gegenpol Auf der anderen Seite steht die Open Source Business Alliance (OSBA) , der Bundesverband für digitale Souveränität. Sie argumentiert ökonomisch: Digitale Souveränität ist Wirtschaftsförderung. Investitionen in Open Source fließen zu großen Teilen in die lokale Wirtschaft (Dienstleister, Systemhäuser, Entwickler in Deutschland/Europa) , statt als Lizenzgebühren steueroptimiert in die USA abzufließen. Die OSBA fordert eine Reform des Vergaberechts. Aktuell bevorzugt das Vergaberecht oft proprietäre Lösungen, weil “Wirtschaftlichkeit” kurzfristig auf den Anschaffungspreis gerechnet wird, statt Lebenszykluskosten und makroökonomische Effekte (Steuerrückfluss, Kompetenzaufbau) zu berücksichtigen. ## DPR-Analyse und Forderungskatalog: Die Revolution beginnt im Rechenzentrum Die Analyse “Berlin vs. Bund” ist ein Lehrstück über das Spannungsfeld zwischen Vision und Wirklichkeit, zwischen Mut und Mutlosigkeit. **Berlin **zeigt, dass es möglich ist. Die Strategie ist nicht perfekt, aber sie existiert. Sie ist konkret. Sie ist messbar. Der **Bund **zeigt, wie man eine historische Chance verspielt. Durch Haushaltstricksereien, intransparente Entscheidungen und technologische Alleingänge (“Deutschland-Stack”) wird die digitale Zukunft des Landes gefährdet. Als **Digitale Politik Revolution (DPR) **leiten wir aus dieser Analyse, basierend auf unseren Grundwerten, folgende Positionen und Forderungen ab: ### Transparenz: Der Code gehört dem Volk Das aktuelle System ist eine Black Box. Wir wissen nicht, was die Software tut, die unsere Steuererklärungen und Sozialdaten verarbeitet. - **Forderung: **Offenlegung aller Softwareverträge der öffentlichen Hand. - **Forderung: **Einführung eines “Public Code Gesetzes” auf Bundesebene nach Schweizer Vorbild. “Open Source” muss der Standard (Default) sein, proprietäre Software die begründungspflichtige Ausnahme (“Comply or Explain”) . ### Evidenz: Fakten statt FUD Die Entscheidung für proprietäre Software basiert oft auf Gewohnheit und Lobby-Einfluss, nicht auf Fakten. - **Forderung: **Eine unabhängige “Total Cost of Ownership” (TCO) Analyse für alle IT-Projekte über 1 Mio. €, die Exit-Kosten (Kosten des Wechsels) und langfristige Abhängigkeiten (“Technische Schulden”) voll einpreist. - **Forderung: **Sofortige Aufstockung des ZenDiS-Budgets auf die geforderten 30 Mio. € und Verstetigung der Mittel. Einsparungen bei Microsoft-Lizenzen können dieses Budget spielend decken (Milliarden-Einsparpotenzial laut GI ) . ### Pluralität: Ein Ökosystem statt Monokultur Eine Demokratie braucht Vielfalt. Eine IT-Monokultur ist anfällig für Angriffe und Erpressung. - **Forderung: **Förderung eines föderalen Netzwerks interoperabler openDesk-Instanzen, betrieben von kommunalen Rechenzentren und lokalen IT-Dienstleistern. - **Forderung: **Zerlegung von Riesen-Ausschreibungen in kleinere Lose, damit mittelständische Open-Source-Anbieter eine Chance haben. - **Forderung: **Stopp des nationalen Alleingangs “Deutschland-Stack”. Beitritt zu und Führung von europäischen Initiativen zur Schaffung eines gemeinsamen, offenen Software-Stacks. ### Schlusswort Die Zeit der Pilotprojekte ist vorbei. Die Technologie ist reif ( **openDesk ** ) . Das Wissen ist vorhanden ( **BSI, OSBA ** ) . Der Weg ist skizziert ( **Berlin ** ) . Was fehlt, ist der politische Wille auf Bundesebene, sich aus der komfortablen Umarmung der Tech-Giganten zu lösen. Die Digitale Souveränität ist nicht verhandelbar. Sie ist die Voraussetzung dafür, dass der Staat auch in Zukunft handlungsfähig bleibt – egal ob in Zeiten von Cyberkriegen, Handelskriegen oder einfach nur bei der täglichen Arbeit für die Bürger. Die DPR wird nicht ruhen, bis das Prinzip “Public Money? Public Code!” in jedem Amtszimmer der Republik Realität ist. Die Revolution findet nicht auf der Straße statt – sie findet in den Repositories, den Rechenzentren und den Haushaltsausschüssen statt. Und wir sind bereit, sie zu führen. _Dieser Bericht basiert auf einer umfassenden Analyse aktueller Haushaltsdaten, Strategiepapiere und technischer Berichte aus den Jahren 2024 bis 2026. Alle genannten Fakten sind durch die angegebenen Quellen belegt. _ ## Datenquellen & Referenzen Zur Transparenz und wissenschaftlichen Nachvollziehbarkeit sind im Text folgende Quellen verarbeitet: - [Digitale Souveränität in der öffentlichen Verwaltung – BMDS – Bundesportal] (https://bmds.bund.de/themen/digitale-souveraenitaet/digitale-souveraenitaet-in-der-oeffentlichen-verwaltung) - [Die Lage der IT-Sicherheit in Deutschland 2024 – BSI] (https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/Lageberichte/Lagebericht2024.pdf? __blob=publicationFile&v=5) - [Microsoft Exchange – Gefährdung für zehntausende Server nach Support-Ende für Versionen 2016 und 2019 – BSI] (https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2025/2025-287772-1032.html) - [Sehr geehrte Damen und Herren Abgeordnete … – Lobbyregister] (https://www.lobbyregister.bundestag.de/media/1e/90/608685/Stellungnahme-Gutachten-SG2509010009.pdf) - [Open Source Strategy for the State of Berlin – OSS Directory] (https://www.ossdirectory.com/en/knowhow/details/open-source-strategie-fur-das-land-berlin) - [Berlin auf dem Weg zur Digitalen Souveränität – Smart City Berlin – Detail News] (https://smart-city-berlin.de/detail-news/berlin-auf-dem-weg-zur-digitalen-souveraenitaet) - [Open Source im Bundeshaushalt: Wieder nur warme Worte statt nachhaltiger Finanzierung] (https://osb-alliance.de/featured/open-source-im-bundeshaushalt-wieder-nur-warme-worte-statt-nachhaltiger-finanzierung) - [ZenDiS Startseite: Gemeinsam. Digital. Souverän. – ZenDiS | Zentrum Digitale Souveränität] (https://www.zendis.de/) - [Drucksache 20/15064 – Deutscher Bundestag] (https://dserver.bundestag.de/btd/20/150/2015064.pdf) - [100 Tage Schwarz-Rot: Wo bleibt der Aufbruch für Freie Software? – FSFE] (https://fsfe.org/news/2025/news-20250814-01.de.html) - [OSBA nimmt Stellung zum Deutschland-Stack] (https://www.egovernment.de/osba-nimmt-stellung-zum-deutschland-stack-a-29f8c042626125315963d98f7574e7ed/) - [Für eine innovative, digital souveräne Verwaltung: Berlin stellt Open Source Strategie vor] (https://osb-alliance.de/featured/fuer-eine-innovative-digital-souveraene-verwaltung-berlin-stellt-open-source-strategie-vor) - [OPEN SOURCE STRATEGIE FÜR DAS LAND BERLIN – Berlin.de] (https://www.berlin.de/moderne-verwaltung/ _assets/02 _anlage-rs _open-source-strategie-fuer-das-land-berlin _20260114.pdf?ts=1768477958) - [Der Aufstieg des Souveränen Arbeitsplatzes: openDesk – Ihre Open Source Alternative zu Microsoft und Google – OpenProject] (https://www.openproject.org/de/blog/souveraener-arbeitsplatz/) - [OpenDesk 1.3: Neues Release mit wichtigen Funktionen und Verbesserungen] (https://www.ossdirectory.com/de/topnews/details/opendesk-13-neues-release-mit-spannenden-funktionen-und-verbesserungen) - [Blog – openDesk] (https://www.opendesk.eu/de/blog) - [Open Desk vs. Microsoft 365: A Comparison of Solutions for Public Administration] (https://www.arvato-systems.com/blog/open-desk-vs-microsoft-365-for-public-administration) - [Open Desk vs. Microsoft 365: Lösungen für die öffentliche Verwaltung im Vergleich] (https://www.arvato-systems.de/blog/open-desk-vs-microsoft-365-fuer-oeffentliche-verwaltung) - [Office ohne Abo: 4 Kauf-Pakete im Vergleich mit openDesk – GECKO mbH] (https://www.gecko.de/wissenshub/office-ohne-abo-4-kauf-pakete-im-vergleich-und-warum-opendesk-noch-besser-abschneidet/) - [Support-Ende: Zehntausende Exchange-Server gefährdet – BSI] (https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2025/251028 _Support _Ende _Exchange-Server.html) - [Warn- und Informationsdienst – Sicherheitshinweis – CERT-Bund] (https://wid.cert-bund.de/portal/wid/securityadvisory?name=WID-SEC-2025-0747) - [Version 1.2: Microsoft SharePoint – Massive Ausnutzung einer Zero-Day Schwachstelle – BSI] (https://www.bsi.bund.de/SharedDocs/Cybersicherheitswarnungen/DE/2025/2025-262781-1032.html) - [Azure Cloud in Europa beeinträchtigt (6. Sept. 2025) – BornCity] (https://borncity.com/blog/2025/09/07/azure-cloud-in-europa-beeintraechtigt-6-sept-2025/) - [Weltweite IT-Ausfälle – BSI] (https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Cyber-Sicherheitslage/Analysen-und-Prognosen/Threat-Intelligence/Krisen-Grosslagen/Crowdstrike _Microsoft/Crowdstrike _Microsoft _node.html) - [Regelungsvorhaben „Public Money? Public Code!“ von „Free Software Foundation Europe e.V.“ – Lobbyregister] (https://www.lobbyregister.bundestag.de/inhalte-der-interessenvertretung/regelungsvorhabensuche/RV0016173/133921) - [Bundestagswahl 2025: Wir fordern öffentlichen Code, sichere Finanzierung für Freie Software und transparente Statistiken! – FSFE] (https://fsfe.org/news/2025/news-20250206-01.de.html) - [German Elections 2025: We demand public code, secure funding for Free Software, and transparent measurement of progress!] (https://fsfe.org/news/2025/news-20250206-01.en.html) - [«Open by default» als Gesetz – SocietyByte] (https://www.societybyte.swiss/2023/07/12/open-by-default-als-gesetz/) - [Wird die Vergabereform die Tür für mehr Open Source in der Verwaltung öffnen?] (https://www.oeffentliche-it.de/blog/wird-die-vergabereform-die-tuer-fuer-mehr-open-source-in-der-verwaltung-oeffnen/) - [Milliarden-Einsparpotenzial: GI-Arbeitskreise fordern verbindlichen Rollout von openDesk] (https://gi.de/meldung/milliarden-einsparpotenzial-gi-arbeitskreise-fordern-verbindlichen-rollout-von-opendesk) ## Frag Logos 0/250Deine Nachricht an den Chatbot ') ; $ ('#lu-ai-chat-history') .scrollTop ($ ('#lu-ai-chat-history') [0] .scrollHeight) ; if (sender === 'bot' && !isRestoring) { if ($ ('#lu-ai-chat-tts-toggle') .hasClass ('active') ) { let cleanText = text.replace (/] *>?/gm, '') .replace (/\*/g, '') ; artyom.say (cleanText) ; } } } // --- INIT & LOAD HISTORY --- var historyData = loadChatFromStorage () ; if (historyData) { // Verlauf vorhanden: Erst Begrüßung rendern $ ('#lu-ai-chat-history') .append ('' + defaultGreeting + ' ') ; // Daten übernehmen fullConversation = historyData; // Dann die gespeicherten Nachrichten anhängen historyData.forEach (function (item) { appendMessage (item.html, (item.role === 'user' ? 'user' : 'bot') , true) ; chatHistory.push ({ role: (item.role === 'user' ? 'user' : 'model') , parts: [{ text: item.text }] }) ; }) ; } else { // Kein Verlauf: Nur Begrüßung rendern $ ('#lu-ai-chat-history') .append ('' + defaultGreeting + ' ') ; } // --- SEND LOGIC --- function sendMessage () { if (isRecording) { clearTimeout (silenceTimer) ; UserDictation.stop () ; isRecording = false; $ ('#lu-ai-chat-mic-btn') .removeClass ('recording') ; } if ($ ('#lu-ai-chat-send-btn') .prop ('disabled') ) return; var message = $ ('#lu-ai-chat-user-input') .val () .trim () ; if (message === '') return; appendMessage (message, 'user', false) ; chatHistory.push ({ role: "user", parts: [{ text: message }] }) ; fullConversation.push ({ role: "user", text: message, html: message }) ; saveChatToStorage () ; $ ('#lu-ai-chat-user-input') .val ('') ; updateCharCount () ; toggleChatState (true) ; var loadingBubbleId = 'lu-ai-loading-bubble-' + Date.now () ; var loadingHtml = ' '; $ ('#lu-ai-chat-history') .append ('' + loadingHtml + ' ') ; $ ('#lu-ai-chat-history') .scrollTop ($ ('#lu-ai-chat-history') [0] .scrollHeight) ; var historyJson = JSON.stringify (chatHistory) ; $.ajax ({ url: 'https://www.dpr-deutschland.de/wp-admin/admin-ajax.php', type: 'POST', data: { action: 'lu _ai _chat _request', message: message, history: historyJson, security: luAiNonce, context _id: contextPostId, custom _context: luAiContext, markdown _url: luAiMarkdownUrl }, success: function (response) { toggleChatState (false) ; var $loadingBubble = $ ('#' + loadingBubbleId) ; if (response.success) { var botResponseHtml = response.data; $loadingBubble.remove () ; appendMessage (botResponseHtml, 'bot', false) ; var cleanBotText = botResponseHtml .replace (/ /gi, "\n") .replace (/] +>/g, '') ; chatHistory.push ({ role: "model", parts: [{ text: cleanBotText }] }) ; fullConversation.push ({ role: "model", text: cleanBotText, html: botResponseHtml }) ; saveChatToStorage () ; } else { appendMessage ("Fehler: " + response.data, 'bot') ; } }, error: function () { toggleChatState (false) ; appendMessage ("Verbindungsfehler aufgetreten.", 'bot') ; } }) ; } $ ('#lu-ai-chat-send-btn') .click (sendMessage) ; $ ('#lu-ai-chat-tts-toggle') .click (function () { $ (this) .toggleClass ('active') ; var isActive = $ (this) .hasClass ('active') ; $ (this) .attr ('aria-pressed', isActive) ; var icon = $ (this) .find ('i') ; if ($ (this) .hasClass ('active') ) { icon.removeClass ('fa-volume-mute') .addClass ('fa-volume-up') ; if (typeof artyom !== 'undefined') { artyom.say ("Sprachausgabe aktiviert") ; } } else { icon.removeClass ('fa-volume-up') .addClass ('fa-volume-mute') ; if (typeof artyom !== 'undefined') { artyom.shutUp () ; } } }) ; $ ('#lu-ai-chat-user-input') .keypress (function (e) { if (e.which == 13) { if (!$ ('#lu-ai-chat-user-input') .prop ('disabled') ) { sendMessage () ; } } }) ; }) ; **Wichtiger Hinweis & Haftungsausschluss (Disclaimer) : **Der KI-Assistent „Logos“ ist eine automatisierte Anwendung auf Basis künstlicher Intelligenz und dient ausschließlich Informations- und Unterhaltungszwecken. Die generierten Antworten werden ohne menschliche Kontrolle erstellt und können systembedingt faktisch unrichtig, unvollständig oder veraltet sein („Halluzinationen“) ; eine Gewähr für die Richtigkeit, Vollständigkeit oder Verlässlichkeit der Inhalte wird daher nicht übernommen. Die Nutzung der bereitgestellten Informationen erfolgt auf eigenes Risiko und ersetzt keine professionelle Beratung, etwa in politischen Angelegenheiten. Wir empfehlen dringend, kritische Informationen vor einer Verwendung stets eigenständig zu verifizieren. Die Haftung des Betreibers für Schäden aus der Nutzung ist auf Vorsatz und grobe Fahrlässigkeit beschränkt; hiervon ausgenommen ist die Haftung für Schäden aus der Verletzung des Lebens, des Körpers oder der Gesundheit sowie für die Verletzung wesentlicher Vertragspflichten (Kardinalpflichten) . Änderungen, Einschränkungen oder Ausfälle des Dienstes sind jederzeit vorbehalten.