Schlagwort-Archive: OpenData

Anti Datenportal Ultras

Immer wieder begegne ich Diskussionen, dass man zum Bereitstellen offener Daten erst einmal ein „Datenportal“ brauche (wahlweise auch eine „Datendrehscheibe“ oder sonstwas; ich schlage fuer das neue Buzzword „Datenraum“ gleich mal vorsorglich hier den Begriff „Datenraumfahrtbahnhof“ vor).

Wasserturm, ehemalige Wiley Barracks in Neu-Ulm
Martavictor, Wasserturm, ehemalige Wiley Barracks in Neu-Ulm, CC BY-SA 4.0

Dieses Vorgehen stellt die Kausalitaet aber auf den Kopf. Das ist so, als wolle man irgendwo im Schrebergarten neben dem Acker eine Moeglichkeit zum Haende waschen und Pflanzen giessen haben, und anstatt mal einen Brunnen zu bohren, plant, konzipiert und baut man einen sehr komplizierten Wasserhochbehaelter. Sobald der dann fertig ist und die ersten Datens^wEimer voll Wasser haendisch reingeleert wurden, faellt dann aber auf, dass es immer noch keinen Brunnen gibt – oder gar eine Pumpe, mit der der Hochbehaelter automatisch gefuellt werden koennte.

Die umgekehrte Vorgehensweise ist die zielfuehrendere: Wenn ich einen Brunnen bohre und erst einmal eine einfache Handpumpe montiere – kann ich meine Haende waschen und die Tomaten giessen. Ziel erfuellt. Ich kann spaeter eine Solarpumpe, einen einfachen Pufferbehaelter oder ein Hauswasserwerk, eine Wasseraufbereitung, eine Klaerstufe, alles moegliche nachruesten, und vor allem auch Dinge durchautomatisieren. Aber die wesentliche Funktion, zu deren Zweck ich das alles gemacht habe, wurde von Anfang an erfuellt.

Und wenn ich mitgedacht habe, habe ich auch auf genormte Anschluesse und flexibel umsteckbare Schlauchsysteme gedacht, falls sich spaeter mal meine Ansprueche aendern.

Um die Metapher mit Leben zu fuellen, reicht ein Blick auf https://gtfs.mfdz.de. Die Seite sieht aus als sei sie auf Geocities gehostet, aber das macht nichts, denn sie ist momentan eine der besten Quellen, um in Deutschland an offene Fahrplandaten zu kommen. Die werden naemlich derzeit an ganz verschiedenen Stellen veroeffentlicht – teilweise ganz einfach auf einer Website aufgelistet, teilweise in einem eigens eingerichteten Datenportal, und teilweise immer noch nur fuer registrierte Nutzer:innen. Letzteres ist aus DSGVO-Sicht spannend, und der Sinn nicht ganz klar – denn als Open Data duerfen sie natuerlich auch gemirrort werden. Oder man baut eben einen URL-Shortener, der nichts anderes tut, als auf das aktuelle ZIP-File zu linken. Naja.

Allen Menschen mit Ambitionen fuer Datenportale kann man derweil nur sagen: Scheut euch nicht, eure Daten einfach in genau so einem Stil herauszugeben. Steckt lieber Energie in automatisierte Bereitstellung, oder passende Prozessketten, die so wie hier auch gleich Berichte ueber Probleme und Fehler automatisiert mit bereitstellen. Wenn Daten das neue Grundwasser sind, dann ist eure Aufgabe, die Daten moeglichst einfach und automatisiert sprudeln zu lassen – und sich dann an den Wasserturm zu machen.

Ein paar Gegenfragen zur Frage „wem gehoeren die Daten?“ (Kurze Antwort: Niemandem. Und das ist auch gut so.)

Vielleicht ist das nur ein subjektiver Eindruck, oder ich reagiere darauf mittlerweile staerker, aber mir begegnen gefuehlt immer haeufiger beilaeufige Bemerkungen oder Fragen dazu, „wem die Daten gehoeren“. Beispielsweise bei der Frage, wer die Veroeffentlichung irgendwelcher Messdaten als Open Data freigeben koenne, „weil die Daten ja XY gehoeren“. Oder aber auch als vermeintliches Argument fuer technologische Souveraenitaet: Die oeffentliche Hand soll Dienste selbstbestimmt anbieten anstatt sie dem freien Markt ueberlassen, „weil dann gehoeren die Daten der IoT-Sensorik am Ende der Stadt, anstatt privatwirtschaftlichen Akteuren“.

Es ist wichtig, dass wir alle solche Bemerkungen immer und konsequent hinterfragen, wenn wir ihnen begegnen. Gerade die zweite Form ist naemlich eigentlich eine fast schon witzige Verdrehung dessen, was passiert ist: Privatwirtschaftliche Akteure haben sehr lange versucht, ein in der Realitaet gar nicht existierendes Eigentumsrecht an Daten in unsere Alltagssprache zu verankern – und indem wir ein Gegenmodell zur Privatisierung von Daten fordern, verbreiten wir ungewollt das Maerchen vom Dateneigentum.

Denn es ist vollkommen egal, ob oeffentliche Hand, Privatperson oder Wirtschaft: Daten (und hier meine ich insbesondere automatisiert erfasste Messdaten, aber auch schiere Faktendaten) koennen niemandem „gehoeren“. Und das ist auch gut und richtig so. Ein „Eigentum“ an Daten wuerde bedeuten, dass ich mit meinem Thermometer die Aussentemperatur messen und dann Dritten verbieten koennte, diesen Temperaturwert an andere weiterzugeben, nachdem ich ihn verraten habe. Und das waere fatal. Genausowenig kann und darf irgendwer mir verbieten oder nur unter bestimmten Auflagen erlauben, weiterzuerzaehlen, dass 768 Stufen aufs Ulmer Münster führen – auch wenn ich das aus einem (insgesamt urheberrechtlich geschuetzten) Buch oder der Wikipedia weiss (siehe auch).

