Skip to main content

­čôľ Interview mit Tobias Zwick (OpenStreetMap)

Tobias Zwick ist der Autor von StreetComplete, einer Android App, mit der man ohne weitere Kenntnisse direkt etwas zur OpenStreetMap (OSM) beitragen kann. Dank der F├Ârderung durch den Prototype Fund (Runde 8) konnte er die Entwicklung 2020/2021 intensivieren. Mittlerweile wird die App von mehr als 22.000 Menschen genutzt, was sie nach Anzahl der Nutzer*innen zurzeit zum zweitbeliebtesten Editor f├╝r OpenStreetMap ├╝berhaupt macht. Auch erh├Ąlt das Projekt schon von Beginn an (seit 2017) zahlreiche Beitr├Ąge von Mitwirkenden.

Was, denkst du, zieht Leute in die OSM Community? Und warst du vorher selbst in der OSM Community aktiv?

Was den Zugang zu freier Information angeht, ist OpenStreetMap sicherlich ├Ąhnlich wie Wikipedia. Allein der Gedanke, hoffentlich hilfreiche Informationen f├╝r andere Menschen frei zur Verf├╝gung zu stellen, ist sicherlich f├╝r viele Motivation genug.

Mir macht es zudem Freude, die wei├čen Flecken auf der Karte zu f├╝llen. Insbesondere wenn man vor Ort ist, f├╝hlt man sich dabei regelrecht wie ein Entdecker. Gleichzeitig ist es motivierend, das Resultat meiner Arbeit hinterher direkt auf der Karte zu sehen - man hat etwas geschafft! Ich hatte dar├╝ber 2013 in meinem damaligen Reiseblog geschrieben.

Letztlich ist es auch ein netter und zumeist wenig fordernder Zeitvertreib, denn um zur OpenStreetMap beizutragen muss man kein*e Expert*in sein.

Wie bist du bei der Einbindung der Community vorgegangen? Reicht der Anschluss an OSM oder bist du selbst dar├╝ber hinaus aktiv geworden, um Menschen zu erreichen?

Vor-Ort Informationen beizutragen war schon immer recht aufw├Ąndig und ben├Âtigt technisches Verst├Ąndnis zu OSM. Die App ├Ąndert das. Das hei├čt, der initiale Erfolg der App, ├╝berhaupt wesentlich genutzt zu werden, ist mir dadurch, dass ich zuf├Ąllig den richtigen Riecher hatte, was dem ├ľkosystem fehlt, quasi in den Scho├č gefallen.

Dieses Projekt ist insofern speziell, als dass es nicht f├╝r sich allein steht oder stehen will, sondern sich in eine gr├Â├čere Community integriert. Potenzielle Nutzer*innen gibt es also viele. Das schr├Ąnkt jedoch ein, was man machen kann - und was nicht. Die App muss sich der bestehenden Community unterordnen, um akzeptiert zu werden und nicht auf den Pr├╝fstand zu kommen. Das musste ich von Anfang an beachten.

Damit die App und die Beitragenden in der Community nicht als Fremdk├Ârper aufgefasst werden, war es allein schon wichtig, die OpenStreetMap-Community von Anfang an einzubinden. Dazu geh├Ârt unter anderem eine Pr├Ąsenz in verschiedenen Community-Channels, eine ausf├╝hrliche Beschreibung der App im Wiki mit Unterseiten, damit auch f├╝r Leute, die die App nicht nutzen, nachvollziehbar bleibt, was mit dieser App getan wird.

Die Einbindung in die Entwicklung, die meiner Erfahrung nach am besten und als erstes funktioniert, ist Crowdsourcing der ├ťbersetzung. Dank einem dezenten Hinweis auf der Projektseite und der verlinkten Wikiseite wurde die App bisher in 46 Sprachen ├╝bersetzt - zu 100 % von Beitragenden.

Letztlich hat die App aber auch neue Zielgruppen erreicht, die bisher noch wenig mit OpenStreetMap am Hut hatten: Leute, denen das Beitragen bisher zu technisch oder zu aufw├Ąndig erschien oder auch Leute, die sonst eventuell eher Pokemon Go oder Geocaching als Zeitvertreib betrieben h├Ątten.

Diese neuen Gruppen zuk├╝nftig (mehr) in die OpenStreetMap-Community im Ganzen zu integrieren, w├╝rde sowohl die OpenStreetMap Community bereichern als auch die Akzeptanz f├╝r die App und ihren Anwendungsfall weiter steigern.

Hast du Tipps f├╝r Leute, die mit ihrem Projekt eine Community erreichen wollen?

Ja, habe ich. Aber ein Disclaimer: Was f├╝r mich funktioniert hat, funktioniert vielleicht nicht f├╝r Andere. Also, Ratschl├Ąge immer mit Vorsicht genie├čen!

Wie schon erw├Ąhnt ist StreetComplete etwas speziell, weil es sich in eine gr├Â├čere Community integriert. Dadurch wurden gleich zu Anfang viele Leute erreicht. Sich einer bestehenden Community anzuschlie├čen oder daraus hervorzugehen ist m├Âglicherweise auch f├╝r andere Projekte ein hilfreicher Ansatz.

