Rückblick auf den Left-Pad-Vorfall 8 Jahre später (2024)

• Der left-pad-Vorfall bleibt auch acht Jahre später ein prägendes Beispiel für Open-Source-Abhängigkeiten und Berechtigungen in der Paketverwaltung; Azer Koçulu erklärt seine damalige Entscheidung erneut
• Die Entscheidung zur Depublizierung entstand weniger aus Wut oder Gier als aus Selbstreflexion; der zentrale Hintergrund war, dass NPM seine eigenen Regeln gebrochen hatte
• Unter dem Druck von Kik Messenger habe NPM aus seiner Sicht andere Werte höher gestellt als die Open-Source-Community; diese Einschätzung führte zur Löschung aller Pakete
• Betroffen waren mehr als 350 Pakete, doch allein anhand von Nutzungsstatistiken und GitHub-Aktivität ließ sich die tatsächliche Tragweite schwer erkennen
• Nach Ausführung des NPM-Skripts brachen innerhalb von etwa 10 Minuten mehrere Projekte, darunter React; innerhalb weniger Stunden wurde das Modul wiederhergestellt und die Lage normalisierte sich

---

Die damalige Entscheidung im left-pad-Vorfall

• Seit dem left-pad-Vorfall sind 8 Jahre vergangen, und Azer Koçulu hielt es lange für besser, dieses Thema zu meiden, um sich auf seine eigentliche Arbeit zu konzentrieren
• Die Entscheidung zur Depublizierung fiel 2016 in einer Zeit, in der er die meisten Wochenenden an abgelegenen Orten ohne Empfang campte
  • Er beschreibt sie nicht als Ergebnis von Logik, Wut oder Gier, sondern als Entscheidung aus Selbstreflexion und aus dem Herzen, entstanden in der Natur
• Das Prinzip hinter seiner Einschätzung war einfach
  • Wenn NPM seine eigenen Regeln bricht und eines seiner Pakete entfernt, dann müsse NPM nach demselben Maßstab auch alle seine Pakete entfernen
• Wichtiger als die Regel selbst sei ihm der Geist hinter der Regel gewesen
  • Er räumt ein, dass es in anderen Kontexten gute Gründe geben könne, die Löschung eines Pakets ohne Zustimmung des Besitzers zu verlangen
  • In diesem Fall jedoch habe Kik Messenger mit Drohungen wie „we’ll bang on your door“ und „take down your accounts“ Macht über die auf NPM basierende Open-Source-Community ausgeübt
• Wer den Vorfall nur als „eine wütende Person protestierte gegen Unternehmensinteressen“ betrachtet, übersieht die E-Mail-Daten und die Timeline, die Situation des Standhaltens unter Druck und die Art, wie Entscheidungen in einem anderen Bewusstseinszustand in Bewegung geraten

Löschvorgang und Auswirkungen

• Aus Sicht von NPM sei die Löschung nicht plötzlich oder unerwartet gewesen
  • Zunächst bat er NPM darum, seine Module zu entfernen, und wartete auf eine Antwort
  • Da er keine Frist gesetzt hatte, hätte NPM seiner Ansicht nach die Gelegenheit gehabt, API und Tools anzupassen und den Übergang sanfter zu gestalten
  • Stattdessen stellte NPM ein Skript bereit, das alle Pakete auf einmal entfernte
• Seine Open-Source-Arbeit bestand überwiegend aus kleinen Paketen, die im Sinne der Unix-Philosophie jeweils genau eine Sache erledigten
  • Es waren mehr als 350 Pakete, alle optimiert und getestet
  • Nach außen wirkten sie wenig populär, NPM zeigte keine Nutzungsstatistiken, und bei 90 % gab es kaum GitHub-Aktivität
  • Aus Sicht normaler Nutzer war schwer abzuschätzen, welche Auswirkungen eine Depublizierung haben würde
