Deutschland-Stack: Was das neue Open-Source-Rahmenwerk für Behörden wirklich bedeutet

Ende Januar hat das Bundesministerium für Digitales und Staatsmodernisierung ein Konzeptpapier veröffentlicht, das in der Verwaltungs-IT-Szene seither ordentlich Staub aufwirbelt: den Deutschland-Stack. Die Idee dahinter ist nicht neu, aber der Anspruch schon: eine gemeinsame technische Basis für Bund, Länder und Kommunen, aufgebaut auf offenen Standards und mit klarer Präferenz für Open Source. Wer jetzt an eine reine Symbolpolitik-Nummer denkt, liegt nicht ganz falsch – aber auch nicht ganz richtig. Es lohnt sich, genauer hinzuschauen, was tatsächlich in den Papieren steht und was Wunschdenken einzelner Blogs ist.

Was der Deutschland-Stack tatsächlich regelt

Der Deutschland-Stack ist kein einzelnes Produkt, keine Distribution, kein Softwarepaket mit Versionsnummer. Es handelt sich um ein Rahmenwerk – eine Art technisches Betriebssystem für die Verwaltung, bestehend aus wiederverwendbaren Basisdiensten wie Identitätsmanagement, Zahlungsabwicklung oder Dokumentenverarbeitung. Statt dass jede Behörde ihr eigenes Fachverfahren einkauft und neu integriert, sollen diese Bausteine einmal entwickelt und über offene Schnittstellen von allen Verwaltungsebenen genutzt werden. Das ist im Kern ein Plattformgedanke, wie man ihn aus dem Softwarearchitektur-Alltag kennt: gemeinsame Bibliotheken statt hundertfach dupliziertem Code.

Federführend ist der Bund, der IT-Planungsrat hat das Vorhaben als gemeinsames Projekt von Bund, Ländern und Kommunen eingeordnet. Das ist an sich schon eine kleine Nachricht wert, denn deutsche Verwaltungsdigitalisierung krankt traditionell an genau dieser Fragmentierung – sechzehn Länder, tausende Kommunen, unzählige parallele IT-Beschaffungen. Der Deutschland-Stack will diese Zersplitterung technisch adressieren, ohne die föderale Struktur politisch anzutasten. Wer sich mit dem Begriff GovTech beschäftigt, erkennt in dieser Konstruktion ein bekanntes Muster: Nicht die Verwaltung selbst soll neu erfunden werden, sondern die technische Infrastruktur darunter, wie es auch in der Begriffsklärung zu GovTech als Konzept beschrieben wird.

Vorrang statt Pflicht – warum die Wortwahl entscheidet

Jetzt zur Sache, die in vielen Schlagzeilen verrutscht: Von einer harten, allgemeinen Open-Source-Pflicht für sämtliche Behörden-IT kann derzeit keine Rede sein. Verbindlich festgelegt ist bislang die Ausrichtung an offenen Standards und der Grundsatz, dass vorrangig Open-Source-Lösungen oder Produkte europäisch souveräner Anbieter eingesetzt werden sollen, wo dies möglich ist. Das ist ein handfester Unterschied zwischen einer Präferenzregel und einem Verbot proprietärer Software.

Wer aus dieser Formulierung ein flächendeckendes Linux-Gebot für jedes Amtszimmer bastelt, überinterpretiert das Papier. Trotzdem ist die Formulierung nicht folgenlos: Wenn Ausschreibungen künftig systematisch prüfen müssen, ob eine offene Alternative existiert, verschiebt sich die Beweislast. Bisher musste man begründen, warum man Open Source statt der etablierten proprietären Lösung nimmt. Künftig könnte es andersherum laufen – wer bei einer Ausschreibung an einem geschlossenen Format oder Anbieter festhält, muss das rechtfertigen. Das ist, ganz persönlich gesagt, der eigentlich relevante Hebel in diesem Papier, nicht die Schlagzeile von der angeblichen Open-Source-Zwangsverordnung.

Governance-technisch ist der Deutschland-Stack außerdem als kooperatives Ökosystem mit teils verbindlicher, teils fakultativer Nutzung einzelner Komponenten beschrieben. Manche Basisdienste werden also Pflicht, andere bleiben optional nachnutzbar. Diese Differenzierung wird in der öffentlichen Debatte gern verschluckt, ist aber entscheidend dafür, wie stark der Stack tatsächlich in bestehende IT-Landschaften eingreift.

Zeitplan: Governance bis Frühjahr 2026, Betrieb ab 2028

Wer jetzt schon eine flächendeckende Migration erwartet, wird enttäuscht. Standards und Governance-Regeln für den Deutschland-Stack sollen laut offizieller Zeitplanung bis Ende März 2026 festgelegt werden. Die eigentliche Plattform, auf der Bund, Länder und Kommunen produktiv arbeiten können, soll ab 2028 zur Verfügung stehen. Basisdienste werden zunächst für den Bund bereitgestellt und anschließend zur Nachnutzung an Länder und Kommunen weitergegeben.