Die erste und gr├Â├čte H├╝rde ist nat├╝rlich aber erst einmal, ein Produkt zu entwickeln, das auch wirklich genutzt wird. Eine Idee kann ein Hit oder ein Miss sein. Generell hat ein Projekt, das ein bestehendes erfolgreiches Produkt erweitert oder erg├Ąnzt, nat├╝rlich bessere Chancen, genutzt zu werden.

Daher - ganz im Sinne des Prototype Funds - ist es wichtig zuerst ein Minimum-Viable-Produkt (MVP) zu erstellen und dieses publik zu machen. Nur wenn das auf positives Feedback st├Â├čt, lohnt es sich, die Idee weiterzuverfolgen. Wichtig ist, dass der Umfang (Scope) des Produkts ganz klar auf das Minimum abgegrenzt ist und in sich geschlossen ist. Ein Produkt, das unfertig wirkt, will niemand benutzen.

Deswegen dokumentiere ├Âffentlich, was Ziel des Projekts ist, was zum Scope geh├Ârt - und was nicht, sodass potenzielle Beitragende wissen, woran sie sind (Beispiel in StreetComplete). Was ist erw├╝nscht und was nicht? Eine ├Âffentliche Dokumentation hilft auch, selbst in den selbst gesetzten Schranken zu bleiben, also Feature-Creep und mehrere gleichzeitige Baustellen zu vermeiden. Meiner Erfahrung nach ist es am besten, wenn das Projekt immer in sich geschlossen und "fertig" wirkt. Baustellen wirken auf Dauer abschreckend f├╝r Nutzende und auch Mitwirkende.

Wenn es konkrete Dinge gibt, die Beitragende tun k├Ânnen um dem Projekt zu helfen, dann schreibe auch das auf. Die Energie von (potenziellen) Beitragenden muss gelenkt werden: Sie m├╝ssen wissen, was sie konkret tun k├Ânnen (als Beispiel CONTRIBUTING.md in StreetComplete). Sonst ist die H├╝rde viel zu hoch.

Wenn es in deinem Projekt einen ├Âffentlichen Issue-Tracker (z. B. GitHub) gibt, k├Ânntest du auch Labels einf├╝hren, mit denen du bestimmte Tickets markieren kannst, z. B. "needs PR", "help wanted", "good first contribution" usw.

Das ist alles, was mir an konkreten Tipps einf├Ąllt. Es gibt noch einige weitere Richtlinien, an die ich mich halte, wie zum Beispiel leicht lesbaren aber modernen und gut dokumentierten Code zu schreiben, damit m├Âgliche Beitragende einen einfacheren Einstieg haben. Aber ob das nun wirklich entscheidend ist, wei├č ich auch nicht.

Die oben genannte Dokumentation auf der anderen Seite hat garantiert einen Unterschied gemacht (am Anfang des Projektes fehlte diese n├Ąmlich und das hat sich bemerkbar gemacht). Es ist eben wichtig, dass die Entscheidungen, die man als Leiter in einem ├Âffentlichen Projekt f├Ąllt, transparent und nachvollziehbar bleiben. Man kann nicht allen alles recht machen, aber versuchen zu erreichen, dass sich niemand verprellt f├╝hlt und alle, die etwas beitragen, ein gutes Gef├╝hl dabei haben.

Ist die Einbindung in die Community ausreichend, um StreetComplete langfristig zu halten oder braucht es noch mehr Ressourcen?

Tja, das langfristige Warten von reinen FOSS-Projekten ohne Gesch├Ąftsmodell ist nat├╝rlich immer so eine Sache. Es hilft, bei der Entwicklung darauf zu achten, dass das Projekt m├Âglichst wartungsfrei durch Automatisierung und Nutzung von stabilen Frameworks ├╝berleben kann. Wenn das Projekt genug genutzt wird, finden sich mit der Zeit ggf. auch Mitstreiter*innen, die dabei helfen, das Projekt aktuell zu halten.

Letzteres ist bei StreetComplete der Fall, allerdings n├╝tzt das eher der Erweiterung des Projektes um weitere Features als der Wartung an sich.

Au├čerdem sind sowohl OpenStreetMap als auch Android als ├ľkosystem sehr instabile Plattformen, sodass der Wartungsaufwand sehr hoch ausf├Ąllt. Instabil ist Android in dem Sinne, dass sich u. a. die empfohlenen Frameworks ├Ąndern, sie teilweise ganz und gar als veraltet markiert werden, weil sich das Verhalten von Android von Version zu Version ├Ąndert und weil die App den sich stetig ├Ąndernden (und immer strenger) ausgelegten Richtlinien des Play Stores entsprechen muss.

OpenStreetMap ist au├čerdem instabil in dem Sinne, dass der Konsens dar├╝ber, wie etwas richtig einzutragen ist, sich st├Ąndig wandelt und erweitert, weswegen die Logik entsprechend st├Ąndig angepasst oder zumindest in Diskussionen verteidigt werden muss.

Dennoch w├╝rde ich sagen, rein die Wartung der App ist dank der vielen Spenden die ich ├╝ber Liberapay, Patreon und Github Sponsors bekomme, gesichert, selbst wenn ich keine Freizeit mehr in dieses Projekt stecken kann.