Mehr Offenheit wagen: Wie Open Source die Verwaltung handlungsfähiger macht

Es gibt in Verwaltungsprojekten einen unspektakulären Moment, der in Erfolgsmeldungen oder bei Fototerminen selten eine Rolle spielt. Die Software ist eingeführt, der erste Druck ist raus, die Startphase ist vorbei. Und dann beginnt der glorreiche Alltag: eine Rechtsänderung, ein neues Datenfeld, eine Sicherheitsmeldung, eine Schnittstelle, die sich anders verhält als geplant.

Dann zeigt sich, wie beherrschbar das System wirklich ist.

Genau dort liegt für mich der eigentliche Wert von Open Source in der Verwaltung. Günstiger, schneller oder automatisch besser wird dadurch nichts. Entscheidend ist, ob eine Verwaltung auch nach Jahren noch handlungsfähig bleibt. Kann sie verstehen, was ihre Software tut? Kann sie Fehler nachvollziehen? Kann sie einen Dienstleister wechseln? Kann sie Anpassungen beauftragen, ohne wieder bei null anzufangen?

Open Source löst diese Aufgaben nicht von allein. Es kann Verwaltungen aber helfen, ihre Handlungsspielräume offenzuhalten.

Verwaltungssoftware bleibt lange im Einsatz

Verwaltungen kaufen Software nicht wie ein beliebiges Tool, das man bei Unzufriedenheit einfach gegen ein anderes Abo tauscht. Sie betreiben Verfahren, über die Menschen Leistungen beantragen, Nachweise erbringen, Zahlungen erhalten oder Bescheide bekommen. Hinter einem Formular stehen oft Fachverfahren, Register, Akten, Postfächer, Archivierung und rechtliche Prüfpflichten.

Das stellt besondere Anforderungen. Verwaltungssoftware muss funktionieren, erklärbar bleiben und sich an veränderte Zuständigkeiten, Haushalte und politische Entscheidungen anpassen lassen. Zugleich muss sie Menschen zuverlässig durch den Alltag bringen: Bürger:innen, denen interne Zuständigkeiten egal sein dürfen, und Sachbearbeiter:innen, die technische Abhängigkeiten nicht ausbaden sollten.

Am Anfang eines Projekts denkt man schnell in Funktionen, Terminen und der Frage, wann etwas abgenommen werden kann. Im Betrieb zählen Wartbarkeit, dokumentiertes Wissen, verlässliche Sicherheitsupdates und verständliche Schnittstellen. Ein Fehler sollte sich nicht nur feststellen, sondern auch eingrenzen lassen.

Hier wird Offenheit praktisch.

Handlungsfähig ist, wer Optionen hat

Digitale Souveränität ist inzwischen ein verbreitetes und entsprechend unscharfes Schlagwort. Für mich wird der Begriff brauchbar, wenn man ihn auf eine einfache Frage herunterbricht: Hat eine Organisation echte Optionen?

Technisch heißt das, dass Daten nicht in einem proprietären Format gefangen sind, Schnittstellen nachvollziehbar bleiben und Komponenten ersetzt werden können. Organisatorisch darf Wissen nicht ausschließlich im Kopf einzelner Personen oder bei einem Anbieter liegen. Wirtschaftlich muss ein Wechsel möglich bleiben, ohne ein komplettes System neu zu bauen.

Open Source kann dabei helfen, sofern mehr als der Quellcode offenliegt. Ohne Dokumentation entsteht keine Souveränität. Eine gute Lizenz nützt wenig ohne verlässlichen Betrieb. Unklare Architekturentscheidungen, Datenmodelle und Schnittstellen begrenzen den Handlungsspielraum weiterhin.

Open Source entfaltet seinen Wert erst als Teil einer nachhaltigen Arbeitsweise. Software muss so gebaut, beschafft und gepflegt werden, dass spätere Entscheidungen möglich bleiben. Daran entscheidet sich, ob die Verwaltung auch in fünf oder mehr Jahren noch handeln kann.

Abhängigkeiten entstehen selten mit Absicht

Der klassische Vendor-Lock-in, also die Abhängigkeit von einem Anbieter, die einen Wechsel technisch, organisatorisch oder wirtschaftlich erschwert, beginnt selten mit einer bewussten Fehlentscheidung. Meist entsteht er durch lauter kleine pragmatische Schritte. Eine proprietäre Schnittstelle, weil es schneller geht. Eine Sonderanpassung, die dauerhaft nur in einer einzelnen Installation steckt. Ein Updateprozess, den nur ein Dienstleister wirklich beherrscht. Ein Datenexport, der zwar theoretisch existiert, praktisch aber kaum nutzbar ist.

Jeder dieser Schritte kann für sich genommen nachvollziehbar und sinnvoll sein. Zusammengenommen erzeugen sie aber ein System, aus dem man nur noch schwer herauskommt. Dann ist ein Anbieterwechsel zwar nicht unmöglich, aber so teuer und riskant, dass er kaum noch als echte Option gilt. Unter Budgetdruck zieht ihn dann kaum jemand ernsthaft in Erwägung.

Open Source verschiebt diese Dynamik. Wenn Quellcode offen verfügbar ist, können Dritte ihn prüfen, erweitern und im Zweifel übernehmen. Wenn Änderungen sauber dokumentiert sind, kann Wissen transferiert werden. Wenn Anpassungen wieder in die gemeinsam gepflegte Version aufgenommen werden, müssen sie nicht bei jedem Update erneut mühsam nachgezogen werden.

Dienstleister werden dadurch nicht überflüssig. Ihr Wert liegt in einem solchen Modell in Kompetenz, Verlässlichkeit und guter Zusammenarbeit, nicht in exklusivem Wissen oder künstlicher Abschottung. Die Verwaltung kauft dann nicht nur Zugriff auf eine Software-Blackbox, sondern Entwicklungs- und Betriebskompetenz, die sich im besten Fall auch auf andere Organisationen oder Projekte übertragen lässt.

Offenheit muss praktikabel sein

Damit offene Software Abhängigkeiten wirklich reduziert, muss klar sein, welche Rechte mit ihr verbunden sind. Darf eine Kommune sie selbst betreiben? Darf ein IT-Dienstleister sie für mehrere öffentliche Stellen betreiben? Dürfen Anpassungen weitergegeben werden? Was passiert, wenn mehrere öffentliche Stellen ein Projekt gemeinsam finanzieren? Solche Fragen entscheidet nicht das persönliche Gefühl von Offenheit, sondern der konkrete Lizenztext.

Die Open Source Definition der Open Source Initiative liefert dafür einen anerkannten Referenzrahmen. Open Source meint demnach nicht nur sichtbaren Code, sondern Nutzungs-, Änderungs- und Weitergaberechte. Allgemeinere Begriffe wie „quelloffen“ oder „source-available“ können sinnvoll sein, brauchen aber dieselbe Klarheit: Welche Nutzung ist erlaubt und welche nicht?

Diese Rechte haben wirtschaftliche Folgen. Lizenzen, die mit den Kriterien der OSI vereinbar sind, erlauben auch die kommerzielle Nutzung durch Wettbewerber. Diese Offenheit liegt besonders nahe, wenn Software öffentlich finanziert wurde und andere öffentliche Stellen sie nachnutzen sollen. Bei privat vorfinanzierten Produkten muss zusätzlich klar sein, wie Pflege, Support und Weiterentwicklung getragen werden.

Sogenannte Copyleft-Lizenzen verpflichten bei Verbreitung dazu, dieselben Freiheiten weiterzugeben. Beispiele sind die GPL und die AGPL. Bei der AGPL gilt die Pflicht zur Bereitstellung des korrespondierenden Quellcodes zusätzlich für veränderte Software, mit der Nutzer:innen über ein Netzwerk interagieren. Solche Lizenzen schaffen innerhalb des OSI-Rahmens mehr Gegenseitigkeit, lösen aber nicht jedes Finanzierungsproblem.

Daneben gibt es Modelle mit einsehbarem Quellcode, die bestimmte kommerzielle Nutzungen einschränken. Bei Aivot nutzen wir zum Beispiel für bestimmte Komponenten die Sustainable Use License, die n8n 2022 geschaffen hat und selbst nutzt. Für unseren konkreten Anwendungsfall heißt das vereinfacht: Die Software darf unter den Lizenzbedingungen für eigene interne Zwecke genutzt und angepasst werden. Unter dieser Lizenz ist es jedoch nicht erlaubt, dass ein Dritter sie ohne gesonderte Vereinbarung als eigenes kommerzielles SaaS-Angebot, also als laufenden Online-Dienst, betreibt. Nach der OSI-Definition ist das keine Open-Source-Lizenz. Solche Modelle sollten deshalb klar bezeichnet und für den jeweiligen Einsatz geprüft werden.

Die Beschaffung entscheidet früh mit

Open Source war in der öffentlichen Beschaffung lange unnötig mühsam. Grundsätzlich beschaffbar war die Software, doch viele Routinen und Vertragsmuster waren auf proprietäre Produkte zugeschnitten. Wer offene Software wollte, musste oft mehr erklären, mehr individuell regeln und mehr Unsicherheit aushalten.