Das klingt nach einem langen Anlauf, ist für ein Vorhaben dieser Größenordnung aber nicht ungewöhnlich. Wer schon mal eine mittelgroße IT-Migration in einer einzelnen Organisation begleitet hat, weiß, wie viel allein an Schnittstellenarbeit, Datenschutzfolgeabschätzungen und Testphasen anfällt. Bei einer Struktur mit Bund, sechzehn Ländern und tausenden Kommunen multipliziert sich dieser Aufwand entsprechend. Zwei Jahre bis zur Nutzbarkeit sind ambitioniert, nicht übertrieben lang.

Kritischer ist die Frage, was in der Zwischenzeit passiert. Bis 2028 laufen weiterhin unzählige Ausschreibungen für Fachverfahren, Cloud-Verträge und Lizenzen – teils mit Laufzeiten von fünf oder mehr Jahren. Jede Behörde, die jetzt einen Vertrag mit Bindungsfrist bis 2031 unterschreibt, hat de facto schon entschieden, wie kompatibel sie mit dem künftigen Stack sein wird, bevor dieser überhaupt steht. Genau hier liegt das eigentliche Zeitfenster-Risiko des Projekts.

Was das für Fachverfahren und Dokumentenformate heißt

Ein Punkt sorgt seit Wochen für Verwirrung: die Behauptung, der Deutschland-Stack bringe ein generelles Ende von .docx und .xlsx in der Verwaltung samt verbindlicher ODF-Pflicht bis 2028. Diese Darstellung, die unter anderem in einem einschlägigen Blog kursiert, findet sich in den offiziellen BMDS-Unterlagen und im Beschluss des IT-Planungsrats so nicht wieder. Fakt ist: Offene Dokumentenformate wie das OpenDocument-Format und barrierefreies PDF werden in Impulspapieren einzelner Länder – etwa aus Schleswig-Holstein – als Mittel zur digitalen Souveränität genannt. Eine bundesweit verbindliche Pflicht ist das aber, Stand heute, nicht.

Das heißt nicht, dass die Richtung falsch wäre. Wer schon einmal versucht hat, ein zehn Jahre altes Word-Dokument mit verschachtelten Formularfeldern in einer anderen Suite zu öffnen, kennt das Format-Chaos, das proprietäre Bindungen über Jahrzehnte anrichten können. Offene Standards lösen dieses Problem nicht automatisch, aber sie machen den Ausstieg aus einer einzelnen Anbieterwelt technisch überhaupt erst möglich. Genau das ist der Kern des Prinzips Open Source First, das in einzelnen Bundesländern schon vor dem Deutschland-Stack diskutiert wurde und jetzt in einen größeren Rahmen eingebettet wird.

Praktisch bedeutet das für IT-Verantwortliche in Behörden: Wer heute Fachverfahren beschafft, sollte Exportfähigkeit in offene Formate als Kriterium mitverhandeln – unabhängig davon, ob eine formale Pflicht schon existiert. Verträge, die das nicht vorsehen, werden in zwei, drei Jahren zu teuren Altlasten. Das gilt besonders für Formate, in denen über Jahre gewachsene Aktenbestände liegen, denn eine nachträgliche Migration ganzer Aktenarchive ist ungleich teurer als eine von Anfang an offene Formatwahl.

Vergaberecht als eigentlicher Flaschenhals

So sehr Ministerien und Landesregierungen den Deutschland-Stack politisch als Meilenstein verkaufen – die entscheidende Bremse liegt woanders: im Vergaberecht. Öffentliche Ausschreibungen folgen festen Verfahren, die auf Wirtschaftlichkeit, Gleichbehandlung und Rechtssicherheit ausgelegt sind. Eine Präferenz für Open Source lässt sich in diese Logik nur einbauen, wenn Vergabestellen belastbare Kriterien haben, mit denen sie „digitale Souveränität“ oder „Wirtschaftlichkeit über die gesamte Nutzungsdauer“ objektiv bewerten können. Genau daran hapert es bislang. Solange nicht klar definiert ist, wie eine Total-Cost-of-Ownership-Betrachtung über zehn Jahre Lizenzkosten, Supportverträge und Migrationsrisiken gegen eine womöglich günstigere, aber offene Alternative aufwiegt, bleibt der Vorrang für Open Source eine politische Absichtserklärung ohne harten juristischen Hebel.

