Im August 2025 stolperte ich ueber die Veroeffentlichung „Nachnutzung digitaler Lösungen
statt Modellprojekte“ der Projekte Agora Digitalwende und re:form. Begleitend wurden die Autoren des Papiers vom Handelsblatt zitiert, dass viele gefoerderte Freie-Software-Projekte nie die „Modellkommune“ verlassen wuerden, innerhalb derer sie gefoerdert wurden. Damit, so die Autoren, „verpuffe“ die Wirkung der Foerderung zu haeufig. Es fehle an einer „Nachnutzung“, an der man die Effektivitaet der eingesetzten Foerderung messen koenne.

Witzigerweise bezieht sich sowohl das veroeffentlichte Papier als auch der Handelsblatt-Artikel deutlich auf den intermodalen Routenplaner „stadtnavi“, fuer den die Stadt Herrenberg gefoerdert worden war. „Witzigerweise“, weil stadtnavi direkt auf die von einer oeffentlichen Stelle entwickelte Freie Software digitransit zurueckgeht, die wiederum durch robbi5 aus dem Digitalen Ehrenamt ueberhaupt erst den Weg nach Deutschland gefunden hat – und ich das quasi live miterlebt hatte. Das „Original“ laeuft nach wie vor langfristig und solide in Helsinki; stadtnavi war selber quasi die „Nachnutzung“ einer „Nachnutzung“.
Witzig ausserdem, weil ich selber ein gefoerdertes Projekt begleitet habe, in dem digitransit eine Rolle spielte, und bei dem der forscherische Kernaspekt ueberhaupt gar nichts mit „Nachnutzung“ zu tun hatte, sondern mit dem Ziel eines besseren Lagebilds des Digitalisierungszustands.

Gegenthesen zur „Nachnutzung“: Warum sie oft gar kein sinnvolles Ziel ist, und was bessere Ansaetze sind

Ich wuerde daher gerne ein wenig mit der „Nachnutzung“ Freier Software als Zielmetrik aufraeumen und einige Gegenthesen in den Raum stellen:

1. Nicht bei jedem Softwaresystem ist es ueberhaupt sinnvoll, dass es anschliessend durch moeglichst viele Kommunen „nachgenutzt“ wird. Im Gegenteil kann es sinnvoller sein, den kommunal durchgespielten Anwendungsfall anschliessend deutlich groesser zu denken und z.B. auf Landesebene auszurollen.
2. Manchmal kann ein greifbarer Anwendungsfall als Durchstich dazu dienen, die vorhandene IT-Infrastruktur, bestehende Datenfluesse und Bedarfe zur Verbesserung von beiden zu kartieren. Das Projekt ist dann eine Lageerkundung darueber, woran vergleichbare Vorhaben in der Praxis bislang scheiterten und was getan werden muss, um die damit verbundenen Huerden zu beseitigen
3. In Verbindung von 1. und 2. kann das bedeuten, dass ein getestetes System in der Folge nur von wenigen Traegern betrieben werden muss – willige Kommunen aber wertvolle Erkenntnisse gewinnen koennen, was sie selbst vor Ort und in ihrem Wirkungsbereich tun muessten, um zu dem dadurch entstehenden Oekosystem beitragen zu koennen.
4. Ganz nebenbei: Stadtnavi ist immerhin nicht nur „Open Source“, sondern Freie Software – das heisst, dass die dort eingeflossenen Foerdergelder zu einem Gemeingut beigetragen haben, das fuer immer als solches erhalten bleiben wird, ohne dass es spaeter einfach privatisiert werden kann.

Insbesondere die Punkte 3 und 4 sind fuer mich moegliche Kernanliegen und Foerderziele. Viele Thesen rund um die Smart-City-Foerderung gehen davon aus, dass Massnahmen auf eine funktionierende, vorhandene IT-Infrastruktur gemaess der anerkannten Regeln der Technik stossen. Meine Praxiserfahrung ist, das man sich von dieser Annahme grusslos verabschieden sollte. Eine der groessten politischen Huerden ist vielmehr, vorhandene technische Schulden und infrastrukturelle Defizite in das mentale Modell der Entscheider*innen als real und akzeptierbar einzubringen. Es ist oft immer noch eine Herausforderung, noetige Haushaltsentscheidungen nicht als optionale Nice-to-have-Massnahmen, sondern als den Abbau eines hochverzinsten Kredits darzustellen. Das ist umso tragischer, da gerade ueber Foerderungen wie im Smart-City-Programm mit ueberschaubarer Kreativitaet die Mittel fuer den weitsichtigen Aufbau bislang fehlender Komponenten haetten eingesetzt werden koennen – aber ueberwiegend nicht wurden.

Zudem geht die ganz praktische Betriebslogik bislang in den meisten Faellen davon aus, dass Softwaresysteme einfach „beschafft“ und viel zu oft von externen Dienstleistern betrieben werden. Zwar sehen die Foerderbedingungen der MPSC-Foerderung „Open-Source-Software“ als Bedingung vor. Gerade die weicheren, sogenannten „permissiven“ Open-Source-Lizenzen (im Gegensatz zu Freie-Software-Lizenzen) ermoeglichen es einem beauftragten Dienstleister jedoch, eine mit seiner Expertise aus dem Auftrag weiterentwickelte Variante eines aus oeffentlichen Mitteln gefoerdertes Systems im Anschluss als Closed-Source-Variante fuer zahlende Kundschaft anzubieten. Die Entwicklung und der Aufbau der Expertise beim Dienstleister wurde zwar aus oeffentlichen Mitteln finanziert, das Endprodukt kann jedoch der Allgemeinheit wieder entzogen werden.

Die Verbindung dieser beiden Straenge sorgt dann fuer die bisweilen etwas hilflos wirkenden Vorschlaege rund um „Marktplaetze“ und aehnliche „klick-dir-dein-Produkt“-Denklogiken. In manchen Konstellationen mag es sinnvoll sein, ein Produkt von einem darauf spezialisierten Dienstleister as-a-Service betreiben zu lassen. Dann sollte umso mehr darauf geachtet werden, dass dieser Dienstleister nicht zur kritischen Abhaengigkeit werden kann.
In vielen anderen Faellen geht es um fundamentale Basisdienste und -infrastrukturen, die manche oeffentliche Stellen selber zu betreiben in der Lage sein sollten. Die dafuer notwendigen Voraussetzungen werden durch Marktplaetze nicht geschaffen. Punkt.

Wie kam eigentlich stadtnavi nach Deutschland?

stadtnavi ist ein direkter Ableger des vom Verkehrsverbund HSL in Helsinki entwickelten digitransit-Projekts. HSL begann um 2014 (PDF), seinen bisherigen Auskunftsdienst durch ein neues Freie-Software-System auf Basis des aus der OpenStreetMap-Welt bekannten OpenTripPlanner zu ersetzen. OpenTripPlanner (OTP) entstand wiederum ab 2009 als Freie Software (unter der LGPLv3-Lizenz) unter Mitwirkung des Portlander Verkehrsverbundes TriMet, der schon eine wichtige Rolle bei der Entwicklung des offenen Fahrplandatenstandards GTFS gespielt hatte. Ab dem Start der Entwicklung waren aber auch zahlreiche andere Akteure an Bord, die in den ersten Jahren seit Veroeffentlichung des GTFS-Standards Software fuer die praktische Anwendung entwickelt hatten. HSL nutzte fuer digitransit „unter der Haube“ OTP als Routenplaner und verpasste ihm ein total neues Look and Feel und eine deutlich verbesserte Usability.

Die Entwicklung von OTP ab 2009 war mit dem Ziel gestartet, Reiseauskuenfte unter Verknuepfung von OpenStreetMap-Kartendaten und maschinenlesbaren ÖPNV-Fahrplaenen zu ermoeglichen – damals vorwiegend noch mit GTFS-Fahrplandaten, spaeter auch unter Beruecksichtigung der europaeischen Fahrplandatenstandards Netex und SIRI. Fuer letzteres spielte die immer breitere Verwendung von Freier Software wie OTP und digitransit in Skandinavien eine wichtige Rolle. Die dortigen Verkehrsverbuende und Aufgabentraeger arbeiteten in den 2010er-Jahren immer mehr zusammen und ergaenzten sich als „Open Mobility Data in the Nordics“ (ODIN) bei ihren Bestrebungen gegenseitig – das kann man beispielsweise in diesem Positionspapier von 2019 nachlesen. Der norwegische Aufgabentraeger Entur trug in der Folge zur Weiterentwicklung von OTP bei, so dass das System seither auch die europaeischen Datenstandards fuer Auskuenfte verwenden kann.

Das alles passierte wohlgemerkt in einer Zeit, in der oeffentliche Fahrplaene in Deutschland noch Mangelware waren. Im Umfeld von Code for Germany wuchs zwar eine aktive Transit-Hacking-Community, die sich fuer offene Fahrplandaten einsetzte, den Ist-Zustand kartierte und sich auf Veranstaltungen wie den ab 2015 stattfindenden DB-Hackathons vernetzte und austauschte. Bis zum Ende der 2010er-Jahre gab es aber im Gegensatz zu den skandinavischen Laendern in Deutschland keine flaechendeckenden offenen Fahrplandaten – und das, obwohl die EU durch eine delegierte Verordnung einen klaren Zeitplan fuer eine verpflichtende Veroeffentlichung erlassen hatte.

Und damit kommen wir zu der Antwort, wie digitransit nach Deutschland kam und spaeter zu stadtnavi wurde. Maxi aka robbi5, einer der vielen Ehrenamtlichen der deutschsprachigen Transit-Hacking-Community hatte irgendwann das digitransit-Repository auf github gefunden und der Benutzeroberflaeche im Dezember 2016 eine deutsche Uebersetzung hinzugefuegt. Und wie es der Zufall wollte, passierten nacheinander ein paar Zufaelle: Im Januar 2018 kam eine Abordnung mit Stefan Kraus vom „agilen Bauhof“ aus Herrenberg nach Ulm, um sich bei der Ehrenamtscommunity im damaligen „echten Verschwoerhaus“ ueber das freie LoRaWAN-Sensornetzwerk TTN zu informieren. Auch irgendwann 2018 begann robbi5, eine digitransit-Instanz mit Ulmer Fahrplandaten zu befuellen und unter ulm.ententei.ch zu betreiben. Und bei einem neuerlichen Besuch der Herrenberger im Sommer 2018 kam ganz zufaellig nebenbei das Thema auf, dass man in Herrenberg gerne irgendwas mit Mobilitaetsauskuenften machen wuerde, und robbi5 konnte sagen, „ich hab da was fertiges vorbereitet“.
Der Rest ist, wie man gerne sagt, Geschichte. (Mehr dazu u.a. hier, hier oder hier)

Stadtnavi ist also bereits eine „Nachnutzung“, oder wie man ausserhalb der Verwaltung einen korrekteren Begriff waehlen wuerde: Eine Wiederverwendung der Vorarbeit vieler anderer Akteure, ohne die solch ein Projekt in dieser Form gar nicht moeglich gewesen waere. Viele andere Menschen aus der deutschsprachigen Transit-Bubble haben in der Folge dazu beigetragen, sowohl stadtnavi als auch die anderen Ableger wie BBNavi und Co zu erweitern und auch strategisch ueber die Fortentwicklung der zugrundeliegenden Komponenten nachzudenken.

Das ist auch ein Grund, warum ich nur maessig begeistert ueber das von den Herrenbergern durchgefuehrte Re-Branding von digitransit als „stadtnavi“ war – zwar waren damit auch Anpassungen auf oertliche Beduerfnisse verbunden, ich hatte aber von Anfang an befuerchtet, dass dadurch die Urspruenge und der Geist der internationalen kooperativen Arbeit an etwas Gemeinsamen aus der Wahrnehmung verschwinden koennten.
Zudem – und damit kommen wir zu Punkt 1 meiner Kritik – erweckte das Branding den Eindruck, dass digitransit etwas ist, was sinnvollerweise jede Stadt fuer sich ausrollen sollte. Diesen Eindruck teile ich nicht und ich hielt dieses Framing von Anfang an fuer falsch.

Kritik 1: Lokal ausprobieren, Skalierung durch gemeinsamen Betrieb statt „Nachnutzung“

Ich bin ein grosser Fan, den Zustand der real existierenden Verwaltungsdigitalisierung durch eine Praxis der unterschiedlichen Geschwindigkeiten voranzubringen. Kommunen sollten sich zwar nicht als ausfuehrende IT-Entwicklungsakteure fuer Neues missbrauchen lassen – sie koennen aber zwei Fliegen mit einer Klappe schlagen und die Internalisierung von IT-Architekturkompetenzen mit dem praktischen Rollout bestehender, ausserhalb der deutschen Verwaltung bewaehrter Systeme verbinden.

Das kann auch bedeuten, dass man als Kommune im Rahmen eines Projekts ein System ausrollt und demonstriert – dass dessen langfristiger Betrieb aber eigentlich anderswo viel besser aufgehoben waere. Digitransit ist meines Erachtens ein Paradebeispiel dafuer: Im Idealfall soll ein intermodaler Routenplaner ja kommunen- und regionenuebergreifend funktionieren und Mobilitaet abseits des Rueckgriffs auf ein eigenes Kraftfahrzeug so muehelos wie moeglich machen. Klassischerweise betreiben zwar neben den Aufgabentraegern der Laender auch viele Verkehrsverbuende eigene Mobilitaetsauskuenfte. Sie greifen aber dafuer auf eine gemeinsame, geteilte Informationsinfrastruktur zurueck. Langfristig sehe ich einen sinnvollen Betrieb von Mobilitaets-Auskunftssystemen wie digitransit daher eher auf Landes- oder gar Europaebene – das verwandte Projekt transitious zeigt seit Anfang 2024 auf beeindruckende Weise, wie so etwas aussehen koennte. Und der anfaengliche praktische Rollout sowie die bessere Dokumentation der dafuer notwendigen Voraussetzungen in Herrenberg und Ulm haben dazu gefuehrt, dass auch Aufgabentraeger der Laender auf das System aufmerksam wurden und eine Anwendbarkeit im eigenen Bereich geprueft haben.

Das Branding von stadtnavi als Stadt-System sowie die an manchen Orten immer wieder laut werdenden Rufe nach „Marktplaetzen“, in denen sich eine Kommune eine angepasste White-Label-Loesung bestellen kann, sorgt dagegen eher fuer einen Flickenteppich, in dem zwar die beschworene „Nachnutzung“ stattfindet, aber nur die Dienstleister als Anbieter der Loesung von Skaleneffekten profitieren. Wenn diese Praxis durch Anreize in der Foerderlogik noch weiter befeuert wird, kann zwar die ohnehin aufgeblaehte GovTech-Bubble weiter gefoerdert werden. Eine Entwicklung hin zu einem viel groesser gedachten Oekosystem wird dadurch aber eher verhindert. Die Erfahrungen zeigen, dass das EFA-Prinzip in der Praxis selten funktioniert. Wie man aktuell bei F13 vs. LLMoin vs. BaerGPT sieht, kommt am Ende doch jede Instanz mit einem Not-invented-here-Einwand um die Ecke und moechte lieber „Meines fuer alle“ entwickeln. Das ist bei einem blasenartigen Hype wie LLMs fuer die oeffentliche Verwaltung (siehe auch) moeglicherweise ausgepraegter als bei gut abgehangenen Systemen wie Mobilitaetsauskuenften. Dennoch wirkt es mich auf mich immer wieder so, als wolle man mit auf den Ist-Zustand angepassten Spezialloesungen einfach den Status Quo der bestehenden IT-Infrastruktur beibehalten und um historische Defizite herumentwickeln, anstatt die bestehenden Systeme im Rahmen eines solchen Projekts auf den Stand der Zeit zu heben.

Kritik 2: Freie-Software-Projekte als Lackmustest fuer den Ist-Zustand oeffentlicher IT-Architektur und Datenflussparadigmen

Die Denkweise, oeffentlich gefoerderte Softwareprojekte als Selbstzweck zu betrachten, der an moeglichst vielen Orten dann „nachgenutzt“ werden soll, vernachlaessigt zudem vollkommen die Idee, solch ein Projekt stattdessen als Analyse- und Lernanlass zu verstehen.

Eine Analogie, die mir dazu einfaellt, ist eine Katastrophen- oder Brandschutzuebung. Im besten Fall kann sie natuerlich unter Beweis stellen, dass die vorab geplanten Ablaeufe gut funktionieren, die Rahmenbedingungen passen, und es keinen Verbesserungsbedarf gibt. Bei einer solchen Uebung jedoch zu erkennen, was nicht funktioniert, wo Annahmen sich als nicht zutreffend herausstellen und welche naechsten Schritte ergriffen werden muessen, ist derweil kein Fehlschlag der Uebung, sondern ein wertvoller Wissenszuwachs.

Es sollte daher als okay und gewollt gelten koennen, am Ende eines Vorhabens nicht etwa ein „nachnutzbares“ Softwaresystem als Ergebnis zu haben, sondern eine Reihe von Erkenntnissen, was fuer einen nachhaltigen Rollout des Systems noch fehlt. Oder, noch besser, bereits im Rahmen des Vorhabens die erkannten Defizite zu adressieren.

Wenn man in der Denklogik einer moeglichst breiten „Nachnutzung“ eines Systems verhaftet bleibt, oeffnet das die Flanke fuer einen Zustand, in dem bei einer Wiederverwendung nicht etwa technische Schulden analysiert und behoben werden, sondern in dem die „Nachnutzung“ darin besteht, um diese Defizite herumzuarbeiten.

Parallel zu Herrenberg hatten wir in Ulm versucht, mittels gleich zweier Foerderprojekte – beide aus den Ehrenamtserfahrungen der Transit-Hacking-Community und durch eine Projekt-Anstellung zweier erfahrener Menschen aus dieser Community hervorgegangen – verschiedene Anschlusspunkte an die real existierenden Voraussetzungen der kommunalen IT-Infrastruktur und noetiger weiterer Akteure praktisch zu testen.

Um intermodales Routing auch mit weiteren Mobilitaetsmodi zu ermoeglichen, setzten wir beispielsweise auf die Idee, die damals in den deutschen Markt draengenden Anbieter von Mikromobilitaet zur Verwendung des internationalen GBFS-Standards zu bringen, der auch von OpenTripPlanner (und damit digitransit) verwendet werden kann. Wir experimentierten fuer ein eigenes Radsharing-System mit der Moeglichkeit fuer Single-Sign-On mittels OAuth mit staedtischen Useraccounts, wofuer leider bis zum Ende des urspruenglichen Verschwoerhaus-Projekts die infrastrukturelle Grundlage seitens der Basis-IT nicht geschaffen werden konnte. Wir analysierten die – abseits der internationalen Standards entwickelten – Datenaustauschformate der deutschen Carsharing-Branche, die seltsame Annahmen ueber Uhrzeiten hatte und bis heute Propaganda verbreitet, dass oeffentlich ausgespielte Fakteninformationen ueber die Position ihrer Fahrzeuge Geschaeftsgeheimnisse sein koennten.

Dass wir das ueberhaupt als staedtische Projekte vorantreiben konnten, hing davon ab, dass Ehrenamtliche aus dem „alten“ Verschwoerhaus ueber Jahre hinweg eine leistungsfaehige Serverinfrastruktur aufgebaut und betrieben hatten, nach der sich viele Kommunen die Finger lecken wuerden, und die wir fuer den Betrieb von digitransit und aller anderer Komponenten verwenden konnten.

Als Ergebnis entstand unter anderem mit den in Herrenberg beteiligten Akteuren ein „Kochbuch“, mit dem damals ein Deployment von digitransit besser dokumentiert wurde. Im Ueberblick der notwendigen Datenfluesse wird grafisch etwas klarer, was alles dazu notwendig ist. Und vor allem auch: An welchen Stellen eine Kommune Wert darauf legen sollte, dass diese Informationen im passenden Aggregatzustand als maschinenlesbare Sachverhaltsdarstellungen wiederverwendbar vorhanden sind.

Die deutsche Tourismus-Branche legt z.B. seit einiger Zeit grossen Wert darauf, Touristik-Informationen als Knowledge Graph automatisiert maschinell wiederverwendbar zu veroeffentlichen. Dieselbe Denklogik kann auch fuer viele weitere POI-Informationen angewandt werden, um eine moeglichst einfache Navigation zu Veranstaltungen, Behoerden und vielen weiteren Orten zu ermoeglichen – beispielsweise auch zusammen mit den ueblichen Zustaendigkeitsfindern der oeffentlichen Hand. Dann koennte ich bereits in der Fahrplanauskunft eingeben, dass ich an die Stelle moechte, wo ich meinen Personalausweis verlaengern kann – und bekomme eine Route mit Bus, Bahn, Fahrrad und Ridesharing vorgeschlagen, wie ich dort rechtzeitig eintreffen kann.

Das ist auch angesichts der aktuellen Hypes um Agentic AI und Chatbots spannned: Staatliche Stellen machen sich gerade umfangreich von Hype-Glauben abhaengig. Derweil gaebe es seit rund 20 Jahren die technologischen Voraussetzungen, dass ich die Frage „welche Filme in Originalfassung kann ich mit 30 Minuten Anfahrtszeit mit oeffentlichen Verkehrsmitteln heute abend im Kino anschauen“ deterministisch und mit um Groessenordnungen geringerem Energieaufwand beantworten koennte, als mit dem oft sektenartig wirkenden genAI-Irrsinn.

Und gleichzeitig kann dadurch auch in der Tiefe erkundet werden, an welchen Stellen in der kommunalen IT-Infrastruktur derzeit noch Fehlstellen existieren, die es seit Jahren aufzufuellen gaelte. Im besten Fall koennte man diese Fehlstellen – als Freie Software! – im Rahmen eines solchen Projekts als notwendige Projektvoraussetzung schliessen – mit dem angenehmen Seiteneffekt, dass diese geschlossene Luecke gleichzeitig auch einen Stuetzpfeiler fuer viele weitere ohnehin notwendigen Modernisierungsmassnahmen bildet.

Ich habe in der Praxis bislang vorwiegend das Gegenteil erlebt. Aus irgendeinem Grund hat sich insbesondere im Kontext der MPSC der Glaubenssatz durchgesetzt, dass man mit den Foerdermitteln nur Dinge „ausserhalb der Verwaltung“ aufbauen kann. Wenngleich durch die Nutzung von Mitteln aus dem Klima- und Transformationsfonds spaeter(!) vorgegeben wurde, dass man damit nur „Infrastruktur“ aufbauen duerfe, wurde das in der Praxis lediglich dahingehend ausgelegt, dass alle Ergebnisse „Open Source“ (sic!) sein muessen. Dass man diese Massgabe dahingehend interpretiert, die Wiederverwendbarkeit von auf Freier Software basierenden Basisinfrastrukturen und die Dokumentation der dafuer noetigen Schritte damit zu foerdern, habe ich in der freien Wildbahn bislang so gut wie nirgendwo gesehen. Stattdessen wurden enorme finanzielle Mittel zur Beauftragung von Dienstleistern ausgegossen, die dann halt irgendwelche Projekte™ gemacht haben – ohne, dass der Staat dadurch langfristig und nachhaltig etwas jenseits der Powerpoint-Ebene gelernt haette.