• Nachdem er das von NPM bereitgestellte Skript ausgeführt hatte, war er einige Minuten abwesend; nach etwa 10 Minuten teilte ihm ein Freund mit, dass das Thema auf Twitter die Runde machte
  • Eines der mehr als 350 Pakete brachte React und mehrere andere Projekte zum Brechen
  • Anschließend schrieb er einen kurzen Blogbeitrag, übergab seine Open-Source-Arbeit und übertrug die Eigentümerschaft der GitHub-Repositories an Freiwillige
  • Innerhalb weniger Stunden wurde das Modul wiederhergestellt, und die Lage normalisierte sich
• Einige Monate später kündigte er seinen Job, verließ die USA dauerhaft und verbrachte ein Jahr in Morocco, Jordan, Türkiye und Indonesia
• left-pad war für ihn ein Moment wie Tod und Wiedergeburt, in dem ein Teil von ihm verschwand, der tief an Open Source hing, und etwas Neues an dessen Stelle trat; heute begeistert ihn neben dem Programmieren auch das Gründen und Führen von Unternehmen

[ndrgrd]

Es war ein Vorfall mit großer Wirkung, aber ich denke, dass – selbst ohne den Text des Paketautors zu lesen – die verflochtenen Unternehmen und Systeme stärker schuld waren als er.

[GN⁺]

Meinungen auf Hacker News

• Die Hälfte des Blogbeitrags habe ich nicht ganz verstanden, weil sich vieles so anfühlte, als fehle der Kontext, aber ich finde es gut, dass die betroffene Person hinter left-pad eine nachträgliche Analyse geschrieben hat.
  Allerdings klingt die Aussage seltsam, „NPM hätte prüfen müssen, ob mein Modul weit verbreitet genutzt wird, und überlegen müssen, wie man es ohne Bruch unveröffentlicht“. Dass das Design der Unpublish-Funktion von NPM fehlerhaft war, stimmt zwar, aber falls damit gemeint ist, dass man erwartet hätte, dass Mitarbeitende des Unternehmens jedes Mal alles manuell prüfen, wenn jemand etwas unveröffentlicht, wirkt das nicht vernünftig. NPM ist als Unternehmen weniger ein Kurator der Registry, sondern hostet sie eher wie einen öffentlichen Dienst.
  Trotzdem ist es schwer, dem Autor große Vorwürfe zu machen. Selbst wenn er den left-pad-Vorfall nicht ausgelöst hätte, hätte ihn früher oder später jemand anderes ausgelöst, und NPM hat das Problem mit einer besseren Unpublish-Policy behoben: https://docs.npmjs.com/policies/unpublish#packages-published...

  • Am 18. März 2016 schickte Isaac Z. Schlueter, CEO von npm, Inc., sowohl an Kik Interactive als auch an Koçulu eine E-Mail, in der er mitteilte, dass er die Eigentümerschaft des kik-Pakets manuell an Kik Interactive übertragen werde. Als Koçulu seine Enttäuschung ausdrückte und ankündigte, die Plattform zu verlassen, stellte Schlueter ihm den Befehl bereit, mit dem er die 273 von ihm registrierten Module löschen konnte.
    Koçulu führte diesen Befehl am 22. März 2016 aus und entfernte lediglich alle Pakete, die er veröffentlicht hatte; später schob NPM ihr eigenes Versagen dem Autor zu.
  • Den Kontext findet man unter https://en.wikipedia.org/wiki/Npm_left-pad_incident.
  • NPM kuratiert die Registry tatsächlich. Vor allem, indem es Verbraucher auf Schwachstellen hinweist und bösartige Pakete entfernt.
  • Früher gab es bei Sourceforge die Policy, dass man erst eine Genehmigung einholen musste, bevor man ein Projekt löschen konnte; nach left-pad verstand ich den Grund dafür.

