Left-Pad (2024)

• Der left-pad-Vorfall ist ein repräsentativer Fall, der den Konflikt von Regeln und Werten zwischen der Open-Source-Community, NPM und Unternehmen zeigt.
• Die Entscheidung, Pakete zu löschen, beruhte nicht auf Logik, Wut oder Gier, sondern auf Aufrichtigkeit und inneren Prinzipien.
• In einer Situation, in der NPM seine eigenen Regeln brach, indem es den Forderungen von Kik Messenger nachgab, entschied sich der Autor, alle seine Pakete zu löschen.
• Nach dem Vorfall veränderte sich die Leidenschaft für Open Source, und das Interesse verlagerte sich auf neue Bereiche wie Business, Marketing und Teamführung.
• Der left-pad-Vorfall wurde zum Anlass für Entwickler und die Startup-Branche, über das Wesen von Open Source und die Komplexität von Entscheidungen neu nachzudenken.

---

Hintergrund des Vorfalls und die Entscheidung

• Acht Jahre nach dem left-pad-Vorfall teilt der Autor persönliche Erfahrungen und Gedanken.
• Zum Zeitpunkt des Vorfalls verbrachte er die meiste Zeit in der Natur ohne Netzempfang, um sich selbst zu reflektieren, und auch die Entscheidung zur Paketlöschung entstand in diesem Prozess.
• Diese Entscheidung beruhte nicht auf rationalem Urteil, Wut oder Gier, sondern auf einem inneren Prinzip: „Wenn NPM seine eigenen Regeln bricht, dann sollten auch all meine Pakete gelöscht werden.“
• Es ging dabei weniger um einen strengen „Regel-Fetischismus“ als um eine Haltung, die den Geist der Regeln selbst höher gewichtet.
• In einer Situation, in der Unternehmen wie Kik Messenger die Open-Source-Community bedrohten und ihre Macht ausübten, ignorierte NPM die selbst gesetzten Regeln und stellte Unternehmensinteressen über alles.

Die Konfliktstruktur zwischen NPM und Community

• Der Autor hatte keine Angst vor den Drohungen von Kik, aber NPM hatte Angst davor, Kik als Kunden zu verlieren.
• Den Vorfall einfach als „ein wütender Mann widersetzte sich einem Großkonzern“ zu deuten, ist eine vereinfachende Sichtweise, die Kontext, zeitlichen Verlauf und das Gewicht der Entscheidung außer Acht lässt.
• Obwohl die NPM-Seite nicht von etwas Plötzlichem oder Unerwartetem überrascht wurde, zeigte sie insgesamt eine herablassende Haltung gegenüber Entwicklern und schob durch eine Reihe widersprüchlicher Entscheidungen die gesamte Verantwortung auf den Autor.

Paketstruktur und Auswirkungen

• Die Open-Source-Arbeit des Autors war größtenteils nach der Unix-Philosophie in kleine Aufgaben aufgeteilt und bestand aus mehr als 350 Paketen.
• Oberflächlich betrachtet gab es kaum sichtbare Nutzungsspuren, doch weil NPM keine Nutzungsstatistiken veröffentlichte, war das tatsächliche Ausmaß der Auswirkungen nicht erkennbar.
• Nutzer hatten keine Möglichkeit, die realen Folgen der Paketlöschung zu kennen, und auch NPM unternahm keine Anstrengungen, die Auswirkungen zu untersuchen oder Probleme durch wahllose Löschungen zu verhindern.

Veränderungen und Wachstum nach 8 Jahren

• Einige Monate nach dem left-pad-Vorfall kündigte der Autor seinen Hauptberuf, verließ die USA und suchte in neuen Umgebungen wie Marokko, Jordanien, der Türkei und Indonesien seinen eigenen Weg.
• Er erlebte einen todesähnlichen Moment, in dem die Leidenschaft für Open Source abriss, und einen Moment der Wiedergeburt mit neuen Interessen.
• Heute widmet er sich Business, Marketing sowie der Führung von Unternehmen und Teams in verschiedenen Bereichen mit derselben Leidenschaft wie dem Programmieren.
• Mit der Botschaft, dass das Leben weitergeht, bleibt der left-pad-Vorfall ein Anlass, freie Entscheidungen, die Werte der Community und die Komplexität von Entscheidungsprozessen erneut zu reflektieren.

[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⁺]

Hacker-News-Kommentare

