Reflexión 8 años después del incidente de Left-Pad (2024)

• El incidente de left-pad sigue siendo, 8 años después, un caso emblemático sobre dependencias de código abierto y permisos de gestión de paquetes, y Azer Koçulu vuelve a explicar la decisión de aquel momento
• La decisión de despublicar no surgió de la ira ni de la codicia, sino de la introspección; el contexto central fue que NPM había roto sus propias reglas
• Consideró que, bajo la presión de Kik Messenger, NPM priorizó otros valores por encima de la comunidad de código abierto, y ese juicio llevó a la eliminación de todos sus paquetes
• Los elementos eliminados fueron más de 350 paquetes, pero era difícil conocer el alcance real del impacto solo con estadísticas de uso y actividad en GitHub
• Tras ejecutar el script de NPM, en unos 10 minutos se rompieron varios proyectos, incluido React; en cuestión de horas, el módulo fue restaurado y la situación volvió a la normalidad

---

La decisión durante el incidente de left-pad

• Han pasado 8 años desde el incidente de left-pad, y Azer Koçulu consideró que, para enfocarse en el trabajo real, era mejor evitar este tema durante ese tiempo
• Tomó la decisión de despublicar en una época en la que pasaba la mayoría de los fines de semana de 2016 acampando en lugares remotos sin señal
  • Explica que no fue una decisión nacida de la lógica, la ira o la codicia, sino de la introspección en la naturaleza y del corazón
• El principio detrás de la decisión era simple
  • Si NPM rompía sus propias reglas y eliminaba uno de sus paquetes, entonces, bajo el mismo criterio, también debía eliminar todos sus paquetes
• Consideraba que el espíritu detrás de las reglas era más importante que las reglas en sí
  • Reconoce que, en otros contextos, podría haber buenas razones para exigir la eliminación de un paquete sin permiso del propietario
  • Pero en este caso vio que Kik Messenger estaba ejerciendo poder sobre la comunidad de código abierto basada en NPM con amenazas como “we’ll bang on your door” y “take down your accounts”
• Si el incidente se interpreta solo como “una persona enojada protestó contra intereses corporativos”, se pierden las fechas de los correos y la línea de tiempo, la situación de resistir bajo presión y la forma en que las decisiones se mueven en otros estados de conciencia

Proceso de eliminación e impacto

• Desde el punto de vista de NPM, la eliminación no fue algo repentino ni inesperado
  • Primero pidió a NPM que eliminara sus módulos y esperó una respuesta
  • Como no fijó una fecha límite, considera que NPM tuvo la oportunidad de ajustar su API y sus herramientas para hacer la transición más suave
  • En cambio, NPM proporcionó un script para eliminar todos los paquetes de una sola vez
• La mayor parte de su trabajo de código abierto consistía en paquetes pequeños que hacían una sola cosa a la vez, al estilo de la filosofía Unix
  • Eran más de 350 paquetes, todos optimizados y probados
  • Desde afuera no parecían populares, NPM no mostraba estadísticas de uso y el 90% casi no tenía actividad en GitHub
  • Desde la perspectiva de un usuario común, era difícil saber qué impacto tendría despublicarlos
• Después de ejecutar el script que le dio NPM, se alejó unos minutos, y en unos 10 minutos un amigo le avisó que el tema se había vuelto tendencia en Twitter
  • Uno de los más de 350 paquetes rompió React y varios otros proyectos
  • Luego escribió una breve entrada de blog y cedió su trabajo de código abierto, transfiriendo la propiedad de los repositorios de GitHub a voluntarios
  • En cuestión de horas, el módulo fue restaurado y la situación volvió a la normalidad
• Unos meses después dejó su trabajo y se fue de Estados Unidos de forma permanente; pasó un año en Marruecos, Jordania, Türkiye e Indonesia
• left-pad fue un momento como de muerte y renacimiento, en el que desapareció una parte de sí mismo profundamente vinculada al código abierto y algo nuevo ocupó su lugar; ahora siente tanta pasión por crear y operar empresas como por programar

[ndrgrd]

Fue un incidente de gran impacto, pero incluso sin leer el texto del autor del paquete, creo que la culpa recae más en las empresas y los sistemas involucrados que en él.

[GN⁺]

Opiniones de Hacker News