• Als jemand, der JavaScript und sein Ökosystem meidet wie die Visual-Basic-Seuche des 21. Jahrhunderts, finde ich an dieser Geschichte am interessantesten, dass Koçulu sich eine Zeit lang von der Tech-Welt distanziert und großartige Wanderungen, Campingtrips und Trail-Erkundungen gemacht hat, aber sich auch nach 8 Jahren offenbar immer noch erklären muss.
  Technologie ist wie eine launische Muse. Wir Nerds fixieren uns auf sie und reiben uns in ihrem Dienst auf, aber sie ruft einen immer wieder zurück ins Licht.
  Als jemand, der beim Morris-Wurm vor Ort dabei war und wochenlang daran gearbeitet hat, seine Auswirkungen zu mindern, sehe ich ein grundlegendes Problem in unserer Fähigkeit, mit heutigen Werkzeugen Technologien zu schaffen, die die Welt verändern. Je weniger Mühe wir uns geben, die organisatorischen und ethischen Fehlleistungen der Technologie zu verstehen, desto schwerer fällt es der Technologie, in den Bereichen, in denen sie eingesetzt wird, produktiven Wandel zu erzeugen.
  Ich selbst werde wohl in etwa einem Monat, und nach ein paar hundert fehlgeschlagenen Kompilierungen, ein Sabbatical nehmen, und ich frage mich, wie der technische Raum, den ich für meine Bedürfnisse in anderem Maßstab und Kontext aufgebaut habe, aussehen wird, wenn ich in ein paar Jahren zurückkomme.
  Vielleicht sollte es bis zu einem gewissen Grad zum Standard werden, dass Techniker häufiger und ernsthafter Sabbaticals nehmen. So könnten wir den Kontext gewinnen, um die ethischen Dilemmata zu verstehen, die auf unseren technischen Fähigkeiten lasten.

• Ein kleiner Punkt, aber der Satz „Die meiste Open-Source-Arbeit folgte der Unix-Philosophie, und Pakete erledigten jeweils eine Sache“ ist vage.
  Als offensichtlichstes Beispiel würde normalerweise niemand libc als Verstoß gegen die Unix-Philosophie ansehen. Die Debatten drehen sich darum, ob ein Befehl oder Daemon zu viele Dinge tut oder nicht komponierbar ist. Ein aktuelles Paradebeispiel ist systemd.

  • Der left-pad-Aufruhr zeigte eher, dass die Granularität von NPM-Paketen so klein geworden war, dass der Overhead des Paketmanagements die Vorteile der Einfachheit einzelner Pakete überstieg.
  • Es gibt durchaus einige Leute, die libc als Verstoß gegen die Unix-Philosophie ansehen. Wenn du willst, kann ich das hiermit sagen.
    Eine moderne libc widerspricht der Unix-Philosophie ziemlich deutlich. Die traditionelle Unix-libc war viel einfacher, und viele Funktionen waren einfach Systemaufrufe. Teile der heutigen libc waren damals in separate Bibliotheken wie libm ausgelagert, und Dinge wie NSS oder komplexe Frameworks zur DNS-Auflösung gab es überhaupt nicht.
  • Auf der anderen Seite von „Tu eine Sache“ steht die Bedingung, dass man diese eine Sache vollständig tun muss.
  • Die Unix-Philosophie ist nutzlos oder vielleicht sogar schädlich. Weil „eine Sache“ nicht klar definiert ist, trägt sie in der Praxis nichts bei und erzeugt nur Debatten.
    Man könnte auch sagen, Eclipse mache „eine Sache, nämlich eine IDE-Plattform“, aber ich glaube nicht, dass Unix-Entwickler das so gemeint haben. Ebenso wenig dürften sie gemeint haben, man solle eine Bibliothek bauen, die nur aus einer einzigen 11-zeiligen Funktion besteht.
    Der eigentliche Rat sollte eher lauten: „Ein Programm oder eine Bibliothek sollte weder zu viel noch zu wenig tun wollen.“ Wie viel zu viel oder zu wenig ist, erfordert am Ende, wie viele Programmierleitlinien, Urteilsvermögen und Erfahrung.
  • Die Unix-Philosophie ist eine Philosophie dafür, wie man auf einem 16-Bit-Minicomputer mit einer maximalen Textsegmentgröße von 64 KiB eine leistungsfähige interaktive Programmierumgebung bekommt. Die libc auf heutigen Smartphones ist mit 1 MiB 16-mal so groß, also widersprechen mindestens 90 % der libc der Unix-Philosophie.
    Wenn man das Lions Book oder APUE liest und andererseits das pthreads-Handbuch oder die ANSI-C-Spezifikation von setlocale() und dann zu dem Schluss kommt, beide stünden für dieselbe Philosophie, dann ist das ungefähr so, als würde man Ayn Rand und Epikur als Vertreter derselben Philosophie ansehen; es bedeutet, dass man sich mit keiner der beiden Seiten ernsthaft befasst hat.