Tatsaechlich kann die Verwertung und Verbreitung von Daten durch Dritte nur unter ganz bestimmten Bedingungen eingeschraenkt werden – beispielsweise aufgrund datenschutzrechtlicher Bestimmungen, meist aber aufgrund des Urheberrechts. Und nachdem sich neben des Begriffs des Dateneigentums auch die Annahme eingeschlichen hat, dass man Lizenzen (also Bedingungen und Einschraenkungen, zu welchen Konditionen Daten verarbeitet oder weiterverbreitet werden duerfen) einfach so anwenden kann (hier ist beschrieben, warum dem nicht so ist), halte ich es fuer ueberfaellig, diese Annahmen durch gezielte Nachfragen bei jeder Gelegenheit einem Realitaetscheck zu unterziehen.

Beispielfragen, die mir bislang eingefallen sind (und die ich bislang nie in exakt diesem Script abgespult habe, weil ich kein sadistischer Quaeler bin):

  • Was meinen Sie mit „gehoeren“?
  • Auf welcher genauen Rechtsgrundlage soll hier die Nachnutzbarkeit durch Dritte eingeschraenkt werden koennen?
  • Ich meine, auf welcher Rechtsgrundlage soll hier die CC-BY-Lizenz verbindlich gemacht werden koennen? Warum soll ein Dritter hier zur verbindlichen Namensnennung verpflichtet werden koennen?
  • Sie sagen schon wieder „gehoert“ – es gibt doch gar kein Eigentumsrecht an Daten, sondern nur bestimmte Immaterialgueterrechte. Bauen Sie hier auf das Urheberrecht auf?
  • Nach welcher Argumentation handelt es sich denn um ein geschuetztes Werk? (vgl. Kapitel 2.6 dieses Abschlussberichts, inline PDF)
  • Aber Faktendaten sind doch gar keine individuelle schoepferische Leistung (PDF), weswegen sollte hier ein Schutz nach § 2 Abs. 2 UrhG vorliegen?
  • Aber das Datenbankurheberrecht nach § 4 UrhG schuetzt doch nur die Form und Anordnung, nicht die Daten selbst. Und ueberhaupt: Ist die Anordnung der Daten hier wirklich eine schoepferische Leistung?
  • Sind Sie sicher, dass fuer das Live-Ausspielen eines aktuellen Messwerts Datenbankherstellerrechte nach §§ 87a ff. UrhG anwendbar sind?
  • Selbst wenn es so ein Eigentum gaebe: Wie wuerden sie das durchsetzen wollen? (PDF)
  • Kennen Sie das Gutachten der Justizministerkonferenz (PDF), dass ein Dateneigentum ueberhaupt nicht sinnvoll waere und oekonomisch keinen Nutzen haette?

Mit solchen (freundlich verpackten) Fragen bekommen wir hoffentlich bald sowohl die Idee vom Dateneigentum wie auch die Annahme von der Anwendbarkeit von „Datenlizenzen“ als magische Zaubersprueche etwas geradegerueckt. Interessanterweise scheint solche Fragen vor allem auf C-Level-Entscheiderebenen sonst kaum jemand zu stellen.

Verantwortung internalisieren: Als Verwaltung Software verstehen

Weil ich gerade einen Vortrag über #opensource-Software höre: Die öffentliche Verwaltung mag es Verantwortung zu externalisieren, gerade bei IT-Themen. Diese Denkweise, also dass Verantwortung externalisieren am Ende überhaupt klappt, muss leider erst mal durchbrochen werden.

Unter diesem Tweet sammelten sich einige Antworten, die mir Anlass sein sollen, einmal unsortierte Gedanken der letzten Monate ein wenig zu ordnen. Die meisten Mitlesenden duerften wissen, dass seit ueber 5 Jahren bei Code for Germany (und vielerorts schon viel laenger, und natuerlich nicht nur in Deutschland) ehrenamtliche oertliche Gruppen der oeffentlichen Verwaltung zeigen, was Open Data bringt. Wie man Daten strukturiert. Worin die Vorteile des Ganzen liegen.

Man koennte also sagen: Dass Open Data nuetzlich ist, das daraus tolle Dinge entstehen, dass das ein anstrebenswerter Zielzustand ist und dass 100% Open Data eigentlich spaetestens seit 4 Jahren Status Quo sein sollte, darueber muss man eigentlich nicht mehr diskutieren.

Und dennoch tut sich die oeffentliche Hand offenkundig an sehr vielen Orten immer noch enorm schwer, dies alles in eine Praxis automatisiert bereitgestellter Offener Daten, passender Beschlussgrundlagen und weitsichtiger Beschaffungspolitik zu giessen. Es beschaemt mich, wenn 2020 immer noch Hackathons als neue Massnahme vorgeschlagen werden. Dazu dachte ich sei auch schon das meiste gesagt, aber ergaenzend sei nochmal auf die vielen vielen Beispiele von Jugend hackt verwiesen, die wirklich nun ueber Jahre und hervorragend zeigen, was sich mit Open Data und einer engagierten Zivilgesellschaft machen laesst. Die Frage ist jetzt doch vielmehr, was die naechsten Schritte sind, um die Ideen der Hackathons in der Verwaltung zu verfestigen.

Witzigerweise zeigte gerade ein eher schiefes Beispiel im weiteren Verlauf der Twitterdiskussion worum es eigentlich geht und wo es hakt:

Replying to @knigotnik @ingo_keck @didumdida Ich halte das für ein Quatsch-Argument. Der Staat baut auch nicht selber Autos, auch wenn er sie dringend für die Sicherheit braucht (Polizei, Feuerwehr, Bundeswehr, Rettungsdienst, …). Kein Beamter muss Vergaser bauen können.

Der Punkt ist natuerlich, dass Kraftfahrzeuge und Vergaser fertig zu kaufende Produkte sind, die selbst fuer den Einsatz im oeffentlichen Dienst passgenau von der Stange gekauft werden koennen. Fuer Spezialanfertigungen – sagen wir mal, Loeschgruppenfahrzeuge – gibt es jahrzehntelang entwickelte Prozesse, Schirrmeistereien und Fachmenschen, die tatsaechlich wissen, welche Ausruestung und Beladung auf das neue Einsatzfahrzeug kommen soll. Und es gibt in der Tat nicht wenige oeffentliche Einrichtungen (ja, ich spreche hier wieder mit der Feuerwehrbrille), die ihre Fahrzeuge selber warten und pflegen. Warum auch nicht.

Auf einer Wardley-Map fuer Datenfluesse, Prozesse und Entwicklungsketten innerhalb der oeffentlichen Verwaltung stuenden aber neben den vielen Bruechen im System jede Menge Komponenten, die entweder aktuell “Custom built” sind oder sich ueberhaupt erst noch in der “Genesis” befinden. Daten werden vielfach noch haendisch per Excel-Export aus Fachverfahren gekratzt und dann mehr oder weniger bereinigt in irgendein Datenportal geschaufelt.

Ueberhaupt: Datenportale. Oder nein, Datenplattformen. Meine Guete. Das ist das Gegenstueck zur Silver Bullet: Wenn man erstmal die Datenplattform hat, dann… ja was dann? Dann ist der Rauskratzprozess der Daten immer noch haendisch. Und was bringt es, wenn das neue Supersystem theoretisch Zeitreihen abbilden kann, wenn innerhalb der Verwaltung niemand da ist, um im Zweifelsfall mittels eines sehr kleinen Shellscripts eine Echtzeit-Datenquelle auch mit der passenden Senke in der Plattform™ zu verbinden? Oder wenn es – noch schlimmer – immer noch keine Ansaetze von Ratsbeschluessen und Grundsaetzen gibt, dass z.B. auf Grundlage von Vergaben entstehende geeignete Daten auch mittels passender Klauseln zu Open Data gemacht werden? Lucy Chambers nennt sowas Upside-Down-Projects: Es soll eine der oberen Schichten im Stack gebaut werden (vielleicht weil das irgendwo in einem Grant Proposal stand), also wird erstmal die Fassade vor dem Fundament gebaut. Oder die uebermaechtige Wasser-Echtzeit-Verbrauchsanzeige, waehrend das metaphorische Wasser noch haendisch im Eimer ins Haus getragen wird. Im schlimmsten Fall hat man nicht mal nen verdammten Eimer.

Und dann sind wir doch relativ schnell wieder bei der Frage, ob die oeffentliche Hand Code anfassen koennen soll. Meine Ueberzeugung: Ja, das sollte sie unbedingt.

Denn, und da sind wir bei einem Knackpunkt fuer mich: Diese Vermittlerrolle, diese Adapterfunktion – Daten aufbereiten, Dinge scrapen, Prozesse bauen – wird bislang viel zu viel vom Digitalen Ehrenamt in Deutschland aufgefangen. Also von all den Menschen, die jetzt immer wieder und immer noch auf Hackathons eingeladen werden, als haetten sie nicht mittlerweile genug damit zu tun, die Proofs-of-Concept aufrechtzuerhalten, was alles moeglich waere, wenn die oeffentliche Hand zumindest in Grundzuegen selber wuesste, wie Code, Datenstandards und IT-Architekturen aussehen.

Paradebeispiele gibt es genug: kleineanfragen.de als Ein-Personen-Projekt, um zu zeigen, wie man solche Dokumente richtig bereitstellt. Einfach nur ein Proof of Concept, seit September 2014(!) bereit zur schluesselfertigen Uebernahme durch die oeffentliche Hand – und nichts dergleichen ist passiert. Im Gegenteil verlassen sich zunehmend JournalistInnen und ParlamentarierInnen auf ein ehrenamtliches Projekt, dem nun seit ueber fuenf Jahren das „offizielle“ Produkt nicht annaehernd gleichziehen konnte (siehe, siehe, siehe). Oder die ganze Geschichte rund um OParl: Ein Datenstandard fuer Parlamentsinformationssysteme, der nur durch massiven persoenlichen Zeitaufwand Ehrenamtlicher entstehen konnte, und fuer den ich bis heute bei keinem Dienstleister eine schicke Auswertung als Ersatz fuer die meist grottigen Ratsinformationssystem-Oberflaechen buchen kann, selbst wenn ich als Kommune Geld darauf werfen wollen wuerde.