• Sentí que no entendí bien la mitad del post del blog porque parecía faltarle contexto, pero me gustó que la persona detrás de left-pad escribiera un análisis retrospectivo.
  Aun así, la afirmación de que “NPM debería haber comprobado si mi módulo se usaba ampliamente y haber considerado una forma de despublicarlo sin romper nada” suena rara. Es cierto que el diseño de la función de despublicación de NPM estaba mal, pero si eso significa que esperaba que empleados de la empresa revisaran manualmente todo cada vez que alguien despublicaba algo, no parece razonable. NPM, como empresa, no curaba el registro, sino que más bien lo alojaba como un servicio público.
  De todos modos, es difícil culpar demasiado al autor. Aunque él no hubiera provocado el incidente de left-pad, tarde o temprano alguien más lo habría hecho, y NPM corrigió el problema con una mejor política de despublicación: https://docs.npmjs.com/policies/unpublish#packages-published...

  • El 18 de marzo de 2016, Isaac Z. Schlueter, CEO de npm, Inc., envió correos tanto a Kik Interactive como a Koçulu para decir que transferiría manualmente la propiedad del paquete kik a Kik Interactive. Cuando Koçulu expresó su decepción y dijo que dejaría la plataforma, Schlueter le proporcionó un comando para borrar los 273 módulos que había registrado.
    Koçulu simplemente ejecutó ese comando el 22 de marzo de 2016 y eliminó todos los paquetes que había publicado; más tarde, NPM atribuyó su propio fracaso al autor.
  • Para el contexto, se puede ver https://en.wikipedia.org/wiki/Npm_left-pad_incident
  • NPM en realidad sí cura el registro. Principalmente avisando a los consumidores sobre vulnerabilidades y eliminando paquetes maliciosos.
  • Cuando usaba Sourceforge antes, existía una política según la cual había que obtener permiso antes de borrar un proyecto, y después de left-pad entendí por qué.

• Como alguien que evita JavaScript y su ecosistema como si fueran la plaga Visual Basic del siglo XXI, lo más interesante de esta historia es que Koçulu pasó un tiempo alejándose del mundo tecnológico y haciendo increíbles caminatas, campamentos y exploraciones de senderos, pero aun así, 8 años después, todavía siente que tiene que explicarse.
  La tecnología es como una musa caprichosa. Nosotros, los nerds, nos obsesionamos con ella y nos desgastamos a su servicio, pero la tecnología siempre nos vuelve a llamar hacia la luz.
  Como alguien que estuvo presente durante el Morris worm y pasó semanas mitigando sus efectos, creo que hay un problema fundamental en la capacidad de crear tecnologías que cambien el mundo con las herramientas actuales. Mientras menos nos esforcemos por entender los fracasos organizativos y éticos de la tecnología, más difícil será que la tecnología produzca cambios productivos en los ámbitos donde se aplica.
  Creo que yo también estoy a más o menos un mes, y a unos cientos de compilaciones fallidas, de tomarme un sabático, y me pregunto cómo se verá dentro de unos años el espacio tecnológico que dejé construido a otra escala y en otro contexto, adaptado a mis necesidades.
  Tal vez debería volverse algo relativamente estándar que los tecnólogos se tomen sabáticos con más frecuencia y más seriedad. Así podríamos obtener el contexto necesario para entender los dilemas éticos que pesan sobre nuestras capacidades técnicas.

• Es un detalle menor, pero la frase “la mayoría del trabajo de código abierto seguía la filosofía Unix, y los paquetes hacían una sola cosa a la vez” es ambigua.
  Como ejemplo más obvio, normalmente nadie considera que libc vaya contra la filosofía Unix. El debate suele darse sobre si un comando o un daemon hacen demasiadas cosas, o si no son componibles. El ejemplo reciente más representativo es systemd.

  • El alboroto por left-pad más bien mostró que la granularidad de los paquetes de NPM se había vuelto demasiado pequeña, hasta llegar a un punto en que la sobrecarga de gestionar paquetes superaba los beneficios de la simplicidad de los paquetes.
  • Hay bastantes personas que sí consideran que libc va contra la filosofía Unix. Si quieres, puedo decirlo ahora mismo.
    Una libc moderna contradice bastante la filosofía Unix. La libc tradicional de Unix era mucho más simple y muchas funciones eran simplemente llamadas al sistema. Partes de la libc actual estaban separadas en bibliotecas independientes como libm, y cosas como NSS o frameworks complejos de resolución DNS ni siquiera existían.
  • En el otro lado de “haz una sola cosa” está el requisito de que debe hacer esa cosa completa.
  • La filosofía Unix puede ser inútil, o incluso dañina. Como “una cosa” no está bien definida, en la práctica no aporta nada y solo genera discusiones.
    También se podría decir que Eclipse hace “una sola cosa: ser una plataforma de IDE”, pero no creo que los desarrolladores de Unix quisieran decir eso. Del mismo modo, probablemente tampoco querían decir que hubiera que crear una biblioteca que contuviera una única función de 11 líneas.
    El consejo real debería ser algo como: “un programa o biblioteca no debería intentar hacer ni demasiado ni demasiado poco”. Determinar cuánto es demasiado o demasiado poco, al final, requiere criterio y experiencia, como muchas pautas de programación.
  • La filosofía Unix es una filosofía sobre cómo obtener un entorno de programación interactivo potente en una minicomputadora de 16 bits cuyo tamaño máximo de segmento de texto era de 64 KiB. La libc que usamos hoy en un teléfono mide 1 MiB, 16 veces más, así que al menos el 90% de libc va contra la filosofía Unix.
    No parece posible leer el Lions book o APUE y, por otro lado, el manual de pthreads o la especificación de setlocale() de ANSI C, y concluir que ambos representan la misma filosofía. Sería como considerar que Ayn Rand y Epicuro representan la misma filosofía: significaría que no se ha tomado en serio a ninguno de los dos.