• Was von diesem Vorfall am stärksten hängen geblieben ist: Die JavaScript-Community war viel zu abhängig von Dependencies.
  Es wurde lediglich ein 11 Zeilen langes Code-Paket https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou... unpublished, und ich verstehe nicht, warum es dafür so viel Kritik gab. Im Text wird auch gesagt, dass nicht vollständig klar war, wie groß die dadurch ausgelöste Frustration sein würde.
  NPM hatte keine Nutzungsstatistiken, und auf GitHub gab es kaum Aktivität, sodass man als Nutzer die Auswirkungen des Unpublishings nicht einschätzen konnte. Die eigentliche Ursache sehe ich weniger darin, dass akoculu das Paket entfernt hat, sondern eher in übermäßiger Abhängigkeit von Dependencies, der npm-Policy und Build-Systemen, die Code nicht cachen oder vendorn.

• Azer Koçulu war nie eine Katastrophe für das NPM-Ökosystem. Niemand hat jemanden gezwungen, left-pad zu verwenden; dass es in so vielen Projekten landete, lag an chaotischen transitiven Dependencies.
  Jon Schlinkert dagegen scheint solche Micro-Libraries absichtlich zu erstellen und sie in das weit verbreitete, legitime Projekt handlebars-helpers einzubauen, ohne irgendeinen Willen zu zeigen, sie in die tatsächlich verwendenden Projekte zu integrieren. Wer sich ködern lassen will, nutzt handlebars-helpers; ansonsten sollte man diese Library eben nicht mehr verwenden.

  • Außerdem hat er lediglich ein von NPM selbst bereitgestelltes Skript ausgeführt. Die Situation mit den Micro-Packages war zwar absurd, aber Azer Koçulu hat nichts falsch gemacht.
    Das Problem war, dass NPM seine Pakete zwangsweise übernommen und ein Skript bereitgestellt hat, das offensichtlich gefährlich war, wenn man es ausführt. Dass Azer Koçulu überhaupt kritisiert wurde, ist lächerlich.
    Jon Schlinkert wirkt wie eine typische, marketinggetriebene Nervensäge, und persönlich finde ich, er sollte von NPM und GitHub ausgeschlossen werden.

• Die Versionshistorie des kik-Pakets ist seltsam. Es wurde vor neun Jahren durch ein sicherheitsbedingtes Platzhalter-Paket ersetzt: https://www.npmjs.com/package/kik?activeTab=versions

  • Die größte Ironie ist, dass das kik-Paket, das Kik so verzweifelt haben wollte, am Ende praktisch nichts war.
    Kik erwies sich als nachlässiges und ziemlich schäbiges Unternehmen. Es gab auch Kontroversen rund um Kryptowährungen, aber das, woran ich mich vor allem erinnere, ist, dass auf Kik Pornografie, insbesondere Material zur sexuellen Ausbeutung von Kindern, weit verbreitet war; das wird auch in dieser Folge von Darknet Diaries behandelt: https://darknetdiaries.com/episode/93/
    Aus dieser Perspektive war es ziemlich befriedigend, dass Azer Koçulu ihnen gesagt hat, sie sollten sich verziehen.
  • Am Ende scheint das alles also für praktisch nichts passiert zu sein.