Die im März 2026 veröffentlichten EVB-IT-Vertragsmuster setzen an diesem Problem an. EVB-IT sind die ergänzenden Vertragsbedingungen, mit denen die öffentliche Hand IT-Leistungen beschafft. Die neuen Muster berücksichtigen Open-Source-Software und Open-Source-Dienstleistungen ausdrücklich.

Nach Angaben des ZenDiS, des Zentrums für Digitale Souveränität der Öffentlichen Verwaltung, wurden acht Vertragsmuster überarbeitet. Neue Softwareprojekte der öffentlichen Verwaltung können damit standardmäßig als Open-Source-Software entwickelt und leichter auf openCode veröffentlicht werden, einer Plattform für offenen Quellcode aus der Verwaltung. Die Muster enthalten außerdem Optionen für die Übergabe einer SBOM, also einer Art Zutatenliste der verwendeten Softwarebestandteile.

Die Form der Beschaffung entscheidet früh darüber, ob später Optionen entstehen oder verschwinden. Wird die Veröffentlichung mitgedacht? Werden Nutzungsrechte sauber geregelt? Gibt es Anforderungen an Dokumentation, Tests, Sicherheitsprozesse und Abhängigkeiten? Ist geregelt, wie Verbesserungen in die gemeinsam gepflegte, offizielle Version zurückkommen, statt ein Dasein als Sonderlösung zu fristen?

Eine gute Ausschreibung macht „Open Source“ noch nicht zu einem guten Produkt. Sie kann aber verhindern, dass Offenheit erst dann eingefordert wird, wenn das Projekt längst falsch aufgesetzt ist und in eine andere Richtung läuft.

Was große Umstellungen uns zeigen

Schleswig-Holstein zeigt derzeit, dass Open Source in der Verwaltung nicht nur aus Grundsatzpapieren bestehen muss. Das Land hat 2024 seine Open Innovation und Open Source Strategie veröffentlicht und arbeitet an einem digital souveränen Verwaltungsarbeitsplatz. Dazu gehören unter anderem LibreOffice, Open-Xchange, Thunderbird, Nextcloud, OpenTalk und die Erprobung von Linux.

Die Größenordnung ist bemerkenswert. Im Oktober 2025 meldete das Land, das Mailsystem der Landesverwaltung nach einem sechsmonatigen Prozess mit mehr als 40.000 Postfächern und deutlich mehr als 100 Millionen E-Mails und Kalendereinträgen auf Open-Xchange und Thunderbird umgestellt zu haben. Im Dezember 2025 folgte die Meldung, dass LibreOffice auf nahezu 80 Prozent der Arbeitsplätze außerhalb der Steuerverwaltung eingesetzt wird.

Ich würde daraus keine einfache Erfolgserzählung machen. Solche Migrationen sind anstrengend. Sie berühren Arbeitsabläufe, Fachverfahren, Schulungen, Gewohnheiten und Mitbestimmung. Wenn etwas nicht funktioniert, landet der Druck nicht in einer Strategiepräsentation, sondern bei den Mitarbeitenden. Der Wert dieser Beispiele liegt in ihrer organisatorischen Dimension. Open Source verändert auch, wie eine Organisation arbeitet: Wer geschult werden muss, wer Support übernimmt, welche Prozesse angepasst werden und wie viel Geduld eine Umstellung im Alltag wirklich braucht.

Auch München bleibt lehrreich. LiMux war das Münchner Projekt, mit dem die Stadtverwaltung ab den 2000er-Jahren viele Arbeitsplätze von Microsoft Windows und Office auf Linux und freie Software umstellen wollte. Später wurde diese Linie politisch teilweise zurückgedreht. LiMux diente danach lange als Symbol: mal für Open-Source-Erfolg, mal für Open-Source-Scheitern. Beides greift zu kurz. Die heutige Münchner Open-Source-Strategie formuliert wieder klar, dass selbst entwickelte Software unter passenden rechtlichen Bedingungen als Open Source umgesetzt und Open-Source-Lösungen bevorzugt beschafft werden sollen. Die Stadt nennt auf ihrer Seite München Open Source sehr nüchtern Gründe wie Herstellerunabhängigkeit, Wiederverwendung, Zusammenarbeit, Sicherheit und Vertrauen.

Diese Nüchternheit ist hilfreich. Sie nimmt Open Source aus der Symboldebatte und bringt es zurück zur Kernfrage, wie Verwaltung langfristig arbeitsfähig bleibt.

Der schwierige Teil ist Pflege und Weiterentwicklung

