Archiv der Kategorie: Allgemein

„Nachnutzung“ als irrefuehrender Erfolgsindikator bei Freie-Software-Projekten der oeffentlichen Hand

3 Antworten

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.

Screenshot der Titelseite

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 Herrenberg im direkten Vergleich mit reittiopas, der Helsinkier digitransit-Instanz – dort sogar mit Ticketing

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.

Eine spätere Fassung der Ulmer digitransit-Instanz von Maxi, die den Weg in ein staedtisches Projekt gefunden 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)

17. Januar 2018: Stefan Kraus (vorne rechts) und Co. sind zum ersten Mal am Weinhof – weil sie mitbekommen haben, dass sie im „alten Verschwoerhaus“ Hands-On-Erfahrungen aus dem Digitalen Ehrenamt anstatt von Produkt-Pitches bekommen konnten.

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

Lernerfolg: Aus verteilten Foerderprojekten heraus entstand 2020 ein Handbuch, wie man digitransit selber mit lokalen Daten zum Laufen bekommen kann.

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.

Welche Daten-Voraussetzungen braucht es fuer eine laufende digitransit-Instanz? Gar nicht so wenige. Automatisch generiertes Blockdiag-Diagramm aus https://transportkollektiv.github.io/digitransit-setup/installation/overview.html
Statische Fahrplandaten im GTFS-Format sind mittlerweile weit verbreitet. Die Verfuegbarkeit von Echtzeitdaten aus dem oeffentlichen Verkehr und vor allem von GBFS fuer Shared Mobility ist aber bis heute ein ernsthaftes Problem!

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.

Hier nur ein Symbolfoto, ohne diesen speziellen Anbieter zu meinen – aber die deutsche Carsharingbranche und ihr Dachverband bcs verbreiten seit Jahren die These, dass es ein Geschaeftsgeheimnis sei, zu wissen, wo dieses Auto steht.

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.

Eigene Hardware mit virtuellen Maschinen, mit denen man auch umgehen kann, kann das Leben deutlich einfacher machen. CC BY 4.0 Holger Dorn/Jugend hackt, via Wikimedia Commons.

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

Das ist „Nachnutzung“: Die Umwidmung des ehemaligen US-Kasernengelaendes der Wiley-Barracks in Neu-Ulm als neues Stadtquartier. Die Verwendung der ehemaligen Kasernen-Highschool als Keimzelle der Fachhochschule. Bei Software bitte einfach „Wiederverwendung“ sagen, anstatt komisches Parallel-Vokabular einzufuehren. Looniverse, Wiley-Park (Neu-Ulm) Richtung NNW, CC BY 4.0
  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.

Rabbitholes um Zusatzzeichen

Schreibe eine Antwort

Wenn man entsprechend komisch im Kopf ist, kann man in wunderbare Rabbitholes rund um Verkehrszeichen und die damit verbundenen Vorschriften fallen. Ich fand den Wikipedia-Artikel um Leitkegel vor einigen Jahren etwas duerftig und das ist dann irgendwie eskaliert und ich habe ueber Kleinanzeigen einen ganzen Satz Leitkegel nach TL gekauft (das war aber auch ein Schnaeppchen, da musste ich zugreifen!), so dass ich ein Gegenueberstellungs-Foto unter Freier Lizenz fuer die Wikipedia hochladen konnte.

Links ein nicht reflektierender Leitkegel ohne Fussplatte, rechts ein voll retroreflektierender Leitkegel nach TL (Quelle)

Wenn man da aber erst einmal angefangen hat, faengt man auch an, in all die anderen Regeln erst der RSA95 und dann der RSA21 einzutauchen, und rsa-online ist dafuer einfach wunderbar. Das ist natuerlich nicht nur Wikipedia-Nerderei, sondern das hat auch eine ganz praktische Bewandtnis, wenn meine Feuerwehr auf irgendeine Weise Dinge mit verkehrsrechtlichen Anordnungen durchfuehren soll – Bayern ist meiner Kenntnis nach das einzige Bundesland, wo die Feuerwehr das tatsaechlich auch darf.

Gar kein richtiges Haltverbot, aber ein typographisch sehr interessantes Schild (Quelle)

Ein so ein typisches Problem sind voruebergehende Haltverbote, die mit Zusatztafeln mit dem Zeitraum der Gueltigkeit des Haltverbots ausgestattet werden muessen. Bei der Herstellung dieser Zusatzschilder herrscht oft grosse… Kreativitaet, wie das ausgefuehrt wird, wie auf rsa-online sueffisant beschrieben und bebildert wird. Eigentlich muessten das richtige, retroreflektierende Zeichen auf Alu mit schwarzem umlaufendem Rand und Beschriftung in DIN-Schrift in der richtigen Hoehe sein. In der Praxis sind das halt ausgedruckte Zettel, die auf ein leeres Zusatzzeichen geklebt oder geklemmt werden – oder ganz selbst ausgedachte Tafeln, bei denen das Datum mit Etiketten angepasst wird.

So ein „richtiges“ Schild mit aktualisierten Folienplots zu beschriften, ist aber leider eine lange Fummelarbeit. Daher fand ich die bei rsa-online als „fragwuerdig“ bezeichnete Idee von „Einschubschildern“ ganz charmant. Der Rand ist fix, und in ein Fenster in der Mitte kann man eine bedruckte, transparente(!) Overheadfolie vor den retroreflektierenden Hinterteil einschieben. Die Schrift erscheint damit vor reflektierendem Hintergrund – zwar sind dann das Fenster und die Folie im Weg, aber besser als nur ein aufgeklebter Zettel.

Vorgestern habe ich zum ersten Mal so ein Ding in Ulm in freier Wildbahn gesehen, und musste gleich schmunzeln. Weil die Ausfuehrung war dann genau das „wie man es nicht macht“, was auf rsa-online beschrieben ist: Auf Papier, falsche Schriftart, und dann auch noch mit eigenem schwarzen Rand auf dem Papier. Dafuer haette man den Mehrpreis nicht bezahlen muessen 😀

Der YouTuber Plankton hatte derweil Ende 2023 ein Video ueber „Verkehrshuetchen“ gemacht, das intensiv auf den Wikipedia-Artikel zurueckgriff, den ich mit erweitert hatte. Die Info ueber die Erfindung von Charles D. Scanlon im Plankton-Video ist halt ohne Scheiss von mir in dewiki eingebracht worden, genauso wie die Info mit den bemalten Oelfaessern, die zu toedlichen Unfaellen fuehrten 😀
Und im Februar 2026 traf ich auf jemanden, der noch obsessiver mit der RSA und Leitkegeln umgeht als ich: Weil in den Kommentaren zum Leitkegel-Artikel tauchte jemand auf, die oder der historisch korrekte Leitkegel 3D-Drucken wollte, Wikipedia zu rate zog aber mit der Info nicht zufrieden war und extra ins Bundesgesetzblatt von 1970 blickte und anmerkte: Ey, die grafische Darstellung in der Wikipedia stimmt eventuell nicht. Seite 41 im PDF sagt: Jo, ich glaub, der Einwand ist berechtigt. Der von mir stolz 2023 in Berlin gefundene „alte“ Leitkegel koennte mit dem ganz kleinen weissen Teil oben mit der alten Bildtafel uebereinstimmen – aber das Sinnbild mit dem grossen weissen Teil oben auf Wikimedia Commons scheint einfach falsch zu sein. Kudos, fellow nerd!

Lock-In-Kosten (Symbolbild)

Schreibe eine Antwort
Foto eines Parkscheinautomaten. Zu lesen ist: "Betrag :11790,00 EUR Noten bis: 20,00 EUR"

Ich habe neulich in einer kleinen Runde nach einem Bild gesucht, mit dem man die versteckten Kosten vermeintlich kostenloser Angebote mit Lock-in-Effekten irgendwie erklaeren kann.

Wenn man irgendeinen Dienst in skalierend fuer entsprechend grosse Nutzendengruppen aufsetzen will, kostet das direkt sichtbar Geld. Der Kostenfaktor fuer Serverinfrastruktur ist dabei meist gar nicht der ausschlaggebende. Vielmehr ist es die Zeit, die fuer das Setup und vor allem die regelmaessige Wartung und Fehlerbehebung draufgehen.
Diese Kosten kann man entweder direkt sehen – wenn das Menschen im bezahlten Arbeitskontext machen, ist das eben die Zeit, die entweder der Kostenstelle „bau und warte System Y“ zugeordnet wird, oder eben nicht mehr fuer andere Aufgaben zur Verfuegung steht. Oder es sind nicht direkt finanziell abbildbare Kosten – im Ehrenamtskontext bindet das Zeit von denjenigen, die das bauen und betreiben, und meist endet das ja nicht mit dem System, und irgendwann ist es aus Versehen eine tragende Saeule der Infrastruktur der Ehrenamtsgruppe geworden, und wenn irgendwas klemmt oder umfaellt, koennen zig andere Leute nicht mehr wie gewohnt weiterarbeiten.

Irgendeinen „kostenlosen“ Dienst zu nutzen, verursacht zunaechst gar keine sichtbaren Kosten. In Wirklichkeit stimmt das aber natuerlich nicht. Je laenger man so einen Dienst als Organisation nutzt, desto hoeher werden die Folgekosten zu genau dem Zeitpunkt, wenn man ihn irgendwann nicht mehr nutzen will oder kann.

Das fiel mir dieser Tage wieder ein, als Bianca Kastl auf Mastodon erzaehlte, dass Unternehmen Stellen abbauen und durch „KI“ (Sammelbegriff) ersetzen wuerden, weil das angeblich Kosten einspare.

Meine Antwort:

Post by @stk@chaos.social
View on Mastodon

Gluecklicherweise habe ich gerade eben das Foto wieder gefunden, das ich im November 2010 von Ernst Abrazzo zugeschickt bekam. Der war im mittlerweile zum Lost Place gewordenen Blautal-Center einfach an einer dauer-offen stehenden Schranke vorbei aus dem Parkhaus gefahren und behielt aber die Parkkarte. Danach ging er dann alle paar Monate mal schauen, was er mittlerweile fuer die Ausfahrt zahlen muesste.

11790 EUR mit maximal 20-EUR-Scheinen sind uebrigens z. B. 589 20-EUR-Scheine und ein 10-EUR-Schein. Laut Sparkasse ist ein Buendel mit 100 50-EUR-Scheinen 1,2 cm hoch. Wenn wir annehmen, dass 20-EUR-Scheine gleich dick sind wie 50-EUR-Scheine, benoetigen die 590 Scheine nur 7 cm Raum im Parkautomaten – bei idealer Packung ohne jedweden Platz zwischen den Scheinen z.B. fuer Luft.
Ich kann nicht mehr nachvollziehen, was fuer einen Scheinakzeptor dieser Parkautomat von damals gehabt haben koennte, typische Akzeptoren koennen aber in der Regel zwischen 200 und 2000 Banknoten annehmen. Man koennte 11790 EUR also in einer Mischung von 20-, 10- oder gar 5-EUR-Noten bezahlen – wenn der Akzeptor nicht an eine Hoechstmenge von Banknoten pro Zahlungsvorgang laeuft.

Ist das denn auch zeitlich machbar? Theoretisch ja: Wenn man jede Sekunde einen Schein in den Automaten steckt, der auch sofort akzeptiert und nicht zurueckgewiesen wird, stuende man beinahe 10 Minuten an diesem Automaten. Vermutlich schafft man diese Quote aber nicht und steht laenger dort. Die Chance ist hoch, dass in der Zeit andere Menschen hinter einem in der Schlange stehen, die eigentlich gerne auch ihre Parkgebuehr entrichten wollen wuerden. Manchen Leuten ist sowas unangenehm, aber vermutlich kommt man nicht in eine Lebenssituation, in der man einfach aus Jux 11790 EUR in einen Parkautomaten steckt, wenn einem aeussere Umstaende allzuviel ausmachen. Dann kann und sollte man aber natuerlich fuer eine ausreichende Bewachung der Situation sorgen – denn wenn eine Person hinter einem minutenlang zusieht, wie man tausende Euro in einen Automaten steckt, koennte man nach nur wenigen Minuten im Kopf grob ueberschlagen, welche Summe sich auch jetzt noch in der Hand der einzahlenden Person befindet und ob man den Zahlungsvorgang nicht mal kurz unterbrechen wollen wuerde.

Was ist eigentlich die SPARK-Plattform?

1 Antwort

Du bist ein neutraler, sehr sorgfältiger Assistent zur Vorprüfung von Genehmigungsverfahren. Du prüfst nur logische/inhaltsbezogene Konsistenz von Aussagen; keine rechtlichen, fachplanerischen oder normativen Entscheidungen.

05-modulcluster/modul-plausibilitaet-pruefung/src/workflows/check_logic_wf/prompts/risk_screener_prompts.py

Seit einer Weile trommelt das deutsche Digitalisierungs- und Staatsmodernisierungsministerium fuer das „Agentic-AI“-System „SPARK“, das auch Teil des Deutschlandstack sein soll (Linkedin-Post von Markus Richter). SPARK soll nach Eigenaussage des BMDS die Prüfung von Antragsverfahren vereinfachen:

Die KI trägt dazu bei, Verwaltungsverfahren zu beschleunigen und Beschäftigte in der öffentlichen Verwaltung bei zeitaufwändigen Tätigkeiten wirksam zu entlasten.

Die jetzt veröffentlichten Module bilden typische Kernaufgaben in Planungs- und Genehmigungsverfahren ab. Dazu gehören die Extraktion relevanter Informationen aus Antragsunterlagen, die formale Vollständigkeits- und Plausibilitätsprüfung sowie unterstützende Funktionen für Verfahrensübersichten, Nachreichungen und Kommentierungen.

Die Basis bildet eine mit KI-Agenten unterstützte Rechtsdogmatik, welche an Gesetzesdatenbanken angeschlossen ist und eine automatisierte Normendekonstruktion und juristische Bewertungsmechanismen beinhaltet. Weitere Module zur materiellen Prüfung, rechtlichen Bewertung und Beschlusserstellung folgen im weiteren Jahresverlauf. Die KI-unterstützten Module bereiten die Information für die Sachbearbeitenden in den Genehmigungsbehörden auf. Die Sachbearbeitenden treffen anschließend die Entscheidung.

Pressemitteilung 17/2026 des BMDS vom 1. April 2026