Der Fisch stinkt hier vor allem vom Kopf. Alle wohlmeinenden Papiere rund um „Nachnutzung“ adressieren bislang rein gar nicht, dass solche strategischen Entwicklungsstellen idealerweise mit Menschen besetzt werden muessten, deren IT-Kompetenz sich nicht lediglich in MS-Office und vor allem Powerpoint erschoepft.

Kritik 3: Was ist mit dem langfristigen Erkenntnisgewinn?

Diese Kritik folgt logisch aus den Punkten 1 und 2. Erkenntnisse sind erneuerbare Ressourcen: Man kann sie immer wieder aufs Neue haben.

Auf dem Chaos Communication Camp 2023 haben Katharin Tai und ich uns einen Spass daraus gemacht, Kritik an EDV-Projekten der DDR mit Kritik an aktuellen Staats-Digitalisierungsprojekten gegenueberzustellen und das Publikum raten zu lassen, was aus der Zeit 1960–1989 in der DDR stammt und was aktuell ist. Mit Ausnahme weniger Menschen im Publikum, die die aktuellen Kommentare des Normenkontrollrats zum OZG auswendig kannten, lag die richtige Zuordnungsquote der vorgestellten Zitate weit unter der Zufallsgroesse von 50%.

Der Verdacht, aktuelle Digitalisierungsprojekte in der Berliner Bundesrepublik wuerden auf strukturell aehnliche Hindernisse stossen wie die Digitalisierung in der zentralisierten DDR, liegt also nahe. Auch der Blick auf die Kritik an staatlichen Digitalisierungsvorhaben in historischen bundesrepublikanischen Tagungsbaenden aus den 1980er-Jahren liest sich heute immer noch erschreckend aktuell. Analog zu den ehrenamtlich aus der Transit-Bubble zusammengetragenen Antipattern zu Mobilitaetsdaten scheint es also so, als gebe es strukturelle Huerden bei der erfolgreichen Modernisierung der staatlichen Digitalisierung. Aber anstatt die bestehenden Erkenntnisse aufzugreifen und sich an eine tiefergehende Analyse zu machen, versucht man einfach nur, weitere Foerderprojekte in genau dieselben Fallgruben laufen zu lassen, die eigentlich laengst bekannt waeren – bei denen sich aber nie jemand die Muehe gemacht hat, sie zu kartieren.

Hier zeigt sich auch eine weitere systematische Fehlstelle. Gerade die Bemuehungen aus dem Digitalen Ehrenamt heraus – die vielfach davon ausgehen, in der oeffentlichen Verwaltung eine IT-Infrastruktur gemaess der anerkannten Regeln der Technik und durch fachliche Expertise gepraegte IT- und Datenfluss-Vorstellungen vorzufinden – sehen sich seit vielen Jahren damit konfrontiert, mit eigenen, oft prinzipiell durch die Verwaltung schluesselfertig uebernehmbaren Proofs of Concept gar nicht anschlussfaehig zu sein. Wer mehr als fuenf Jahre im Feld unterwegs ist, sieht regelmaessig „neue“ Projekte und Ansaetze an gleichfoermigen Huerden zerschellen, an denen aehnliche Vorhaben bereits Jahre zuvor scheiterten.

ProjectTogether als „Mutterschiff“ von re:form lud beispielsweise 2021–22 zu „Update Deutschland“ ein, einem Hackathon als Fortsetzung des in der Civic-Tech-Szene sehr kritisch beaeugten WirVsVirus-Hackathon (siehe auch hier), bei dem schon aufgrund der Hackathon-Formatierung berechtigte Zweifel am langfristig-nachhaltigen Erfolg bestanden. Bei einer kursorischen Analyse von Aktiven aus der Civic-Tech-Ehrenamtsszene stellte sich auch sehr schnell heraus, dass zu den von den teilnehmenden Kommunen eingebrachten „Challenges“ eine ganze Reihe Herausforderungen zaehlte, die bislang genau deswegen nicht geloest werden konnten, weil seitens der Kommunen für bestehende Beispielimplementierungen aus dem Ehrenamt nicht die notwendigen Voraussetzungen bereitgestellt wurden. Anstatt aus den Erfahrungen auf Basis der Proofs of Concepts Lehren zu ziehen, wurde stattdessen eine weitere Generation Ehrenamtlicher eingeladen, erneut und von Null anfangend gegen die eigentlich schon bekannten Huerden auf staatlicher Seite zu laufen.

