Ohne einen Ort für Code bleibt EfA Theater

Ursprünglich 2021 bei publicplan erschienen . Inhaltlich gleicher Artikel, in meiner persönlichen Sichtweise geschrieben.

Stellen Sie sich vor, drei Behörden bauen im Sinne des EfA-Prinzips eine gemeinsame Lösung für die Online-Terminbuchung. Behörde D, sechs Monate später vor dem gleichen Problem, sucht nach einer bestehenden Lösung. Wo schaut sie nach? Wer pflegt das Verzeichnis? Wer prüft, ob die Lösung zu den eigenen Anforderungen passt?

Hier hakt es bisher. Das EfA-Prinzip funktioniert nur, wenn nachnutzungswillige Verwaltungen die nachnutzbaren Lösungen finden . Ohne einen zentralen Ort für Code bleibt EfA ein Versprechen ohne Liefer-Mechanik.

Was schon angelegt ist

Das Bewusstsein dafür ist gewachsen. Initiativen wie „Public Money? Public Code!" machen seit Jahren deutlich, was Open Source in der Verwaltung leisten kann. Der 9-Punkte-Plan des Bundes-CIO Markus Richter setzt Open Source als strategisches Element. Das EfA-Prinzip ist als föderaler Konsens akzeptiert. All das ist Voraussetzung. Es ist aber noch keine Lieferung.

Die Open Source Business Alliance und Vitako haben gemeinsam mit mehreren Partnern, das Konzept „Ein Ort für öffentlichen Code" vorgelegt. Im März 2021 haben das Land Nordrhein-Westfalen, Baden-Württemberg und der Bund angekündigt, daraus ein Pilotprojekt zu starten. Mitte 2021 soll die Plattform stehen. Sie schließt die Lücke, an der Nachnutzung bislang scheitert: einen gemeinsamen, durchsuchbaren Bestand von Verwaltungs-Software mit Quellcode, Dokumentation und nachvollziehbarem Steckbrief.

Warum nicht einfach GitHub

Der Reflex liegt nahe. GitHub ist das mit Abstand größte Code-Repository der Welt, von Microsoft betrieben, von Millionen Entwickler:innen täglich verwendet. Warum nicht einfach dort hinlegen, was die Verwaltung baut?

Die Antwort liegt nicht in der Technik, sondern in der Rechtssicherheit. GitHub liegt unter US-Recht, ist über den CLOUD Act für US-Behörden zugriffsfähig und kann seine Nutzungsbedingungen jederzeit ändern. Für eine privatwirtschaftliche Open-Source-Community ist das unproblematisch. Für eine Plattform, auf der die deutsche Verwaltung Software hinterlegt, die in kritischen Verfahren läuft, ist das eine strukturelle Abhängigkeit, die sich vermeiden lässt.

Hinzu kommt: Der Bedarf der Verwaltung ist nicht der einer reinen Entwickler:innen-Community. Wer in der Behörde mit Beschaffungs-Verantwortung arbeitet, muss in einer Code-Plattform andere Dinge schnell finden können als ein Open-Source-Maintainer. Welche Lösungen lösen welches fachliche Problem? Welche Lizenz steht dahinter? Welcher Reifegrad? Welche Behörde nutzt das produktiv? Solche Fragen beantwortet GitHub nicht. Und ist auch nicht dafür gemacht.

Was die Verwaltungs-Plattform leisten muss

Eine Plattform für öffentlichen Code muss zwei Dinge gleichzeitig tun. Sie muss technisch brauchbar sein für die, die wirklich Code verwalten. Repository-Funktionen, Versionierung, Issue-Tracking, Pull-Request-Workflows in einer Qualität, die der Entwicklung gerecht wird. Und sie muss zugänglich sein für die, die nicht selbst Code schreiben, aber Lösungen suchen oder anbieten. Ein Steckbrief-Layer, der Lösungen so beschreibt, dass auch Nicht-Techniker:innen Eignung und Anschluss-Aufwand abschätzen können.

Diese Verbindung von Entwickler:innen- und Verwaltungs-Sicht ist der eigentliche Wert. GitHub kann die erste Hälfte. Ein Steckbrief-Portal kann die zweite Hälfte. Eine deutsche Verwaltungs-Plattform muss beide sauber miteinander verbinden, mit Melde- und Vorschlagswegen, die direktes Feedback an die Maintainer ermöglichen.

Ein Beispiel, das die Differenz greifbar macht: Wenn eine Stadt eine Online-Terminbuchung sucht, will sie nicht zwanzig Repositories durchwühlen. Sie will einen Steckbrief, der ihr zeigt, welche Lösung in welcher anderen Kommune bereits produktiv läuft, mit welcher Lizenz, welchem Pflegestatus, welchem Beispiel-Setup. Der Sprung in den Quellcode kommt dann erst, wenn die Vorauswahl steht. Diese Vorauswahl ist auf GitHub heute nicht möglich.

Das Rad muss nicht neu erfunden werden

Die gute Nachricht: Die Bausteine existieren. GitLab, Gitea und ähnliche Open-Source-Lösungen können als Basis dienen. Für den Steckbrief-Layer gibt es Standards aus dem internationalen Public-Money-Public-Code-Umfeld, etwa die publiccode.yml-Spezifikation aus dem italienischen Verwaltungs-Kontext. Was fehlt, ist die Integration und der Betrieb im deutschen Verwaltungs-Kontext.

Genau das soll das Pilotprojekt aus NRW, BW und dem Bund leisten. Wenn es gelingt, wird der Ort für öffentlichen Code für das EfA-Prinzip das, was der Portalverbund für die OZG-Bürger:innen-Sicht ist: die Mechanik, ohne die das Versprechen nicht trägt.

Eine Plattform ist erst der Anfang

Eine Plattform allein nützt allerdings nichts, wenn sie nicht gefüllt und gepflegt wird. Die Frage, wer welchen Code dort hinlegt, wer ihn pflegt, wer für die Qualität bürgt, ist eine Governance-Frage. Sie wird nicht im Plattform-Design entschieden, sondern in den Vergaben, Verträgen und Kooperationsvereinbarungen, die rund um sie geschlossen werden. Wer Open-Source-Code beauftragt und nicht festschreibt, dass er auf der gemeinsamen Plattform landet, sorgt dafür, dass die Plattform leer bleibt.

Ein Ort für öffentlichen Code ist kein Selbstzweck. Er ist die Bedingung dafür, dass die anderen Versprechen wie EfA, Nachnutzung und digitale Souveränität überhaupt eingelöst werden können. Ohne diesen Ort bleibt jede Lösung in ihrem Tresor. Und EfA bleibt Theater.

Hat Sie das Thema interessiert?

Dann schreiben Sie mir gerne eine kurze Nachricht.