Jetzt koennte man an viele der Aussagen des BMDS ein [citation needed] anfuegen, z. B. an die sehr undifferenzierte Aussage, dass „die KI (sic)“ dazu beitrage, Verwaltungsverfahren zu beschleunigen. Es lohnt sich aber, fuer eine weitere Einordnung dem tatsaechlich existierenden System einmal unter die Haube zu sehen. Aus aktuellem Anlass hatte ich endlich die Zeit und die Verfassung, endlich einmal das seit dem 31.3. oeffentliche Repository auf openco.de zu sichten, in dem das System „lizenzfrei“ (korrekt: unter freier EUPL-Lizenz und den Lizenzen der verwendeten F/LOSS-Bausteine) veroeffentlicht wurde. Der PStS Thomas Jarzombek hatte unlaengst im Digitalausschuss dazu eingeladen, „sich die Sourcecodes mal anzugucken“ (in der Aufzeichnung ab 05:37), also bin ich der Einladung mal gefolgt.

Und ich muss ganz offen gestehen: Ich bin erstens nicht beeindruckt. Und zweitens geradezu erschuettert, dass ich keine journalistische Quelle und keine weitere Fundstelle gefunden habe, in der andere der Einladung von Jarzombek gefolgt sind und wo das System in den vergangenen fuenf Wochen einmal begutachtet wurde.

Was macht SPARK?

Du bist ein juristischer Fachassistent für Infrastruktur- und Umweltrecht.
Deine Aufgabe ist es, hypothetische Fragen zu generieren, die ein Benutzer stellen könnte, um den Inhalt des folgenden Textabschnitts zu finden.

05-modulcluster/modul-inhaltsextraktion/src/workflows/hypothetical_questions/prompt.py

Aus der oeffentlichen README.md wird nicht auf den ersten Blick klar, was das System unter der Haube macht. In der docker-compose.yaml findet man abgehangene Systeme wie ElasticSearch, Postgres, Prometheus und temporal, die vergleichsweise neue Vektorsuchmaschine qdrant und einen Monitoring-/Visualisierungsstack rund um Grafana. Die weiteren Komponenten kleben u.A. einen litellm-Proxy und unoserver zusammen – jeweils zusammen mit ihren jeweiligen Abhaengigkeiten.

In den Readmes der „Kernmodule“ modul-inhaltsextraktion, modul-formale-pruefung und modul-plausibilitaet-pruefung wird ueber Abbildungen von Prozessgraphen etwas klarer, was das System unter der Haube mit den dort eingeworfenen Antragsdokumenten tun soll:

  1. Im ersten Schritt werden die vorliegenden Dokumente – genannt sind DOCX, PDF und PPTX(dafuq!) – nach Markdown konvertiert. Dafuer wird offenbar ein vollstaendiges LibreOffice verdockert, das aktuell mit einer CVE daherkommt (via Thomas Fricke). In dem Schritt wird ueber die per litellm eingebundenen LLMs versucht, Bilderkennung zu betreiben, in PDF/Word/Powerpoint-Tabellen gefangene Daten fuer maschinelle Auswertbarkeit umzuformen, die Texte zusammenzufassen, und Aussagen in die Vektordatenbank fuer eine spaetere Auswertung mit qdrant zu werfen. Ausserdem wird versucht, die Struktur/das Inhaltsverzeichnis aus den vermutlich Kraut-und-Rueben-formatierten Dokumenten zu ermitteln.
  2. Im zweiten Schritt wird das verwendete LLM gepromptet, die Struktur der Dokumentensammlung sowie die ermittelten Inhaltsverzeichnisse sowie die im ersten Schritt generierten Zusammenfassung mit einer „Musterloesung“ zu vergleichen. Damit sollen fehlende Dokumente oder fehlende Abschnitte in der TOC-Struktur erkannt werden. Wohlgemerkt soll das alles ueber Prompt-Massage passieren, a la „Du bist ein Experte für die Analyse von Planfeststellungsunterlagen.“
  3. Danach soll das System den Antrag auf Plausibilitaet pruefen – einerseits um interne Inkonsistenzen zu finden, andererseits offenbar auch wieder mit einem Vergleich mit einer Musterloesung. Fuer die interne Konsistenzpruefung werden z.B. die vorher in Vektoren uebersetzten „Claims“ miteinander verglichen, das LLM soll dann abweichende Cluster analysieren und die Abweichungen wieder in menschliche Sprache ausformulieren. Schoener Prompt an anderer Stelle im Modul: „Finde potenziell konfliktträchtige Aussagepaare früh, ohne Fakten zu erfinden“.

Die in der Eigendarstellung behauptete „Rechtsdogmatik“ und den „Anschluss an Gesetzesdatenbanken“ konnte ich bei meinem Blick unter die Haube nicht finden. Das scheint sich allein auf die Prompts und ein wenig RAG auf Gesetzestexten zu beschraenken. Und angesichts des Track Records von LLM bei der Interpretationsfaehigkeit von Gesetzen ist das schon ein wenig haarig.

Besonders hervorhebenswert finde ich den Troubleshooting-Hinweis im Modul fuer die Plausibilitaetspruefung, was passiert, wenn man sie mehrfach durchfuehrt:

Inconsistent Results Between Runs
LLM outputs are non-deterministic — results may vary between runs. Output quality is significantly affected by model choice.

05-modulcluster/modul-plausibilitaet-pruefung/README.md

Ja natuerlich sind LLM nicht-deterministisch. Das liegt in ihrer Natur. Das ist der Grund, weswegen die Verwendung von stochastischen Systemen wie genAI fuer Verwaltungshandeln sowieso grundsaetzlich fragwuerdig ist – denn die Verwaltung soll berechenbar, normentreu, nachvollziehbar und nach Prinzipien wie dem Gleichheitssatz arbeiten. Die Verwendung von LLM als „Unterstuetzung“ fuer diese Prozesse stellt alle diese Grundsaetze in Frage – mehr u.a. hier.

Aber schon der allererste Schritt, die Umwandlung von Dokumenten im DOCX-Format und vergleichbaren Datengefaengnissen nach Markdown, hat eine genauere Betrachtung verdient.

Eine teure Loesung fuer selbstgewaehlte technische Schulden

„project_applicant“: {{
„value“: „Nordwind Infrastruktur GmbH“,
„source“: „Die Nordwind Infrastruktur GmbH als Vorhabenträger beantragt…“
}}

05-modulcluster/modul-inhaltsextraktion/src/workflows/base_metadata/prompt.py

Ich bin immer wieder erstaunt, an wie vielen Stellen mir bei Vorschlaegen fuer die Verwendung von genAI der Umgang mit in Office-Dokumenten eingesperrten Informationen begegnet ist. Mit SPARK scheint man das „Problem“ zu loesen versuchen, dass die Verwaltung seit Jahrzehnten nicht etwa digitalisiert wurde, sondern lediglich vorherige Formblaetter „elektrifiziert“ hat, so dass man sie nun mit Office-Produkten am Rechner ausfuellen kann anstatt mit Schreibmaschine.

Dokumente liegen dann zwar digital vor, sind aber weiterhin so konstruiert, dass sie vor allem fuer den menschlichen Konsum gedacht sind: Texte, Tabellen und Illustrationen sind so aufbereitet, dass sie von der Maschine lediglich dargestellt und dann von Menschen analysiert und interpretiert werden sollen. Natuerlich bindet das menschliche Arbeit – denn obgleich beispielsweise eine Tabelle urspruenglich maschinell interpretiert und ausgewertet werden konnte, spaetestens mit der Konversion dieser urspruenglich vorliegenden Daten nach PDF wird das vollkommen unnoetig erschwert.

Abgesehen davon, dass man Antragsverfahren sowieso deutlich verschlanken und abspecken sollte – schon die Konversion der Office-Gefaengnisse nach Markdown als ersten Schritt legt nahe, dass man Antraege auch direkt in Markdown schreiben koennte.
Das ist (trotz existierender WYSIWYG-Editoren) fuer viele vermutlich ungewohnt. Aber auch das liegt letztlich nur daran, dass wir nunmehr seit 25 Jahren Jugendlichen in der Schule Office-Produkte als Standard fuer „speichere Informationen ab“ beibringen, ohne Ruecksicht auf Konzepte wie Datenstrukturen und Maschinenlesbarkeit. So wie es durch „Business-Standards“ wie Outlook und Co. vollkommen normal geworden ist, E-Mails sinnlos mit TOFU zu beantworten, haben wir uns auch daran gewoehnt, Excel als Layouttool zu missbrauchen und fuer jeden denkbaren Text irgendein Office-Dokument aufzumachen – und da ist es eigentlich egal, ob das dann MS-Office, LibreOffice oder die allgegenwaertige Google-Suite ist, obwohl es oft viel bessere Werkzeuge gaebe (siehe auch: Markdown ate the World).

Wuerde ein Antragsformular nicht nur als ausfuellbares Office-Dokument vorliegen, das selbst schon keine Ruecksicht auf die vorgesehene Dokumentenstruktur mit TOC legt. Sondern wuerde man auf eine Vorlage mit wohldefinierter Datenstruktur zurueckgreifen. Dann liessen sich gar nicht so wenige Teile einer Vollstaendigkeitspruefung schon direkt mit einem sehr, sehr kleinen Python-Script umsetzen. Ob das dann Markdown oder eine andere Art von Formular ist: Geschenkt. Man koennte auch ganz kecke, ausserhalb der Verwaltung seit Jahrzehnten verbreitete Methoden wie die Verknuepfung mit eindeutigen Identifiern fuer Firmen, Orte oder sonstige Dinge verwenden, um nicht auf die Interpretation von Freitexten durch LLM angewiesen zu sein.
An der Stelle koennte man auch total davon profitieren, wenn der Staat als Garant fuer verlaessliche Informationen moeglichst viele solcher Informationen bereits seit Jahren eineindeutig identifizierbar gemacht haette – beispielsweise Paragraph X in Gesetz Y in der Fassung von (hier Datum einsetzen). Und auch eine automatisierte Vollstaendigkeitspruefung, anstatt dass diese „Wochen spaeter vom Sachbearbeiter“ erfolgt (Aufzeichnung 11:11 ff.) koennte ganz ohne LLM und Agentic AI laengst Realitaet sein.

Das hat der Staat aber nie in Angriff genommen. Sondern laesst die fossilisierten Schichten historisch gewachsener Office-Dokumente einfach auf sich beruhen, und fuegt nun einen Bohrturm mit einem Rudel von LLM hinzu, um mit viel Energieaufwand diese fuer Menschen geschriebenen Dokumente stochastisch fehlerbehaftet analysieren. Anstatt den ganzen Bums mal aufzuraeumen und solche Pruefungen wenigstens teilweise deterministisch und mit einem Bruchteil des Aufwands vornehmen zu koennen. Das wuerde am Ende auch den Antragstellenden helfen.

Sonstige Beobachtungen

Wohlwollend koennte man sagen: Da hat ein Dienstleister zwei Handvoll F/LOSS-Komponenten zusammengeklebt, um ein wenig (stochastische) „Analyse“ mittels herunterladbarer Freeware-LLM ueber Kraut-und-Rueben-Dokumente laufen zu lassen. Bislang weiss ich nicht, was das gekostet hat – auf FragDenStaat habe ich zwar eine sehr interessante Anfrage zu den Chatverlaeufen des Digitalministers mit KI-Chatbots gefunden, deren Antwort wiederum eine ganze Reihe von Rabbit Holes aufmacht, aber keine Anfrage ueber das SPARK-Projekt. Das habe ich natuerlich sogleich behoben. Nachtrag: Politico berichtete am 17.4.2026 hinter Paywall, dass das Projekt bis dahin rund 96 Millionen EUR gekostet habe, danke Ben Burmeister fuer die Ergaenzung.

Dass das Projekt unter EUPL auf Opencode gelandet ist, ist angesichts seines Aufbaus auch nur konsequent. Der Beitrag des Projekts sind die notwendigen Skripte, um die einzelnen F/LOSS-Bausteine zu einem Workflow zusammenzukleben. Die eigentliche Betriebslogik kommt aus den Prompts und den verwendeten Freeware-LLM, das Projekt selbst ist nur „Boilerplate und docker compose“.

Weniger wohlwollend koennte man auf handwerkliche Regeln zu IT-Sicherheit blicken. Thomas Fricke machte mich auf mehrere bemerkenswerte Aspekte aufmerksam: An ganzen 17 Stellen wird in Dockerfiles zur Laufzeit mit pip install etwas nachinstalliert – hauptsaechlich uv (je nach Stelle in den Versionen 0.5.27 und 0.9.6, okay), aber auch unoserver, eine ganz bestimmte Version von pip, setuptools und litellm[proxy]. Mit dem Vulnerabiltiy-Scanner grype fand Thomas eine ganze Reihe von vulnerabilities, darunter eine kritische CVE in glibc.

Das System enthaelt zwar eine ruehrige „Prompt Defense“, die in den zu verarbeitenden Dokumenten eingebaute Prompt Injections unterbinden soll – ihrerseits als Prompt an das zu verwendende LLM gerichtet. Ob und wie das System ueberhaupt auf moegliche Angriffsvektoren getestet wurde, bleibt aber vollkommen unklar. Wer weiss, was passiert, wenn ein Antrag mal eine als Gedicht getarnte Prompt Injection enthaelt. Der Vollstaendigkeit halber sei erwaehnt, dass kurz vor Veroeffentlichung des SPARK-Repos ein Supply-Chain-Angriff in LiteLLM bekannt wurde.

Zielmarken, Vibe Evaluation und (keine) journalistische Einordnung

Ueberhaupt wuerde mich interessieren, ob es konkrete Pruefmarken gibt, anhand derer man den Erfolg oder Nicht-Erfolg des Systems ueberhaupt messen koennen soll. Gab es Tests, wie haeufig das System etwas falsch positiv oder falsch negativ geprueft hat? Ueberhaupt irgendeine Art von Stresstest, um moegliche Fehlerquoten zu ermitteln? Welche Fehlerquote haelt das BMDS fuer solch ein System ueberhaupt fuer akzeptabel? Gab es einen Sicherheitsaudit? Eine Risikobewertung, in welchem Umfang Antraege falsch beschieden werden koennten und welche Kosten das verursacht? Wird der Einsatz des Systems evaluiert? Nach welchen Kriterien?

Und gibt es eine Messung, wie viel Arbeit tatsaechlich durch das System ueberhaupt eingespart werden kann? In der Anhoerung im Digitalausschuss fragte Rebecca Lenhard, worauf sich die Einschaetzung von Minister Wildberger stuetze, dass sich Antragsverfahren durch Agentic-AI-Systeme wie SPARK „um bis zu 80% beschleunigen lassen“ (ab 17:29 in der Aufzeichnung). Die Antwort: Das seien die Erfahrungen des Projektteams von SPARK. Das klingt nicht nach einer systematischen Analyse, sondern nach anekdotischer Evidenz. Ein „Argument“ von Jarzombek war, dass vorher Bezirksregierungen im Rahmen von Einwendungen „Briefe oeffnen“ mussten – anscheinend hilft Agentic AI kuenftig auch dabei, per Brief eingehende Einwendungen zu oeffnen, man weiss es nicht. Wer Informatiker*in ist und unter niedrigem Blutdruck leidet, sollte unbedingt den Teil der Fragerunde mit Sonja Lemke ab Minute 20:40 ansehen, danach ist man definitiv kuriert.