Ein Blick in die Vergangenheit zeigt, wie heikel dieses Terrain ist. Das viel zitierte Münchner Linux-Projekt, das über Jahre als Vorzeigebeispiel für kommunale Open-Source-Strategien galt, wurde nach etlichen Jahren des Betriebs teilweise wieder zurückgebaut – nicht primär aus technischen Gründen, sondern wegen organisatorischer Reibung, fehlender durchgängiger Fachverfahren-Kompatibilität und politischem Richtungswechsel. Wer den Deutschland-Stack als Selbstläufer verkauft, blendet solche Erfahrungen gerne aus. Realistisch betrachtet ist jede großflächige Open-Source-Migration in der Verwaltung ein Projekt mit hohem Beharrungsrisiko, weil es nicht nur um Software geht, sondern um eingeübte Arbeitsabläufe, Schulungsaufwand und die Frage, wer im Zweifel haftet, wenn ein Basisdienst ausfällt.

Kritik aus der Open-Source-Szene: zu wenig Transparenz

Nicht jeder in der Open-Source-Community feiert das Konzeptpapier unkritisch. Journalistische Analysen aus dem Umfeld der digitalpolitischen Berichterstattung bemängeln, dass unklar bleibe, nach welchen Kriterien eine Technologie überhaupt als „digital souverän“ gilt. Diese Unschärfe ist kein rein akademisches Problem: Wenn der Begriff nicht sauber definiert ist, kann im Zweifel auch ein US-Hyperscaler mit einem europäischen Rechenzentrum als „souverän genug“ durchgehen, während eine kleine europäische Open-Source-Alternative im Vergabeverfahren durchfällt, weil sie formal nicht alle Compliance-Kästchen bedienen kann.

Ein zweiter Kritikpunkt betrifft die Beteiligung. Community-Projekte, die seit Jahren an offenen Verwaltungslösungen arbeiten, fühlen sich bei der Ausarbeitung der frühen Governance-Regeln zu wenig eingebunden. Das ist ein bekanntes Muster bei GovTech-Vorhaben: Ministerien entwerfen Rahmenwerke top-down, während die praktische Expertise oft in kleineren Projekten und Vereinen sitzt, die selten am Verhandlungstisch sitzen. Ob der Deutschland-Stack hier tatsächlich anders funktioniert als frühere E-Government-Initiativen, wird sich erst zeigen, wenn konkrete Ausschreibungen laufen.

Meine persönliche Einschätzung: Die Skepsis ist berechtigt, aber nicht Grund genug, das Projekt kleinzureden. Ein Rahmenwerk, das offene Standards zumindest zur politischen Leitplanke macht, ist ein Fortschritt gegenüber dem Status quo aus Insellösungen und Lizenzabhängigkeiten – auch wenn die Umsetzung am Ende butterweicher ausfallen könnte, als es die Ankündigungen versprechen.

Chancen und Risiken für Mittelstand und lokale IT-Dienstleister

Ein Aspekt, der in der bisherigen Debatte zu kurz kommt: die wirtschaftlichen Folgen für kleinere IT-Dienstleister, die heute schon Kommunen und Landesbehörden betreuen. Ein bundesweit standardisierter Stack mit offenen Schnittstellen könnte für regionale Anbieter durchaus eine Chance sein, weil sie nicht mehr gegen die geschlossene Integrationstiefe großer Systemhäuser antreten müssen, sondern auf Basis offener Standards eigene, spezialisierte Lösungen andocken können. Wo heute ein einzelner Großanbieter eine Kommune über Jahre an sich bindet, könnte künftig ein Ökosystem aus mehreren kleineren Anbietern entstehen, die jeweils Teile des Stacks betreuen.

Gleichzeitig gibt es ein reales Risiko: Wenn der Bund die zentralen Basisdienste selbst betreibt oder an wenige große Auftragnehmer vergibt, könnte genau das Gegenteil passieren – eine neue, diesmal staatlich verordnete Zentralisierung, die kleinere private Anbieter aus dem Markt drängt, weil kommunale IT-Abteilungen schlicht nichts mehr selbst beschaffen müssen. Ob der Deutschland-Stack am Ende Wettbewerb fördert oder ihn kanalisiert, hängt stark davon ab, wie offen die Schnittstellen der Basisdienste tatsächlich gestaltet werden und ob Drittanbieter gleichberechtigten Zugang erhalten. Diese Frage ist in den bisherigen Papieren noch kaum konkretisiert.

Föderalismus als Praxistest

Der eigentliche Stresstest für den Deutschland-Stack wird nicht in Berlin stattfinden, sondern in den Kommunen. Ein Basisdienst, der beim Bund reibungslos läuft, muss noch lange nicht in einer mittelgroßen Stadtverwaltung mit fünfzehn Jahre alten Fachanwendungen funktionieren. Genau an dieser Schnittstelle sind in der Vergangenheit viele Digitalisierungsvorhaben der öffentlichen Hand gescheitert oder verzögert worden – nicht an mangelndem politischem Willen, sondern an der schieren technischen und organisatorischen Heterogenität zwischen den Ebenen.