• Lo que quedó más marcado de este incidente fue que la comunidad JavaScript dependía demasiado de las dependencias.
  Solo se despublicó un paquete de 11 líneas de código https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou..., y no entiendo por qué recibió tantas críticas. El texto también dice que no comprendía del todo cuánta frustración podía causar eso.
  NPM no tenía estadísticas de uso y casi no había actividad en GitHub, así que, desde el punto de vista del usuario, no se podía saber el impacto de despublicar el paquete. Creo que la causa de fondo no fue que akoculu bajara el paquete, sino más bien la dependencia excesiva, las políticas de npm y los sistemas de build que no cacheaban ni vendorizaban el código.

• Azer Koçulu nunca fue un desastre para el ecosistema de NPM. Nadie obligó a nadie a usar left-pad, y la razón por la que terminó en tantos proyectos fue por las dependencias transitivas desordenadas.
  En cambio, Jon Schlinkert parece haber creado deliberadamente este tipo de microlibrerías y haberlas metido en handlebars-helpers, un proyecto legítimo y ampliamente usado, sin ninguna intención real de integrarlas en los proyectos que las usan. Si quieres caer en la trampa, usa handlebars-helpers; si no, deja de usar esa librería.

  • Además, él solo ejecutó un script que NPM le proporcionó directamente. Es cierto que la situación de los micropaquetes era absurda, pero Azer Koçulu no hizo nada malo.
    El problema fue que NPM le quitó el paquete por la fuerza y le proporcionó un script que claramente era peligroso si se ejecutaba. Que Azer Koçulu haya recibido críticas es ridículo.
    Jon Schlinkert parece el típico personaje molesto de marketing y, personalmente, creo que deberían prohibirlo en NPM y Github.

• El historial de versiones del paquete kik es extraño. Hace 9 años fue reemplazado por un paquete de ocupación con fines de seguridad: https://www.npmjs.com/package/kik?activeTab=versions

  • La mayor ironía es que el paquete kik que Kik deseaba con tanta desesperación terminó siendo básicamente nada.
    Kik resultó ser una empresa descuidada y bastante turbia. También hubo controversias relacionadas con criptomonedas, pero lo principal que recuerdo es que en Kik proliferaba la pornografía, especialmente material de explotación sexual infantil, y también se trató en este episodio de Darknet Diaries: https://darknetdiaries.com/episode/93/
    Desde esa perspectiva, resulta bastante satisfactorio que Azer Koçulu les haya dicho que se fueran al diablo.
  • Al final, parece que todo esto ocurrió por nada.

• Que left-pad fuera un paquete en sí mismo es bastante gracioso. Me hace pensar en cuántos bytes habrán circulado por CDNs, proxies, pipelines de build, etc., solo para usar una función utilitaria diminuta.
  Aprovechar soluciones existentes está bien, pero cuando necesitas padding de strings, no termino de entender pensar “seguro que hay un paquete para esto”.

  • Parte de la discusión de entonces iba en la línea de que era una llamada de atención necesaria para los desarrolladores web que dependían sin parar de micropaquetes como left-pad.
    También existía una cultura de publicar paquetes para ganar popularidad y estrellas en GitHub, y desarrolladores que insistían en que implementar algo que se podía instalar con NPM era “reinventar la rueda”. Incluso hoy trabajo mucho con desarrolladores que prefieren micropaquetes aunque sea para funciones simples; para ellos eso significa “menos mantenimiento”.
  • La implementación original del paquete https://en.wikipedia.org/wiki/Npm_left-pad_incident también parece que habría tenido un comportamiento O(n²), no el O(n) deseado.
  • Me pregunto si realmente hay una diferencia cualitativa tan grande entre usar una función utilitaria que alguien ya escribió dentro del proyecto y usar un paquete que alguien ya publicó dentro del ecosistema.
    Obviamente no son lo mismo, pero si existen herramientas lo bastante desarrolladas, no parecen estar tan alejados como para no entender que alguien quiera tratarlos de forma parecida.
  • Me parece que ahora con la IA pasa algo similar. ¿Cuántos prompts podrían resolverse con una simple búsqueda web?
    No es más que copiar y pegar con un paso adicional.
  • Es la máxima ostentación de reutilización de código; copiar y pegar es cosa de perdedores.