Abschliessend muss ich nochmal wiederholen: Ich bin ernsthaft entsetzt, dass ich auch nach Aufruf auf Mastodon keine einzige Quelle gefunden habe, in der das SPARK-Repo auch nur einem kursorischen Blick in den Quelltext ausgesetzt wurde. Das ist wirklich erschreckend und ein riesiges Warnsignal fuer das Auseinanderdriften der Erfahrung-mit-IT-und-Daten-Bubble und der Netz-und-Digitalpolitik-Bubble. Man kann sehr viel Geld fuer von FOMO lebenden, taeglich erscheinenden Digitalpolitik-Journalismus-Newslettern ausgeben, die mittlerweile (hinter der Paywall) mit die letzten Outlets fuer die journalistische Begleitung der mittlerweile mit einem eigenen Ministerium ausgestatteten Digitalpolitik sind – und niemand dort hielt es offenbar fuer geboten, jemanden mit praktischer Erfahrung mit so etwas mal in dieses Repo schauen zu lassen. „Transparenz“ wird damit zur Nebelkerze: Das BMDS veroeffentlicht regelmaessig irgendetwas und kann darauf vertrauen, dass gar niemand damit hinterherkommt, diese Veroeffentlichungen auf Herz und Nieren abzuklopfen. Der Fachbegriff dafuer ist, soweit ich weiss, Gish-Gallop.

Wohl gemerkt: Ich halte mich auch nur fuer jemanden mit gefaehrlichem Halbwissen – ich kann Docker-Container aufsetzen und Compose-Files lesen, aber mein Kontakt zu IT-Sicherheitsforschung beschraenkt sich weitgehend darauf, mal in einem rc3-Beitrag von Zerforschung einen baertigen Schreiner der Hack, Hack, Hack & Hack UG gespielt zu haben. Aber schon die Antworten auf meinen Masto-Rant von heute scheinen weit ueber das hinauszugehen, was irgendwo in klassischen Journo-Outlets beschrieben wurde.

Das ist enorm bedenklich. Ich sehe nicht den einen Faktor, woran das liegt. Vermutlich ist es Multiorganversagen: Vor 17 Jahren praegte „das alte Twitter“ von damals, was „der Netzdiskurs“ war. Das war noch bevor die Guttenberg-Apologet*innen wenige Jahre spaeter – fuer viele ueberraschend – auch im Netz waren. In der Zwischenzeit wurde Digitalpolitik immer mehr zur Nische, gibt es immer weniger fachlich fundierte Begleitung, wurde das ehemalige Twitter zum Hellhole, gibt es auf Mastodon das „Wohnzimmer fuer Nerds“, das aber wenig Anschluss zur Politik hat, und beschraenken sich viel zu viele Digital-NGOs darauf, immer absurdere Ideen der Bundesregierung mit immer weniger aus dem IT-Bereich rekrutierten Personal nur mehr „weniger schlimm“ oder „irgendwie gemeinwohlorientiert“ machen zu wollen, anstatt fundamentale fachliche Widersprueche aufzuzeigen. Und das wird immer mehr zu einem richtig grossen Problem.

Nachtrag

Quasi als P.S., ich hatte es bereits auf Mastodon geposted: Ich war auch etwas erschrocken darueber, dass ich beim Eintauchen in das Repo immer wieder gemurmelt hatte, warum das denn noch niemand sonst analysiert habe. Und ich daraufhin Rueckfragen bekam, warum das nicht z.B. die oben genannte zerforschung-Gruppe zerlegt habe, oder konkret Lilith Wittmann, oder Bianca Kastl. Ich werte das mal vorwiegend als Kompetenz- und Vertrauenserklaerung gegenueber diesen Menschen.

Aber, ganz offen: Diese Menschen haben zwar vielfach in der Vergangenheit Quatsch als solchen benannt. Aber sie sind halt ehrenamtliche Menschen, die all zu schlimmen Unsinn aufgedeckt haben. Es kann und darf nicht sein, das wir als Gesellschaft solche Analysen allein solchen Ehrenamtlichen aufbuerden. Zumal es sowohl im Journalismus als auch im NGO-Bereich bezahlte Menschen gibt, die z.B. „Wirkungsorientierung“ bei staatlichen Digitalprojekten analysieren wollen. It’s your fucking job, folks. Was tut ihr, um solche Analysen zu machen und sie einem allgemeinen Publikum zugaenglich zu machen?

Linked Open Data mit CSVW und fuer Ratsprotokolle

Schreibe eine Antwort

Zwei Fundstuecke der letzten Monate:

CSVW alias CSV on the Web ist ein auch vom britischen GDS offiziell empfohlener W3C-Standard, um klassische tabellarisch vorliegende Datenbestaende mit Semantik anzureichern. Das oben eingebettete Webinar gibt einen kleinen Ueberblick, diese Website mit „maturity levels“ erklaert schoen bildlich Schritt fuer Schritt, wie man von einer (fuer menschlichen Konsum gedachten) Tabelle bis zu tatsaechlichem Linked Data kommen kann.

Das Beispiel mit den maturity levels gefaellt mir deswegen so gut, weil es einen haeufig genannten Knoten loest. Bei der klassischen Darstellung der Treppe von 1*- bis 5*-Daten stolpern viele ueber die Frage, wie man denn von CSV weiter in Richtung Linked Data kommen kann. Das Beispiel beginnt bereits damit, nicht nur ein CSV, sondern ein „tidy“ CSV herzustellen. Schon das ist ein enorm wichtiger Schritt, der aber bei staatlichen Datenbestaenden viel zu oft ausgelassen wird – vermutlich auch deswegen, weil diejenigen, die diese Datenbestaende anlegen, sie nur sehr selten ueberhaupt selber automatisiert weiterverarbeiten. (Danke an Benjamin Degenhart fuer den Tipp)

Von einem weiteren spannenden Projekt erzaehlte mir Matthias Groenewald auf dem Open-Data-Barcamp in Hamburg: Lokale Besluiten Linked Open Data (LBLOD) ist eine fuer Flandern entwickelte Werkzeugkiste, mit der Protokolle semantisch annotiert werden koennen.

Das Projekt ist bereits ueber 10 Jahre alt und mir bislang peinlicherweise noch nie ueber den Weg gelaufen – die zugehoerigen Github-Repositories legen aber die Vermutung nahe, dass das bis heute aktiv eingesetzt wird. Hier ist beispielhaft ein so aufbereitetes Ratsprotokoll von Ende Maerz aus Mesen.

Das finde ich auch deswegen so spannend, weil gerade „Agentic AI“ als Allheilmittel fuer alle moeglichen Verwaltungsdigitalisierungsprobleme in den Ring geworfen wird – auch z.B. fuer angeblich so komplizierte haendische Schwaerzungen bei der Erfuellung von Antraegen nach Informationsfreiheitsgesetzen. Haette man – wie Flandern – schon vor 10 Jahren damit angefangen, Dokumente semantisch zu annotieren, haette man damit z.B. auch „hier ist ein Personenbezug“ maschinenlesbar einfuegen koennen. Mit nur ein klein wenig mehr Weitsicht beim Anlegen der Dokumente wird damit eine automatisierte Schwaerzung zum Kinderspiel – ganz ohne irgendwelche „Agentensysteme“.

Was heisst eigentlich „maschinenlesbar“ – und weiss das auch der Gesetzgeber?

Schreibe eine Antwort

Wenn man sich durch Gesetzestexte rund um Daten und ihre Verfuegbarkeit graebt, faellt einem irgendwann auf, dass da zwar von „Daten“ und auch „maschinenlesbaren Daten“ geschrieben wird – damit aber ganz unterschiedliche Bedeutungen verbunden sein koennen. Vor ein paar Wochen ist mir das wieder aufgefallen, als ich eine kleine Anfrage zum Stand von Linked Open Data in Hamburg (Drucksache 23/1881) zugeschickt bekam, die „maschinenlesbar“ geradezu wahllos interpretiert hatte.

In „Open Data, wie es zu Covid haette sein koennen“ bin ich im Januar 2022 schon ein wenig auf die verschiedenen Ebenen von Maschinenlesbarkeit eingegangen. Damit ich das nicht alles wiederholen muss, empfehle ich, den Artikel vorher zu lesen. Ich warte solange 🙂

Beim Blick in Gesetze fallen nun verschiedene Definitionen fuer Maschinenlesbarkeit auf. Manchmal steht da gar nichts dazu (aber immerhin in der Gesetzesbegruendung, so wie beim EGovG), manchmal gehen die Definitionen mehr ins Detail:

Die Behörden des Bundes mit Ausnahme der Selbstverwaltungskörperschaften stellen unbearbeitete maschinenlesbare Daten, die sie zur Erfüllung ihrer öffentlich-rechtlichen Aufgaben erhoben haben oder durch Dritte in ihrem Auftrag haben erheben lassen, zum Datenabruf über öffentlich zugängliche Netze bereit.

§ 12a EGovG

Im Sinne dieses Gesetzes […]
3. sind Daten vorhandene Aufzeichnungen, unabhängig von der Art ihrer Speicherung, […]
5. liegt ein maschinenlesbares Format vor, wenn die Daten durch Software automatisiert ausgelesen und verarbeitet werden können,
6. ist offenes Format ein Dateiformat, das nichtproprietär und plattformunabhängig ist und der Öffentlichkeit ohne Einschränkungen, die der Nutzung von Daten hinderlich wären, zugänglich gemacht wird,
7. ist förmlicher offener Standard ein in Textform niedergelegter Standard, in dem die Anforderungen für die Sicherstellung der Interoperabilität der Software niedergelegt sind,

§ 3 Nr. 3 und 5–7 DNG

Im Sinne dieses Gesetzes ist
1. ein maschinenlesbares Format ein Dateiformat, das so strukturiert ist, dass Softwareanwendungen bestimmte Daten, einschließlich einzelner Sachverhaltsdarstellungen und deren interner Struktur, leicht identifizieren, erkennen und extrahieren können,
2. ein offenes Format ein Dateiformat, das plattformunabhängig ist und der Öffentlichkeit ohne Einschränkungen, die der Weiterverwendung von Informationen hinderlich wären, zugänglich gemacht wird,
3. ein anerkannter, offener Standard ein schriftlich niedergelegter Standard, in dem die Anforderungen für die Sicherstellung der Interoperabilität der Software niedergelegt sind.

§ 5 Abs. 3 LTranspG Rheinland-Pfalz

Das koennte man amuesant finden, sorgt aber in der Praxis bisweilen zu ganz unterschiedlichen Auslegungen auch der Verwaltung beim Vollzug, was denn nun damit vom Gesetzgeber gemeint war. Und damit auch fuer eine sehr unterschiedliche Wiederverwendbarkeit: Kann ich diese „Daten“ auch ohne grossen Aufwand weiterverarbeiten, oder muss ich erst einmal viel Energie investieren, um sie in eine nutzbare Fassung zu bringen?

Diese Begriffsvielfalt ruehrt vermutlich auch von der Doppeldeutigkeit her, mit der wir im Alltag von „Daten“ sprechen. Wenn man nachfragt, was damit eigentlich gemeint ist, laeuft es meistens auf eine von zwei Definitionen hinaus:

  1. Irgendwas, was digital gespeichert ist und von einer Maschine interpretiert und dargestellt werden kann
  2. Eine Menge von Sachverhaltsdarstellungen, die maschinell und automatisiert ausgewertet werden kann

Diese Unterscheidung sieht auf den ersten Blick etwas haarspalterisch und detailverliebt aus. Bei genauerem Hinsehen eroeffnet das aber ein besseres Verstaendnis fuer die fundamentalen Missverstaendnisse, die daraus im Alltag entstehen koennen – aber auch in der Gesetzgebung.

Sichtweise 1: Alles, was als Bits und Bytes daherkommt, sind Daten (Daten als Symbole)

Das ist die Trivial-Interpretation des Daten-Begriffs, die immer noch erstaunlich weit verbreitet ist. Auf der Smart-Country-Convention lauschte ich 2025 einem Panel zu Open Data, auf dem einer der Diskutanten behauptete, dass man ja den Fokus bei Open Data nicht nur auf „Daten-Daten“ richten sollte, sondern man koenne ja auch mit „Text-Daten“ arbeiten, weil das koenne ja kuenftig alles „die KI“ richten.

Dass man sowas auf solch einem Panel sagen kann, ohne irgendeinen Einspruch gegen die These oder die Erfindung des Begriffs „Daten-Daten“ zu erfahren, ist fuer sich schon beachtlich. Andererseits erklaert die weite Verbreitung dieser Vulgaerdefinition von Daten aber sowohl die teilweise sinnentstellende Verwendung von „Maschinenlesbarkeit“ als auch die Erwartung an „KI“ – gemeint waren hier wohl Spielarten von LLM – als Heilsbringer.

Konkret bis zum Ende durchgedacht, faellt mit der Definition „alles, was als digitale Symbole vorliegt, sind Daten“ naemlich auch der Begriff der Maschinenlesbarkeit in sich zusammen. In diesem Bild geht es allein darum, dass irgendetwas von der Maschine binaer entgegengenommen und dann auf irgendeine Weise einer Person dargestellt wird. Eine MP3 mit einem Musikstueck: Daten. Ein Foto: Daten. Eine eingescannte Tabelle, die dann als Bild in eine Worddatei eingefuegt wird: Daten. Dieselbe Word-Datei, als PDF ausgegeben (aber immer noch nur mit einem Scan der Tabelle): Daten.

Mit dieser Definition wird jede digitale Zeichenkette, die nicht gerade zufaelliges Rauschen ist, sondern auf irgendeine Weise als Dateiformat interpretiert und dargestellt werden kann, zu „Daten“. Das ist maximal die unterste Stufe der 5-Sterne-Definition fuer offene Daten: Ich kann das Ding ueber Computernetzwerke verschicken, ein Rechner kann es irgendwie darstellen, aber eine maschinelle Auswertung einzelner Sachverhaltsdarstellungen darin bedarf einer menschlichen Interpretation.

Vermutlich kommt daher auch die Begeisterung fuer „die KI“: Nachdem man Sachverhaltsdarstellungen ueber Jahrzehnte in Schrottformaten hin- und hergeschoben hat, die laufend menschlicher und haendischer Interpretation beduerfen und bei denen die automatisierte Weiterverarbeitung hoechst muehsam ist, haben wir jetzt eine Silver Bullet, die das bestimmt alles loesen wird. Also, zwar nicht deterministisch, sondern auf stochastischen Methoden basierend, aber es wirkt am Ende so, als komme ein Ergebnis heraus. Schliesslich schlaegt einem „die KI“ das voller Ueberzeugung vor.

