- L'affaire left-pad est un cas emblématique montrant le conflit entre règles et valeurs au sein de la communauté open source, de NPM et des entreprises.
- La décision de supprimer les paquets ne venait ni de la logique, ni de la colère, ni de la cupidité, mais d'une sincérité et de principes intérieurs.
- Dans une situation où NPM, en cédant aux exigences de Kik Messenger, a enfreint ses propres règles, l'auteur a choisi de supprimer tous ses paquets.
- Après l'affaire, sa passion pour l'open source a changé, et son intérêt s'est déplacé vers de nouveaux domaines comme le business, le marketing et la gestion d'équipe.
- L'affaire left-pad a conduit les développeurs et l'écosystème des startups à repenser la nature de l'open source et la complexité de la prise de décision.
Contexte de l'affaire et décision
- Huit ans après l'affaire left-pad, l'auteur partage son expérience personnelle et ses réflexions.
- À l'époque, il passait la majeure partie de son temps dans la nature, hors de portée du réseau, dans une démarche d'introspection, et la décision de supprimer les paquets est née dans ce contexte.
- Cette décision ne relevait ni d'un jugement logique, ni de la colère, ni de la cupidité, mais de son principe intérieur : « si NPM enfreint ses propres règles, alors tous mes paquets doivent aussi être supprimés ».
- Plus qu'un adepte strict du « respect des règles », il accordait davantage d'importance à l'esprit même des règles.
- Face à des entreprises comme Kik Messenger qui menaçaient la communauté open source et exerçaient leur pouvoir, NPM a ignoré ses propres règles et fait passer les intérêts des entreprises en premier.
Structure du conflit entre NPM et la communauté
- L'auteur ne craignait pas les menaces de Kik, mais NPM craignait de perdre Kik.
- Réduire l'affaire à « un homme en colère qui s'est opposé à une grande entreprise » est une lecture simpliste qui ignore le contexte, la chronologie et le poids de la décision.
- Du côté de NPM, il ne s'agissait ni d'un événement soudain ni d'une surprise, pourtant l'entreprise a globalement adopté une attitude autoritaire envers les développeurs et, par une série de décisions incohérentes, a rejeté toute la responsabilité sur l'auteur.
Structure des paquets et impact
- L'essentiel du travail open source de l'auteur était divisé en petites fonctions selon la philosophie Unix, pour un total de plus de 350 paquets.
- En apparence, il y avait peu de traces d'utilisation, mais comme NPM ne publiait pas les statistiques d'usage, il était impossible d'évaluer l'ampleur réelle de l'impact.
- Les utilisateurs n'avaient aucun moyen de connaître les véritables répercussions de la suppression des paquets, et NPM non plus ne faisait pas d'efforts pour mesurer l'impact ni pour éviter les problèmes causés par des suppressions inconsidérées.
Huit ans plus tard : changements et croissance
- Quelques mois après l'affaire left-pad, l'auteur a quitté son activité principale puis les États-Unis, et a cherché sa propre voie dans de nouveaux environnements comme le Maroc, la Jordanie, la Turquie et l'Indonésie.
- Il a connu un moment comparable à une mort, marquant une rupture dans sa passion pour l'open source, puis une renaissance vers de nouveaux centres d'intérêt.
- Aujourd'hui, il consacre la même passion qu'à la programmation à des domaines variés comme le business, le marketing, la gestion d'entreprise et la gestion d'équipe.
- En transmettant l'idée que la vie continue, il considère l'affaire left-pad comme une occasion de revenir sur la liberté de décision, les valeurs de la communauté et la complexité du processus de décision.
2 commentaires
C’était un incident aux conséquences importantes, mais même sans lire le texte de l’auteur du package, je pense que la faute vient moins de lui que des entreprises et des systèmes impliqués.
Avis Hacker News
Honnêtement, j’ai l’impression de ne pas bien comprendre la moitié de ce billet de blog, comme s’il me manquait du contexte, mais j’apprécie le fait que le « left pad guy » récapitule l’affaire
En revanche, l’affirmation suivante me paraît un peu étrange
Après left-pad, j’ai parfaitement compris pourquoi
Détail mineur, mais
La libc que j’utilise aujourd’hui sur mon téléphone fait 1 MiB, soit 16 fois la taille d’un Unix traditionnel
J’en conclus qu’au moins 90 % de libc va à l’encontre de la philosophie Unix
Après avoir lu le Lions Book ou APUE, il suffit de regarder la documentation de pthreads ou la spécification ANSI C de
setlocale()pour voir qu’il s’agit d’une philosophie totalement différenteSi vous considérez que ces philosophies sont les mêmes, c’est la preuve que vous n’adhérez sérieusement à aucune des deux
Parce que le sens de « one thing » n’est pas clair, elle n’aide concrètement en rien et ne fait que provoquer des débats
On pourrait dire qu’Eclipse ne fait qu’« une seule chose », à savoir être un IDE, mais ce n’est évidemment pas ce que voulaient dire les développeurs Unix
Cela ne veut pas non plus dire qu’il faut créer une bibliothèque composée uniquement de fonctions de 11 lignes
Le vrai conseil devrait plutôt être : « qu’un programme ou une bibliothèque n’en fasse ni trop ni trop peu »
Et déterminer ce qui est trop ou trop peu relève finalement de l’expérience et du jugement
Merci à akoculu d’avoir écrit ce texte
Pour moi, cet incident est un exemple très clair de la communauté JavaScript, c’est-à-dire d’un écosystème trop dépendant de ses dépendances
Je ne comprends pas pourquoi autant de gens l’ont autant blâmé
Il n’a fait qu’unpublish un package contenant 11 lignes de code, et il n’a sans doute pas pu prévoir entièrement les effets de bord
L’auteur le dit d’ailleurs lui-même dans le texte
L’historique des versions du package kik est étrange
Il a été remplacé il y a 9 ans par un package de security holding
Historique des versions du package kik
La plus grande ironie de toute cette affaire, c’est le package kik
Le package kik que Kik voulait à ce point récupérer n’a finalement servi à rien
Et l’entreprise Kik s’est révélée être un endroit négligent et problématique
Il y a eu des controverses liées à la crypto, et elle a aussi été citée discrètement comme plateforme de diffusion de contenus tels que de la pédopornographie
Voir Darknet Diaries épisode 93
Du coup, le refus catégorique d’Azer Koçulu face à Kik a quelque chose d’assez satisfaisant
Donc au final, tout ça n’aura… finalement servi à rien ?
Le simple fait que left-pad existe en tant que package est déjà assez comique
Pour une simple fonction de remplissage de chaîne, une quantité énorme d’octets a transité via CDN, proxys, pipelines de build, etc.
Je suis d’accord avec l’idée de bien réutiliser les solutions existantes, mais avoir fini par se dire « il y a sûrement un package pour ça » juste pour une fonction qui ajoute des caractères au début d’une chaîne reste difficile à comprendre
Une partie du débat à l’époque a servi d’électrochoc face à l’obsession aveugle des développeurs web pour les micro-packages
Il existait aussi une culture de publication de packages pour la popularité ou les étoiles Github
Et à l’inverse, une forte culture consistant à ne jamais réimplémenter soi-même la moindre fonction si elle pouvait être installée avec npm
Beaucoup de développeurs avec qui je travaille aujourd’hui préfèrent encore souvent des packages, même pour des choses simples
Leur logique, c’est que « cela réduit la charge de maintenance »
Une réalité assez ironique
L’implémentation d’origine du package semble elle aussi provoquer des opérations inefficaces en
O(n^2)plutôt qu’enO(n)Référence Wikipédia
Y a-t-il vraiment une si grande différence de qualité entre s’inspirer d’une fonction utilitaire dans le projet de quelqu’un d’autre et utiliser un package déjà largement diffusé dans tout l’écosystème ?
Ce n’est pas exactement la même chose, mais dans un environnement doté d’un outillage suffisamment mûr, je ne pense pas que les deux approches soient si éloignées en pratique
Cette volonté de pousser au maximum la réutilisation du code, avec l’idée fixe que le copier-coller est une méthode dépassée
Est-ce que ce n’est pas un peu la même situation qu’avec l’IA ?
On repose à une IA, avec d’innombrables prompts, des questions qu’une simple recherche permettrait déjà de résoudre
Une structure qui ajoute juste une étape inutile au C&P
La philosophie Unix, c’est « faire une seule chose et bien la faire »
left-pad a manqué la deuxième partie (« bien la faire »)
J’ai été surpris que tant de projets aient repris tel quel cette implémentation naïve
Une implémentation plus optimisée aurait pu être à la fois plus rapide et plus petite
Je connais mal la culture JavaScript, mais il me semble qu’il existait une tendance à faire la course aux téléchargements npm
left-pad comptait 1,4 million de téléchargements hebdomadaires, is-even 160 000
Certains ajoutaient des micro-packages comme dépendances pour plaisanter, d’autres pour gonfler les indicateurs de popularité de leur bibliothèque
Il y avait aussi des voix opposées à l’inclusion de packages comme is-even à l’intérieur de bibliothèques connues basées sur React
à cause d’un principe strict du type « si ça existe déjà, il faut l’importer, même si on pourrait l’écrire soi-même »
Histoire liée : pourquoi le package is-odd a été installé près de 3 millions de fois en une semaine
Je serais curieux de voir un exemple d’« implémentation non naïve »
Je maintiens un package npm populaire
Je m’y retrouve complètement
À un moment, npm a commencé à s’éloigner de la collaboration communautaire
Son rachat par Microsoft a encore consolidé cela, mais les signes étaient visibles bien avant
Il y avait beaucoup de choses agaçantes : plusieurs modes de fonctionnement de npm, son attitude peu coopérative avec la communauté et l’équipe Node, son obsession pour la commercialisation, la réputation de certains membres, etc.
Je me souviens avoir visité les bureaux d’Oakland, et comme les interactions ce jour-là n’ont pas été très positives, je préfère ne pas entrer dans les détails
La faille autour de l’unpublish était un problème dont tout le monde avait conscience à l’époque
Tout le monde a accusé uniquement l’auteur avec l’idée que « left-pad a cassé Internet », mais je pense que le vrai problème venait davantage de la mauvaise gestion de npm
Si je me souviens bien, le package a été restauré de force contre la volonté du mainteneur, ce qui était complètement déconnecté de la communauté que npm prétendait représenter (et juridiquement étrange, au minimum)
Ensuite, npm s’est presque désintéressé de la gestion des abus, du spam, etc. (comme le spam publicitaire autour de core.js), ainsi que des discussions avec la communauté sur les standards et la compatibilité
La sortie de npm@5 a aussi été un fiasco, tout comme l’introduction du lockfile
(Le fait que l’équipe Node ait publié sans attendre que npm soit prêt me paraît même avoir été une bonne décision)
À ce moment-là, la communication avec la communauté était désastreuse : gros bugs, reproches faits à la communauté, attitude autoritaire, etc.
C’était bien la preuve que npm ne représentait plus l’esprit open source
Je ne me souviens plus très bien si left-pad est arrivé avant ou après ce tournant, mais à l’époque tout l’écosystème traversait une longue phase de stagnation et de confusion
Les packages npm sont souvent perçus comme des packages autonomes pour des fonctions triviales, presque comme un mème, mais si l’on remet les choses en contexte, npm a été le premier gestionnaire de packages vraiment accessible pour une technologie émergente populaire, exploité par la communauté et intégré de façon organique à Github
C’était au tout début de Node, avant même ES5, à l’époque de
varet deprototype, avant que Joyent ne cède Node.js à la communauté, avant le fork Io.js et avant la longue stagnation de Node 0.10/0.12Personne ne savait vraiment encore ce qu’étaient les bonnes pratiques
Je comprends totalement le point de vue de l’auteur
Du point de vue de la sécurité, l’affaire left-pad a été un grand réveil sur la séparation réelle entre entreprises et communauté dans l’écosystème, ainsi que sur la sécurité de la supply chain
Elle a déclenché d’importantes discussions sur la redondance et la sécurité
Je pense qu’au final, cela a fait progresser l’industrie
C’est intéressant à relire aujourd’hui
npm n’a pas été le premier gestionnaire de packages, quel que soit le langage, et beaucoup de gens avaient déjà alerté sur la prolifération de packages aussi minuscules
J’ai l’impression que npm et tout l’écosystème JS ont surtout été victimes d’un effet de mode
Discussions liées à l’époque de left-pad
Discussion Hacker News
Pourquoi Java a-t-il des bibliothèques utilitaires fiables comme Apache Commons ou Google Guava, alors que JS n’a rien d’équivalent ?
JavaScript a aussi des bibliothèques utilitaires fiables comme Lodash. Par rapport au passé, la plupart des fonctionnalités sont désormais intégrées à la bibliothèque standard
En fait, Lodash proposait déjà les fonctions pad/padStart/padEnd trois mois avant l’affaire left-pad
Documentation Lodash pad
Je pense que les raisons principales sont, dans l’ordre : la culture, l’existence d’une bibliothèque standard bien conçue, puis la présence ou non d’outils empêchant d’enfiler plus de 300 packages inutiles dans ses dépendances
Maven est vraiment un outil très bien conçu (ironiquement, alors qu’il est toujours critiqué), et c’est un facteur clé du succès de Java
S’il n’existe pas de compromis commerciaux du type npm, c’est aussi parce que Java dispose de l’Apache Foundation, une structure non lucrative et communautaire bien établie (ce genre de structure est très rare, et c’est un heureux concours de circonstances né de l’histoire juridique complexe de Java)
(Il existe aussi d’excellentes bibliothèques en JS. Le vrai problème, c’est surtout une gestion des packages trop centralisée et mal administrée)
Google Guava est plus proche de lodash, et pas de left-pad
Autrefois, des bibliothèques comme Jquery et Underscore jouaient ce rôle
Je trouve toujours étonnant que tant d’entreprises ne mirorent pas en interne toutes les dépendances nécessaires à leurs builds
Il devrait être possible de faire tout le processus de build proprement hors ligne, et compter uniquement sur le cache de téléchargement revient à s’en remettre à la chance
Dans mes projets, je vendorise toujours les dependencies en interne
C’est prévisible, buildable hors ligne, et le coût de stockage est faible