Wer schon immer mal wissen wollte, wo genau sich denn welche Baustellen in Aachen befinden, der konnte bislang nur die lange Liste der Stadt Aachen durchforsten. Doch viel besser wäre es doch sicher, das mal auf einer Karte anzuschauen.

Der Import der Baustellen

Das geht jetzt auch, denn wir haben uns die Liste mal genommen und mit einer Kartenanwendung versehen, die unter baustellen.offenes-aachen.de zu finden ist. Grundlage ist die oben genannte Liste, die wir leider bislang noch per Hand abtippen müssen. Das soll sich zwar irgendwann einmal ändern, wenn die neue Datenbank-Anwendung für diese Baustellen eingeführt wird, die wohl auch einen Export haben soll. Da uns das aber irgendwie zu lange dauert, haben wir das einfach schonmal selbst umgesetzt.

Die Anwendung selbst bietet im Moment nur die Basisfunktionen, man kann aber zumindest zwischen Baustellen unterscheiden, die nur auf Gehwegen stattfinden (wie Glasfaser-Ausbau) oder aber auch auf der Fahrbahn. In Kürze wird es zudem noch einen Export der Daten geben und wir arbeiten an einem Editor, um die Baustellen noch genauer einzeichnen zu können (soweit dies aus der Baustellen-Liste ersichtlich ist). Und auch eine mobile Version ist in Arbeit (vielleicht machen wir auch eine App draus).

Nicht alle Baustellen sind im Moment übrigens richtig platziert. Dies werden wir mit dem Editor dann beheben. Die Automatisierung hat bei den vorhandenen Daten leider ihre Grenzen.

Wer den Source-Code einsehen will, der kann auch dies tun, indem er einfach diesem Link folgt. Dort ist auch eine CSV-Datei der aktuellen Daten mit Stand 22.4.2013 zu finden.

Und mit diesem Blogpost ist dann auch unser neues Blog eröffnet, dass als Fokus hoffentlich auch viel Technik haben wird 🙂 (und alle weiteren Einstellung, Plugins usw. kommen dann nach der re:publica dran).

Website: baustellen.offenes-aachen.de

Update: Inzwischen hat die Stadt Aachen eine offizielle Schnittstelle implementiert und wir haben die Anwendung aktualisiert, so dass wir diese Schnittstelle nutzen. Kein Abtippen mehr und damit eine bessere Datenqualität sind die Folge. Außerdem ein gutes Beispiel, was man machen kann, wenn öffentliche Institutionen Ihre Daten offenlegen.

Dienstag war kein guter Tag für die JavaScript-Welt. Denn so manch Entwickler staunte nicht schlecht, als sich sein JavaScript-Projekt nicht mehr zusammenbauen ließ. Grund dafür: Eine kleine JavaScript-Bibliothek namens left-pad wurde vom Autor aus dem Node Package Manager gelöscht.

Was ist NPM?

Der Node Package Manager (NPM) wurde einst für die JavaScript-Umgebung node.js ins Leben gerufen und ist ein System, bei dem JavaScript-Entwickler ihre Open Source-Bibliotheken registrieren können. Einmal auf NPM, können dann andere Entwickler diese Bibliotheken relativ einfach für eigene Projekte nutzen. Und weil NPM so praktisch ist, wird es inzwischen nicht nur für node.js-Projekte auf dem Server, sondern auch für die JavaScript-Entwicklung im Browser eingesetzt.

Eines dieser Pakete auf NPM war das Paket left-pad, was im Prinzip nicht mehr ist als ein 11-zeiliger Code-Schnipsel ist. Ein Schnipsel allerdings, den scheinbar viele Programmierer brauchten und deshalb in ihrer eigenen Bibliotheken via NPM eingebunden haben, die dann wieder in größeren Anwendungen genutzt werden. So kommen tausende von Projekten zustande, die direkt oder indirekt von left-pad abhängen.

Als nun left-pad Anfang der Woche plötzlich vom Autor aus NPM gelöscht wurde, brach daher das Chaos in der JavaScript-Community aus.