Sichtweise 2: Daten als maschinell verarbeitbare Sachverhaltsdarstellungen oder Aussagen ueber Fakten

Diese Sichtweise steht im Fuenf-Sterne-Modell fuer die Stufen 3–5: Es reicht nicht mehr, dass das Dokument nur irgendwie darstellbar ist, sondern es muessen auch einzelne Sachverhaltsdarstellungen oder auch Zusammenhaenge zwischen ihnen maschinell auswertbar sein. Das ist der Wortlaut, der sich beispielsweise im oben zitierten Landestransparenzgesetz RLP findet. Der Begriff „Daten“ steht damit nicht mehr fuer „da ist irgendwas binaer gespeichert“, sondern fuer „eine Menge von Sachverhaltsdarstellungen, die eine Maschine ohne weiteres Zutun erkennen und auswerten kann“.

In der Praxis heisst das folgerichtig mindestens, dass auch einzelne Sachverhaltsdarstellungen maschinenlesbar codiert sein muessen – das ist die etwas umstaendliche Definition von „eine Tabelle ist nicht nur ein Scan oder im PDF codiert, sondern liegt als weiterverarbeitbares CSV vor“. Idealerweise geht die „Identifizierung und Erkennung von Sachverhaltsdarstellungen“ durch Software aber noch weiter: Mit Linked-Data-Prinzipien koennen auch semantische Zusammenhaenge maschinell auswertbar codiert werden. Mehr dazu wie oben angerissen im Open-Data-bei-Covid-Artikel von vor vier Jahren.

Eselsbruecke: Nicht ueber Daten sprechen

Was ich gerne vorschlage, wenn Begriffe (z.B. „Digitale Souveraenitaet“ *hust) von verschiedenen Leuten ganz unterschiedlich und sich widersprechend verwendet werden, ist eine Runde Tabu zu spielen: Lass mal darueber diskutieren, aber niemand darf „Daten“ sagen.

Das hat mir geholfen, die altbekannte DIKW-Pyramide ein wenig anzupassen. Die schlaegt urspruenglich eine Hierarchie vor, wie man von „Data“ ueber „Information“ und „Knowledge“ zu „Wisdom” kommt. Da „Data“ aber jetzt verboten ist, ersetzen wir das durch „Facts“ „Statements of Facts“:

Bearbeitung nach Longlivetheux: DIKW Pyramid, CC BY-SA 4.0

Zusaetzlich fuehren wir eine Y-Achse ein, die angibt, welche Ebene der Pyramide in Symbolen (also Bits und Bytes, als Ersatzbegriff fuer diese Definition von „Daten“) codiert ist. Das Beispiel des Scans einer Tabelle als Foto in einem PDF liegt digital vor, es handelt sich aber um Informationen fuer menschlichen Konsum, deren weitere maschinelle Verarbeitung einer Aufarbeitung bedarf. Wenn man genAI-Bro ist, kann man natuerlich sagen, dass einem das Lieblingssprachmodell das alles nach Excel uebersetzen kann. Das ignorieren wir aber mal, denn so eine Tabelle lag ja bereits einmal als Spreadsheet vor, vielleicht sogar im CSV-Format.

Wenn wir die Tabelle bekommen, sind einzelne Fakten- oder Sachverhaltsdarstellungen maschinell auswertbar und verarbeitbar. Ich muss zwar immer noch zuordnen, was in welcher Spalte zu finden ist und ggf. auch Einheiten zuordnen (stehen die Zahlen in Spalte F fuer Minuten oder fuer °C, bzw. welche Spalten von Zahlen und damit verbundenen Einheiten gehoeren logisch zusammen?), ich muss aber diese Darstellungen nicht mehr fuer die Weiternutzung erst aufbereiten.

Exkurs: Ich habe mittlerweile auch wirklich eine Abneigung gegen den Begriff der „Veredelung von Daten“ entwickelt. Der ist eng mit der Behauptung von Daten als dem neuen Oel verbunden, die Clive Humby 2006 in die Welt gesetzt hatte: Wie Rohoel seien „Rohdaten“ an sich wenig nuetzlich, aber durch ihre „Veredelung“ koenne eine Vielzahl wertvoller Produkte geschaffen werden. Der Vergleich ist ohnehin aus vielen Gruenden total Banane, wenn man mehr als fuenf Minuten ueber ihn nachdenkt: Daten sind anders als Oel nicht-rivalisierende Gueter, sie verbrauchen sich nicht etc.pp. Und genauso ist es stets eine Entscheidung, auf welche Weise man Informationen speichern kann: Niemand wird gezwungen, „Daten“ erstmal als Rohoel oder Klaerschlamm oder Rizinusoel zu speichern, das man erst einmal irgendwie kompliziert „raffinieren“ muss. Man kann’s halt auch gleich von Anfang an moeglichst „raffiniert“ speichern, himmihergottnochamal.

So, geht schon wieder. Die von vorneherein „edle“ Speicherung bringt uns dann naemlich dazu, auch Semantik zu codieren und Linked-Data-Prinzipien zu verwenden. Damit werden die Zusammenhaenge zwischen Aussagen so codiert, dass sie als propositionales Wissen nach Regeln der Logik maschinell auswertbar sind – und im Gegensatz zu Sprachmodellen geht das deterministisch (es kommt jedes Mal dasselbe raus und nicht einmal dies und einmal das) und ohne dafuer Energiemengen ganzer Volkswirtschaften einfach so mal eben zu verbraten.

PS zu diesem Abschnitt: Ich bin heute nicht so ganz gluecklich damit, dass ich beim Zusammenbasteln der Darstellung das PDF auf Stufe 2 der angepassten DIKW-Pyramide gesetzt hatte. Das ergibt nur dann Sinn, wenn man diese „Information“-Stufe als „normalerweise nur durch Menschen auswertbar“ annimmt – oder eben zulaesst, dass man Sprachmodelle draufwirft, womit die maschinelle Auswertung hier aber im Gegensatz zu allen anderen Stufen nicht mehr deterministisch passieren kann.

Und was sagen jetzt der Gesetzgeber und die Verwaltung?

Ganz unterschiedliche Sachen. Das EGovG definiert den Begriff im Gesetz gar nicht, das Datennutzungsgesetz ist… interpretationsoffen, je nachdem, wie man interpretiert, ob „Daten“ nun Symbole oder Sachverhaltsdarstellungen sind. In der Gesetzesbegruendung wird die Wichtigkeit von Maschinenlesbarkeit mit Verweis auf die Europaeische Open-Data-Richtlinie hervorgehoben und auch eine ausfuehrlichere Definition mit Verweis auf Erwaegungsgrund 35 der Open-Data-Richtlinie ausgefuehrt – dort steht naemlich:

Ein Dokument sollte als maschinenlesbar gelten, wenn es in einem Dateiformat vorliegt, das so strukturiert ist, dass Softwareanwendungen die konkreten Daten einfach identifizieren, erkennen und extrahieren können. Daten in Dateien, die in maschinenlesbarem Format strukturiert sind, sollten als maschinenlesbare Daten gelten. Ein maschinenlesbares Format kann offen oder proprietär sein. Es kann einem formellen Standard entsprechen oder nicht. Dokumente, die in einem Dateiformat kodiert sind, das eine automatische Verarbeitung einschränkt, weil die Daten nicht oder nicht ohne Weiteres aus ihnen extrahiert werden können, sollten nicht als maschinenlesbar gelten. Die Mitgliedstaaten sollten die Anwendung in der Union oder international anerkannter offener, maschinenlesbarer Formate — wo dies möglich und angemessen ist — fördern. Bei der Entwicklung technischer Lösungen für die Weiterverwendung von Dokumenten sollte gegebenenfalls der europäische Interoperabilitätsrahmen berücksichtigt werden.

Erwaegungsgrund 35 der Richtlinie (EU) 2019/1024

Das ist leider auch nicht so einfach verdaulich. Die Open-Data-Richtlinie spricht allgemein von „Dokumenten“ (egal in welcher Form) im Besitz oeffentlicher Stellen, d.h. vom Papierdokument ueber die Fachverfahrensdatenbank und andere digital codierte Dokumente bis zu einer Steintafel kann damit alles gemeint sein (Artikel 2 Nr. 6). „Daten“ werden nicht ausdruecklich definiert, durch die Definition der Maschinenlesbarkeit in Artikel 2 Nr 13 in Verbindung mit den Erwaegungsgruenden liegt aber nahe, dass damit die Definition „Daten als Sachverhaltsdarstellungen“ innerhalb von Dokumenten gemeint ist:

Im Sinne dieser Richtlinie bezeichnet der Ausdruck […]
13. „maschinenlesbares Format“ ein Dateiformat, das so strukturiert ist, dass Softwareanwendungen konkrete Daten, einschließlich einzelner Sachverhaltsdarstellungen und deren interner Struktur, leicht identifizieren, erkennen und extrahieren können;

Ein Dokument kann also auch digital vorliegen, und Sachverhaltsdarstellungen darin sind „Daten“. Warum man das nicht 1:1 so wie in der Open-Data-Richtlinie bzw. der Gesetzesbegruendung ins DNG und EGovG geschrieben hat, weiss ich auch nicht. Das DNG verwendet den „Daten“-Begriff in § 3 direkt nacheinander so, wie die Open-Data-Richtlinie zuerst „Dokumente“ und dann „Daten/Sachverhaltsdarstellungen“ bezeichnet. Das ist unnoetig verwirrend und mir ist nicht klar, ob dahinter eine Absicht steckte oder ob das ein Unfall war.

Diese Unschaerfe hatte offenbar mittlerweile Folgen, weil andere wiederum das DNG als Vorlage fuer weitere Gesetze verwendet haben. Oben hatte ich § 5 LTranspG Rheinland-Pfalz zitiert, das woertlich die Definition aus PSI- bzw. Open-Data-Richtlinie mit den Sachverhalten uebernommen hatte. Meiner Lesart nach haette man dieses Landestransparenzgesetz ohne Probleme anpassen koennen, um damit auch Open Data abfruehstuecken zu koennen. Die Landesregierung hatte sich aber ohne Not dazu entschlossen, ein eigenes Open-Data-Gesetz zu stricken, weil sie zwischen Dokumenten „fuer menschlichen Konsum“ und Daten „fuer maschinelle Verarbeitung“ unterscheiden wollten. Dort steht als Definition nun nur mehr:

Daten sind vorhandene Aufzeichnungen, unabhängig von der Art ihrer Speicherung. […]
Maschinenlesbar sind Daten, wenn sie in einem Format vorliegen, das ihre automatisierte Auslesung und Verarbeitung durch Software ermöglicht.

§ 3 ODGRP

Der Gesetzesentwurf und seine Begruendungen sind noch an vielen anderen Stellen hanebuechen (ich durfte das auf Arbeit kommentieren und es fiel mir schwer, freundlich zu bleiben). Die Gesetzesbegruendung (PDF, Seite 36 „zu Absatz 4“) legt nahe, dass beim Entwurf Leute die Formulierungen aus dem DNG abgekupfert haben, ohne sie so ganz zu verstehen – so auch bei der Begruendung auf Seite 24, warum das schon alles so seine Richtigkeit habe weil’s ja ans DNG angelehnt sei. Dass dann auch noch davon gesprochen wird, dass Offene Daten deswegen so wertvoll seien, weil sie Grundlage fuers Training generativer KI-Modelle sein koennten, passt perfekt zum Rest des Gesetzes.

Grosse Teile der Antworten auf die kleine Anfrage in Hamburg, die Ausloeser fuer diese Ueberlegungen war, kann ich mir auch nur so erklaeren: Irgendwo hat man Definitionen gelesen, was „Daten“ und „maschinenlesbar“ sein soll, interpretiert dann das hinein, was sich auf die eigenen Vorstellungen mappen laesst und spielt reihenweise Fluesterpost, an deren Ende dann halt auch mal wirklicher Unsinn rauskommt. Verwaltungsdigitalisierung als Hoehlengleichnis oder so.

Was lernen wir daraus?

  • Die Definitionen in der Open-Data-Richtlinie sind ganz okay…
  • …wurden aber in EGovG und DNG ziemlich schludrig uebersetzt, so dass die Interpretation des Sinnzusammenhangs eigene praktische Erfahrungen im Umgang mit „Daten“ erfordert (also maschinelle Verarbeitung von Zusammenhaengen, nicht nur „Powerpoint und Excel klicken“)
  • andere schreiben nun wiederum vom DNG ab
  • vermutlich ohne die Definitionen in der Open-Data-Richtlinie verstanden zu haben
  • das fuehrt zu seltsamen Antworten und unnoetigen Gesetzen und generell der Verfestigung von Bloedsinnsideen wie der Unterscheidung von „Textdaten und Daten-Daten“
  • man sollte sagen koennen, was man meint, ohne den Begriff „Daten“ zu verwenden (als lustige Uebung fuer zwischendurch)
  • (man sollte vielleicht auch mehr rausgehen oder in eine Huette im Wald ziehen)
  • (aber das hat nichts mit dem Datenbegriff zu tun)
  • auf jeden Fall sollten beim Staat viel mehr Leute arbeiten, die praktische Erfahrungen mit all diesem Zeug haben, damit sie bessere Gesetze dafuer schreiben und es besser praktisch in die Tat umsetzen koennen
  • es koennte sich lohnen, die Formulierung im DNG nochmal zu praezisieren, damit da nicht weiter schludrig abgeschrieben wird
  • alternativ (und langfristig sicher auch sinnvoll) koennte man diejenigen, die sowas schludrig abschreiben und sich nicht auskennen, sowas nicht mehr machen lassen sondern sie z.B. rausschicken oder in eine Huette im Wald ziehen lassen.

Nachtrag Juni 2026: Ich hatte hier urspruenglich immer wieder von Daten als „Sachverhalten“ geschrieben, obgleich das gar keinen Sinn ergibt – die richtige Formulierung, die auch so in der ODD steht, ist „Sachverhaltsdarstellungen“. Damit loest sich auch der Knoten in meinem Kopf, den ich urspruenglich bei der Ersetzung von „Data“ in der DIKW-Pyramide durch „Facts“ hatte: Auch das ergibt eigentlich keinen Sinn, und das Stoergefuehl, das ich dabei hatte, haette mich eigentlich stutzig machen muessen. Wenn man Daten als Sachverhaltsdarstellungen ansieht, werden daraus auf Englisch korrekterweise „Statements of Facts“, was auch zulaesst, dass diese Statements falsch, unzulaenglich o.ae. sein koennen – so wie das bei Daten eben auch der Fall ist. Die Formulierungen im Text habe ich entsprechend korrigiert.

Aufnahme eines Betonbaus als Zugang zu einer Tiefgarage, darueber ein Sparkassen-Lichtreklamen-Logo

