Schlagwort-Archiv: Businesskasper

Hydrantenmapping in OpenStreetMap – Schoener leben mit Fast-Linked-Open-Data

Ich hatte neulich zweieinhalb Wochen Urlaub und bin dabei unvermittelt in eine ganze Reihe von Rabbit Holes gefallen, in die ich mich ueber den Urlaub hinweg reingegraben habe. Das ueberrascht niemanden, die/der mich kennt, aber ich fand die Zusammenhaenge dazwischen so spannend, dass ich das mal aufschreiben wolle.

Alles fing mit einem Abend in der Feuerwehr an. Wir sollten ueber mehrere Abende alle Hydranten im Ortsgebiet anfahren, kontrollieren, spuelen und – wo noetig – Maengel aufschreiben. Fehlt ein Hinweisschild eines Unterflurhydranten, laesst sich ein Hydrant nicht vernuenftig oeffnen – oder aber auch, sind neue hinzugekommen, die wir nicht in unserem Hydrantenplan haben. In einer idealen Welt gaebe es natuerlich einen gut funktionierenden Austausch zwischen Gemeinde, Wasserversorger und Feuerwehr, so dass alle immer denselben Zustand dokumentiert haben. Aber ich muss ja niemandem erzaehlen, dass wir nicht in einer perfekten Welt leben.

Wo sind Hydranten – von analog zu digital?

Als ich 1999 zur Feuerwehr kam, bestand der Hydrantenplan aus einer fotokopierten Ortskarte, in die mit roter und blauer Farbe die Ueber- und Unterflurhydranten haendisch hineingemalt worden waren. Kurz darauf erstellten zwei Kollegen quasi ein „Lookbook“, in dem jeder der Hydranten mit einem Foto des Umfelds und einer kurzen Beschreibung je eine Karteikarte in einem Ordner bekam, die dann alle alphabetisch nach Strassennamen sortiert waren.

Beide Ansaetze haben Vor- und Nachteile: Bei der Uebersichtskarte sieht man stets den geographischen Kontext – gerade Unterflurhydranten tarnen sich aber gelegentlich recht gut in ihrer Umgebung, so dass man sie nicht immer leicht findet. Das Umfeldfoto hilft beim Auffinden, dafuer kann man ohne eine Kontext-Karte umliegende andere Hydranten uebersehen, die in einer anderen, aber nahen Strasse liegen.

Wegen eines anderen Urlaubs-Rabbitholes kam ich daher recht schnell auf die Idee, Umfeldfotos und Karte mit Koordinaten zu verbinden – und was laege da naeher, als eine gute Vermessung mit Hilfe von OpenStreetMap und Wikimedia Commons!

Die ersten Hydranten habe ich ganz klassisch nur per Smartphone positioniert. Da wir im temporaerhaus aber seit diesem Jahr einen echtzeitkinematikfaehigen simpleRTK2B-GNSS-Empfaenger samt passender Antenne haben, wollte ich das natuerlich etwas genauer haben 😉 Und so kam es zu einem unvorhergesehenen Projekt zwischen temporaerhaus und Feuerwehr Altenstadt.

Und was mappt man da?

RTK-Mapping: Positioniere Antenne ueber Hydranten, warte auf RTK-Fix, trage Position und Tags in OSM ein. Links ein alter Erhard-Ueberflurhydrant, rechts ein Unterflurhydrant.

Eigentlich alles, was in emergency=fire_hydrant auf OSM beschrieben ist. Um moeglichst alles abzudecken, kann man recht einfach zwischen Tags fuer alle Hydranten und Erweiterungen jeweils fuer Ueber- und Unterflurhydranten unterscheiden:

Fuer alle Hydranten

refDie Hydrantennummer auf dem Hinweisschild oder dem Hydranten selbst – sofern vorhanden
fire_hydrant:pressureDas laesst sich quasi nie ermitteln, d.h. hier einfach yes
fire_hydrant:positiongreen fuer Gruenflaeche, lane fuer die Fahrbahn, sidewalk fuer den Gehweg und parking_lot fuer Parkplaetze. Insbesondere bei Unterflurhydranten ist es super gut zu wissen, ob er auf einer Parkflaeche liegt!
water_sourcein der Regel main, also die abhaengige Loeschwasserversorgung
survey:dateDas Datum, an dem du diesen Hydranten eingetragen hast, YYYY-MM-DD
Auf solch einem Hinweisschild ist normalerweise haeufig eine Identfikationsnummer zu sehen. Hier aber leider nicht. Immerhin laesst sich der Leitungsdurchmesser 80 mm durch das „80“ rechts vom „H“ ablesen.