• Dass left-pad überhaupt ein Paket war, ist schon ziemlich lustig. Man fragt sich, wie viele Bytes über CDNs, Proxys, Build-Pipelines usw. gelaufen sind, nur um eine winzige Utility-Funktion zu nutzen.
  Bestehende Lösungen zu verwenden ist gut, aber wenn man String-Padding braucht und denkt: „Dafür gibt es bestimmt ein Paket“, kann ich das nicht wirklich nachvollziehen.

  • Ein Teil der damaligen Diskussion ging in die Richtung, dass das ein dringend nötiger Weckruf für Webentwickler war, die sich endlos auf Micro-Packages wie left-pad verließen.
    Es gab auch eine Kultur, Pakete zu veröffentlichen, um Popularität und GitHub-Stars zu bekommen, sowie Entwickler, die darauf beharrten, dass man „das Rad neu erfinde“, wenn man etwas selbst implementiert, das sich per NPM installieren lässt. Auch heute arbeite ich noch viel mit Entwicklern, die selbst für einfache Funktionen Micro-Packages bevorzugen; für sie bedeutet das „weniger Wartung“.
  • Die ursprüngliche Implementierung des Pakets https://en.wikipedia.org/wiki/Npm_left-pad_incident sieht ebenfalls so aus, als hätte sie sich nicht wie gewünscht in O(n), sondern in O(n²) verhalten.
  • Ich frage mich, ob der qualitative Unterschied zwischen der Nutzung einer Utility-Funktion, die jemand im Projekt bereits geschrieben hat, und der Nutzung eines Pakets, das jemand im Ökosystem bereits veröffentlicht hat, wirklich so groß ist.
    Natürlich sind die beiden Dinge nicht identisch, aber sie scheinen mir auch nicht so weit auseinanderzuliegen, dass man nicht verstehen könnte, warum man sie mit ausreichend ausgereiften Tools ähnlich behandeln möchte.
  • Bei AI ist es heute vielleicht ähnlich. Wie viele Prompts ließen sich wohl durch eine einfache Websuche lösen?
    Es ist im Grunde nur Copy-and-paste mit einem zusätzlichen Schritt.
  • Es ist die Zurschaustellung maximaler Code-Wiederverwendung, und Copy-and-paste ist etwas für Verlierer.

• Es gibt die Passage: „Auf Seiten von NPM sah ich eine allgemeine Haltung der Herablassung gegenüber Entwicklern, die zu einer Reihe irrationaler Entscheidungen führte und am Ende alle Kosten mir zuschob.“ NPM scheint aus diesem Vorfall auch danach nicht besonders viel gelernt zu haben.

• Es war gut, dass dieser Vorfall passiert ist. Namensbesetzung ist ein echtes Problem, und in Zweifelsfällen sollte man die Option wählen, die Nutzer am wenigsten überrascht.
  Dass es keine Nutzungsstatistiken gab, war ebenfalls ein großes Problem, und dass man einfach unpublishen konnte, ebenso. Dass Infrastruktur von trivialem, zehn Zeilen langem Code abhängt, der von einer meinungsstarken Einzelperson erstellt wurde, war damals wie heute ein reales Problem. In dieser Situation lässt sich schwer sagen, dass wirklich jemand schuld ist, und niemand schuldet jemand anderem etwas, aber alle können daraus lernen.

