Schlagwort-Archive: Hackathon

Paper der Woche: Hackathons

Tolle Paper-Empfehlung von Paula: Hackathons as Co-optation Ritual: Socializing Workers and Institutionalizing Innovation in the “New” Economy

Abstract

Hackathons, time-bounded events where participants write computer code and build apps, have become a popular means of socializing tech students and workers to produce “innovation” despite little promise of material reward. Although they offer participants opportunities for learning new skills and face-to-face networking and set up interaction rituals that create an emotional “high,” potential advantage is even greater for the events’ corporate sponsors, who use them to outsource work, crowdsource innovation, and enhance their reputation. Ethnographic observations and informal interviews at seven hackathons held in New York during the course of a single school year show how the format of the event and sponsors’ discursive tropes, within a dominant cultural frame reflecting the appeal of Silicon Valley, reshape unpaid and precarious work as an extraordinary opportunity, a ritual of ecstatic labor, and a collective imaginary for fictional expectations of innovation that benefits all, a powerful strategy for manufacturing workers’ consent in the “new” economy.

 

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.

Mein erster Hackathon

Nach der Idee von Benjamin habe ich am vergangenen Wochenende tatsaechlich an meinem ersten Hackathon teilgenommen. Das ist tatsaechlich in etwa so, wie man sich das klischeeweise vorstellt: Man verbringt beinahe 48 Stunden mit seinem Team und stellt in der Zeit etwas auf die Beine.

In unserem Fall eine Livekarte der Stadt Ulm mit den Nahverkehrslinien 1, 3/5 und N1–N8. Auf denen sich die Busse live bewegen. Awesome.

Unser Team bestand aus Benjamin, cmichi, Fox und mir, musste gemaess der Regeln des Nodeknockout-Wettbewerbs node.js verwenden und hatte genau 48 Stunden Zeit, etwas auf die Beine zu stellen. Klar, dass wir vor unserem ulmapi-Hintergrund irgendetwas in der Richtung offene Daten und Nahverkehr machen wollten 😉

 

„Tatort“ war das Students‘ Lab der Fachschaft Elektrotechnik, wo wir dankenswerterweise von Samstag frueh bis Montag frueh arbeiten und zum Teil auch schlafen durften.

Aber von Anfang an.

Livevisualisierungen sind jetzt keine bahnbrechende, neue und revolutionaere Sache (mehr), das gibt es schon eine ganze Weile. Wir hatten uns aus zwei Gruenden trotzdem dazu entschlossen, so etwas umzusetzen:

  1. Es ging beim Contest um node.js, was insbesondere fuer Benni und Michi eine ziemlich erotisierende Wirkung hat aktuell sowas wie eine Lieblingssprache ist. Zudem baut die Loesung auf freien(!) Frameworks auf, im Gegensatz zum Beispiel zu Google Maps, was man hier ja immer mal wieder sieht
  2. Wir wollten uns einmal selbst „so richtig“ mit der General Transit Feed Specification (GTFS), dem Quasi-Standard fuer maschinenlesbare Nahverkehrsdaten, auseinandersetzen. Ich hatte mich schon vorab immer mal wieder in den Standard eingelesen, jetzt sollte es aber ans Eingemachte gehen.

Womit wir dann schon gleich beim grossen Problem waren.

I can haz GTFS feed, plz?

Unsere Nahverkehrsanbieter (DING fuers Umland, SWU fuer die staedtischen Linien) bieten einfach nichts dergleichen an. Waehrend das Frontend dank der freien Leaflet-Bibliothek und dazu passenden huebschen OpenStreetMap-Karten in kurzer Zeit aufgebaut war, mussten die notwendigen Betriebsdaten erstmal muehselig von Hand zusammengebaut werden.

(An dieser Stelle moechte ich noch einmal erwaehnen, wie toll ich Leaflet und auch die Cloudmade-OSM-Karten finde. Wie neulich hier schon geschrieben: Die freien Dienste muessen gut aussehen, und mit der Leaflet/Cloudmade-Kombination sieht OSM einfach rattenscharf aus und bedient sich erstklassig.)

Ja. Die Fahrplandaten. Das klingt jetzt wirklich archaisch, aber: Alles, was momentan auf der Livekarte zu sehen ist, ist datenseitig mit viel Handarbeit zusammengestueckelt worden. Mittels einiger Skripte konnten wir die Shapefiles der Busrelationen aus der DING-Fahrplanauskunft extrahieren, und die Relationen selbst (also der Plan, welche Fahrgastfahrt der Linie X um welche Zeit von A nach B faehrt und wo sie ueberall haelt) ist aus den PDF-Fahrplaenen der SWU zusammengebaut. Das ist haesslich, das war verdammt zeitaufwaendig, aber es ist zumindest halbwegs vollstaendig.