Mit der Veröffentlichung des Codes beginnt der schwierige Teil oft erst. Jemand muss Sicherheitsmeldungen bewerten, neue Versionen planen, Abhängigkeiten aktualisieren, Umstellungen vorbereiten, Fragen beantworten, Dokumentation schreiben und Prioritäten sortieren.

Gerade diese Arbeit erhält in Projekten oft zu wenig Budget und Aufmerksamkeit. Veröffentlichter Code ohne Pflege bleibt im Zweifel eine Ablage. Ein offenes Projekt ohne klare Verantwortung kann sogar zusätzliche Unsicherheit erzeugen, weil theoretisch alle etwas tun könnten, praktisch aber niemand zuständig ist.

Damit wird Open Source zu einer Produktfrage: Wer trägt langfristig Verantwortung? Wer bezahlt Wartung und Weiterentwicklung? Wer entscheidet, welche Anforderungen in die gemeinsame Version aufgenommen werden? Wer sorgt dafür, dass nicht jede Behörde ihren eigenen kleinen Sonderweg entwickelt?

Für Verwaltungen ist diese Sicht unbequem, aber hilfreich. Sie verlangt, Software als fortlaufend gepflegte Infrastruktur zu behandeln und nicht als einmalige Lieferung. Aus meiner Sicht ist das der Kern einer ernsthaften Open-Source-Strategie.

KI ändert das Tempo, nicht die Verantwortung

Auch KI verändert diese Debatte. Cloudflare zeigt mit EmDash und vinext, wie schnell sich umfangreiche Softwarekonzepte inzwischen mit KI-Unterstützung neu umsetzen lassen.

Technisch finde ich das super faszinierend. Für Verwaltungen sollte dennoch eine andere Frage im Vordergrund stehen: Wer pflegt so etwas in drei Jahren?

KI kann neue Alternativen erzeugen, aber auch Abspaltungen, Varianten und halbfertige Projekte vermehren. Damit werden Herkunft, Wartung, verlässliche Veröffentlichungen, Sicherheitsprozesse und klare Zuständigkeiten noch wichtiger.

Das gilt genauso für KI-Systeme selbst. In der Praxis begegnet KI der Verwaltung oft als Funktion in einem Fachverfahren, als Assistenzsystem oder als externer Dienst über eine Schnittstelle. Dann ist vieles nicht unmittelbar sichtbar: welches Modell genutzt wird, wohin Daten fließen, welche Schutzmechanismen greifen, wann ein Modell ausgetauscht wird und wie Fehler oder Verzerrungen geprüft wurden.

Die Folgen werden konkret, sobald ein KI-System Anträge vorsortiert, Texte erzeugt oder Mitarbeitende bei Entscheidungen unterstützt. Dann muss nachvollziehbar sein, wofür es geeignet ist, wo seine Grenzen liegen und wer Änderungen verantwortet. Sonst entsteht eine neue Form von Abhängigkeit: nicht nur vom Code, sondern von einem Modellverhalten, das sich kaum prüfen lässt.

Open-Weight-Modelle, also KI-Modelle, deren gelernte Parameter veröffentlicht sind, sind darauf eine mögliche Antwort, reichen allein aber nicht aus. Die gelernten Zahlen im Modell liegen dann offen; mit welchen Daten trainiert wurde, welche Inhalte herausgefiltert wurden und welche Tests es gab, sieht man daraus aber nicht zuverlässig. Die Open Source AI Definition 1.0 der OSI fasst Offenheit bei KI deshalb breiter: Es geht auch um Dateninformationen, Trainingscode und die Möglichkeit, ein System wirklich zu untersuchen, zu verändern und neu zu bauen.

Offenheit, die im Alltag trägt

Ich wünsche mir mehr Open Source in der Verwaltung. Entscheidend ist für mich, dass daraus weder Symbolpolitik noch eine reine Pflichtübung wird. Software muss langfristig betreibbar, prüfbar und austauschbar bleiben.

Mehr Offenheit wagen beginnt bei jeder relevanten Softwareentscheidung mit konkreten Fragen. Können wir das System verstehen? Können wir Daten mitnehmen? Können wir Anbieter wechseln? Können wir Verbesserungen teilen? Können wir Wartung finanzieren? Können wir gegenüber Bürger:innen und Mitarbeitenden erklären, warum ein System vertrauenswürdig ist?

Wer diese Fragen ernst nimmt, nutzt Open Source als Mittel für mehr Handlungsfähigkeit. Offene Software ist nicht automatisch besser, erhöht aber die Chance, später noch gute Entscheidungen treffen zu können.

Für die Verwaltung ist das vielleicht der wichtigste Punkt: Software muss dort nicht nur in Betrieb gehen. Sie muss bleiben können.