Wo sind Sparkassen nahe an Tiefgaragen – Schoener leben mit Linked Open Data

1 Antwort

Wenn man (aus welchen Gruenden auch immer) wissen wollte, wo in der Gegend Sparkassen nahe an Tiefgaragen liegen, dann liegt es natuerlich sehr nahe, auszurufen „aha, das ist ein Fall fuer Open Data!“ und damit auch gleich ziemlich richtig zu liegen.

Titelfoto: Peter Nath, 2014 09 21 OG Sparkassenareal und noerdl Innenstadt 34, CC BY 4.0

Mit der Overpass-API lassen sich naemlich nicht nur Features – wie zum Beispiel Hydranten – aus OpenStreetMap abfragen, man kann auch komplexere Abfragen nach Dingen in einem bestimmten Abstand zu anderen Dingen dort machen. Die Beispielliste fuehrt lustigerweise ein Query nach Banken auf, die weit weg von Polizeistationen liegen. Das laesst sich fuer unseren Zweck natuerlich leicht anpassen.

So sah meine schnell zusammengeschusterte Abfrage nach Banken aus, die maximal 30 Meter um eine gemappte Tiefgarage liegen:

[out:json][bbox:{{bbox}}][timeout:25];
// gather results
//nwr["amenity"="bank"]["name"="Sparkasse"]->.sparkassen;
nwr["amenity"="bank"]->.banken;
nwr["parking"="underground"]->.tiefgaragen;

nwr.banken(around.tiefgaragen:30);
// print results
out geom meta;

He warte, wir wollten Sparkassen!

Aber Moment mal: Das filtert doch nach allen in OpenStreetMap verzeichneten Banken, nicht nur nach Sparkassen! Ja, richtig – in der Zeile obendrueber ist ein Filter, der nur die Banken beruecksichtigt, die „Sparkasse“ heissen. Aber der beruecksichtigt eben nur Banken, die exakt Sparkasse in genau dieser Schreibweise heissen.

Manche Sparkassenfilialen sind in OpenStreetMap auch einfach nur als Sparkasse getaggt, andere heissen so wie die jeweilige Kreis- oder Stadt- oder sonstige Sparkasse. Ob name = Sparkasse Neu-Ulm - Illertissen (Brückenhaus) schon zu ausfuehrlich ist, mag ich nicht beurteilen. Wenn man alle Banken sucht, in deren name Sparkasse vorkommt, koennte man die Abfrage mit einem Regulaeren Ausdruck bauen, beispielsweise mit einer Suche nach nwr["amenity"="bank"][name~".*(S|s)parkasse.*"]. Das Problem dabei: Solch eine Anfrage an die Overpass-API laeuft schnell in einen Timeout, sobald der abzufragende Kartenausschnitt etwas groesser ist.

Der Unterschied zwischen Namen, Betreiber und Marke

Beim Blick auf den Screenshot oben mit der Filiale am Brueckenhaus faellt aber der Key operator= auf, in dem hier explizit die Sparkasse Neu-Ulm – Illertissen (mit exakt diesem etwas seltsam aussehenden Namen) als Betreiberin eingetragen war. Und wenn man das Tagging-Schema fuer Banken genauer betrachtet, wird dort der Key brand= vorgeschlagen, mit dem die „Marke“ einer Einrichtung angegeben werden kann.

Das vereinfacht die Suche nach bestimmten Banken, ohne irgendwelche Wildcard-Suchen auf den Namen machen zu muessen – wenn die Bank denn ausfuehrlich getaggt worden ist:

  • name bezeichnet den Eigennamen genau dieser Bankfiliale. Vielleicht reicht hier eh nur „Sparkasse“, andere schreiben sonst noch was dazu, so ist das eben in OSM.
  • operator ist die Betreiberin – hier eben die jeweilige oeffentlich-rechtliche Sparkasse mit ihrem Kreis- oder Stadt- oder sonstigen Namen
  • brand ist die (Dach)Marke der Bank – und das ist hier tatsaechlich immer „Sparkasse“

Ist „Aldi Sued“ dasselbe wie „ALDI SÜD“?

Alles erledigt, jetzt koennen wir filtern, wuerde man meinen – oder? Die deutschsprachige Beschreibung von brand weist aber darauf hin, dass der Markenname gemaess der jeweiligen Namenskonventionen eingetragen werden soll. Als Beispiel: Aldi-Supermaerkte werden im Name-Tag als „Aldi“ oder „Aldi Nord“ oder „Aldi Sued“ getaggt. Die Schreibweise der Marke sei jedoch „ALDI Nord“ oder „ALDI SÜD“. Das muss man natuerlich dann erst einmal wissen, sowohl beim Tagging als auch bei der Abfrage.

Mit Linked Open Data ist aber auch dieser Fallstrick ueberhaupt kein Problem mehr, und sowohl die Wiki-Beschreibungen von brand als auch von operator verweisen jeweils auf die optionalen Keys operator:wikidata und brand:wikidata, mit denen beiden die eindeutige Wikidata-ID zugewiesen werden kann. Fuer eine Sparkassenfiliale kommt also neben brand=Sparkasse einfach brand:wikidata=Q13601825 dazu. Und schon lassen sich tatsaechlich nur Sparkassen anzeigen, die nahe an Tiefgaragen liegen – sofern denn brand und wikidata-ID der Marke getaggt wurden:

[out:json][bbox:{{bbox}}][timeout:25];
// gather results
nwr["amenity"="bank"]->.banken;
(
  nwr.banken["brand"="Sparkasse"];
  nwr.banken["brand:wikidata"="Q13601825"];
)->.sparkassen;
nwr["parking"="underground"]->.tiefgaragen;

nwr.sparkassen(around.tiefgaragen:30);
// print results
out geom meta;

(Randbemerkung, weil ich die letzten Stunden Wikidata-IDs und operators und brands auf OpenStreetMap nachgetragen habe: Fuer Sparkassen ist das schoen aufdroeselbar. Bei Genossenschaftsbanken, die mal als „Volksbank“, mal als „Raiffeisenbank“ firmieren und fuer die es keine Wikidata-ID fuer die jeweilige „Marke“ zu geben scheint, wird das schon wieder komplexer. Ein neues Rabbit Hole!)

Deutschland-Stack – Der Zeitstrahl einer Silver Bullet

Schreibe eine Antwort

Der sogenannte „Deutschland-Stack“ ist seit einigen Monaten aus Diskussionen rund um die Verwaltungsdigitalisierung kaum mehr wegzudenken. Ob es sich dabei um einen leeren Signifikanten, eine verschiedentlich umdeutbare Projektionsflaeche oder ein sinnvolles Vorhaben handelt, bleibt strittig. Aus Neugier hatte ich die letzten Tage mal eine Timeline der Entwicklung des Begriffs bis Ende November 2025 und die zeitliche Parallelitaet zur Diskussion ueber einen „Euro-Stack“ zusammengestellt und mit anderen Menschen geteilt. Auf verschiedentliche Aufforderung wollte ich sie hier veroeffentlichen. Bei der Vervollstaendigung bin ich dann etwas eskaliert.