Speziell fuer Unterflurhydranten

fire_hydrant:typeunderground
fire_hydrant:diameterDas ist der Wert auf dem zugehoerigen Hydrantenschild – sofern das vorhanden ist! Falls keines vorhanden ist, siehe…
fire_hydrant:diameter:signed=noWenn kein Hinweisschild vorhanden ist. Dadurch lassen sich auch leicht die Hydranten ohne Schilder spaeter ermitteln

Speziell fuer Ueberflurhydranten:

fire_hydrant:typepillar
couplingsDie Anzahl der Festkupplungen, z.B. 2 oder 3
couplings:typeHier in der Regel storz
couplings:diametersNach den deutschen Kupplungsbezeichnungen, z.B. B;B oder B;B;A oder gar C;C;B (ja, das gibt es, und das festzustellen, ist spannend!)
manufacturer…irgendwann lernt man dann auch die Hersteller anhand der Logos oder Aufschriften zu unterscheiden und kann entweder den Hersteller oder die Wikidata-ID des Herstellers eintragen…
Links ein alter VAG-Hydrant mit „DN 80“ im Guss, rechts ein Erhard-nach-1996-Hydrant mit „DN 80“ auf dem Typenschild – das sagt aber nichts ueber die Versorgungsleitung aus.

Zu beachten bei Ueberflurhydranten: Die haben zwar bisweilen auch einen Rohrdurchmesser angegeben – bei den alten Hydranten im Guss im Hydrantenkoerper, bei den neueren auf den Typenschildern ausgewiesen. Dieser Durchmesser gilt aber nur fuer das Steigrohr, nicht fuer die Wasserversorgung selbst. Im OSM-Wiki wird daher davon abgeraten, diesen Durchmesser als Leitungsdurchmesser zu taggen!

Auch nur eine Karte – aber auswertbar

Darstellung in der OpenFireMap

Zunaechst hat man damit auf den ersten Blick nicht viel gegenueber der alten handgemalten Karte gewonnen: Die Hydranten sind in OpenStreetMap eingetragen, und in Ansichten wie z.B. dem „Humanitaer“-Layer kann man sie in der gerenderten Karte auf openstreetmap.org auch anzeigen – wobei die nicht einmal zwischen Ueber- und Unterflurhydranten in der Darstellung unterscheidet.

Auf OSMHydrant oder der OpenFireMap bekommt man jedoch schon jetzt eine genauere Darstellung und bei OSMHydrant per Klick auf den Hydranten auch weitere Informationen. Damit alleine liesse sich schon auf einem Alarmmonitor im Feuerwehrhaus anzeigen, welche Wasserentnahmestellen es im Umfeld eines Einsatzorts bei einem Brandalarm gibt!

Zu beachten: Die OpenFireMap wird nur woechentlich am Dienstag aktualisiert. Von der Eintragung bis zur Anzeige im Kartenlayer kann also bis zu einer Woche vergehen.

Links ein alter VAG-Hydrant mit nur zwei C-Abgaengen und einem B-Abgang – ungewoehnliche Konstellation, die wir bei der Erhebung „Hutzelmaennchen“ genannt haben. Man beachte die Oeffnungsvorrichtung oben, die nicht einmal einen Sechskant fuer den Hydrantenschluessel Typ B hat. Rechts ein moderner VAG Nova Niro 365 mit zwei B-Abgaengen.

Die eigentliche Magie beginnt aber, wenn man die so hinterlegten Daten weiter direkt aus der Overpass-API auswertet, beispielsweise mit OverpassTurbo. Beispielsweise koennen wir uns alle Unterflurhydranten ausgeben lassen, fuer die wir angegeben haben, dass sie keinen angegebenen Leitungsdurchmesser haben – also das zugehoerige Hinweisschild fehlt:

node["emergency"="fire_hydrant"]["fire_hydrant:type"="underground"]["fire_hydrant:diameter:signed"="no"]({{bbox}});

Genauso koennen wir spaeter so alle Hydranten abfragen, als JSON exportieren und weiterverarbeiten – beispielsweise, um eine Kartei mit einer Karte pro Hydrant daraus zu erstellen. Oder aber auch, um die „besonderen“ Hydranten zu identifizieren, die beispielsweise nur zwei C-Abgaenge haben.