Also nein, Software ist kein Auto. (Manche Vergleiche sind aber absurd. Okay.) Aber wenn dieses Digitalisierungszeug endlich mal gelingen soll – und wenn wir die vielen Ehrenamtlichen, die jahrelang gezeigt haben, wo die Reise hingehen kann, endlich aus der nie gewollten Garantenposition herausloesen wollen – gehoert nach dem Pioneer/Settler/Town-Planner-Muster auch passende Kompetenz in der Verwaltung aufgebaut. Muessen zumindest manche VerwaltungsbeamtInnen auch irgendwann mal Cronjobs und Shellscripts einrichten koennen. Muessen dafuer schnell passende VMs fuer die Verwaltung klickbar sein. Muss statt Innovationstheater mit (natuerlich nicht transferierbaren) Leuchttuermen die marode IT-Basisinfrastruktur in einen brauchbaren Zustand versetzt und kontinuierlich weiter gewartet werden koennen. Nicht unbedingt, weil die oeffentliche Hand alles selber machen koennen sollte. Im Gegenteil, moeglichst viel sollte als Commodity klickbar sein. Dafuer muesste man aber wissen, was es alles gibt, und Technikfolgen abschaetzen koennen. Und dafuer hilft es ungemein, mal ellenbogentief in APIs gewuehlt zu haben.

Davon hoere ich auf den ganzen Schlipstraeger-Digitalisierungsgipfeln aber erstaunlicherweise immer noch erstaunlich wenig.

Fahrplandaten, Zwischenstand 2020

„Wissen nicht woher“: Apple greift VGN-Daten für Maps ab. #Nürnberg nordbayern.de/region/nuernbe… None

Seit September 2006 gibt es das GTFS-Format fuer Soll-Fahrplandaten des oeffentlichen Verkehrs, entstanden mehr als Zufalls-Seitenprojekt aus einer Kooperation zwischen einem Google-Maps-Entwickler und dem Portlander Verkehrsverbund. Gedacht war es als Standard-Austauschformat, um Fahrplandaten in verschiedene beliebige Verkehrsauskuenfte zu integrieren – auch Google Maps, aber eben auch viele andere Anwendungen.

In Deutschland dauerte es sehr lange, bis GTFS oder das sehr viel umfangreichere NeTEx-Format halbwegs breit als Grundlage fuer Open-Data-Fahrplaene angeboten wurde. Deutsche Verkehrsverbuende sind vielfach bis heute der Ueberzeugung, dass nur sie selbst „richtige“ Auskuenfte geben koennen. Das wuerde ich generell sowieso in Frage stellen, aber das ist gaengige Policy, und auch in der VDV-Schrift 7030 „Open Service“ in eine wirklich haarstraeubende Sammlung zurschaugestellter Ahnungslosigkeit und Falschdarstellungen zusammengefasst. Teile der Geschichte dazu lassen sich in meiner Diplomarbeit von 2014 (sic) nachlesen.

Sehr sehr langsam tat sich aber etwas in Deutschland – auch weil Anfang Dezember 2019 die Delegierte Verordnung (EU) 1926/2017 die Auslieferung aller(!) Soll-Fahrplandaten ueber einen Nationalen Accesspoint zur Pflicht machte. Die Verbuende, die sich lange Zeit wehrten, mussten also nun ihre Fahrplaene offenlegen, auch zur Nachnutzung durch Dritte. Die Open-Data-Landkarte, auf der 2013 nur der VBB und die vergleichsweise winzigen Stadtwerke Ulm zu finden waren, faerbte sich nach und nach:

Wenn auch viel zu spaet und sehr schleppend und weit entfernt von den skandinavischen Best-Practise-Beispielen, die hier meilenweit voraus sind: Es tat sich was.

Das schien nun also der Anlass fuer diverse Diensteanbieter zu sein, nun auch die notorisch verspaeteten deutschen Verbuende in ihre Auskuenfte einzubinden. So auch Apple Maps, die offenbar nun einige Regionen mehr in ihre Auskunft aufnahmen – was zu diesem denkwuerdigen Artikel auf nordbayern.de fuehrte, der einem nochmal plakativ vor Augen fuehrt, auf welchem unterirdischen Niveau wir 2020 noch ueber intermodale Verkehrsauskuenfte reden. Beste Zitate:

Die Daten stammen, so behauptet es Apple in der App, von der Verkehrs-Aktiengesellschaft Nürnberg (VAG) und dem Verkehrsverbund Großraum Nürnberg (VGN). Dort allerdings wundert man sich. „Es gibt keine vertragliche Vereinbarung (…) zu einer Überlassung von Fahrplandaten“, sagt VGN-Sprecher Manfred Rupp. „Wir wissen auch nicht, woher Apple die Fahrplandaten zu den VGN-Linien hat.“ Man könne, sagt Rupp, nur spekulieren – und sei dabei, die technischen Vorgänge aufzuarbeiten.

Das ist wirklich bemerkenswert, denn auf der Website des VGN selber findet sich ein Punkt „Soll-Fahrplaene im GTFS-Format“, und ueber den Standardvertrag der Creative-Commons-Lizenz ist auch die vertragliche Ueberlassung von Fahrplandaten ganz klar geregelt (Ueberlegungen, ob es sich bei Fahrplandaten ueberhaupt um ein urheberrechtlich geschuetztes Werk handelt, auf das auf dem UrhG basierende Lizenzen anzuwenden sein koennen, seien mal aussen vor gelassen).

Im weiteren Text wird zunaechst behauptet, Apple erwecke den Eindruck, dass es sich um Echtzeitdaten (also unter Einberechnung von Verspaetungen) handle. „Das könne aber gar nicht sein […] Die liegen nicht einmal mehr auf unseren Servern“ wird der VGN zitiert. Einen Absatz weiter wird jedoch zurueckgerudert, dass es sich um „aeltere“ Soll-Fahrplandaten unklaren Alters handelt.

Diese Reaktion ist fuer mich wirklich erschreckend. Ziel des VGN muesste es sein, eine stabile Quelle tagesaktueller Soll-Fahrplaene bereitzustellen. Sollte Apple wirklich den GTFS-Feed des VGN vom Dezember 2019 benutzen und dieser nicht aktuell sein, liegt das Problem glasklar auf Seiten des Verbunds. Er hat dafuer zu sorgen, dass Dritte Daten in guter Qualitaet nutzen koennen – spaetestens seit der Delegierten Verordnung. Und die vielfach als Argument angefuehrten Echtzeit-Ist-Daten sind vielmehr ein gewichtiges Argument, spaetestens jetzt die Vorbereitungen zu treffen, auch diese Daten fuer Dritte nutzbar ausspielen zu koennen. Denn Echtzeit und Open Data schliessen sich nicht aus – wenn man denn wie die Skandinavier auf die richtigen Formate setzt, anstatt dem VDV-Unsinn rund um den sogenannten „Open Service“ nachzulaufen.

Die Uhr tickt indes. Spaetestens im Dezember 2023 ist die Ausspielung der dynamischen (Echtzeit) Daten gemaess DV 1926/2017 EU-weit gefordert und nicht mehr nur optional. Ich bin gespannt, ob die deutschen Verbuende das auch so grandios verkacken werden wie bei den Soll-Daten.

PS: Wer Lobbyarbeit machen moechte: Die Karte oben stammt aus dem 2017 als Spassprojekt gestarteten One-Click-Lobby-Projekt rettedeinennahverkehr.de – dort kannst du dich mit wenig Aufwand an deinE LandraetIn oder OberbuergermeisterIn wenden.

Offene Schnittstellen fuer intermodale Mobilitaet

Die Konsequenz des obigen Zitats finde ich sehr spannend. Mobilitaet in der beschriebenen Form eines gemeinsam gedachten und funktionierenden Systems kann also nur funktionieren, wenn a) ein Anbieter alles aus einer Hand anbietet. Das scheint das Modell zu sein, das einige Verkehrsverbuende fuer sich zu beanspruchen scheinen: Alles soll in ihre App. Und auch einige privatwirtschaftliche Anbieter wollen jeweils marktbeherrschender Platzhirsch werden – denn wenn ihnen die Paymentfunktion gehoert, haben sie den Markt gecornert.

Modell b) waere dagegen, die einzelnen Komponenten fuer Mobilitaet nach den Modellen der Unix-Philosophie oder des Internets zu betrachten: Jede Komponente macht ihren Teil wirklich richtig gut, und laesst sich ueber definierte Schnittstellen zu einem groesseren Ganzen zusammenfuegen.

Die grosse Frage ist in Deutschland seit Jahren, wie man die Schnittstellen in diese Mobilitaet hineinbekommt. Selbst Soll-Fahrplandaten für den ÖPNV sind in Deutschland immer noch Mangelware, und Verbünde preisen ihre architektonischen Inselloesungen zu Echtzeit-Fahrplanauskuenften mit der Marketingluege „Open Services“ an, obwohl sie weder Open noch ein sich in ein Gesamtsystem einbetten lassender Service sind. Und private Mobilitaetsdienstleister nutzen zwar gerne oeffentlichen Raum im Sinne des Gemeingebrauchs fuer ihre Dienste, geben aber im Gegenzug enorm ungern Daten wieder preis.

Max und Consti haben dieser Tage einen laengeren Artikel darueber geschrieben, wie die City of Los Angeles per kommunaler Satzung an dieser Stelle mitbestimmt und den Markt im Sinne des Gemeinwohls steuert. Die Stadt hat sowohl eine Satzung als auch gleich einen passenden Datenstandard verabschiedet, an den sich alle halten muessen, die innerhalb der staedtischen Jurisdiktion Dienste anbieten wollen. Das Motto: Wer hier Geschaefte machen will, muss das auch sozialvertraeglich tun und dafuer Sorge tragen, dass das eigene System sich in das groessere Mobilitaetssystem einbetten laesst.

Im Artikel wird darauf verwiesen, dass Elektrokleinroller jetzt bald auch in Deutschland legal im Strassenverkehr einsetzbar sein werden, und dadurch bald auch Scooter-Sharinganbieter wie Lime und Bird auf den deutschen Markt vordringen werden. Das sei eigentlich der ideale Zeitpunkt, auch in Deutschland kommunale Satzungen zu verabschieden, die sich an der von Los Angeles orientieren.

Mehr Lektuere dazu gibt es im API-Policy-Paper der Transit App, mit einer Menge von Links, die sich zu lesen lohnen.

Linksammlung, offene-Tabs-vom-Sommer-2018-Edition

Understanding the Users of Open Data – Studie vom Mai 2017, welche NutzerInnengruppen eigentlich die Offenen Daten von NYC nutzen, und daraus gebildete Personas (via Knut)

·

Scientists Warn the UN of Capitalism’s Imminent Demise – “Capitalism as we know it is over. So suggests a new report commissioned by a group of scientists appointed by the UN Secretary-General. The main reason? We’re transitioning rapidly to a radically different global economy, due to our increasingly unsustainable exploitation of the planet’s environmental resources.”

·