Ich habe bei weitem nicht alles aufgenommen, sondern versucht, zu filtern. Alles, was sich direkt auf den Sauerkrautstack bezieht, habe ich gefettet, der Rest ist quasi die umgebende Kulisse. Ergaenzungen, Hinweise und Erweiterungen gerne in die Kommentare oder auf anderem Wege an mich!

  • 2024-09-01: Erste Fundstelle in der Wayback Machine fuer eurostack.eu (offenbar damals mit Platzhalterseite)
  • 2024-12-19: Die erste Policy Study ueber einen „Eurostack“ wird veroeffentlicht (Archivlink). Auftraggeber waren die FES und die Foundation for European Progressive Studies.
  • 2025-01-03: Francesca Bria, eine der Autorinnen der Policy Study, veroeffentlicht einen Meinungsbeitrag zum „Eurostack“ im SZ Dossier Digitalwende (Paywall-Vertical). Ziel sei „Die Priorisierung strategischer Investitionen in fortschrittliche Halbleiter, öffentliches Supercomputing, Cybersicherheit, souveräne KI und Cloud-Infrastruktur“
  • 2025-01-06: Der Beitrag wird im SZ Dossier Platz der Republik (Paywall-Vertical) nochmals aufgegriffen.
  • 2025-01-23: Vor dem Hintergrund der US-„Stargate“-Initiative fuer generative KI-Systeme wird Bria nochmals im SZ Dossier Digitalwende (Paywall-Vertical) zitiert: „Es ist Zeit für mutige Investitionen und schnelles Handeln.“
  • 2025-02-??: Veroeffentlichung des ersten „Pitch Document“ auf eurostack.eu. Urspruenglich war vermutlich(!) dieses PDF gemeint (fruehester Archivlink vom Oktober 2025). Heute (Dezember 2025) verweist der URI auf https://eurostack.eu/wp-content/uploads/2025/08/eurostack-white-paper-final-19-05-25-3.pdf (Archivlink)
  • 2025-02-11: Bericht im Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical) zum „Euro-Stack“ mit Verweis auf das „Pitch Document“.
  • 2025-02-13: Veroeffentlichung von „EuroStack – A European Alternative for Digital Sovereignty“ (Archivlink) von Bria et al, „Commissioned by the Bertelsmann Stiftung“ (Archivlink des PDF)
  • 2025-02-13: Besprechung des Bertelsmann-Papiers im SZ Dossier Digitalwende (Paywall-Vertical): „Herzstück der Initiative ist die digitale Infrastruktur bestehend aus Chips, Kommunikation, Cloud, IoT, Datenräume, digitale Identitäten und KI“
  • 2025-02-23: Bundestagswahl
  • 2025-03-05: „Bitkom fordert Digitalpakt Deutschland“ (Archivlink), erste mir bekannte Erwaehnung eines Deutschland-Stack durch BITKOM
  • 2025-03-18: Bericht im SZ Dossier Digitalwende (Paywall-Vertical): „Mehr als 90 Unternehmen fordern mehr staatliche Investitionen in Schlüsseltechnologien“ mit Verweis auf den Euro-Stack.
  • 2025-03-25: Bericht bei Golem.de ueber die Koalitionsverhandlungen mit Erwaehnung eines „Deutschland-Stack“: „Ein »interoperabler und europäisch anschlussfähiger souveräner Deutschland-Stack« soll künstliche Intelligenz (KI), Clouddienste sowie Basiskomponenten integrieren. Dieser Stack werde Ländern und Kommunen bereitgestellt.“
  • 2025-03-25: Bericht im SZ Dossier Digitalwende (Paywall-Vertical) ueber Ergebnisse der AG Digitales zum Koalitionsvertrag. „Ein »interoperabler und europäisch anschlussfähiger Deutschland-Stack« soll Wettbewerb, Innovation und Transfer fördern und umfasse KI, Cloud-Dienste sowie Basiskomponenten, wie die Eudi-Wallet. Der Stack soll für Länder und Kommunen geöffnet werden, was einen Einstieg in ein gemeinsames Plattformdenken darstellen könnte.“
  • 2025-03-26: Der (fachlich dafuer zustaendige) IT-Planungsrat veroeffentlicht Version 1.0 der Leitlinien und des Zukunftsbilds der foederalen Digitalstrategie (Archivlink, PDF, PDF-Archivlink)
  • 2025-04-12: ZDF heute berichtet ueber die Koalitionsverhandlungen (Archivlink): „Schwieriger ist schon „Deutschland-Stack“. Googeln liefert als Ergebnis nur, dass der Branchenverband Bitcom einen solchen »Deutschland-Stack« gefordert hat. ChatGPT antwortet: »Der Begriff „Deutschland-Stack“ ist derzeit nicht als feststehender Begriff in der deutschen Digitalpolitik etabliert.« Wohl aber im Koalitionsvertrag von Union und SPD.“
  • 2025-05-05: Der Koalitionsvertrag wird unterzeichnet. Fundstelle: „Ländern und Kommunen wird die Nutzung folgender Lösungen ermöglicht, die prioritär umgesetzt werden: Ein interoperabler und europäisch anschlussfähiger souveräner Deutschland-Stack integriert KI, Cloud-Dienste sowie Basiskomponenten.“
  • 2025-05-06: Titel im Tagesspiegel Background Digitalisierung und KI (Paywall-Vertical), „Was steckt hinter dem Deutschland-Stack?“: „Die Euro-Stack-Initiative ist in erster Linie eine Industriestrategie mit dem Ziel, die EU digital souveräner und weniger abhängig von den Vereinigten Staaten und China zu machen. […] Abgesehen von diesen Anhaltspunkten ist das Konzept für den Deutschland-Stack aber noch sehr schemenhaft. […] Kernfrage wird dabei sein: Wie können existierende Vorhaben, Konzepte und Ideen in den Deutschland-Stack integriert werden?“. Der Artikel geht auch auf die Parallelentwicklungen des Schlandstack zur foederalen IT-Architektur ein. Fazit: „Die Frage, was der Deutschland-Stack werden soll, wird sich also erst in einigen Monaten langsam klären.“
  • 2025-05-13: SZ Dossier Digitalwende (Paywall-Vertical) berichtet von der anstehenden ersten Digitalministerkonferenz: „Zentral wird in dieser Hinsicht auch ein anderes Thema aus der Klausur des IT-Planungsrats: der sogenannte »Deutschland-Stack«, den Union und SPD laut Koalitionsvertrag entwickeln wollen. Die Idee ist noch so vage, dass die Debatte einen großen Teil der Klausur eingenommen hat. Nach Informationen von SZ Dossier könnte ein wichtiger Baustein ein Projekt werden, das noch gar nicht in Betrieb ist. Konkret geht es um eine KI-gestützte Plattform zur beschleunigten Planung des Wasserstoff-Kernnetzes, wie das Bundeswirtschaftsministerium das Vorhaben im vergangenen Dezember ankündigte.“
  • 2025-05-28: Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical) berichtet vom Auftritt von Digitalminister Wildberger bei der re:publica: „Im Gegensatz zum Wirtschaftstag konnte Wildberger damit aber bei der Republica keinen frenetischen Applaus einheimsen – wirklich enthusiastisches Klatschen gab es nur bei dem Versprechen des Ministers, bei dem geplanten Deutschland-Stack auf Open Source zu setzen.“
  • 2025-06-11: SZ Dossier Digitalwende (Paywall-Vertical) berichtet, dass der „Deutschland-Stack […] bis 2028 bereitstehen“ soll: „Bei der Klausur des Bund-Länder-Gremiums IT-Planungsrats stellte eine Bundesvertreterin kürzlich lediglich vage Ideen vor […] Gesucht wird allerdings noch eine Plattform, die bundesweit anschlussfähig ist und von den Ländern akzeptiert wird. Wie SZ Dossier berichtete, bevorzugt der Bund hier wohl die sogenannte Wasserstoffplattform. Konkret geht es um eine KI-gestützte Plattform zur beschleunigten Planung des Wasserstoff-Kernnetzes, wie das Bundeswirtschaftsministerium das Vorhaben im vergangenen Dezember ankündigte. Die Idee: Sie sollte für alle Genehmigungsprozesse genutzt werden, nicht nur in diesem engen Bereich.“
  • 2025-06-11: „Thesen zu einem erfolgreichen DeutschlandStack / EuroStack“ vom „Sovereign Cloud Stack“ aus dem Umfeld der OSBA (Archivlink). Sehr vom DigiSouv-Buzzword getrieben und darauf gemuenzt, dass der „Stack“ lieber von vielen mittelstaendischen Anbietern als von einem monolithischen europaeischen Anbieter betrieben werden solle. Inhaltlich wirkt es hier so, als werde der Schlandstack lediglich als eine nationale Variante der (als an eine allgemeine Oeffentlichkeit gerichtete Dienstleistungsinfrastruktur) „Eurostack“-Idee angesehen, nicht als ein Vorhaben fuer die oeffentliche Verwaltung.
  • 2025-06-20: Tagesspiegel Background Digitalisierung & KI titelt „Deutschland-Stack: Gerangel um die Deutungshoheit“: „Bei der Definition des Deutschland-Stacks verhält es sich wie bei dem Gleichnis mit den blinden Männern und dem Elefanten: Je nachdem, wen man fragt, fällt die Beschreibung anders aus. […] Ein erstes, grobes Zielbild kann das BMDS inzwischen beschreiben: Der Stack soll eine »nationale, souveräne Technologieplattform« werden.“ Hier wird auch die Frage ueber Funktionen, Voraussetzungen, bereits Vorhandenes und Fundamente gestellt: „Im Hintergrund ist jedoch zu hören, dass das Mission-0-Team Schwierigkeiten hat, die obigen Fragen zufriedenstellend zu klären – denn ihnen fehlen zum Teil wichtige Informationen, vor allem zu der geplanten Wasserstoffplattform. Wie Tagesspiegel Background erfuhr, ist in dem Team immer noch unklar, wie die Plattform aufgebaut ist, welche Anforderungen sie erfüllt und welche konkrete Rolle sie spielen soll.“
    Im spaeteren Verlauf wird die Idee der „Aufbohrung“ der schon am 11.6. genannten Wasserstoffplattform spannend werden, die offenbar vom GovTech-Campus als Universalloesung vorgeschlagen wurde: „Und dann gibt es noch einen Pitch aus dem Govtech Campus, der über eine KI-gestützte Plattform hinausgeht […] Wie aus Kreisen des Govtech Campus zu hören ist, soll die Plattform, die seit vergangenem Jahr entwickelt und in der zweiten Jahreshälfte in Betrieb gehen wird, unter anderem eine Entwicklungs- und Laufzeitumgebung mit Multi-Cloud-Infrastruktur, Basisdienste, Querschnittsdienste wie Lowcode und Dokumentenmanagement sowie einen Marktplatz für spezialisierte Fachanwendungen umfassen. Ob und wie die Idee Eingang in die Stack-Pläne finden wird, ist aber noch offen.“
  • 2025-07-07: Digitalminister Wildbeger im Interview mit SZ Dossier Digitalwende (Paywall-Vertical). Frage: „Werden die US-Hyperscaler Teil des Deutschland-Stacks?“ Antwort: „Ja, sie werden möglicherweise Teil der Lösung sein. Es muss aber auch unser Ziel sein, die europäischen Anbieter stärker zu berücksichtigen als bisher.“
  • 2025-07-07: Die Agora Digitalwende meldet sich im Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical) mit einem Meinungsbeitrag zu Wort: „Der Deutschland-Stack ist zur Projektionsfläche geworden: Unterschiedlichste Akteur:innen deuten den Stack aus ihrer jeweiligen Perspektive und ordnen ihre Projekte kurzerhand dem Stack zu. Doch so verwässern sie den eigentlichen Kern, schreibt Thilak Mahendran von der Agora Digitale Transformation. Das Digitalministerium sollte eine präzise Definition vorlegen, alle zentralen Akteure an einen produktiven Tisch bringen und den Stack interföderal verankern.“
  • 2025-07-07: Publikation „Government-as-a-Platform als Leitbild des Deutschland-Stacks“ (Archivlink) von Thilak Mahendran, agora Digitalwende: „Zentraler Baustein dieses Ansatzes ist der Deutschland-Stack – also ein strategisch gefasster Plattformkern aus Basisdiensten für Authentifizierung, Datenübertragung und Transaktionen. Doch: Der Stack ersetzt keine Architektur. Er ist Teil der »Deutschland-Architektur«, die aktuell im Rahmen der föderalen Digitalstrategie entsteht. Wer den Stack isoliert vorantreibt oder politisch überdehnt, riskiert eine technikgetriebene Fragmentierung – statt koordinierter Konsolidierung.“
  • 2025-07-15: SZ Dossier Digitalwende mit einem „Tiefgang“-Beitrag zu Sachsen-Anhalt. Zitat: „»Uns Ländern liegen keine Informationen zum Deutschland-Stack vor.« (Bernd Schlömer, Sachsen-Anhalts Beauftragter der Landesregierung für die Informationstechnik)“
  • 2025-07-17: „Was wäre, wenn wir den Deutschland-Stack vor­an­trei­ben?“, Po­si­ti­ons­pa­pier von Dirk Meyer-Claassen und Thilak Mahendran, im „re:form-Newsletter“ verschickt, offenbar nicht ausserhalb des Newsletters nachlesbar.
  • 2025-07-17(?, laut PDF-Metadaten): Positionspapier „Zentraler Marktplatz für cloudbasierte IT im öffentlichen Sektor“ des BITKOM (PDF, Archivlink, PDF-Archivlink). Hier wird interessanterweise nicht geraetselt a la „was koennte der Schlandstack nur sein“ (denn der BITKOM hat den Begriff ja ueberhaupt erst eingefuehrt), sondern hier geht es sehr konkret und beinahe schon stumpf um ein „hallo, verwaltungsdigitalisierung bitte mit moeglichst niedrigen huerden fuer die verwaltung, der wirtschaft geld geben zu koennen“. Wettbewerb belebe Innovation, mit Cloud-Loesungen werde man „KI-faehig“, durch Cloud-Loesungen bekomme man einheitliche Standards. [citation needed], wuerde ich sagen.
  • 2025-08-04: „Die fünf Etappen des Deutschland-Stacks“ im Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical): „Der Deutschland-Stack ist eines der großen Prestigeprojekte des neu gegründeten Digitalministeriums (BMDS). Begleitet wird das Vorhaben aber von sehr vielen Fragezeichen – angefangen damit, was genau der Stack eigentlich werden soll, welche Projekte integriert werden und welche Ziele erreicht werden sollen. […] Zu der Idee des Govtech Campus, die Wasserstoffplattform zu einer »Deutschlandplattform« auszubauen, will sich das BMDS derweil nicht äußern. Kern des Vorhabens ist ein »Betriebssystem für die Verwaltung« für Bund, Länder und Kommunen aufzubauen (Tagesspiegel Background berichtete). Betreiben würde diese »eierlegende Wollmilchsau«, wie böse Zungen flüstern, natürlich der Govtech Campus – der sich so langfristig eine zentrale Position im Wimmelbild der Verwaltungsdigitalisierung sichern würde.“ Spannend hier die Erwaehnung, dass Schlandstack und foederale IT-Architektur parallel arbeiten: „Wie die genaue Zusammenarbeit zwischen Team Stack und Team Architektur aussehen wird, soll »noch ausdefiniert« werden, wie das BMDS mitteilt.“
  • 2025-08-07: „Der geplante Deutschland-Stack soll eine souveräne Cloudinfrastruktur bekommen. Das teilte das Bundesdigitalministerium (BMDS) auf Anfrage von Tagesspiegel Background mit.“ (Tagesspiegel Background Digitalisierung & KI, Paywall-Vertical). „Auf der Infrastruktur soll unter anderem bis Ende des Jahres die KI-Plattform Kipitz laufen, eine der fünf Missionen des Deutschland-Stacks […] Der Stack soll eine »nationale, souveräne Technologieplattform« werden, die aus einer einheitlichen IT-Infrastruktur mit Basiskomponenten wie Cloud- und IT-Diensten, Fachplattformen sowie klar definierten Schnittstellen besteht.“
  • 2025-08-19: Bericht im SZ Dossier Digitalwende (Paywall-Vertical) ueber Kritik des des Global Government Technology Centre (Archivlink scheint nicht herzustellen zu sein): „Im Fokus der Kritik steht die Euro-Stack-Initiative […] »Wir wollen über Sachargumente statt Begriffe diskutieren«, sagte Kilian. Die Diskussion um einen Euro-Stack, also ein technologisches Schichtenmodell für Europa, laufe ins Leere.“.
  • 2025-08-?? (20?): „Impulse für einen offenen, interoperablen und europäisch anschlussfähigen Deutschland-Stack“ aus Schleswig-Holstein (Archivlink)
  • 2025-08-22: Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical) stellt das GovStack-Projekt dem Schlandstack gegenueber. „Wie viele Stacks braucht ein Land? […] Das Govstack-Projekt legt also einen anderen Fokus als der Deutschland-Stack: In dem BMDS-Vorhaben geht es zwar um Basiskomponenten und technische Standards, aber auch um fertige Lösungen wie die »H2KI«-Plattform, und den Aufbau einer souveränen Cloudinfrastruktur für den D-Stack. Die muss aber zunächst ausgeschrieben werden, bis wann und mit welchen Anforderungen will das BMDS nicht verraten. Damit ist der Deutschland-Stack weiter gefasst. […] Spannend wird die Frage, inwiefern die Govstack-Spezifikationen mit der geplanten Deutschland-Architektur und vor allem den bestehenden Basiskomponenten wie der Bund-ID zusammenpassen. Auf Rückfrage, ob die Erkenntnisse aus dem Govstack-Projekt in den Deutschland-Stack einfließen sollen, zeigt sich das BMDS zurückhaltend […]“
  • 2025-09-05: Markus Richter berichtet im SZ Dossier Digitalwende (Paywall-Vertical), er sei als IT-Beauftragter der Bundesregierung „gescheitert“. „Der Deutschland-Stack soll offen sein und auch von außerhalb der Kernverwaltung genutzt werden – etwa von den Sozialversicherern, aber auch von der Wirtschaft, sagte Richter.“
  • 2025-09-05: Markus Richter im Interview mit Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical): „»Ich halte mehr von einem kleinen Zielbild«, sagte Richter auf einer Bitkom-Veranstaltung am Donnerstag. Zentral dafür sei der Aufbau des Deutschland-Stack als nationale, souveräne Technologieplattform, bei der Ende-zu-Ende-Digitalisierung voranzukommen sowie Silos aufzubrechen. Für den Deutschland-Stack setzt er große Hoffnungen in die Wasserstoffplattform »H2KI«, bei der Künstliche Intelligenz (KI) bei Genehmigungsprozessen unterstützen soll. Der Zeitplan sehe Ergebnisse bis Ende des Jahres vor.“
  • 2025-09-15: Erster Commit im Repository „D-Stack Home“ auf OpenCoDE durch Heiko Hartenstein (Archivlink).