Und auch die Versorgung von Gebaeuden laesst sich dadurch auswerten. OSMHydrant bietet einen ersten Eindruck, indem man dort Umkreise um Hydranten zeichnen kann – das hilft schon fuer einen groben Ueberblick. In der Realitaet lassen sich Schlauchleitungen aber nicht in Luftlinie von einem Hydranten verlegen, sondern muessen Strassen folgen – und koennen z.B. auch nicht einfach eine Bahnlinie queren.

Wunderbar passend bloggte Supaplex030 genau zum Zeitpunkt der Erhebung, wie man solch eine Analyse auch mit dem freien GIS QGIS erstellen und dabei entlang von Strassenzuegen arbeiten kann. So laesst sich beispielsweise pruefen, welche Strecken beispielsweise mit einer oder zwei Einpersonenhaspeln oder dem Rollschlauchmaterial auf einem Loeschfahrzeug entlang kartierter Wege erschliessen lassen – und wo die Strecken zu weit dafuer sind. Ein Bonuslevel waere natuerlich die Verbindung mit einem Digitalen Hoehenmodell, wo eine Haspel nicht mehr so einfach bergauf gefahren werden kann – aber prinzipiell geht auch das 😉

Bonuslevel: Fotos machen!

Ein modernerer Erhard-Hydrant mit zwei B-Abgaengen, Modellserie nach 1996

Was in so einer Karte dann aber noch fehlen wuerde, ist das Umfeldfoto, wie es in der frueheren, mit Word erstellten Kartei zu finden waere. Das koennen wir aber beheben!

Wir haben beim Einmessen auch Fotos eines jeden Hydranten mit der Hauskamera aus dem Technikpool des temporaerhaus gemacht und auf Wikimedia Commons in die Kategorie Fire hydrants in Altenstadt (Iller) geladen, die ich dafuer angelegt hatte. In der OpenStreetMap lassen sich solche Fotos ueber Photo Linking mit Objekten verknuepfen. Hier habe ich jedem Hydranten ueber den Tag wikimedia_commons die jeweilige Datei zugeordnet, z.B. File:2025 Altenstadt (Iller) Hydrant Memminger Straße 54.jpg

Hydranten, die zwar schon vermessen, aber noch nicht mit einem Foto versehen sind, lassen sich natuerlich auch einfach mit Overpass Turbo abfragen – man muss die Suche lediglich erweitern, dass kein wikimedia_commons-Tag vorhanden ist:

node["emergency"="fire_hydrant"][!"wikimedia_commons"]({{bbox}});

Spaeter lassen sich diese Fotos so extrahieren und weiterverwenden. Sowohl Hydranten als auch Gebaeuden liesse sich auch ein URL zu Panoramax zuordnen, einer Freien Alternative zu Google StreetView – damit liesse sich noch mehr Kontext herstellen, aber auch die direkte Ansicht einer Adresse vom Strassenniveau aus waere auf dem Einsatzmonitor moeglich, wenn ein Alarm eingeht!

Und jetzt… verlinkt?

Schon mit diesem Informationsbestand ist deutlich mehr moeglich, als das in den bisherigen Hydrantenkartierungen meiner Feuerwehr der Fall war:

  1. Die Koordinaten sind – vor allem durch die RTK-Vermessung – viel praeziser
  2. Wir haben Metadaten zu den Schildern (oder ihrer Abwesenheit), dem Nenndurchmesser der Zuleitung (sofern erfassbar), den Abgangsgroessen und vielem mehr
  3. Wir koennen diese Informationen automatisiert weiterverarbeiten
  4. Auswaertige Kraefte koennen ohne weiteres auf diesen Bestand in OSM zugreifen
  5. und auch andere MapperInnen koennen dazu beitragen, den Bestand zu verbessern, falls z.B. irgendwo ein Hydrant errichtet wurde, den wir gar nicht auf dem Schirm hatten!

Ein typischer Einwand koennte hier sein, dass ja der Datenbestand in der OSM jederzeit boeswillig veraendert werden koennte. Das ist prinzipiell richtig. In der Realitaet kommt das aber beruhigend selten vor. Dennoch koennte es sinnvoll sein, einen eigenen, geprueften Informationsbestand vorzuhalten – der auch Annotationen haben koennte, die in OSM nicht so gedacht sind.