Wenigstens die Nachtbusse sind tatsaechlich zu 100% und auch korrekt nach GTFS ueberfuehrt. Immerhin. Dafuer fahren sie auf der Karte auch jede Nacht 🙂 (siehe unten)

Da stimmt aber noch irgendetwas nicht…

Ja:

  • GTFS sieht ziemlich genaue Unterscheidungen vor, welche Services wann fahren. Auf der aktuellen Karte fahren aber auch die Busse, die (korrekterweise) dem Service „university“ angehoeren, also eigentlich nur an Vorlesungstagen fahren. Unser Parser ignoriert das momentan und laesst alles fahren, was er an Daten vorliegen hat: Alles, was Montag bis Freitag an einem Vorlesungstag ausserhalb der Schulferien auf besagten Linien faehrt. Und die Nachtbusse 😉
  • Einige Sonderrelationen sind noch nicht abgebildet. Linien die spaet abends nur freitags fahren, oder nur freitags nicht, dafuer Montag bis Donnerstag. Sorry. Kuerze der Zeit. Die Rohdaten aus den Fahrplaenen sind aber mittlerweile halbwegs so aufbereitet, dass man sie fuer einen kompletten GTFS-Datensatz umparsen koennte. Stattdessen koennte man aber auch eine Datensammlung aus der DING-Onlinefahrplanauskunft machen.

Ich bin mir momentan nicht sicher, was die „beste“ Loesung ist, um endlich einen vollstaendigen GTFS-Datensatz fuer die SWU-Linien inklusive aller Sonderfaelle zu bekommen (im Dezember ist uebrigens wieder Fahrplanwechsel…), aber klar ist: Ideal waere eine vernuenftige Originalquelle direkt vom Verkehrsdienstleister. Vielleicht haben wir mit der Karte ja nun weiteres Interesse bei den Stadtwerken geweckt 🙂

Nachtrag am 31. August

Einige Dinge waren wohl trotz der „About“-Seite nicht so ganz klar, und andere habe ich vergessen zu erwaehnen:

  • Warum fahren da Busse, die da nicht fahren sollten? — Die GTFS-Scrapedaten unterscheiden zwar zwischen Nachtbusterminen und Wochentagen, der Parser diskriminiert hier aber nicht. Das heisst zum Beispiel, dass die Nachtbusse jede Nacht fahren, und auch trotz vorlesungsfreier Zeit die Sonderfahrten zwischen Science Park II und Ehinger Tor auf der Karte unterwegs sind
  • Warum fahren die Busse laenger, als sie sollten? — Der no.de-Server laeuft auf UTC, waehrend Ulm momentan auf UTC+2 liegt. Tatsaechlich sieht man also, was vor zwei Stunden los war. Das ist wegen der zyklischen Plaene tagsueber nicht so schlimm, schoen aber natuerlich auch nicht.
  • Warum macht der Bus beim Umlauf 3/5 keine Klinikpause? — GTFS sieht hier vor, fuer jeden Halt eine zurueckgelegte Strecke auf dem Streckenshape zu hinterlegen. Das auszurechnen war in den 48h nicht moeglich (zum Vergleich: Alleine die Linie 3 hat bei uns momentan fuenf verschiedene Shapes fuer alle moeglichen Start-Ziel-Kombinationen). Die Position wird momentan nur relativ krude ueber Start- und Zielort sowie vergangener Zeit approximiert.
  • Warum verwendet die Karte keine Echtzeitdaten? — Uns war es wichtig, hier auf den offenen Standard GTFS zu setzen. Was in den 48h herausgekommen ist, ist zwar keine wirklich saubere Loesung, kann aber noch so weit „gesaeubert“ werden, dass am Ende ein vollstaendiger GTFS-Datensatz verwendet wird, und eben keine Flickschusterei mit manipulierten Fahrauskunft-Anfragen, die man dann minuetlich fuer alle Relationen aktualisieren muesste.

    Es gibt mittlerweile die Erweiterung GTFS-Realtime, die mit Echtzeitdaten umgehen kann. Mit diesen Daten koennte man sogar soweit herunterbrechen, dass angezeigt wird, welcher Bus da jetzt gleich kommen wird (Kennzeichen, dadurch dann z.B. auch, ob es ein Gelenkbus, Standardbus, Viertuerer, Dreituerer, klimatisiert… ist). All das setzt aber erst einmal voraus, dass wir irgendwann einen GTFS-Volldatensatz von den SWU bekommen. Und darum geht’s jetzt erst einmal.