Illustrierende Darstellung aus diesem Commit 😉 (Archivlink)
  • 2025-09-19: „BMDS-Abteilungsleiter vor dem Aus. Eines der Prestigeprojekte des neuen Digitalministers wackelt: Nach Informationen von [Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical)] wird es beim Deutschland-Stack zu deutlichen Verzögerungen bei dem H2KI-Projekt kommen. […] Die Plattform sollte ursprünglich bis Mitte Dezember zur Verfügung stehen, nach Informationen von Tagesspiegel Background wird dieser Zeitplan aber nicht zu halten sein.“
  • 2025-09-22: „Deutschlandstack: Abteilungsleiter wurde abgesetzt“ im SZ Dossier Digitalwende (Paywall-Vertical): „Bereits seit Wochen gibt es das Gerücht, dass von Simson abgesetzt wird. Kürzlich war er nach Informationen von SZ Dossier bereits während einer wichtigen Klausur des neuen Ressorts nicht mehr dabei. Das Ressort dementierte Anfragen zum Thema bisher.“
  • 2025-09-24: Mit „Verzögerungen beim Deutschland-Stack“ berichtet Tagesspiegel Background Digitalisierung & KI (Vertical-Paywall) ueber die Modernisierungsoffensive des BMDS. „Richtungsfragen beantwortet auch die Modernisierungsagenda nicht, sie werden eher noch zahlreicher. […] Offene Fragen liefern auch die Ausführungen zur Registermodernisierung: In dem Entwurf heißt es, das Nationale Once Only Technical System (Noots), über das die Register Daten austauschen sollen, solle auf dem Deutschland-Stack implementiert werden. […] Wie Noots, das vom Bundesverwaltungsamt entwickelt wird, in die noch unbekannte technische Infrastruktur des Stacks integriert werden soll, ist unklar.“
  • 2025-09-24: Der Branchenverband eco legt Leitlinien fuer einen „Deutschland-Stack“ vor (Archivlink)
  • 2025-09-25: Das BMDS sei federfuehrend bei Open Data der Bundesregierung, titelt SZ Dossier Digitalwende (Paywall-Vertical) und zitiert Peter Parycek: „»Entscheidend ist, deutschlandweit einheitliche Standards und Austauschformate über den Deutschland-Stack zu etablieren«, sagte Parycek, der unter Angela Merkel im Digitalbeirat der Bundesregierung saß. Das BMDS müsse übergreifend steuern, damit Bund, Länder und Kommunen ihre Daten interoperabel und nutzbar bereitstellen. Er plädierte für ein bundesweites Netzwerk von Daten- und KI-Reallaboren, deren Ergebnisse in die Weiterentwicklung von Recht und Standards einfließen.“
  • 2025-10-01: Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical):„Digitalministerium startet Konsultation für D-Stack-Standards“. Nach einem Gespraech mit Markus Richter heisst es: „Denn einerseits solle der Deutschland-Stack Komponenten für die Wirtschaft zur Verfügung stellen, zum Beispiel eine Wallet. Andererseits solle aber auch die Wirtschaft in die Lage versetzt werden, dem Staat IT-Leistungen anzubieten.“
  • 2025-10-02: Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical): „Neue Leitung für die Abteilung Deutschland-Stack“: „Der frühe Wechsel an der Spitze der Abteilung Deutschland-Stack war offenbar nötig geworden, weil das Projekt bislang nicht von der Stelle kommt. Personen, die mit der Arbeit der Abteilung vertraut sind, sprechen von »Chaos«, fehlendem strategischen Handeln und Unklarheiten über den Kern der Mission.“
  • 2025-10-02: Der Normenkontrollrat reisst in seinem Jahresbericht den „Deutschland-Stack“ an (Archivlink): „Dabei kann die Bundesregierung auf die Vorarbeiten des NKR zur Vereinfachung und Automatisierung von Sozialleistungen […] als auch auf die NKR-Vorschläge zur Bündelung im Föderalstaat zurückgreifen […]. Wenn die Bundesregierung es ernst meint mit dem Once-Only-Prinzip, dann legt sie einen besonderen Fokus darauf, dass Nachweise und Informationen in Verwaltungsverfahren automatisiert ausgetauscht werden können.“
  • 2025-10-08: SZ Dossier Digitalwende (Paywall Vertical): „Dem BMDS fehlt die klare Vision beim Deutschland-Stack. Immer noch ist unklar, was das Vorhaben konkret darstellen soll und in welche Richtung es geht. […] Auch Dienstleister sind mittlerweile verunsichert. […] Das Ministerium bittet zwar um Beteiligung, liefert aber keine konkreten Konzepte oder Ideen, die Nutzerinnen und Nutzer kommentieren könnten.“
  • 2025-10-09: Das BMDS launcht eine Seite zum Schlandstack und ruft zur Konsultation auf OpencoDE auf (Archivlink)
  • 2025-10-16: Zitat St Hoelscher: „»Ich habe heute Morgen mit einer Kollegin aus der bayerischen Staatskanzlei telefoniert, die mir sagte: Mich hat diese Woche Montag um 6:30 Uhr Herr Söder angerufen und gefragt, was verdammt ist denn der Deutschland-Stack«, erzählte Luise Hölscher (CDU), Staatssekretärin im Digitalministerium (BMDS), gestern bei einer Veranstaltung im Bundesinnenministerium.“ im SZ Dossier Digitalwende (Paywall-Vertical). Weiter: „Mit der Anekdote wolle sie Söder übrigens keinesfalls unterstellen, den Deutschland-Stack nicht verstanden zu haben, sagte Hölscher, es sei ihm darum gegangen, den Stack in einem Satz erklären zu können. Was bisher niemand wirklich kann – und damit ein Teil des Problems des Megavorhabens offensichtlich wird.“
  • 2025-10-21: Tagesspiegel Background Digitalisierung & KI (Paywall-Vertical) schreibt: „Der Deutschland-Stack soll das Fundament für die moderne Verwaltung werden – doch auch Monate nach dem Start des Projekts bleibt unklar, was der Stack eigentlich ist. Eine neue Info-Website und ein Konsultationsprozess sollen Orientierung bringen, doch viele Fragen bleiben offen. […] Eine Liste mit Schlagworten, zusammengeschusterte Grafiken, ein neues Wimmelbild, aber kaum Substanz, melden Expert:innen an Tagesspiegel Background zurück. […] Damit zeigt sich die zentrale Schwäche des D-Stack-Projekts. Am Anfang konnte die Idee als Projektionsfläche viele begeistern, gerade weil sie so vage war. […] Doch mit der Zeit wuchs die Ungeduld. Denn die große Vision blieb abstrakt: Was genau sollte der Stack eigentlich sein – abgesehen von den fünf Missionen, die das BMDS definiert hat?“
  • 2025-10-27: Interview mit Cisco-Deutschlandchef Uwe Peter zum Deutschland-Stack: „Wir gehen davon aus, dass wir eine Rolle spielen werden“ (SZ Dossier Digitalwende, Paywall-Vertical)
  • 2025-11-10: KI-Plattform für 250 Millionen Euro geplant (Tagesspiegel Background Digitalisierung & KI, Paywall-Vertical). „Auf der Plattform soll die im Rahmen des Deutschland-Stack geplante KI-Anwendung zur Beschleunigung von Planungs- und Genehmigungsverfahren laufen. Auch die bisherige KI-Plattform des ITZ Bund (Kipitz) soll dort eine neue Heimat finden.“
  • 2025-11-11: Stellungnahme der OSBA zum Deutschland-Stack (Archivlink): „Der Deutschland-Stack ist eines der wichtigsten Digitalvorhaben der Bundesregierung zur Stärkung der digitalen Souveränität und der IT-Wirtschaft. Die Open Source Business Alliance (OSBA) unterstützt ausdrücklich die Ziele, die mit dem Deutschland-Stack erreicht werden sollen, fordert aber eine verbindliche Umsetzung der formulierten Kriterien sowie eine klare Ausrichtung auf Open Source Software, offene Standards und offene Schnittstellen. Denn nur mit Open Source können die Ziele des Deutschland-Stacks effektiv und nachhaltig erreicht werden.“
  • 2025-11-28(?): Positionspapier des BITKOM zum Deutschland-Stack (Archivlink, PDF, PDF-Archivlink): „Der Deutschland-Stack stellt einen wichtigen Schritt dar, um die Verwaltungsdigitalisierung in Deutschland zu harmonisieren, zu beschleunigen und technisch souverän auszurichten. In der derzeitigen Ausgestaltung bestehen jedoch noch Unschärfen: […]”

Spannend finde ich die zeitliche Abfolge zwischen den oeffentlichen Diskussionen um einen „Eurostack“ (der sich augenscheinlich breit auf Voraussetzungen fuer IT-Infrastrukturen fuer eine groessere Allgemeinheit zu beziehen scheint) und einen „Deutschland-Stack“ (der zunaechst sehr herumwabert, dann aber irgendwas als Voraussetzung fuer staatliche IT-Infrastrukturen verkauft wird, obgleich parallel eine foederale IT-Architekturplanung besteht).

In der Folge wirkt es so, als werde aus dem Umfeld des GovTech-Campus die „H2-Plattform“ zu einer „die-kann-alles-Plattform“ aufgebaut werden, die durch „KI“ ueber alle bekannten und bestehenden Probleme hinwegspringen kann, an der die Registermodernisierung knabbert. Als diese Plattform das hoch gesteckte Ziel eines Starts zum Ende des Jahres 2025 nicht einloesen kann, kommt es zu Personalrochaden.

Noch im Oktober wird bemaengelt, dass konkrete Ziele und eine Einbettung in die bestehenden Architekturziele fehlen. Mit Beginn der Konsultation folgen dann aber im November Stellungnahmen, die die Eigenaussagen zu den postulierten Zielen des „Stacks“ fuer bare Muenze nehmen zu scheinen und ihn zu „einem der wichtigsten Digitalvorhaben“ oder zumindest einen „wichtigen Schritt“ machen.

Was ich aber auch frappierend fand: Es fiel mir immer wieder schwer bis sehr schwer, fuer die Insiderinformationen aus den Paywall-Verticals oeffentlich zugaengliche Quellen zu finden. Das spricht natuerlich fuer den zu bezahlenden Wert dieser Newsletter. Es heisst aber auch, dass es ehrenamtlichen Wikipedia-AutorInnen sehr schwer fallen wuerde, eine umfassende Darstellung unter Einbezug all dieser Zitate abzubilden, falls man jemals eine Geschichte des Schlandstacks in der Wikipedia abbilden wollte.

(2025-12-20: Ergaenzungen SCS-Position Juni, BITKOM-Papier aus dem Juli, erster Commit der Website im September, nach Hinweis von Johannes Schnatterer)

Meshtastic-Node basierend auf einem Faketec-Aufbau mit Display

Building a cheap solar Meshtastic node

Schreibe eine Antwort

Updated March 22nd 2026: The first solar node has been running uninterrupted for over five months now.

At temporaerhaus, we have been playing with LoRa and LoRaWAN since 2016 – that is low-power, wide-area radio communications for sensors, both as infrastructure like TTN as well as the peer-to-peer Meshtastic system. Lately, a few of us have tinkered around finding matching spots for more TTN gateways, but also for Meshtastic nodes that increase the coverage of the system. Looking into Meshtastic started out as more of a side project, but since the nodes do not necessarily need Internet and constant power hookup, building these nodes went over more quickly than getting new TTN gateways up and running.

Additionally, I found that building a grid-independent Meshtastic node can be done even more cheaply than the usual instructions floating around at (mostly) YouTube – while those end up upward of 70 EUR per node with RAK-based transceivers, I got away with an even cheaper solution using a Faketec PCB build.

I was able to build my nodes for around 30 EUR per device – by cheating a bit, because I had quite a lot of the parts already lying around and we were able to source dirt cheap surplus antennas. Realistically, you can build one such node at about 30–60 EUR, with antenna size and quality being mostly responsible for the 30 EUR leeway.

A Faketec V3 PCB as ordered from JLPCB. -stk, FakeTec board back P1089951, CC BY-SA 4.0

The Faketecs are a community-developed PCB base plate in the form factor of the widely-used Heltec LoRa32 boards. The Heltecs can be sourced from Aliexpress etc. in the 15–25 EUR range per device, depending on availability and special offers. They come with a display and are… okay for first steps with the Meshtastic (or Meshcore) ecosystem. They come with WiFi and can be accessed through your local network instead of through a Bluetooth or serial connection, but due to them being based on a ESP32, they are rather power-hungry and the radio is just so-so, at least in the now-to-be-superseded V3 version.

The Faketecs in their most basic form just connect a nRF52840-based microcontroller board to a HT-RA62 LoRa radio board. If you want the most basic imaginable build, you just solder these three parts together and you’re done. If you want, you can add a voltage divider to measure the battery voltage, the two buttons also used on the Heltecs (for resetting/setting the device into DFU mode for flashing, and navigating through the menu options) and a cheap OLED display to arrive at pretty much the functionality of the Heltec boards, sans WiFi connectivity.

The boards have been expanded by community members to also include MOSFETs to drive an optional GPS receiver, buzzers, vibrating motors etc, and there is also a version around that even includes a MPTT charger for solar recharging. I stuck to the “basic” version – and I think this is still enough to build a solar node.

What I used

It’s not pretty and it does not use fancy 3d printed mounting options, but it works. -stk, 2025-10 Meshtastic Node temporaerhaus P1090100, CC BY-SA 4.0

To build one node (with options for many more to come) I used the following components:

  • 30 (yes) PCBs of the FakeTec v3 version ordered through JLPCB, about 4 EUR (about 15¢ each)
  • 1 Nice!Nano-clone, about 3 EUR from AliExpress
  • 5 HT-RA62, about 23 EUR from AliExpress (4,60 EUR each)
  • 5 IPEX to SMA pigtails, supposedly with RG178 cabling, about 3 EUR from AliExpress (60¢ each)
  • 2 SMD resistors for the voltage divider, spare parts lying around
  • SMA 868 MHz antenna for testing, spare part lying around

This means that a bare-bones Faketec node costs me about 8,35 EUR per pop – or, more realistically, 45–50 EUR for five nodes, with leftover PCBs to give away to others. If you include the push-buttons and have to buy resistors, this will add another ~5 EUR to the total bill.

In order to make this a solar node for outside, a couple of other parts were necessary:

  • 5 TP4056 charging boards with undervoltage protection, unter 2 EUR from AliExpress (about 40¢ each) – I had these lying around already; if you need to buy those anyway, you might want to use “proper” solar chargers instead it’s often still okay to use them instead of MPPT/solar chargers (see below)
  • 1 6V 6W solar panel, surplus from “smart” bike lock experiments by radforschung, can be sourced new from AliExpress for about 12 EUR
  • 1 2×18650 (parallel) battery holder, about 1,30 EUR from AlIExpress
  • 2 spare 18650 batteries from leftover battery packs that had been lying around
  • Set of waterproof cable glands, ca 8 EUR, AliExpress
  • 1 waterproof junction box, f-tronic NFK08, 2,50–6 EUR
  • spare SMA to N-type adapter with a really beefy coax cable that barely fit through a PG11 cable gland that was part of a collection of leftover Helium mining equipment sourced dirt-cheap through ebay
  • Fiberglass antenna with N-type connector from the same source
The finished setup mounted on top of a roof. -stk, 2025-10 Meshtastic Node temporaerhaus P1090106, CC BY-SA 4.0

I have tried a couple of different junction boxes for the setup so far. The NFK08 can be bought at the local hardware store (Hornbach) in Germany off the shelf, albeit for about 6 EUR per piece. When shopping around or being able to source them through somebody bulk ordering material for electrical installations, they can be had for as little as 2,50 EUR. This box leaves just enough space for a two-cell 18650 battery holder, the Faketec node, the charging board and the necessary cabling. They feature membranes for the openings through which the solar connector can be poked through at the bottom. For real water-proof connections, the membranes can be cut out and M20 cable glands can be screwed into the existing threads.

Another box I tried is the Wiska COMBI 407 which sold for 2,50 per pop for ages – their price shot up recently for whatever reason. The Wiska box has more space and is able to fit a three-cell 18650 holder.

The solar cells were just laying around, but they can be ordered at Ali for about 12 EUR a piece. Due to their intended use for smart bike locks, they came with Julet M8 connectors, which fit my idea quite nicely – this way, I ended up with a water-proof connection outside the junction box. The panels are probably quite over-dimensioned for this type of task. I chose to under-engineer the charging circuit part and rather have a really beefy solar panel instead.

Putting the antenna in front of the humble junction box. -stk, 2025-10 Meshtastic Node temporaerhaus P1090099, CC BY-SA 4.0

There are two ways to connect an antenna to such a box while still leaving everything rain-proof: Connecting the antenna to the top while ensuring everything is waterproof, or leading the cable out at the bottom in a loop. Some outdoor nodes I saw used N-type terminals at the top of the box onto which the antenna is directly screwed. The antennas I had available have a N-type socket at their bottom instead of a plug. Apparently, this is rather unusual, and I could not find any fitting N-type plug adapters that would have allowed mounting the antenna directly to the junction box. Fortunately, we had some 10cm adapter leads from SMA to N-type with beefy cabling lying around that just fit through a PG13.5 cable gland. This allowed for a (hopefully) water-proof connection through one of the M20 mounting holes on top of the box.
This makes the antenna the primary mounting point, with the junction box more or less dangling below it – it was fixed to the mounting pole with zip ties and that was it. Due to the lever the massive antenna has, this is most likely the smarter option.

Charger considerations

Not great, not terrible: The TP4056 with added battery protection. -stk, TP4056 board P1089956, CC BY-SA 4.0

Using a TP4056 board for solar charging is… controversial, and others might scold you for that idea and recommend you using “real” MPTT circuits like a CN3791 module and using its power path capabilities. I had the TP4056s already lying around with no other use for them, and I liked that they have the DW01 battery undervoltage IC onboard. The surplus 18650 cells I had left over came without any battery protection, and I’d rather have the charging boards functionality keeping the batteries from being sucked dry than optimizing for perfect charging conditions.