Five Things We Need to Know About Technological Change – Vortrag von Neil Postman von 1998, der nichts von seiner Aktualitaet verloren hat. Kernpunkte:

  • Jeder Fortschritt ist ein Kompromiss: Der entstandene Vorteil wird mit einem verbundenen Nachteil erkauft. “ulture always pays a price for technology”
  • Die Vor- und Nachteile der neuen Technologie sind nicht gleichverteilt – eine Gruppe profitiert, eine andere erleidet einen Nachteil, und vermutlich juckt’s eine große Gruppe gar nicht erst
  • Jede Technologie basiert auf einer darunterliegenden Philosophie, die wiederum die Denkweise von Menschen beeinflusst, die sich davon leiten lassen. So wie manche Leute gerade ueber alles eine Blockchain pflastern wollen. Vielleicht.
  • Technologischer Fortschritt ist nicht additiv, er verändert jeweils das Ökosystem, in dem er sich befindet
  • Medien [d.h. Technologien] haben die Tendenz, mythisch zu werden: “When a technology become mythic, it is always dangerous because it is then accepted as it is, and is therefore not easily susceptible to modification or control. If you should propose to the average American that television broadcasting should not begin until 5 PM and should cease at 11 PM, or propose that there should be no television commercials, he will think the idea ridiculous. But not because he disagrees with
    your cultural agenda. He will think it ridiculous because he assumes you are proposing that something in nature be changed; as if you are suggesting that the sun should rise at 10 AM instead of at 6.”

·

Tesla, software and disruption – “A great, innovative car and a great car company are not the same thing” (via @tobiasknobloch)

·

Anatomy of an AI System – Tiefer(!) Einstieg in die Zusammenhaenge von Rohstoffbeschaffung, Energiebedarf, Wertschoepfung (und der Ausbeutung privaten Handelns durch Unternehmen), Konsumverhalten etc. am Beispiel von Amazon Echo. (via @lorz)

wasfehlt: Gruendungsberatung fuer Civic-Tech-Projekte

Dieser Tage ging mein Blogpost wieder rum, in dem ich Hackathons als langsam etwas abgedroschenes Standardformat fuer Open Data und Civic Tech betrachtet und gefragt habe, wie sich die Community nachhaltiger foerdern liesse.

Tatsaechlich gibt es mittlerweile schon einige Ansaetze, wie auch die vielen ehrenamtlichen Gruppen gefoerdert werden koennen, und nicht nur die Fraunhofers und sonstigen etwas verstaubten grossen Player. Der Prototype Fund der OKF DE ist ein Beispiel, und dass die Stadt Ulm der Civic-Tech-Community ein ganzes Haus samt Ausstattung zur Verfuegung stellt, findet hoffentlich bald Nachahmung in anderen Staedten.

Eine Sache fehlt aber nach wie vor ganz gewaltig, und das ist Beratung. Auch als Bruecke, um die vielen Ideen, die in den OK Labs und anderen Initiativen entstehen, ueberhaupt erst in einen Zustand zu versetzen, um sich beispielsweise fuer den Prototype Fund bewerben zu koennen.

Startup- vs. Gemeinwohlberatung

Es ist ja eigentlich eine Crux: Wer heutzutage ein Startup gruenden und VC-Gelder verbrennen moechte, findet an jeder Ecke institutionalisierte Beratung. Gruenderzentren, IHK und Co. pruegeln sich geradezu, wer denn nun kompetenter beraten kann, Literatur gibts zuhauf, und wenn die politischen Signale guenstig stehen, fliessen auch die Foerdertoepfe grosszuegig.

Fuer Civic-Tech-Projekte – insbesondere diejenigen, aus denen sich kein Geschaeftsmodell entwickeln laesst, sondern deren Gemeinnuetzigkeit dem entgegensteht – sieht die Lage mau aus. Das klang neulich schon an, als ich nach Alternativen zu den von unbedachten Hackathon-Veranstaltern oft ausgelobten grossen Barpreisen fragte:

Was auffaellt: Viele der Vorschlaege drehen sich um Mentorierung und Folgefinanzierung – der Rest um die schon im Dezember angesprochenen Huerdensenker wie Reisekosten etc.

Weil

Das da oben habe ich mittlerwiele zigmal gehoert.

Jedes Mal in einer Runde mit faehigen Leuten[1], die die Idee garantiert umsetzen koennten. Und fuer die der Schritt aber gefuehlt zu gewagt ist, ihre (in der Regel) Festanstellung zu reduzieren und nebenher finanziert aus $Foerdertopf dieses Projekt voranzubringen. Oder es laeuft noch viel banaler, und die oertliche Civic-Tech-Gruppe bekommt von Lokalpolitikern eingefluestert, dass man sie schon laengst in einem Foerderprogramm untergebracht haette, wenn sie nur endlich mal einen gemeinnuetzigen Verein gegruendet haetten.

Diese Kluft haette ich gerne ueberbrueckt. Damit nicht nur Vereinsprofis und die jetzt schon freiberuflich arbeitenden Softwareentwickler*innen eine Chance auf Foerderung haben, sondern auch moeglichst viele andere.

Auf dass es bald in jedem OK Lab heissen kann:

Wiederkehrender Dialog:
„Ja ey, [XYZ] bräuchte es!“
„Ja, und das wuerde sogar zu [Foerdertopf] passen“
„Hm“
„Ich frag mal die Civic-Tech-Sprechstunde“
„Jo“

[1] Meine Definition in diesem Kontext: Leute, die etwa tausendfach besser Software entwickeln koennen als ich. Das fuehrt unweigerlich dazu, dass ich von enorm vielen faehigen Leuten umgeben bin.

Offene Daten für den Einzelhandel

Man kann eine ganze Reihe von Gruenden finden, warum man etwas im lokalen Einzelhandel und nicht online kauft. Weil man nicht dazu beitragen will, dass Menschen Robotergleich durch Versandzentren gescheucht werden, beispielsweise. Oder weil es um die Arbeitsbedingungen bei den Paketdiensten oft nicht besser ist. Oder weil man generell einen Wert darin sieht, vor Ort noch Ladengeschaefte zu haben – und die eben auch Umsatz brauchen, um zu ueberleben. Politischer Konsum, ganz klassisch.

In Ulm scheint man der Ansicht zu sein, den Einzelhandel vor allem durch Fahrspuren fuer Autos foerdern zu koennen. Weil, so die Logik, Leute ja staufrei mit dem KFZ in die Innenstadt fahren wollen, um dann zu konsumieren. Die angedachte Reduktion der Friedrich-Ebert-Strasse von vier auf zwei Fahrspuren wurde denn gleich als Untergang des Einzelhandels gebrandmarkt – egal was die verkehrsplanerische Vernunft sagt, denn das Braess-Paradoxon ist eben mal kontraintuitiv.

Aus Sicht einer, aeh, vielleicht mehr netz- als autoorientierten Generation laege die Loesung aber ganz woanders. Die Schmerzen bestehen fuer mich viel mehr darin, dass ich mich gar nicht damit beschaeftigen will, wo ich denn nun mein gewuenschtes Produkt im stationaeren Einzelhandel bekomme und wie ich da hinkomme. Je niedriger diese Schwelle ist, desto einfacher wird der Amazon-Verzicht. Eine Bierlaunenidee war da schnell gefunden:

Browserplugin, das auf Amazon eine OPNV-Route ausrechnet, um dasselbe Produkt aufm Heimweg im Einzelhandel aufzugabeln.

Offene Daten ueber offene Schnittstellen aus dem Einzelhandel, dazu Soll-Fahrplandaten im GTFS-Format – damit waere das Feld bestellt, auf dem beliebige Browserplugins geschrieben werden koennten, um dem Ziel naeherzukommen.

Wie sich wenige Tage spaeter herausstellte, gibt es so etwas tatsaechlich schon:

Library Extension is a Chrome plug-in that shows if a book on Amazon is available at your library libraryextension.com pic.x.com/og5v4fbtuo

Zugegeben, fuer den Buecher-Anwendungsfall ist die Angelegenheit etwas einfacher – jedes Buch laesst sich ja eindeutig ueber seine ISBN identifizieren, und quasi alle Bibliotheken haben irgendeine Form von OPAC, in den sich die ISBN fuettern laesst. Bei anderen Produkten ist das schwieriger aufzuloesen – und vor allem hat der Einzelhandel auch bislang seltenst ueberhaupt Schnittstellen fuer sein Inventar. Geschweige denn in standardisierter Form.

Langfristig waere aber genau das der richtige Ansatz: Offene, standardisierte Schnittstellen. Auf deren Basis dann jemand beispielsweise als Radkutschenkurier sein eigenes Geschaeft aufbauen kann, um entweder binnen einer Stunde die gewuenschte Ware aus dem Laden in der Stadt nach Hause liefert.

Das wird nicht gleich morgen entstehen, und es beraubt einen des befriedigenden Gefuehls der Geschaeftigkeit, das man beispielsweise beim Einrichten von Portalen hat (niemand braucht und/oder nutzt Portale). Geschaeftigkeit ist aber nicht Produktivitaet – und was ich fuer die nachhaltigere Loesung halte, duerfte klar sein, oder? 😉

Lieber Clever als Smart: Civic Tech fuer Menschen

Drei (plus x) Lese- und Ansehempfehlungen, die mir gestern nach und nach in den Twitterfeed gepurzelt sind und ebenfalls zur Frage passen, wie Civic Tech weitergesponnen werden kann.

Erstens das Boston Smart City Playbook, das schon gleich mit einem Kracher anfaengt:

The age of the “Smart City” is upon us!

It’s just that, we don’t really know what that means. Or, at least, not yet.

So far, every “Smart City” pilot project that we’ve undertaken here in Boston has ended with a glossy presentation, and a collective shrug. Nobody’s really known what to do next, or how the technology and data might lead to new or improved services.

Es folgt ein Rant ueber Vertriebsdrohnen von „Smart City“-Verkaufsbueros, eine Rueckbesinnung auf die Menschen, um die’s gehen soll, dass es nicht noch eine Plattform braucht (!!! zefix!!!), und dass im Zweifel eine „Clevere“ Stadt besser ist als eine „Smarte“: Mit einem Prototypen, einer intelligenten Strassenlaterne. Kleinen Spielplaetzen, die spaeter vielleicht hochskaliert werden, wenn sie sich bewaehren. Anstelle von Alles-oder-nichts-Megaprojekten.

Zweitens The Engine Room’s Advent Calendar mit einem Lesetipp fuer jeden Tag. Beispielsweise, dass „Startup-Kultur“ eine denkbar depperte Denkweise und Rahmenbedingung fuer gesellschaftsveraendernde Projekte ist. Dass „Innovation“ vollkommen ueberbewertet ist und „Wartung und Unterhalt“ eigentlich die wichtigeren Buzzwords sein sollten. Oder dass im Westen nach wie vor nicht-wohlhabende nicht-weisse Nicht-Akademikerinnen (hier: spezifisches Femininum) vergleichsweise wenig von Civic Tech haben.

Um Ausschluesse geht es – drittens – auch in Programming is Forgetting: Towards a New Hacker Ethic. Der etwas mehr als 20minuetige Vortrag (siehe oben) ist hier komplett transkribiert und lohnt sich zu lesen, gerne auch haeppchenweise. Am Beispiel einer Anekdote um die juengst mit der Presidential Medal of Freedom ausgezeichneten Margaret Hamilton zerlegt Allison Parrish Stueck fuer Stueck die „Hackerethik“, wie sie Steven Levy 1984 in seinem Buch “Hackers” dargestellt hatte. Nach einem Exkurs ueber soziale Kontexte stellt sie den urspruenglichen Lemmas jeweils eine Frage gegenueber. Und ich finde sie grossartig:

allison-parrish-programming-forgetting-26

(danke @lorz und @mjays fuer die Links. Ich weiss leider nicht mehr, von wem ich den Vortrag retweeted bekam.)

Von Hackathons und Communityfoerderung

Foto: Sebastián Laraia für Deutsche Bahn / CCBY4.0

Foto: Sebastián Laraia für Deutsche Bahn / CCBY4.0

Mittlerweile hat sich herumgesprochen, dass Hackathons eine ganz gute Moeglichkeit sind, die eigene Stadt, Behoerde oder Konzern zu oeffnen und sich frischen Wind in die verstaubten Hallen zu holen. Das BMVI lud derletzt zum zweiten Mal zum Data Run, und die Deutsche Bahn hatte gestern den fuenften Hackathon binnen 20 Monaten ueber die Buehne gebracht. Nicht schlecht, koennte man sagen.

Was mir aber schon bei unseren OpenCityCamps auffiel: Nach einer Weile scheint sich das etwas totzulaufen. Die ausrichtende Einrichtung darf von Mal zu Mal neue Datenquellen freischaufeln, um sich nicht dem Vorwurf auszusetzen, es bewege sich nichts mehr. Ob diese – muehsam irgendeiner grantelnden Fachabteilung abgetrotzten – Daten dann helfen, tatsaechliche Probleme echter Menschen zu beheben, weiss vorher kein Mensch. Und irgendwann ist auch der Punkt erreicht, an dem die naechsten grossen zu beackernden Baustellen einfach gar nicht mehr an einem 24-Stunden-Hackathon bearbeitet werden koennen.

Vor diesem Hintergrund deswegen mal ein paar halbgare Einwuerfe, was mir die letzten eineinhalb Jahre so durch den Kopf gegangen ist:

  1. Mit das wichtigste Ergebnis einer Open-Data-Veranstaltung ist, dass sich die Teilnehmer*innen live treffen und austauschen. Egal ob Freiwillige mit Ministeriumsleuten, Ministeriumsleute mit Konzernbeschaeftigten oder sonstwas: Diese Aufeinandertreffen motivieren, inspirieren und sorgen fuer die notwendige regelmaessige Hirnbelueftung mit frischen Ideen. Fuer diesen Austausch muss genuegend Zeit und Raum vorhanden sein. Das haben wir als blutjunge Fachschaftler*innen bei der Konferenzorga zwar gelernt, bei Behoerden darf man von dem Wissen aber nicht unbedingt ausgehen 😉
    Hierzu gehoert auch: Wenn ein Ministerium, eine Landeseinrichtung, ein Staedtetag oder sonstwer eine schicke Austauschveranstaltung macht, dann sollte sie unbedingt auch die Freiwilligen aus der Community mit einladen. Die OPEN! hat das nach der Kritik von 2015 dieses Jahr gemacht, das VDV-Verkehrscamp ebenso. Weiter so!
  2. Irgendwann ist jedoch der Punkt erreicht, an dem das klassische Hackathon-Wettbewerbs-Format nicht mehr traegt. Erstens, weil beim Coden immer die Frage im Raum steht, mit welchem Projekt man denn Preise gewinnen kann. Anstelle der Frage, was nuetzlich, wichtig und sinnvoll waere. Zweitens, weil es das Potenzial verschenkt, gemeinsam mit den vielen tollen, kompetenten Leuten mal ein Wochenende lang strategisch wichtige Dinge auszuarbeiten. Mal dieses Werkzeug uebersetzen. Oder dieses Tool schreiben, das es noch nicht gibt und das bisher jedes Mal irgendwie fehlte. Gruppenuebergreifende Metaprojekte, bei denen jede Gruppe einen kleinen Teil fuer das Gesamtprojekt entwickelt
  3. Aus 1) und 2) folgend: Der konsequente naechste Schritt waere, genau solche Zusammenkuenfte zu foerdern. Bei denen nicht kompetitiv Prototypen gebastelt, sondern gemeinsam die Dinge beackert werden, die fuer die Weiterentwicklung von Open Data in Deutschland wichtig sind.
  4. Die Teilnahme an den Aktionen in 3) darf nicht mehr nur auf den Schultern von Leuten mit viel Zeit oder ausreichend Geld oder beidem ruhen. Die Freiwilligen, die sich ein Wochenende um die Ohren schlagen, duerfen nicht auch noch aus eigener Tasche Anreise und Unterkunft bezahlen muessen, oder per Anhalter anreisen und dann irgendwo auf WG-Sofas pennen. Wer quer durch Deutschland zu so einer Aktion reist, gibt fuer solch ein Wochenende je nach Zeit-Geld-Tradeoff irgendwas zwischen 30 und 300 EUR aus. Das kann sich nur eine ueberschaubare Gruppe privilegierter Leute leisten.

An jeder Ecke wird derzeit haufenweise Kohle auf Big Data, Blockchain 4.0 in der Cloud as a Service und andere Ideen mit ueberschaubarer Halbwertzeit geworfen, die aus irgendeinem Berater-Powerpoint gefallen sind. Foerderfunds werden ins Leben gerufen, auf die sich aufgrund der Rahmenbedingungen letztlich eh nur die ueblichen Verdaechtigen bewerben und die Kohle in bekannter Manier zum Fenster rauswerfen.

Ich wage zu behaupten: Die Foerderung von Veranstaltungen wie in 3) beschrieben und die Vergabe von Reisestipendien fuer Open-Data-Aktivist*innen haette ein deutlich besseres Preis-Leistungs-Verhaeltnis. Da wuerde auch wirklich ein Bruchteil der 100 Millionen des BMVI reichen.