• Ehrlich gesagt habe ich bei der Hälfte dieses Blogposts das Gefühl, nicht wirklich zu verstehen, worum es geht, als würde mir irgendein Kontext fehlen, aber ich finde es gut, dass der „left pad guy“ die Ereignisse aufarbeitet.
  Allerdings wirkt die folgende Behauptung etwas seltsam.

  Ich verstehe allerdings immer noch nicht, warum NPM nicht untersucht hat, wie häufig meine Module genutzt wurden, und sich keinen Weg überlegt hat, das Unpublishing so zu handhaben, dass nichts kaputtgeht
  Natürlich war NPMs Unpublish-Mechanismus schlecht designt, aber was der Autor sagt, klingt für mich so, als hätte er erwartet, dass bei jedem Unpublish jemand manuell prüft, ob alles in Ordnung ist. Diese Erwartung erscheint mir nicht vernünftig. NPM ist aus meiner Sicht keine Organisation, die das Register kuratiert, sondern ein Anbieter eines öffentlichen Dienstes.
  Trotzdem fällt es mir schwer, dem Autor die Schuld zu geben; wenn er den „left-pad incident“ nicht ausgelöst hätte, hätte es vermutlich bald jemand anders getan. NPM hat das Problem behoben und inzwischen auch bessere Unpublish-Regeln eingeführt.
  Zur Information: NPMs neue Unpublish-Richtlinie

  • Dass du sagst, du verstehst die Hälfte dieses Blogposts nicht
    liegt vermutlich daran, dass du al-Ghazali noch nicht gelesen hast.
    (Das ist der arroganteste und egozentrischste Teil des Textes.)

  • Als Hintergrund dazu eignet sich der Wikipedia-Eintrag zum Npm-left-pad-Vorfall

  • Am 18. März 2016 schickte npm-CEO Isaac Z. Schlueter sowohl an Kik Interactive als auch an Koçulu eine E-Mail mit der Mitteilung, dass das Eigentum am Paket kik manuell an Kik Interactive übertragen werde.
    Nachdem Koçulu seine Enttäuschung über die Entscheidung von npm ausgedrückt und gesagt hatte, dass er nicht weiter auf der Plattform mitwirken wolle, gab Schlueter ihm einen Befehl, mit dem er alle 273 von ihm registrierten Module löschen konnte.
    Koçulu führte diesen Befehl am 22. März aus und löschte damit alle von ihm veröffentlichten Pakete.
    Der Autor hat also lediglich einen Befehl ausgeführt, den NPM ihm selbst direkt genannt hatte, und danach hat NPM ihm die gesamte Verantwortung zugeschoben.

  • Die Firma NPM kuratiert das NPM-Register nicht
    Tatsächlich tut sie das doch, etwa indem sie Meldungen über Sicherheitslücken entgegennimmt und Nutzer informiert oder bösartige Pakete entfernt.

  • Als ich früher Sourceforge genutzt habe, gab es eine Richtlinie, nach der vor dem Löschen eines Projekts ausdrücklich um Erlaubnis gebeten werden musste.
    Nach left-pad habe ich sehr gut verstanden, warum.