For now, even though far from being optimal solar charging boards, the TP4056 boards appear to be doing their job. The first prototype had been lying with its solar panel behind a window with almost no direct line of sight to the sun at any time, and 42 days in with getting less and less light, the two 18650 cells are still not completely drained. The installation on the roof with direct sun exposure continues to be practically completely charged all the time, even now at the end of November.

I will eventually go and replace the TP4056 boards with a “proper” solar charging setup, after adding battery protection features to the cells I used. For now, the setup works fine though – the Faketecs draw amazingly little power, even without any energy management optimization so far. I had initially planned for 4×18650 cells powering the node, but experimenting with the first prototype made it clear that even two cells might suffice.

Update 2026-03-22: I had ordered MPPT charger boards a while back and considered exchanging the TP4056 with them. However, I decided against it for now: The node has been running continuously for over 150 days, and from what I can tell, the voltage has never dropped below 3.9V even during the winter months. The solar panel seems massively oversized for the power requirements of the node, so the advantages of the TP4056’s battery protection features outweigh any (unneccessary) efficiency gain. I have started to test another node with a much smaller solar panel and a TP4056 in order to test whether the charging circuit is sufficient even in this setup.

Another update, 2026-04-20: This writeup (in German) suggests that MPPT chargers might often perform worse than simple linear chargers like the TP4056 under two conditions: 1) the voltage difference between solar/input voltage and charging/output voltage is low, 2) the absolute wattage of the solar panel is low. They argue that the efficiency gains of MPPT come at the cost of more power consumption for the power point tracking – and if both the voltage leeway to chase the maximum power point and the input power are below a certain threshold, the total calculation is in favor of simple linear chargers.

Things to watch out for when building your own

  • Make sure the NiceNano boards already have a bootloader installed before soldering them to the PCB. The cheaper versions on Ali sometimes come without a bootloader installed, and while you can flash the bootloader before soldering, if you find out after soldering the controller to the PCB, you’re pretty much out of luck.
  • As with all RF boards, do not power up the Faketec without an antenna attached to the RF module
  • bring the 18650 cells to the same charge before connecting them in parallel
  • I have painstakingly avoided calling this solar node a “repeater” or anything like that. While, functionally, putting this thing up on a high rooftop makes it kind of an “extender” of a Meshtastic network, this is essentially not different from any other node taking part in the system. The role for the node should therefore be set to CLIENT and not ROUTER or REPEATER, unless it is positioned really, really high up. Think not “on the top of a tall building”, but rather “the 120m tall silo that sits on top of one of the tallest hills overlooking pretty much everything around here”.
  • Do adapt the output power of your node to the antenna gain to stay within legally mandated limits. In Europe, the limit is at 27 dBm EIRP.

So, how much is this node, in total?

It all depends on how many nodes you will be building and what you’re already having lying around unused. Assuming you gang up with friends and build several nodes, a realistic guesstimate runs something like this:

  • 1 FakeTec node: About 8,50 EUR
  • 1 Junction box: 2,50–4 EUR
  • 1 18650 Battery holder: 1,20–2,50 EUR (depending on number of cells)
  • 1 TP4056 board with DW01: 40¢, or a CN3791 board: ~2,50 EUR
  • 1 Adapter cable from SMA to your antenna connector of choice: 2–8 EUR, depending on cable type and length
  • 1 Solar cell with connector: ~12 EUR (update 2026-03-26: Cheaper options might be tenable)
  • 2–n 18650 cells: Source locally, prices vary widely
  • 1 868 MHz antenna of your choice, with mounting option: Prices and quality also vary extremely widely here. Some supposed 868 MHz antennas are tuned to something between 850 and 920 MHz, with the sweet spots far away fom 868 MHz. Your mileage will vary – antenna know-how and access to a VNA pays off a lot.

Total: 27–37 EUR, plus battery, plus antenna

Realistically, depending on where and how you get your batteries and antenna, you might end up at about 30–60 EUR in total. That is quite a bandwidth – it depends mostly on whether you’re able to source your antennas and batteries cheaply and whether you have some of the stuff already lying around uselessly. Comparing this to the usual current howtos, the RAK WisBlock kits they use alone will set you back about 35–45 EUR – and that’s without any case, battery or solar panel. Don’t misunderstand me – if you want something that just works, go for e.g. the Seed Solar Node and be done with it. This build is interesting if you already have some of the parts and/or can source matching antennas with high gain.

What is it with the 18650s?

You can also use some “pillow style” LiIon batteries. I’d personally rather not buy new batteries for something like this, but rather look into pilfering worn-out laptop batteries and the like. That is just a personal choice.

Probleme mit DCAT-AP.de, heute: Lizenzen

Schreibe eine Antwort

Manchmal trifft man ja auf Dinge, bei denen man gar nicht glauben kann, dass sie einem nicht schon viel frueher aufgefallen sind. Und vor allem aber, dass das nicht schon laengst jemand anders aufgezeigt hat.

Aktuelles Beispiel sind die Lizenzdefinitionen in DCAT-AP.de, der nationalen Implementierung von DCAT-AP als Beschreibungsstandard fuer Open Data. Ich war schon im Fruehjahr 22 darueber gestolpert, dass DCAT-AP.de sprechende URIs fuer die Lieferanten von Daten definiert – was auch heisst, dass sich diese URIs immer wieder mal aendern. Das BMI hiess dort 2018 beispielsweise bundesministeriumDesInnern, 2020 bundesministeriumDesInnernFuerBauUndHeimat, 2022 bundesministeriumDesInnernUndHeimat – und im August 2025 in der aktuellsten Version und nach der Umbenennung des Ministeriums ist es dort immer noch das bundesministeriumDesInnernUndHeimat. Ein reines bundesministeriumDesInnern gibt es dort immer noch nicht als Datenlieferant – ebensowenig wie das BMDS oder das BMFTR.

Einschub: Auch Wikidata macht diese Abbildung nicht ganz so perfekt. Das zugehoerige Datenobjekt ist dort immer dem Wikipedia-Artikel zum derzeit aktuellen BMI zugeordnet und schleppt quasi die Versionshistorie mit. In der Gemeinsamen Normdatenbank ist jede „Instanz“ des BMI mit einem eigenen Identifier bezeichnet; im Identifier fuer das vormalige Bundesministerium des Innern und fuer Heimat sind sowohl das „neue“ BMI (fuer den „Innern“-Teil“) als auch das „neue“ BMLEH (fuer den „Heimat“-Teil) als Nachfolgeinstanzen des „alten“ BMI angegeben. So waere das meines Erachtens auch fuer DCAT-AP.de richtig.

Als ich vergangene Woche bei einem Workshop die Liste der Lizenzen auf DCAT-AP.de vermutlich erstmals so richtig angesehen habe, war ich aber wirklich ueberrascht. Denn neben Lizenzen, die vermutlich aus historischen Gruenden mitgeschleift werden, finden sich dort ein paar Definitionen, die meines Erachtens nie richtig sein konnten und dort auch nicht hingehoeren – aber in der Praxis in Gebrauch zu sein scheinen.

Historisches, oder: Die Datenlizenz Deutschland als DDR der Lizenzen.

Bei Lizenzen, die historisch mal irgendwo in Gebrauch waren, kann man das nachsehen. Schliesslich soll solch eine Liste ja alle Faelle abdecken, die tatsaechlich real im Umlauf sein koennten. Die Datenlizenz Deutschland 1.0 ist seit dem Juli 2014 formell ueberholt (die Datenlizenz Deutschland 2.0 prinzipiell auch schon immer, aber darum geht es hier nicht), aber es koennen immer noch Datensaetze im Umlauf sein, die mit der DL-DE 1.0 lizenziert wurden.
Das ist quasi analog zu einem Eintrag „Geburtsland: Deutsche Demokratische Republik“ in den Urkunden von Menschen: Das gibt’s in der Realitaet, das ist auch formell korrekt so, und es ist auch sinnvoll, das maschinenlesbar abbildbar zu machen, solange das die Realitaet beschreibt (selbst wenn das nicht mehr lebende Personen betrifft). Das heisst aber natuerlich nicht, dass es sinnvoll oder geboten waere, solch einen Eintrag bei einer jetzt gerade neu geborenen Person vorzunehmen. Weil das waere ja Quatsch. Bei bereits geborenen Menschen, fuer die das zutrifft: Prima. Neuvergabe: Nein.

Analog gilt das auch fuer Lizenzen, die mal fuer Datensaetze vergeben worden sind, deren Neuvergabe aber im Konflikt mit der EU-Open-Data-Richtlinie stuende. Die NC-Variante der CC-Lizenzen („nur zu nichtkommerziellen Zwecken“) geht ohnehin meist am Ziel vorbei (PDF), fuer Open Data ist sie jedenfalls gemaess der Open-Data-Richtlinie nicht passend und sollte daher auch nicht fuer neu hinzukommende Datensaetze ueberhaupt zur Auswahl stehen.

Unsinniges, oder: Lizenzangaben, die so nie sein duerften

Wirklich am Kopf kratzen musste ich mich aber bei den Definitionen eigentlich „okayer“ Lizenzen gemaess der DCAT-AP.de-Liste. Die CC-BY-Lizenz gibt es beispielsweise in mehreren „Geschmacksrichtungen“: Der seit November 2013(!) ueberholten, aber vielfach noch verwendeten Version 3.0 (als cc-by-de/3.0), der zu bevorzugenden, aktuellen Variante CC BY 4.0 (als cc-by/4.0) und einer… ja, was eigentlich? Einer „allgemeinen“ Variante moechte man meinen, die als cc-by bezeichnet wird – die aber nicht klarstellt, welche Version eigentlich gemeint ist. Und das koennte ein Problem sein.

Gleich mehrere Lizenzen verweisen naemlich im Feld Lizenztext nicht etwa auf den kanonischen URL der jeweils bezeichneten Lizenz, sondern jeweils auf eine Uebersichtsseite bei opendefinition.org. cc-by verweist auf https://opendefinition.org/licenses/cc-by/, und dort findet sich eine Auflistung aller fuenf Versionen dieser Lizenz. Welche Version gemeint ist? Man weiss es nicht.
Genauso ist es bei der CC-0 1.0: Die wird in DCAT-AP.de cc-zero genannt (ohne Version, also nicht etwa cc-zero/1.0) und verweist ebenfalls auf eine Beschreibungsseite bei opendefinition.org und nicht auf die Freigabeerklaerung/Lizenz selbst. Solange es nur diese eine Version gibt, ist das vermutlich nicht schlimm. Korrekt ist das aber trotzdem nicht, weil hinter dem Lizenztext-Eintrag findet sich schlicht nicht der Lizenztext.

Noch kaputter ist das bei der (ohnehin zu vermeidenden, siehe oben) vermeintlich „allgemeinen“ Fassung von cc-by-nc, die auf http://creativecommons.org/licenses/by-nc/ verweist: Dieser URL liefert laut Internet Archive seit etwa 2010 einen Fehler 404; zuvor fand sich dort mal ein directory listing der darunter zu findenden verschiedenen Versionen der Lizenz. Als kanonischer URL fuer eine „allgemeine“ Fassung war das aber wohl erstens nie gedacht und ist auch weder fuer Altbestaende noch fuer neue Datensaetze sinnvoll.

Was heisst das in der Praxis – fuer Verwendende?

Wann immer man irgendwo auf einen Datensatz mit cc-by oder cc-by-sa oder cc-by-nc in den Metadaten trifft, duerfte es sich um einen Datensatz mit „ungueltiger“ Lizenz handeln. Es ist nicht klar, welche Version genau gemeint ist. Sorry, Linie uebertreten, Versuch ungueltig. cc-by-nd verweist immerhin eindeutig auf die (seit nun fast 12 Jahren ueberholte) Lizenzversion 3.0, sinnvoll ist das aber ueberhaupt nicht.

Was heisst das in der Praxis – fuer Open-Data-Stellen?

Spannend ist jetzt die Frage, wie Datenbereitstellende oder Betreibende von Datenportale mit dieser Liste umgehen sollen. Ich habe letzte Woche erfahren, dass manchmal der Eindruck entsteht, dass man in einem Datenportal auch alle Lizenzen annehmen muesse, die in dieser Liste stehen. Schon durch das DDR-Beispiel sollte klar sein, dass das nicht sinnvoll ist.

Aus meiner Sicht ergeben sich daher folgende Handlungsempfehlungen:

  • Govdata.de, CCOD und weitere beratende Stellen muessen klarstellen: Die DCAT-AP.de-Lizenzliste ist keine „Positivliste“ aller auch jetzt noch zulaessigen Lizenzen fuer neue Datensaetze.
  • Ebenso: Explizite Positiv-Empfehlungen, was als Standard gesetzt werden soll. Das ist CC-0 1.0 und CC BY 4.0 (mit expliziter Versionierung). Letzteres mit der verpflichtenden Namensnennung idealerweise nur dann, wenn es sich bei dem zu lizenzierenden Gegenstand auch zweifelsfrei um urheberrechtlich geschuetzte Inhalte handelt, nicht nur um Daten, die allenfalls dem Datenbankherstellerrecht unterliegen.

Fuer Stellen, die Datenportale betreiben und/oder Daten von anderen per Harvesting konsumieren:

  • Fuer manuelle Pflege, solange es das noch gibt: Analog zum Open-Data-Kompass des ehemaligen BMDV (Archivlink) sollen die Lizenzen CC-0 1.0 und CC BY 4.0 bevorzugt angezeigt werden; „Lizenzen“ mit unklarer Geltung wie z.B. die DL-DE sollen allenfalls mit Warnhinweis ueberhaupt anwaehlbar sein. Idealerweise mit Verweis auf zentral (s.o.) gepflegte Erklaerungen, warum diese Lizenzen ein Problem sein koennten.
  • Auch die „komischen“ Lizenzen koennen per Harvesting akzeptiert werden, sollten aber Ausloeser fuer eine Qualitaetssicherungs-Massnahme in Richtung der Quelle sein. D.h., wenn irgendwo etwas mit z.B. cc-by eingesammelt wird, sollte das einen automatischen Hinweis in Richtung dieser Stelle triggern: Das ist eventuell nicht das, was ihr machen solltet. Ziel muss sein, solche Schroedinger-Datensaetze in einen definierten Zustand zu heben.

Und wer auch immer die Liste in DCAT-AP.de pflegt:

  • in DCAT-AP.de muss „aufgeraeumt“ werden. Insbesondere die Legacy-Lizenzen, aber auch die Definitionen mit unklarer Definition muessen als deprecated markiert werden: Die dienen der Beschreibung, was mal vorgekommen ist, sollen aber nicht fuer neue Datensaetze verwendet werden.
  • und auch die CC-0 1.0 muss „richtig“ vergeben werden. Keine Ahnung, was das fuer einen Rattenschwanz nach sich zieht, aber der derzeitige Zustand ist… seltsam.