Das Impulspapier eines Bundeslands zum Thema macht deutlich, dass zumindest auf Länderebene ein gewisses Bewusstsein für dieses Risiko existiert: Gefordert wird konsequente Ausrichtung an digitaler Souveränität, die Vermeidung neuer Herstellerabhängigkeiten und eine starke Rolle offener Schnittstellen. Ob solche Forderungen in verbindliche Beschaffungsregeln münden oder als hübsch formulierte Absichtserklärung enden, ist eine offene Frage – und genau diese Frage wird am Ende darüber entscheiden, ob der Deutschland-Stack ein reales Stück digitaler Souveränität in Behörden wird oder nur ein weiteres Konzeptpapier im Aktenschrank.

Ein realistisches Szenario, wie es in Gesprächen mit kommunalen IT-Leitungen immer wieder anklingt, sieht so aus: Eine kleine Kreisstadt mit begrenztem Personal und knappem Budget kann sich weder eine eigene Migrationsstrategie noch dedizierte Open-Source-Expertise leisten. Für sie wird der Deutschland-Stack nur dann relevant, wenn Land oder Bund die Basisdienste tatsächlich betriebsfertig, dokumentiert und mit Support-Strukturen bereitstellen – nicht nur als Bauplan, sondern als nutzbares Produkt. Genau das ist der Unterschied zwischen einem Rahmenwerk auf dem Papier und einer Infrastruktur, die im Alltag einer Verwaltung mit drei IT-Mitarbeitenden tatsächlich funktioniert.

Was IT-Verantwortliche in Behörden jetzt tun sollten

Bis zur verbindlichen Governance-Festlegung im ersten Quartal 2026 bleibt Zeit, sich vorzubereiten – die sollte man nutzen. Ein paar konkrete Schritte, die sich aus der aktuellen Lage ableiten lassen:

• Laufende Vertragsverlängerungen und Lizenzverträge auf Exportfähigkeit in offene Formate prüfen, statt automatisch zu verlängern.
• Bestehende Fachverfahren dokumentieren: Welche Schnittstellen sind proprietär, welche folgen bereits offenen Standards?
• Interne Kompetenz für Open-Source-Betrieb aufbauen, statt bei Bedarf komplett auf externe Dienstleister zu setzen – Support-Verträge sind kein Ersatz für Grundverständnis im eigenen Haus.
• Frühzeitig Kontakt zu Landes- und Bundes-Ansprechpartnern für den Deutschland-Stack suchen, um bei der Ausgestaltung konkreter Basisdienste mitzureden, statt fertige Vorgaben nur noch umzusetzen.
• Realistische Migrationsbudgets für die Jahre 2027 und 2028 einplanen, statt den Stack als kostenlose Fertiglösung zu erwarten.
• Datenschutzfolgeabschätzungen für zentrale Basisdienste frühzeitig mitdenken, denn gemeinsame Identitäts- und Zahlungsdienste bündeln Verantwortung an einer Stelle, die im Störungsfall besonders sensibel ist.

Das ist mühsame Kleinarbeit, keine große Digitalisierungs-Show. Aber genau diese Kleinarbeit entscheidet am Ende, ob offene Standards in der Verwaltungspraxis ankommen oder auf der Konzeptpapier-Ebene verharren. Wie das Ministerium in Berlin über digitale Souveränität spricht, ist eine Sache – wie eine Kreisverwaltung mit begrenztem IT-Budget diese Vorgaben tatsächlich umsetzt, eine völlig andere.

Was bleibt?

Der Deutschland-Stack ist, Stand heute, ein ambitioniertes Rahmenwerk mit klarer Richtung, aber ohne die harte Verbindlichkeit, die manche Schlagzeilen suggerieren. Offene Standards werden zur politischen Leitplanke, Open Source bekommt Vorrang, wo möglich – doch der Weg von der Absichtserklärung zur produktiven Basisdienst-Landschaft führt über Jahre voller Vergaberecht, Altverträge und föderaler Reibung. Wer wissen will, ob aus dem Papier wirklich digitale Souveränität wird, sollte weniger auf die nächste Pressemitteilung achten als auf die konkreten Ausschreibungstexte, die in den nächsten Monaten veröffentlicht werden. Dort zeigt sich, ob aus Vorrang tatsächlich Praxis wird – oder ob am Ende doch wieder der bekannte proprietäre Rahmenvertrag gewinnt, weil er sich einfach schneller unterschreiben lässt. Ausführlicher lässt sich das Vorhaben auch in Berichten zur Linux-Offensive in der Verwaltung nachlesen, die einzelne Pilotprojekte konkreter beleuchten als das offizielle Konzeptpapier selbst.