• Eine eher kleine Anmerkung:

  Meine Open-Source-Projekte folgten größtenteils der Unix-Philosophie und waren so gestaltet, dass Pakete jeweils nur eine Sache auf einmal tun
  Niemand behauptet, dass libc gegen die Unix-Philosophie verstößt. Debatten entstehen meist dann, wenn Befehle oder Daemons zu viele Funktionen haben — systemd ist das typische Beispiel — oder wenn es an Kombinierbarkeit fehlt.

  • Für mich hat der left-pad-Vorfall gezeigt, dass die Granularität von NPM-Paketen zu weit ins Extrem getrieben wurde, sodass der Overhead die Vorteile der Vereinfachung deutlich überstieg.

  • Niemand sagt, dass libc gegen die Unix-Philosophie verstößt
    Im Gegenteil, viele Leute haben genau das vorgeschlagen, und ich selbst halte das ebenfalls für richtig.
    Moderne libc hat mit der traditionellen Unix-Philosophie überhaupt nichts mehr zu tun.
    Früher war libc einfacher, viele Funktionen waren in separate Bibliotheken wie libm ausgelagert, und komplexe Dinge wie DNS gab es dort nicht.

  • Was im Widerspruch zu „do one thing“ steht, ist, dass man „eine Sache vollständig erledigen“ muss.
  • Die Unix-Philosophie war eine Leitlinie dafür, auf 16-Bit-Minicomputern eine leistungsfähige interaktive Programmierumgebung zu schaffen.
    Die libc, die ich heute auf meinem Handy nutze, ist 1 MiB groß, also sechzehnmal größer als die eines klassischen Unix.
    Daraus folgt, dass mindestens 90 % von libc gegen die Unix-Philosophie verstoßen.
    Wenn man das Lions Book oder APUE gelesen hat und sich dann das pthreads-Handbuch oder die ANSI-C-Spezifikation von setlocale() anschaut, sieht man sofort, dass dort eine völlig andere Philosophie dahintersteht.
    Wenn man glaubt, das sei dieselbe Philosophie, dann zeigt das nur, dass man mit keiner von beiden wirklich ernsthaft etwas anfangen kann.
  • Die „Unix-Philosophie“ ist eine nutzlose Philosophie, vielleicht sogar eine schädliche.
    Denn die Bedeutung von „one thing“ ist unklar, hilft praktisch überhaupt nicht und erzeugt in der Realität nur Streit.
    Man könnte auch sagen, Eclipse mache nur „eine Sache“, nämlich eine IDE zu sein, aber das ist offensichtlich nicht das, was Unix-Entwickler damit meinten.
    Es bedeutet ebenso wenig, dass man Bibliotheken mit 11-zeiligen Funktionen schreiben soll.
    Der eigentliche Rat sollte eher lauten: „Programme oder Bibliotheken sollten weder zu viel noch zu wenig tun.“
    Wo genau zu viel beginnt und zu wenig aufhört, ist letztlich eine Frage von Erfahrung und Fingerspitzengefühl.

• Danke an akoculu, dass er diesen Text geschrieben hat.
  Für mich ist dieser Vorfall ein klares Beispiel für die JavaScript-Community, also für ein Ökosystem, das sich zu stark auf Abhängigkeiten stützt.
  Ich verstehe nicht, warum so viele Leute ihm die Schuld geben.
  Er hat lediglich ein Paket mit 11 Zeilen Code unpublisht und konnte die Nebenwirkungen davon wahrscheinlich nicht vollständig vorhersehen.
  Der Autor schreibt selbst:

  NPM hat auch die Nutzungsstatistiken nicht gut sichtbar gemacht, und auf Github gab es fast keine Aktivität.
  Aus Sicht eines Nutzers war es schwer einzuschätzen, welche Auswirkungen das Unpublishing eines Pakets haben würde.
  Ich würde die eigentliche Ursache nicht in akoculus Unpublish sehen, sondern eher in übermäßigen Abhängigkeiten, den npm-Regeln und dem fehlenden Caching/Vendoring in Build-Systemen.
  Siehe den Wikipedia-Abschnitt zum Hintergrund des Vorfalls

• Die Versionshistorie des kik-Pakets sieht merkwürdig aus.
  Es wurde vor 9 Jahren durch ein Security-Holding-Paket ersetzt.
  Versionshistorie des kik-Pakets

  Die größte Ironie in dieser ganzen Sache ist am Ende das kik-Paket.
  Das Paket kik, das Kik unbedingt haben wollte, ist am Ende völlig nutzlos.
  Und die Firma Kik hat sich später selbst als nachlässig und problematisch erwiesen.
  Es gab Kontroversen rund um Krypto, und das Unternehmen wurde zudem stillschweigend als Plattform für die Verbreitung von Kinderpornografie und Ähnlichem genannt.
  Siehe Darknet Diaries, Episode 93
  Deshalb fühlt es sich im Nachhinein fast befriedigend an, dass Azer Koçulu gegenüber Kik so entschieden Nein gesagt hat.

  Am Ende bedeutet das also ... dass das alles letztlich völlig sinnlos war?

• Schon die Tatsache, dass left-pad überhaupt als Paket existiert, ist ziemlich absurd.
  Wegen einer einzigen String-Padding-Funktion wurden über CDN, Proxys, Build-Pipelines und Ähnliches gewaltige Datenmengen bewegt.
  Ich stimme zu, dass es sinnvoll ist, bestehende Lösungen gut zu nutzen, aber dass man bei einer simplen Funktion zum Auffüllen einer Zeichenkette denkt: „Dafür gibt es bestimmt ein Paket“, ist schwer nachzuvollziehen.

  Ein Teil der damaligen Debatte bestand darin, Webentwickler aus ihrer blinden Fixierung auf Mikropakete aufzurütteln.
  Es gab auch eine Kultur, in der Pakete veröffentlicht wurden, um Popularität oder GitHub-Stars zu sammeln.
  Gleichzeitig war die Haltung verbreitet, keine Funktion selbst zu implementieren, wenn sie sich per npm installieren ließ.
  Viele Entwickler, mit denen ich heute arbeite, bevorzugen immer noch selbst sehr einfache Pakete.
  Für sie lautet die Begründung: „Das reduziert den Wartungsaufwand.“
  Eine ziemlich ironische Realität.

  Auch die ursprüngliche Implementierung des Pakets scheint ineffiziente Operationen in O(n^2) statt O(n) auszulösen.
  Siehe Wikipedia

  Gibt es qualitativ wirklich einen großen Unterschied zwischen dem Rückgriff auf Utility-Funktionen aus fremden Projekten und der Nutzung eines Pakets, das bereits im gesamten Ökosystem verbreitet ist?
  Es ist nicht exakt dasselbe, aber in einer Umgebung mit ausgereiften Tools liegen die beiden Ansätze meiner Meinung nach praktisch gar nicht so weit auseinander.

  Dieses extreme Streben nach maximaler Wiederverwendung von Code, als wäre Copy-Paste eine veraltete Methode.

  Ist das vielleicht ein ähnlicher Fall wie bei KI?
  Probleme, die sich schon mit einer simplen Suche lösen ließen, werden in der Praxis stattdessen mit unzähligen Prompts erneut an eine KI gestellt.
  Eine Struktur, die C&P nur um einen unnötigen zusätzlichen Schritt erweitert.

• Die Unix-Philosophie lautet „do one thing well“.
  Bei left-pad wurde die zweite Bedingung — „well“ — verfehlt.
  Es hat mich überrascht, dass so viele Projekte die naive Implementierung einfach übernommen haben.
  Eine stärker optimierte Implementierung könnte schneller und gleichzeitig kleiner sein.

  Ich kenne mich mit der JavaScript-Kultur nicht besonders gut aus, aber ich meine mich zu erinnern, dass es eine Art Wettbewerb gab, die npm-Downloadzahlen hochzutreiben.
  left-pad hatte 1,4 Millionen Downloads pro Woche, is-even 160.000 Downloads.
  Manche haben aus Spaß Mikropakete als Abhängigkeiten hinzugefügt, andere, um die Popularitätskennzahlen ihrer Bibliothek zu steigern.
  Es gab auch Widerstand dagegen, Pakete wie is-even in intern genutzte Teile bekannter React-basierter Bibliotheken einzubauen.
  Dahinter stand eine strikte Regel nach dem Motto: „Wenn man den Code selbst schreiben kann, soll man ihn trotzdem importieren.“
  Verwandte Geschichte: Warum das Paket is-odd in einer Woche fast 3 Millionen Mal installiert wurde

  Mich würde ein Beispiel für eine „nicht naive Implementierung“ interessieren.

• Ich bin Maintainer eines beliebten npm-Pakets.
  Ich kann das sehr gut nachvollziehen.
  npm begann irgendwann, sich von der Zusammenarbeit mit der Community zu entfernen.
  Die Übernahme durch Microsoft hat das nur weiter verfestigt, aber die Anzeichen waren schon lange vorher deutlich.
  Viele Aspekte der Arbeitsweise von npm, das unkooperative Verhalten gegenüber der Community bzw. dem Node-Team, die starke Fokussierung auf Kommerzialisierung und der Ruf mancher Beteiligten waren in vieler Hinsicht unerquicklich.
  Ich erinnere mich daran, das Büro in Oakland besucht zu haben; die Interaktion an diesem Tag war nicht besonders positiv, deshalb gehe ich nicht weiter ins Detail.
  Die Lücke rund um unpublish war damals ein Problem, das allen bewusst war.
  Alle gaben nur dem Autor die Schuld, nach dem Motto „left-pad hat das Internet kaputtgemacht“, aber tatsächlich war das Missmanagement bei npm der größere Faktor.
  Wenn ich mich richtig erinnere, wurde das Paket sogar gegen den Willen des Maintainers zwangsweise wiederhergestellt; das war eine Maßnahme, die völlig von der Community abgekoppelt war, die npm angeblich vertreten wollte, und zumindest rechtlich ebenfalls fragwürdig.
  Danach kümmerte sich npm kaum noch um Missbrauch, Spam und Ähnliches, etwa core.js-Werbespam, und beteiligte sich auch kaum an Diskussionen mit der Community über Standards und Kompatibilität.
  Auch das Release von npm@5 war ein großes Desaster, und die Einführung von Paket-Lockfiles ebenfalls ein Chaos.
  (Dass das Node-Team Releases nicht zurückhielt, um auf npm zu warten, halte ich im Rückblick eher für eine gute Entscheidung.)
  Die Kommunikation mit der Community war zu der Zeit geprägt von großen Bugs, Schuldzuweisungen an die Community und einem herablassenden Tonfall.
  Das war ein klares Zeichen dafür, dass npm nicht mehr für den Geist von Open Source stand.
  Ich weiß nicht mehr genau, ob left-pad davor oder danach war, aber das gesamte Ökosystem befand sich damals in einer längeren Phase von Stagnation und Verwirrung.
  npm-Pakete gelten heute leicht als eine Art Meme, bei dem selbst triviale Funktionen als eigenes Paket erscheinen, aber im Kontext betrachtet war npm der erste leicht zugängliche Paketmanager für eine neu aufkommende populäre Technologie, wurde gemeinschaftsgetrieben betrieben und war organisch in GitHub integriert.
  Das war noch in den frühen Node-Zeiten, vor ES5, in der Ära von var und prototype, noch bevor Joyent Node.js an die Community übergeben hatte und vor dem io.js-Fork sowie der langen Stagnationsphase von Node 0.10/0.12.
  Es war eine Zeit, in der niemand so recht wusste, was Best Practices überhaupt sein sollten.
  Ich kann die Perspektive des Autors daher sehr gut nachvollziehen.
  Aus Sicherheitssicht war der left-pad-Vorfall, wenn auch unbeabsichtigt, ein wichtiger Weckruf hinsichtlich der Trennung zwischen Unternehmen und Communities im Ökosystem sowie in Bezug auf Supply-Chain-Security.
  Er hat wichtige Diskussionen über mehr Redundanz und mehr Sicherheit ausgelöst.
  Ich denke, der Branche hat das am Ende gutgetan.
  Nach so langer Zeit ist es interessant, das noch einmal zu lesen.

  npm war nicht der erste Paketmanager irgendeiner Sprache, und viele Leute hatten schon damals davor gewarnt, dass es so viele winzige Pakete gab.
  Ich denke, npm und das gesamte JS-Ökosystem wurden ein Opfer des Trends.

• Diskussionen aus der Zeit des left-pad-Vorfalls:
  Hacker-News-Diskussion

• Warum hat Java mit Apache Commons und Google Guava vertrauenswürdige Utility-Bibliotheken, JS aber nichts Vergleichbares?

  Auch in JavaScript gibt es mit Lodash eine etablierte und vertrauenswürdige Utility-Bibliothek. Die meisten ihrer Funktionen sind heute allerdings im Vergleich zu früher bereits in der Standardbibliothek enthalten.
  Tatsächlich bot Lodash pad/padStart/padEnd schon drei Monate vor dem left-pad-Vorfall an.
  Lodash-pad-Dokumentation

  Ich denke, die wichtigste Ursache ist die Kultur, danach eine gut gestaltete Standardbibliothek und danach das Vorhandensein von Tools, die verhindern, dass man mehr als 300 nutzlose Pakete in die Abhängigkeiten stopft.

  Maven ist wirklich ein sehr gut designtes Tool — ironischerweise obwohl es ständig beschimpft wird — und ein Geheimnis des Java-Erfolgs.
  Dass es dort keine kommerziellen Kompromisse wie bei npm gibt, liegt daran, dass Java mit der Apache Foundation eine gut unterstützte, gemeinnützige, communitybasierte Organisation hat. (Solche Strukturen sind sehr selten und in Javas Fall ein glücklicher Zufall, der aus seiner komplizierten rechtlichen Geschichte entstanden ist.)
  (Auch im JS-Ökosystem gibt es viele gute Bibliotheken. Das Problem war eher, dass das Paketmanagement zu zentralisiert und zu schlecht verwaltet war.)

  Google Guava ist eher mit lodash vergleichbar und nicht mit left-pad.

  Früher übernahmen Bibliotheken wie Jquery und Underscore diese Rolle.

• Ich finde es immer wieder erstaunlich, wie viele Unternehmen nicht alle für Builds nötigen Abhängigkeiten intern spiegeln.
  Man sollte den gesamten Build-Prozess offline als Clean Build durchführen können; sich nur auf den Download-Cache zu verlassen, ist letztlich Glückssache.

  In meinen Projekten werden Abhängigkeiten immer intern vendored.
  Das ist vorhersehbar, erlaubt auch Offline-Builds, und Speicherplatz ist billig.