Am Anfang war ein Markenstreit

Doch wie kam es eigentlich dazu? Der Grund ist ein Streit zwischen dem Messenger Kik und Azer Koçulu, dem Autor von left-pad und einem Paket namens „kik„. Letzteres, so befand der Messenger Kik, könnte Verwirrung auslösen, da sie selbst auch planten, eine Open Source-Bibliothek zu veröffentlichen. Sie schrieben daher an Azer und baten ihn, auch aufgrund von Trademark-Regelungen, sein Paket umzubenennen. Doch Azer Koçulu verneinte.

Kik wandte sich dann an NPM Inc., die Firma, die das NPM-Repository hostet. Wie NPM Inc.-Mitgründer Isaac Z. Schlueter hier erklärt, haben sie daraufhin ihre Package Name Dispute Policy bemüht und auf dieser Grundlage entschieden, den Paketnamen dem Messenger zukommen zu lassen.

Azer Koçulu wollte das nicht auf sich sitzen lassen und hat all seine 273 Pakete von NPM entfernt, weil er meinte, dass NPM privates Land sei und er ja Open Source mache, um die „Macht dem Volke“ zu geben und eben nicht Firmen wie NPM Inc. oder Kik.

Das Resultat dieser Entscheidung war, wie gesagt, verheerend und das Problem wurde erst durch die Wiederveröffentlichung von left-pad durch einen anderen Autor gelöst (denn wenn ein Paket entfernt wird, wird der Name auch wieder frei).

Hat NPM Inc. richtig gehandelt?

In seinem Blogpost stellt Isaac nochmal seine Sicht der Dinge klar, nämlich dass

• es bei der Entscheidung nicht um das Markenrecht ging, sondern rein nach der Dispute Resolution gehandelt wurde.
• NPM das Paket left-pad nicht gestohlen habe, da die Lizenz des Pakets ausdrücklich eine Wiederveröffentlichung erlaubt
• sowohl Kik ihre neue Bibliothek hätten veröffentlichen können als auch Benutzer des alten kik-Pakets keine Beeinträchtigungen erfahren hätten, wenn Azer nichts getan hätte

Im Endeffekt besagt die Dispute Policy aber nur, dass NPM Inc. selbst eine Entscheidung fällt, wenn beide Parteien nicht innerhalb von ca. 4 Wochen zu einer eigenen Einigung kommen. Nach welchen Kriterien dann aber genau entschieden wird, ist dort leider nicht festgehalten. Das könnte man vielleicht noch verbessern oder zumindest im Nachhinein dokumentieren.

Eines aber lernt NPM aus diesem Debakel: Die Möglichkeit, einfach all seine Pakete aus dem Index zu nehmen, ist eine schlechte Idee. Hier wird also wahrscheinlich demnächst nachgebessert werden.

Meines Erachtens gibt es aber noch ein weiteres Problem: Man kann ein neues Paket unter gleichem Namen hochladen, wenn der Autor das alte Paket gelöscht hat. Wenn es sich bei dem neuen Paket um Malware handelt und ein Entwickler nicht aufpasst, hat man plötzlich eine Sicherheitslücke im eigenen Projekt. Auch hier sollte man vielleicht noch nachbessern.

Was die Aufstellung von NPM als private Firma betrifft, kann man ebenfalls Bauchschmerzen haben. Das Python-Pendant PyPI z.B. wird von der Python Software Foundation betrieben (war vorher aber auch in privater Hand, wenn ich mich recht erinnere). Das gibt der Community zumindest theoretisch mehr Mitspracherecht.

Hat Kik richtig gehandelt?

Trademark ist natürlich Trademark und auch wenn ich kein Anwalt bin, so weiß ich doch, dass man ein Trademark auch verteidigen muss. Denn sonst verliert man die Marke. So kann man das auch in diesem Fall sehen und Mike Roberts von Kik schreibt das ja auch genau so in einer Mail an Azer. Ob die Anfrage allerdings jetzt so freundlich formuliert ist, wie er meint, sei mal dahingestellt:

We don’t mean to be a dick about it, but it’s a registered Trademark in most countries around the world and if you actually release an open source project called kik, our trademark lawyers are going to be banging on your door and taking down your accounts and stuff like that — and we’d have no choice but to do all that because you have to enforce trademarks or you lose them.

Das hätte man sicher auch anders formulieren können, wobei aber auch Azer nicht gerade kompromissbereit war:

Sorry, I’m building an open source project with that name.

Mit ein bisschen mehr Wohlwollen von beiden Seiten hätte man die Situation sicherlich verhindern können.

Eine Frage, die sich mir allerdings noch stellt (bin ja kein Anwalt): Wie problematisch ist es für eine Marke, wenn eine Open Source-Bibliothek den gleichen Namen trägt? Schliesslich gibt es ja auch Bibliotheken, die z.B. die Twitter-API nutzen und „twitter“ heissen, aber nicht von Twitter veröffentlicht worden sind. Oder wie in diesem Fall, wo sich „kik“ ja mehr an „Kickstarter“ anlehnt und etwas ganz anderes macht als einen Messenger-Dienst zu implementieren.

Was lernt die JavaScript-Community daraus?

Interessanterweise führt dieser Vorfall zu viel weitreichenderen Diskussionen als nur NPM in der JavaScript-Welt. Da geht es dann nämlich plötzlich um das Paket left-pad selbst, das ja aus nur 11 Zeilen besteht. So fragt sich David Haney, wieso dazu überhaupt eine Bibliothek genutzt werden muss. Man hätte das ja als Entwickler auch schnell selbst implementieren können. Er analysierte daraufhin auch noch weitere Projekte auf NPM und fand solche, die aus nur 4 Zeilen oder gar nur 1 Zeile Code bestehen. Der 1-Zeiler hat dabei fast 1 Million Downloads pro Tag.

Er fragt daher, ob man denn verlernt habe zu programmieren oder ob man es als Job eines Entwicklers ansehe, die kleinstmögliche Anzahl von Code-Zeilen selbst geschrieben zu haben. Eine wilde Diskussion auf Hacker News ist die Folge.

Go- und JavaScript-Programmierer Felix Geisendörfer sieht allerdings nicht die Entwickler selbst als die Schuldigen an, sondern die Entscheidung von node.js, eine möglichst kleine Standard-Library haben zu wollen. Unix-Ansatz halt. Wäre ein left-pad standardmäßig dabei, wäre ja eine solche Abhängigkeit gar nicht nötig.

Und auch ECMAScript (sozusagen der offizielle Name von JavaScript) sei Teil des Problems, denn die kommen ja mit überhaupt keiner Standard-Library daher (stimmt nicht so ganz, aber es ist wenig und fest in die Sprache integriert). Historisch bedingt ist das auch kein Wunder, war sie doch zunächst nur als kleine Browser-Sprache konzipiert. Hätte man aber natürlich inzwischen ändern können.

Oh, and perhaps it would be even better if this challenge was picked up our #ecma overloards. They're the ultimative origin of no stdlib.

— Felix Geisendörfer (@felixge) March 24, 2016

Laut Antworten auf seinen Tweet sind aber sowohl node.js als auch ECMAScript dabei, selbst ein leftpad nativ zu implementieren. Insofern würde zumindest diese Abhängigkeit in Zukunft nicht mehr nötig sein.

Beim aktuellen Fall hätte dies geholfen, aber es gibt bestimmt noch weitere populäre Pakete, die vielleicht nicht ganz so klein sind, aber bei Löschung eine ähnliche Auswirkung hätten.

Das aktuelle Problem ist gelöst, aber die Diskussionen halten noch an. Und dass ein eher kleiner Markenstreit solche Auswirkung hat, hätte ich auch nicht gedacht. Aber manchmal braucht es vielleicht ein Gewitter, damit man danach klarer sehen kann.