Ein riesiges, bislang beinahe vollstaendig ungeschoepftes Potenzial liegt derzeit daher darin, genau diese aus ehrenamtlichen Bestrebungen heraus entstandenen Erfahrungen zu kartieren und die Erkenntnisse der metaphorischen Brandschutzuebungen als Hausaufgaben fuer eine erfolgreiche Verwaltungsdigitalisierung nachzuhalten.
Mein Versuch, die bereits stattgefunden habenden praktischen Rollouts von digitransit als ungeschoepftes Potenzial zur Wissensverstetigung als Aufgabenbeispiel fuer einen Wissens-Nachhaltungsauftrag fuer das damals zu gruendende Dateninstitut zu lancieren, fuehrte lediglich dazu, dass digitransit zu einem weiteren Beispiel eines „Use Case“ fuer das Dateninstitut wurde. Ich hatte anhand des Beispiels davon abgeraten, einfach neue „Use Cases“ durchzuspielen um bereits gemachte Erfahrungen nur nochmal von vorne zu machen, und mein Gegenueber hat daraus lediglich mitgenommen, dass das ja ein toller „Use Case“ waere. Das war hart. Im Arbeitskontext habe ich versucht, das diplomatisch zu umschreiben.

Dieses Vorgehen scheint allgemein beliebt zu sein: Fachlich wirklich tief in der Materie eingestiegene Ehrenamtliche machen Loesungsvorschlaege fuer einen Ausweg aus den real existierenden Defiziten der Verwaltungsdigitalisierung. Die praktische Umsetzung scheitert am Unwillen oder der Handlungsunfaehigkeit der eigentlich zustaendigen oeffentlichen Stellen, die dafuer notwendigen Voraussetzungen zu schaffen. Und anstatt diese Defizite zu beheben, macht man dieselben Erfahrungen einfach wiederholt nochmal (oder stiftet dazu an, sie nochmals zu machen) ohne aus den bereits gemachten Erfahrungen etwas zu lernen. Wie jemand aus dem damaligen Ulmer Projekt sagte: „Lernen durch Schmerzen, nur ohne Lernen“.

Kritik 4: „Open Source“ vs. Freie Software, oder Foerderung der GovTech-Blase vs. Sicherung von Gemeinguetern

Ich muss es offen zugeben: Als ich vor vielen (ueber 20) Jahren den Streit zwischen „Freie Software“ und „Open Source“ kennenlernte, fand ich das verbohrt und ideologisch aufgeladen. Daran duerfte auch einen Anteil haben, dass sich die Freie-Software-Bewegung Richard Stallman als quasi Schutzheiligen auserkoren hat, an dem es eine ganze Litanei zutiefst berechtigter Kritik gibt und der der Idee Freier Software seit Jahren meines Erachtens durch die Gleichsetzung seiner Person mit der Bewegung einen Baerendienst erweist.

Egal, wie man die jeweiligen ideologischen Ziele dieser beiden Stroemungen einordnet, muss man dennoch anerkennen, dass „Open Source“ und die Umarmung der damit verbundenen Softwarelizenzen in den 1990er-Jahren entstanden, um der von der Wirtschaft als zu radikal empfundenen Freie-Software-Bewegung ein schmackhafteres und einfacher wirtschaftlich ausbeutbares Gegenmodell anzubieten. Ganz kurz gesagt ist der Gegensatz dieser: „Freie Software“ verfolgt das Mantra, dass was auf Freier Software aufbaut, auch in der Folge „Frei“ sein muss, also ein Gemeingut. Wer auf die Vorarbeit Anderer aufbaut, soll auch Abwandlungen dieser Vorarbeit stets allen wieder als Freie Software bereitstellen („Copyleft“), sobald diese in irgendeinem Kontext vertrieben wird. „Open-Source“-Software verzichtet auf diesen Gedanken, einmal „Freie“ Software auch als Gemeingut zu erhalten: Wer moechte, kann die Vorarbeit anderer Nutzen, um auf dieser Basis z.B. Software-as-a-Service anzubieten, die nur gegen Entgelt zugaenglich und nutzbar ist. Open-Source-Software und die Vorarbeit anderer ist zwar die Grundlage, und jemand anders kann theoretisch auf derselben Grundlage ein aehnliches Produkt entwickeln, aber die Zusatzentwicklungen auf der Basis dieser Vorarbeit koennen geschlossen und geheim sein.

Im politischen Diskurs werden Freie Software und „Open-Source-Software“ mittlerweile – zu meinem riesigen Bedauern – praktisch gleichgesetzt. Praktisch ist „Freie Software“ der enger gefasste Begriff, der durch seine Lizenzbedingungen sicherstellen wuerde, dass aus oeffentlichen Mitteln gefoerderte Systeme nicht privatisiert werden koennen. In Foerderbedingungen und auch Kommentaren wie dem der Agora Digitalwende ist derweil fast immer nur vom weiter gefassten Begriff der „Open-Source-Software“ der Begriff – also ausdruecklich unter Einschluss von Systemen, deren Weiterentwicklung in der Folge privatisiert werden darf.