Ein „Tele-Hydrant“ von Hawle. Der telefoniert nicht etwa, sondern er kommt ohne Standrohr aus: Ein Rohr mit zwei B-Abgängen lässt sich einfach herausziehen.

Man koennte beispielsweise all die eingetragenen und geprueften Koordinaten fuer sich vorhalten und periodisch mit OSM vergleichen: Kam etwas hinzu, wurde etwas veraendert, muss ich das pruefen, um meinen Informationsbestand valide zu halten? Was hierfuer in meiner Gemeinde fehlt, ist eben der ref-Identifier, den OSM hier eigentlich vorsieht. Weder die Hydrantenschilder noch die Hydranten selbst haben irgendwo eine ID angegeben, mit der man den Hydranten identifizieren koennte. Zu pruefen waere hier, ob es irgendwo tatsaechlich eine offizielle Nummer gibt, die man „nur“ anbringen und dann einpflegen muesste.

Man koennte hier natuerlich Wikidata missbrauchen, alle Hydranten dort als Datenobjekte anlegen und das als Identifier nutzen – das hielte ich aber schon fast fuer eine Zweckentfremdung des Projekts. Eine eigene Wikibase-Instanz fuer die Feuerwehr, um den bestaetigten Stand festzuhalten, faende ich… lustig! Das ordne ich mal unter „Seitenprojekt des Seitenprojekts“ ein, wenn mir mal langweilig sein sollte 😀

Spannend finde ich zuletzt aber, dass die gewachsene Cottage Industry rund um „Datenverwaltung in Feuerwehren“ eine sehr unterschiedliche Haltung zu so einer Verlinkung faehrt. Einzelne Softwaresysteme erlauben wohl eine Verbindung zu OSM, andere scheinen darauf zu setzen, dass man z.B. Hydranten rein in ihrem Oekosystem pflegt, auf dass man z.B. eine Tablet-Version ihrer Software kauft, die die Anzeige dieser Daten ermoeglicht. Das Charmante am OSM-Mapping finde ich, dass man damit zumindest nach aussen jegliche dieser Lock-Ins aufbricht: Egal woher eine ueberoertliche Unterstuetzung kommt und welche Systeme sie verwendet: Wenn sie OSM auswerten kann, bekommt sie zumindest die grundlegenden, wichtigen Informationen.

Und das zeigt fuer mich wieder einmal: Die ganzen Loesungen, die auf Vermarktung und Verwirtschaftlichung ausgerichtet sind, machen das Ergebnis meist eher nur shitty. Die Erfassung aller Hydranten in einer – zugegeben, im Kernort nur um die 4000 BewohnerInnen starken – Kommune hat mich einen Mittwochabend und einen Sonntagnachmittag gekostet. Eine Befahrung fuer Panoramax waere an einem weiteren entspannten Nachmittag moeglich und haengt gerade nur daran, dass die 360°-Kamera des temporaerhaus wegen eines Defekts die letzten Wochen ausgefallen war. Wenn wir nur allen Menschen mehr Freizeit ermoeglichen wuerden, waere so viel Cooleres, Besseres moeglich. Und ganz nebenher kann man dabei lernen, verschiedene Hydrantenhersteller auf einen Blick zu erkennen und etwas ueber das Hydrantenkartell zu lernen 😀

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.

 

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.

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.)

Disruptive Kasperei

Vermutlich kann man damit ganz schnell ganz viel VC einsammeln, aber jedenfalls kommt heute gefuehlt keine Unterhaltung ueber Geschaeftsmodelle mehr ohne das Buzzword „Disruption“ aus, sobald irgendetwas darin „digital“ ist.

Bildschirmfoto vom 2016-08-15 19:59:25

Jetzt ist es halt so, dass Worte eine gewisse Bedeutung haben, und da ist Disruption beziehungsweise Disruptive Technologie keine Ausnahme. Und damit man das anschaulich lernen kann, ohne die Originaldefinition von Christensen lesen zu muessen, hat die kommunikonautin vor einigen Tagen eine wunderschoene Animations-Geschichte von hardbound auf Twitter geteilt, um das Prinzip zu verdeutlichen.

*