• Aus der Perspektive von jemandem, der einige Top-10-npm-Pakete maintainiert, ergibt dieser Beitrag vollkommen Sinn
  Irgendwann hörte NPM auf, mit der Community zusammenzuarbeiten. Durch die Übernahme durch Microsoft wurde das zementiert, aber es war schon lange davor offensichtlich
  In der Art, wie npm betrieben wurde, gab es viele Risse; man arbeitete weder mit der Community noch mit dem Mainline-Node-Team gut zusammen, und das Drängen in Richtung kommerzieller Nachhaltigkeit wirkte sehr störend und zwanghaft. Mehrere Teammitglieder hatten zudem einen eher rauen Ruf
  Ich war auch einmal im Büro in Oakland; dort gab es einige ziemlich interessante Interaktionen, die nicht besonders positiv waren, aber die Details lasse ich weg
  Das damalige Unpublish-Loch war bekannt. Alle gaben left-pad die Schuld dafür, das Internet kaputtgemacht zu haben, aber kaum jemand fragte nach der Verantwortung von npm, das Ganze ernsthaft falsch gemanagt zu haben
  Wenn ich mich richtig erinnere, stellte npm das Paket gegen den Willen des Maintainers zwangsweise wieder her; im besten Fall zeigt das eine Entfremdung von den Menschen, denen sie angeblich dienten, im schlimmsten Fall war es auch rechtlich fragwürdig. Kurz danach kümmerte man sich auch nicht mehr besonders um Plattformmissbrauch; es gab Dinge wie den core.js-Werbe-Spam, und auch bei Standards, Kompatibilität usw. arbeitete man nicht richtig mit der Community zusammen
  Das npm@5-Release war eine Katastrophe. Die Einführung von Package-Lock-Dateien hätte kaum schlechter laufen können, und meiner Erinnerung nach gab es Druck, es passend zum nächsten Major-Release von Node.js herauszubringen. Es fühlte sich so an, als hätte das Node-Team nicht darauf gewartet, dass npm bereit war; angesichts der Tatsache, dass npm ein gewinnorientiertes Unternehmen war oder sich zumindest so verhielt, halte ich das eher für gut
  Die Reaktion gegenüber der Community in der Zeit endloser kritischer Bugs, die Haltung, die Druck machende Community zu beschämen, und diese scheinheilige Pose waren Belege dafür, dass npm nicht mehr als Vertreter freier und Open-Source-Software agierte. Ich erinnere mich nicht, ob left-pad davor oder danach war, aber in meinem Kopf ist es Teil eines langen Niedergangs des Ökosystems
  Heute sind npm-Pakete zum Meme kleiner Pakete für triviale Aufgaben geworden, und alle machen sich darüber lustig. Rückblickend war das vielleicht nicht optimal. Aber der Kontext ist wichtig. npm war der erste sehr leicht zugängliche Paketmanager für eine neu aufkommende, populäre Technologie, wurde fast vollständig von der Community verwaltet, hatte ein gutes Suchsystem und war eng mit GitHubs Geist des „Social Coding“ integriert
  Es existierte in der Frühzeit von Node, als es noch nicht einmal ES5 gab und man var und prototype verwendete. Es gab kaum etablierte Best Practices für JavaScript, es war vor der Übergabe von Node.js durch Joyent an die Community und auch vor dem Ausbruch aus dem langen Stillstand von Io.js-Fork und Node 0.10/0.12
  Niemand wusste, was der beste Weg war
  Ich verstehe den Autor vollkommen. Aus Sicherheitsperspektive bin ich wirklich dankbar, dass left-pad passiert ist. Auch wenn das nicht die Absicht des Autors war, hat es den Menschen sehr deutlich gezeigt, welche Risiken entstehen, wenn man sich auf Unternehmensinteressen verlässt, die von der Community getrennt sind, der sie angeblich dienen. Es hat viele Diskussionen über Supply-Chain-Sicherheit, Redundanz usw. angestoßen und die Branche langfristig ein wenig besser gemacht

  • Es war weder der erste Paketmanager für eine Programmiersprache, noch war die Dummheit eines derart kleinen Pakets eine neue Erkenntnis; viele hatten bereits darauf hingewiesen
    npm und JavaScript insgesamt sind vor allem Opfer des Hypes