Das hat ganz praktische Auswirkungen. Es ist nicht nur denkbar, sondern auch beobachtbar, dass aufgrund dieser Gleichsetzung – und mangelnder internalisierter Steuerungskompetenzen bei der oeffentlichen Hand – sowie der durch Foerderbedingungen entstandenen normativen Attraktivitaet des „Open-Source“-Begriffs Softwaresysteme durch Dienstleister aus oeffentlichen Mitteln unter permissiven Lizenzen bis zu einer gewissen Marktreife entwickelt werden.
Dass fuer das so entwickelte System auch nach Abschluss des Foerderprojekts weitere Anforderungen entstehen, ist keine Ausnahme – auch dies ist ein Problem mangelnder internalisierter Kompetenzen auf staatlicher Auftraggeberseite. Fuer den Anbieter aus der GovTech-Bubble, der oeffentlich finanziert die Basis entwickelt und intime praktische Einblicke in die Beduerfnisse der oeffentlichen Auftraggeber entwickelt hat, ist es auf dieser Basis ein Leichtes, quasi selbstlos und kostenlos Anpassungen der ihm sehr vertrauten Basisplattform zu entwickeln und das resultierende Produkt als SaaS gegen geringe Abonnementgebuehren der oeffentlichen Hand anzubieten.
Die gesamte Grundlagenetwicklung wurde so oeffentlich gefoerdert, letztlich wurde aber nicht etwa ein Gemeingut als Ergebnis geschaffen, sondern das Potenzial einer marktdominierenden Stellung fuer die auf Grundlage der urspruenglich als „Open Source“ entwickelten und danach praktisch privatisierten Dienstleistung. Aufgrund der intensiven Vertrautheit des urspruenglichen Dienstleisters mit der Codeplattform sowie den typischen Anforderungen und den oekonomischen Realitaeten des GovTech-Nischenmarkts ist es auch hoechst unwahrscheinlich, dass irgendein marktbereinigender Konkurrenzakteur die urspruengliche, oeffentlich als „Open Source“ noch verfuegbare Codeplattform konkurrenzfaehig anbieten kann.

(Eigentlich kann man all dies hier zusammenfassen als: Alle beteiligten Akteure spielen hier „Open Source“-Cosplay, waehrend niemand je in der Tiefe darueber nachdenkt, was eigentlich die strategischen Ziele dahinter sein koennten. Der ganze „Digitale-Souveraenitaet“-Bullshit fuegt sich hier nahtlos ein. Aber die kaiserliche Kleidermanufaktur sorgt nach wie vor fuer gar nicht so schlechten Umsatz.)

tl;dr, was lernen wir daraus

1. Kompetenzen internalisieren: Nicht jede Kommune soll alle Dienste selber betreiben. Aber wenn dort Menschen mit der IT befasst sind, die solche Dienste souveraen betreiben koennten, dann haben sie auch ein Verstaendnis von Requirements, Infrastruktur etc, die sie von einem Dienstleister betreiben lassen koennen. Es darf nicht mehr sein, dass Menschen ueber strategische IT-Fragen entscheiden, deren IT-Kompetenzen nicht ueber Office, Powerpoint, Freecell und Taschenrechner hinausgehen.
2. Wenn diese Kompetenzen vorhanden sind, liegt der groesste Anreiz fuer eine Wiederverwendung im tatsaechlichen Nutzen. Leider hilft aber auch der alleine nichts, wenn fuer den Rollout eines Systems reihenweise Voraussetzungen fehlen. Deswegen sollte man…
3. Projekte als Lackmustest fuer Infrastrukturen und Datenfluesse durchfuehren: Manchmal liegt der groessere Wert in der Erkenntnis, an welchen Stellen das Projekt bei der Umsetzung Schwierigkeiten bekommt. Weil Daten in der erforderlichen Qualitaet fehlen, weil Infrastrukturvoraussetzungen fehlen oder kaputt sind, etc pp. – und dann muessen diese Maengel konsequent fuer andere nachvollzieh- und umsetzbar beschrieben und als naechste Aufgabe angegangen werden, anstatt um sie herumzuarbeiten und das Projekt als Erfolg zu verkaufen.
4. Raus aus der Verwaltungsbubble: Das Beispiel Panoramax zeigt, dass ein Freie-Software-Oekosystem gerade dann besonders erfolgreich sein kann, wenn es einen greifbaren Nutzen fuer Nutzende und einen Anreiz fuer Beitragende in und ausserhalb der Verwaltung bietet. Die Gemeinschaft der Entwickelnden beschraenkt sich dann nicht nur auf die wenigen dazu ausgestatteten Inseln innerhalb der Verwaltung, sondern auf ein viel breiteres Oekosystem.