Ueberhaupt, dieser Kapitalismus und die Innovation – geht das ueberhaupt Hand in Hand? Martin Spindler teilte heute “The Capitalist’s Dilemma” aus dem Harvard Business Review, wo die Quintessenz ist: Meh. Firmen schwimmen aktuell in disponiblem Kapital, und trotzdem machen sie nichts daraus. Aber warum?

Die Autoren (unter anderem der von vorhin schon bekannte Christensen) teilen Innovationen mal abgesehen von disruptive und sustaining in drei Kategorien ein:

  • Performance-improving: Alte Produkte werden durch neue, bessere ersetzt.
  • Efficiency innovations: Firmen koennen dem gleich gebliebenen Publikum marktreife Produkte zu geringeren Preisen anbieten
  • Und zuletzt: Market-creating innovations – die Art von Veraenderung, die auf einmal vollkommen neue Maerkte erschliesst.

Die grossen Veraenderungen, argumentieren Christensen und van Bever, kommen aus der dritten Kategorie: Aus dem Paradigmenwechsel vom Mainframe vom PC, oder vom PC zum ubiquitaeren Tablet Computer, beispielsweise. In die klassischen BWL-Werkzeuge zur Quantifizierung wirtschaftlichen Erfolgs passen solche grossmasstaeblichen Veraenderungen jedoch nicht – sie dauern schlichtweg zu lange, als dass sie in den naechsten Quartalszahlen als Erfolg verbuchbar waeren. Ganz gleich, dass sie eigentlich der richtige Weg waeren:

This, then, is the capitalist’s dilemma: Doing the right thing for long-term prosperity is the wrong thing for most investors, according to the tools used to guide investments. In our attempts to maximize returns to capital, we reduce returns to capital. Capitalists seem uninterested in capitalism—in supporting the development of market-creating innovations. Left unaddressed, the capitalist’s dilemma might usher in an era of “post-capitalism.” Adam Smith’s “invisible hand” is meant to work behind the scenes, efficiently allocating capital and labor to sectors in which prices and returns are rising, and taking resources away from those in which they’re falling. But if the cost of capital is insignificant, it emits only the faintest of signals to the invisible hand about where and when capital should flow.

 

Ich grueble seither. Ueber Unterhaltungen der letzten Wochen, mit Menschen aus Unternehmen, die jetzt ganze Intrapreneur-Abteilungen aufziehen. Und die immer wieder hmmm-ten, wenn ich begeistert von Testfeldern sprach, auf denen man doch beispielsweise die Civic-Tech-Community einfach mal machen lassen koennte. Oder noch besser: Auf denen man mit dieser Community den Markt auf den Kopf stellen koennte, mit einem Bekenntnis zu F/OSS-Implementierungen. Auf dass das der Game Changer werde, als Grundlage fuer ganz neue Dinge.

Aber so einfach ist das wohl nicht. Denn zu jeder Idee gehoert wohl ein Business Case, der sich kurzfristig umsetzen laesst.

Grad schad drum.

*

Nachtrag: Eine ungenannte Quelle besteht darauf, dass ich unbedingt dazuschreiben soll, dass disruptiv eh sooo 2015 sei. Na gut. Darum geht’s mir aber eigentlich hier gar nicht.

Zu Businesskasperei und Open Data

IMG_9820-09820-20140716

Vergangenes Wochenende war ich bei Workshops von Code for Germany und Code for All; am Montag startete Code for Germany offiziell; und danach war OKFest in Berlin.
Anlaesslich dieser Veranstaltung wurden Dinge gesagt, getan und geschrieben, die ich nicht unkommentiert stehen lassen moechte.

Erstens.

Ich halte die Initiative „Code for Germany“ fuer wertvoll, auch wenn ich den Namen nicht mag. Wir in Ulm coden nicht „fuer Germany“ und wir coden eigentlich auch nur deswegen „fuer Ulm“, weil wir zufaellig dort wohnen und das das naheliegendste Einsatzgebiet ist.

Der Witz an der Sache ist meines Erachtens genau nicht nur „fuer Ulm“ oder „fuer Germany“ zu entwickeln, sondern die Ideen anderer ueberhaupt erst zu entdecken und auf die eigene Situation anpassen zu koennen – und dass Ideen aus der eigenen Stadt anderswo aufgegriffen werden. Oder dass wir fuer die Ulmer Kita-Karte nun auf einen Kartendienst aus dem Berliner Lab zurueckgreifen konnten (danke, Jochen!)

Und nicht zuletzt habe ich es als unglaublich motivierend empfunden, festzustellen, dass es auch anderswo gleichgesinnte gibt, die fuer dieselben Dinge brennen. Vor allem nicht nur in Berlin.

IMG_1062

Zweitens.

Ich konnte mich schon auf der Launchveranstaltung nicht beherrschen und habe Seitenhiebe auf einen vorangegangenen Redner abgefeuert, der den Hauptvorteil offener Daten darin zu sehen schien, Geschaeftsmodelle zu entwickeln, um die von ihm zitierten 33 Millionen EUR Wert pro Jahr aus den Berliner Daten abzuschoepfen. Wir bei der datalove-Gruppe haben kein Geschaeftsmodell. Wir haben das bislang gemacht, weil es Spass macht, weil wir Probleme loesen und die Welt zu einem besseren Ort machen wollen.

Dass das in die klassische kapitalistische Logik nicht so recht passen will, ist bedauerlich. Den Ausweg sehe ich aber nicht darin, immer noch mehr Startup-Ideen anzukurbeln und aus der Herzenssache einen Brotjob zu machen zu versuchen – und ja, auch ich bin dem Google-Sponsoring fuer codefor.de gegenueber skeptisch, auch wenn ich gerade deutlich zu nuechtern bin, das so auszudruecken wie Stefan Schulz in der FAZ.

Ich fand es aufschlussreich, wie viele der anderen Workshopteilnehmer_innen mir am Wochenende zustimmten, dass der Traum doch eine 20–30h-Woche in einem schoenen Beruf waere, der fuer Wohnung, Essen und Mobilitaet sorgt – und die restliche Freizeit kann dann mit Weltverbesserung gefuellt werden.
Dass so etwas in der Praxis nur einer kleinen Elite vergoennt ist, ist mir schmerzlich bewusst. Aber wenigstens liesse man sich auf diese Tour weder so einfach zum “useful idiot”¹ machen, noch muesste man irgendwelchen Investorengeiern hinterherlaufen. Sondern koennte wirklich an dieser Weltverbesserung arbeiten.

IMG_1063

Weswegen. Drittens.

Ich gerne die Gruppe vorwiegend weisser, maennlicher Informatiker, die zumindest das Ulmer Lab momentan praegen, stark erweitern wuerde – mit der bestehenden Gruppe als Kristallisationspunkt, um den herum neue, interessante Dinge entstehen.

Das Laboradorio Para La Ciudad ist ein herrliches Beispiel dafuer, wie das aussehen kann: Im Vordergrund steht der Lebensraum Stadt und die Menschen, die ihn bewohnen, und sie sind es auch, die ihre alltaeglichen Probleme am besten kennen. Im Idealfall steht hinter allen Projekten auch das Ziel, die BewohnerInnen selbst zur Umsetzung der Loesungen zu ermaechtigen – Code Literacy als Auftrag, angefangen von SchuelerInnen bis ins dritte Lebensalter.

Das wuerde erstens helfen, dass nicht wie bisher alle Projekte auf den Schultern immer derselben wenigen Aktiven ruhen; zweitens deutlich vielfaeltigere Problemlagen erschliessen; und drittens einem deutlich groesseren und breiteren Bevoelkerungsquerschnitt den Zugang zu moeglichen Loesungen verschaffen.

Claus Arndt hat bei sich in Moers bereits ein Schulprojekt angestossen, dessen bisherige Ergebnisse sich spannend anhoeren – so etwas koennte beispielsweise auch in die Ulmer Drei-Generationen-Universitaet passen.

Dahinter wird in den seltensten Faellen ein Business Modell zu finden sein. Aber wenn’s zur Weltverbesserung reicht, waere mir das gut genug.

¹ ich stimme an der Stelle zum vermutlich ersten Mal in meinem Leben Evgeny Morozov zu 🙁

So bewirbt man sich auf eine Bachelorstelle

Frueher ist man halt in das Institut gegangen, das einem thematisch am naechsten liegt, und hat ein Thema vorgeschlagen — oder man hat sich eine Firma ausgesucht, die passt.

Wenn man aus der Businesskasperecke kommt und gaengige Klischees ueber WiWis bedienen moechte, macht man heute einfach ein Video. Ich bin mir noch nicht sicher, ob das nicht wieder ein Werbestunt fuer eine Firma ist, oder ob das tatsaechlich ernst gemeint war…

‪Direktphilippvaleriusgottfriedbacher / via