• Hay una parte que dice: “Del lado de NPM vi una actitud general de menosprecio hacia los desarrolladores, y eso llevó a una serie de decisiones irracionales que al final hicieron que todos los costos recayeran sobre mí”. Parece que NPM no aprendió demasiado de este incidente.

• Fue bueno que este incidente ocurriera. La ocupación de nombres es un problema real, y cuando hay ambigüedad se debería elegir la opción que menos sorprenda al usuario.
  Que no hubiera estadísticas de uso también era un gran problema, y que simplemente se pudiera despublicar también lo era. Que la infraestructura dependa de un trivial código de 10 líneas creado por una persona con opiniones fuertes fue, y sigue siendo, un problema real. En esta situación no creo que haya realmente alguien a quien culpar; nadie le debe nada a nadie, pero todos pueden aprender algo.

• Desde la perspectiva de alguien que mantiene varios paquetes npm top 10, este texto tiene todo el sentido
  En algún momento, NPM dejó de colaborar con la comunidad. La adquisición por parte de Microsoft lo consolidó, pero era evidente desde mucho antes
  Había muchas grietas en la forma en que se operaba npm, no colaboraba bien con la comunidad ni con el equipo principal de Node, y el impulso hacia la sostenibilidad comercial se sentía muy molesto y coercitivo. Varios miembros del equipo también tenían una reputación algo áspera
  Llegué a visitar la oficina de Oakland, donde hubo interacciones bastante interesantes; no fueron especialmente positivas, pero me guardo los detalles
  En ese entonces, el agujero de la despublicación era bien conocido. Todos culparon a left-pad de romper Internet, pero casi nadie responsabilizó a npm por haber gestionado todo aquello de forma gravemente deficiente
  Si mal no recuerdo, npm restauró el paquete por la fuerza contra la voluntad del mantenedor, lo que, en el mejor de los casos, muestra una desconexión con las personas a las que decía servir y, en el peor, resulta legalmente cuestionable. Poco después dejó de preocuparse mucho por el abuso de la plataforma, ocurrieron cosas como el spam publicitario de core.js, y tampoco colaboró bien con la comunidad en estándares, compatibilidad, etc.
  El lanzamiento de npm@5 fue un desastre. La introducción del archivo de bloqueo de paquetes no pudo haber salido peor y, según recuerdo, había presión por sacarlo a tiempo para la siguiente versión mayor de Node.js. Daba la impresión de que el equipo de Node no esperó a que npm estuviera listo, pero considerando que npm era una empresa con fines de lucro, o al menos actuaba como tal, creo que eso en realidad fue algo bueno
  La respuesta a la comunidad durante aquella etapa de interminables bugs críticos, la actitud de avergonzar a la comunidad que presionaba y esa postura de hacerse los piadosos fueron prueba de que npm ya no era un representante del software libre y de código abierto. No recuerdo si left-pad fue antes o después de eso, pero en mi cabeza quedó como parte de una misma corriente de largo declive del ecosistema
  Hoy los paquetes npm se volvieron un meme de paquetitos pequeños que hacen tareas triviales, y todo el mundo se burla. En retrospectiva, quizá no fue lo ideal. Pero el contexto importa. npm fue el primer gestor de paquetes muy accesible para una tecnología popular emergente; estaba gestionado casi por completo por la comunidad, tenía un buen sistema de búsqueda y estaba estrechamente integrado con el espíritu de “codificación social” de GitHub
  Existía en los primeros días de Node, en una época en la que ni siquiera existía ES5 y se usaban var y prototype. Tampoco había buenas prácticas de JavaScript bien establecidas, era antes de que Joyent entregara Node.js a la comunidad y también antes de salir del fork Io.js y del largo estancamiento de Node 0.10/0.12
  Nadie sabía cuál era la mejor forma de hacerlo
  Entiendo totalmente al autor. Desde el punto de vista de la seguridad, estoy realmente agradecido de que haya ocurrido left-pad. Aunque esa no haya sido la intención del autor, mostró con claridad a la gente qué riesgos aparecen cuando se depende de intereses corporativos separados de la comunidad a la que dicen servir. Inició muchas conversaciones sobre seguridad de la cadena de suministro, redundancia, etc., y a largo plazo hizo que la industria mejorara un poco

  • No fue el primer gestor de paquetes para un lenguaje de programación, y muchas personas ya habían señalado que paquetes tan pequeños eran una tontería
    npm, y JavaScript en general, son principalmente víctimas de la moda