Dependencies und Open-Source-Projekte

Lessons Learned aus dem npm-Dilemma

Melanie Feldmann

© Shutterstock / tomertu

Letzte Woche zog der Entwickler Azer Koçulu all seine Module aus dem Open Source Packet Manager npm zurück. Mit dabei das weit verbreitete left-pad-Modul. Daraufhin brachen reihenweise JavaScript-Anwendungen zusammen. Was die Community und npm daraus gelernt haben.

npm hat Konsequenzen aus dem Dilemma gezogen und seine Unpublish Policy geändert. Jetzt ist es Entwicklern nur noch möglich Pakete zurückzuziehen, die jünger als 24 Stunden sind. Das Paket kann unter demselben Namen erneut veröffentlicht werden, zum Beispiel damit der Entwickler einen Bug beheben oder eine Sicherheitslücke schließen kann. Wenn der Code länger als 24 Stunden online war, muss der Entwickler den npm-Support kontaktieren. Dieser prüft dann, ob das Zurückziehen des eigenen Pakets andere Pakete betrifft. Sollten Dependencies bestehen wird das Paket nicht gelöscht. Der Entwickler hat dann entweder die Möglichkeit seinen Code jemand anderem zu übertragen oder auf die Entwickler der anderen Pakete zuzugehen, und sie darum zu bitten ihre Dependencies zu ändern. npm spricht davon, dass die geänderte Policy lediglich ein erste Schritt sei. Das Ziel: „balancing the rights of individual publishers with npm’s responsibility to maintain the social cohesion of the open source community“. Auf GitHub diskutiert npm mit der Community über die Änderungen.

Keine Reue, aber was gelernt

Azer Koçulu sagte The Register, dass er sein Handeln nicht bereue: „Regrets? Of course not. In the long term, the community will benefit from this experience a lot.“ Womit er nicht ganz Unrecht hat. Sowohl die Diskussion rund um das Thema, wer über Open-Source-Code bestimmen darf, als auch das Thema des sorgfältigen Einsatzes von Dependencies haben von dem Vorfall profitiert. Es ist ein komplexes Thema das Recht des Einzelnen am eigenen Code damit abzuwägen, dass sich eine Gruppe auf eben diesen Code verlässt. Während auf der einen Seite viele Entwickler Koçulu darin unterstützen, dass er jederzeit das Recht hatte seinen Code zurückzuziehen, gibt es ebenso viele Unterstützer auf Seiten von npm, die Schadensregulierung und den Anspruch der Gruppe auf den funktionierenden Code befürworten. Hier gilt es einen guten Mittelweg zu finden, was npm augenscheinlich versucht.

Faulheit siegt

Betroffene JavaScript-Entwickler durften sich aber auch einiges anhören. Für manche Kollegen war es unverständlich, dass man für elf Zeilen Code eine Dependency aufbaut, die tendenziell unsicherer ist als eben in fünf Minuten jene elf Zeilen selbst zu schreiben. Viele machen gerade im ebenfalls betroffenen Node.js-Universum einen Trend hin zu Mini-Modulen aus. Diese Module enthalten keine komplizierten 3D Engines oder Verschlüsselungsalgorithmen, sondern recht einfachen Code. The Register zeigt in einem Artikel zum Thema schöne Beispiele für recht unsinnige, weil einfache npm-Module.

Und wer den Schaden hat braucht für den Spott nicht zu sorgen. Vor allem die Java-Community konnte sich die Schadenfreude kaum verkneifen.

Aufmacherbild: stopping domino effect von Shutterstock / Urheberrecht: tomertu

Verwandte Themen:

Geschrieben von
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: