Left-Pad (2024)

• El incidente de left-pad es un caso representativo que muestra el choque de reglas y valores entre la comunidad de código abierto, NPM y las empresas.
• La decisión de eliminar los paquetes surgió de la sinceridad y de principios internos, no de la lógica, la ira ni la codicia.
• En una situación en la que NPM rompió sus propias reglas al ceder ante las exigencias de Kik Messenger, el autor decidió eliminar todos sus paquetes.
• Después del incidente, su pasión por el código abierto cambió, y su interés se desplazó hacia nuevos campos como negocios, marketing y gestión de equipos.
• El incidente de left-pad se convirtió en una oportunidad para que desarrolladores y la industria startup replantearan la esencia del código abierto y la complejidad de la toma de decisiones.

---

Contexto del incidente y la decisión

• Ocho años después de que ocurriera el incidente de left-pad, el autor comparte su experiencia personal y sus reflexiones.
• En ese momento pasaba la mayor parte del tiempo en la naturaleza, sin señal, haciendo introspección, y la decisión de eliminar los paquetes también fue una elección tomada en ese proceso.
• Esta decisión no nació de un juicio lógico, ira o codicia, sino de un principio interno: "si NPM rompe sus propias reglas, entonces todos mis paquetes también deben ser eliminados".
• Más que un estricto "seguidor de reglas", tenía una postura que valoraba más el espíritu de las reglas en sí.
• En una situación donde empresas como Kik Messenger amenazaban y ejercían poder sobre la comunidad de código abierto, NPM ignoró las reglas que ella misma había establecido y priorizó los intereses corporativos.

La estructura del conflicto entre NPM y la comunidad

• El autor no temía las amenazas de Kik, pero NPM sí temía perder a Kik.
• Interpretar el incidente simplemente como que "un hombre enojado resistió a una gran empresa" es una visión simplificada que pasa por alto el contexto del incidente, el paso del tiempo y el peso de la decisión.
• Aunque para NPM no fue algo repentino ni inesperado, en general mostró una actitud autoritaria hacia los desarrolladores y, con una serie de decisiones incoherentes, terminó trasladando toda la responsabilidad al autor.

Estructura de los paquetes e impacto

• El trabajo de código abierto del autor estaba dividido en pequeñas funciones según la filosofía Unix, por lo que se componía de más de 350 paquetes.
• En apariencia casi no había señales de uso, pero como NPM no publicaba estadísticas de uso, era imposible conocer el alcance real del impacto.
• Los usuarios no tenían forma de saber el efecto real de la eliminación de los paquetes, y NPM tampoco hizo esfuerzos por investigar el impacto ni por prevenir problemas derivados de eliminaciones indiscriminadas.

Cambios y crecimiento ocho años después

• Unos meses después del incidente de left-pad, dejó su trabajo principal y salió de Estados Unidos, buscando su propio camino en nuevos entornos como Marruecos, Jordania, Turquía e Indonesia.
• Experimentó un momento parecido a la muerte, en el que su pasión por el código abierto se rompió, y otro en el que volvió a nacer a través de nuevos intereses.
• Actualmente se dedica con la misma pasión que ponía en la programación a negocios, marketing y la gestión de empresas y equipos, entre otros campos.
• Transmite el mensaje de que la vida sigue, y el incidente de left-pad quedó como una ocasión para revisitar las decisiones libres, los valores de la comunidad y la complejidad del proceso de toma de decisiones.

[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

• Si soy honesto, siento que no entendí bien de qué iba la mitad de esta entrada del blog, como si me faltara contexto, pero me gusta que el "left pad guy" ponga en orden lo que pasó.
  Aun así, esta afirmación sí me parece un poco rara.

  Pero sigo sin entender por qué NPM no investigó qué tan usados eran mis módulos ni pensó en una forma de manejar el unpublishing sin que nada se rompiera
  Claro, el diseño del unpublish en NPM sí estaba mal hecho, pero lo que dice el autor suena a que esperaba que alguien revisara manualmente cada vez que alguien hiciera un unpublish. Esa expectativa no parece razonable. Mi impresión es que NPM no era una organización que curaba el registro, sino una entidad que prestaba un servicio público.
  Aun así, cuesta culpar al autor; si él no hubiera provocado el "left-pad incident", probablemente alguien más lo habría hecho poco después. NPM corrigió el problema y también estableció una mejor política de unpublish.
  Información de referencia: nueva política de unpublish de NPM

  • Dices que no entiendes la mitad de esta entrada del blog
    Creo que es porque todavía no has leído a al-Ghazali.
    (Esta es la parte más arrogante y egocéntrica del texto).

  • El contexto de referencia puede verse en Wikipedia sobre el incidente de left-pad en npm

  • El 18 de marzo de 2016, Isaac Z. Schlueter, CEO de npm, envió correos tanto a Kik Interactive como a Koçulu informándoles que la propiedad del paquete kik sería transferida manualmente a Kik Interactive
    Cuando Koçulu expresó su decepción con la decisión de npm y dijo que ya no quería seguir participando en la plataforma, Schlueter le proporcionó un comando con el que podía borrar los 273 módulos que había registrado
    Koçulu ejecutó ese comando el 22 de marzo y eliminó todos los paquetes que había publicado
    El autor simplemente ejecutó un comando que el propio NPM le indicó, pero después NPM le echó toda la culpa a él.

  • La empresa NPM no cura el registro de NPM
    En la práctica sí lo hace, por ejemplo al recibir reportes de vulnerabilidades de seguridad y alertar a los usuarios, o al eliminar paquetes maliciosos.

  • Cuando antes usaba Sourceforge, había una política que exigía pedir permiso antes de eliminar un proyecto.
    Después de left-pad entendí perfectamente por qué.

• Es un detalle menor, pero

  La mayoría de mis proyectos open source seguían la filosofía Unix, diseñados para que cada paquete hiciera solo una cosa a la vez
  Nadie sostiene que libc viole la filosofía Unix. Las discusiones suelen surgir más bien sobre si un comando o un daemon tiene demasiadas funciones —systemd es el ejemplo típico— o si su composabilidad es deficiente.

  • Creo que el caso de left-pad mostró que la fragmentación de los paquetes de NPM se hizo demasiado extrema, al grado de que el costo extra era mucho mayor que los beneficios de simplificar paquetes.

  • Nadie dice que libc viole la filosofía Unix
    De hecho, mucha gente sí lo ha planteado, y yo también creo que es cierto.
    La libc moderna no se parece en nada a la filosofía Unix tradicional.
    Las libc antiguas eran más simples; varias funciones estaban separadas en otras bibliotecas como libm, y no existían complejidades como DNS.

  • Lo opuesto a "do one thing" es que "hagas completa esa única cosa".
  • La filosofía Unix era una guía para construir un entorno potente de programación interactiva en minicomputadoras de 16 bits.
    La libc que hoy uso en mi teléfono ocupa 1MiB, dieciséis veces más que un Unix tradicional.
    La conclusión es que al menos 90% de libc va contra la filosofía Unix.
    Si lees el Lions Book o APUE y luego revisas el manual de pthreads o la especificación ANSI C de setlocale(), se nota que son filosofías completamente distintas.
    Si crees que son lo mismo, eso demuestra que no conectas seriamente con ninguna de las dos filosofías.
  • La "filosofía Unix" es una filosofía inútil, e incluso puede ser dañina.
    Como el significado de "one thing" no es claro, en la práctica no ayuda en nada y solo provoca discusiones.
    Eclipse también puede verse como "una sola cosa", la de ser un IDE, pero evidentemente eso no era lo que querían decir los desarrolladores Unix.
    Tampoco significa que debas crear una biblioteca formada por funciones de 11 líneas.
    El verdadero consejo debería ser algo como: "que un programa o una biblioteca no hagan ni demasiado ni demasiado poco".
    Decidir qué cuenta como mucho o poco al final depende de la experiencia y el criterio.

• Gracias a akoculu por escribir esto.
  Creo que este incidente fue un caso clarísimo de la comunidad de JavaScript, es decir, de un ecosistema que dependía demasiado de las dependencias.
  No entiendo por qué tanta gente te culpa así.
  Solo despublicaste un paquete con 11 líneas de código, y probablemente no podías prever por completo todos los efectos secundarios.
  El propio autor lo menciona en el texto.

  NPM tampoco mostraba bien las estadísticas de uso, y en Github casi no había actividad
  Desde la perspectiva del usuario, era difícil saber el impacto que tendría despublicar un paquete
  En vez de buscar la causa raíz en el unpublish de akoculu, yo la veo en el exceso de dependencias, en las políticas de npm y en la falta de caching/vendoring en los sistemas de build.
  Referencia: wiki con el contexto del incidente

• El historial de versiones del paquete kik es raro.
  Hace 9 años fue reemplazado por un paquete de security holding.
  historial de versiones del paquete kik

  La mayor ironía de todo este caso es el paquete kik.
  El paquete kik que Kik quería apropiarse con tanta insistencia al final no sirve para nada.
  Y la empresa Kik terminó revelándose como un lugar descuidado y problemático.
  Hubo controversias relacionadas con cripto, y además se le ha señalado discretamente como una plataforma de distribución de pornografía infantil, entre otras cosas.
  Referencia: Darknet Diaries episodio 93
  Por eso resulta incluso satisfactorio que Azer Koçulu se haya negado de forma tan tajante a Kik.

  Entonces, al final, todo esto... ¿terminó no significando nada?

• El simple hecho de que left-pad exista como paquete ya es bastante gracioso.
  Por una sola función de padding de cadenas se movieron cantidades enormes de bytes a través de CDN, proxies y pipelines de build.
  Estoy de acuerdo en aprovechar bien las soluciones existentes, pero cuesta entender que alguien pensara "seguro hay un paquete para eso" tratándose solo de una función para rellenar por la izquierda una cadena.

  Parte del debate en ese momento sirvió para despertar conciencia sobre la obsesión ciega de los desarrolladores web con los micro paquetes.
  También existía una cultura de publicar paquetes por popularidad o para conseguir github stars.
  Y por otro lado, también estaba muy extendida la cultura de no implementar por cuenta propia ninguna función si se podía instalar con npm.
  Muchos desarrolladores con los que trabajo hoy todavía prefieren incluso paquetes muy simples.
  Para ellos, la lógica es que "reduce la carga de mantenimiento".
  Qué realidad tan irónica.

  Parece que la implementación original del paquete también provocaba operaciones ineficientes O(n^2), en lugar de O(n).
  Referencia en Wikipedia

  ¿Hay realmente una gran diferencia de calidad entre tomar una función utilitaria del proyecto de otra persona y usar un paquete que ya está difundido por todo el ecosistema?
  No son lo mismo, pero en un entorno con herramientas suficientemente maduras, creo que en la práctica no están tan lejos.

  Esa obsesión por reutilizar código al máximo, como si el copy-paste ya fuera un método obsoleto.

  ¿No se parece esto un poco a lo de la IA?
  La realidad de volver a preguntarle a una IA, con incontables prompts, algo que podría resolverse con una simple búsqueda.
  Una estructura que solo añade un paso innecesario encima del C&P.

• La filosofía Unix es "hacer bien una sola cosa".
  left-pad falló en la segunda parte: hacerlo bien.
  Me sorprendió que tantos proyectos usaran tal cual una implementación ingenua.
  Una implementación más optimizada podría ser más rápida y más pequeña.

  No conozco tan bien la cultura de JavaScript, pero recuerdo que existía una tendencia a competir por subir el número de descargas en npm.
  left-pad tenía 1.4 millones de descargas semanales e is-even 160 mil.
  Algunas personas añadían micro paquetes como dependencia en broma, y otras para inflar las métricas de popularidad de sus bibliotecas.
  También hubo voces en contra de meter paquetes como is-even dentro de bibliotecas famosas basadas en react.
  Eso venía de una regla estricta del tipo "si el código se puede traer, tráelo siempre", aunque uno mismo pudiera escribirlo.
  Historia relacionada: por qué el paquete is-odd se instaló casi 3 millones de veces en una semana

  Tengo curiosidad por ver un ejemplo de una "implementación no ingenua".

• Soy maintainer de paquetes populares en npm.
  De verdad puedo identificarme mucho con esto.
  En algún momento npm empezó a alejarse de la colaboración comunitaria.
  La compra por parte de Microsoft solo consolidó eso, pero ya había muchas señales desde antes.
  Había muchas cosas irritantes: varias prácticas operativas de npm, su actitud poco cooperativa con la comunidad y el equipo de Node, su obsesión con la comercialización y la reputación de algunas personas dentro del proyecto.
  Recuerdo haber visitado la oficina de Oakland, y como la interacción de ese día no fue muy positiva, prefiero no entrar en detalles.
  El hueco en unpublish era un problema que todos conocían en aquel entonces.
  Todos culpaban solo al autor con la idea de que "left-pad rompió internet", pero yo creo que el problema real fue más bien la mala gestión de npm.
  Si no recuerdo mal, restauraron el paquete por la fuerza contra la voluntad de su maintainer, y eso fue una medida completamente separada del nivel de comunidad que npm decía representar —como mínimo, incluso legalmente suena raro—.
  Después de eso, npm casi no mostró interés en moderar abusos o spam —como el spam publicitario de core.js— y casi no participó en discusiones con la comunidad sobre estándares o compatibilidad.
  El lanzamiento de npm@5 también fue un desastre total, y la introducción del lockfile de paquetes fue un caos.
  (De hecho, me parece que fue una buena decisión que el equipo de Node no esperara a que npm estuviera listo para lanzar).
  En ese momento la comunicación con la comunidad era pésima: bugs grandes, culpar a la comunidad y una actitud autoritaria.
  Fue una señal de que npm ya no representaba el espíritu open source.
  No recuerdo bien si left-pad fue antes o después de esa transición, pero en esa época todo el ecosistema estaba en un largo periodo de estancamiento y confusión.
  Los paquetes de npm suelen verse como si fueran paquetes independientes por funciones triviales, casi como un meme, pero si piensas en el contexto, npm fue el primer package manager realmente accesible para una tecnología emergente y popular, operado por la comunidad e integrado de forma orgánica con Github.
  Era la época temprana de Node, antes incluso de ES5, cuando se usaban var y prototype, antes de que Joyent entregara Node.js a la comunidad, y antes del fork de Io.js y del largo estancamiento de Node 0.10/0.12.
  Era una etapa en la que nadie sabía bien cuáles eran las mejores prácticas.
  De verdad simpatizo con la posición del autor.
  Desde una perspectiva de seguridad, el incidente de left-pad fue un gran llamado de atención sobre la separación entre empresas/comunidades dentro del ecosistema y sobre la seguridad de la cadena de suministro, aunque no fuera esa la intención.
  Provocó discusiones importantes sobre redundancia y seguridad.
  Creo que, al final, sirvió para que la industria mejorara.
  Volver a leerlo después de tanto tiempo resulta interesante.

  npm no fue el primer package manager de ningún lenguaje, y mucha gente ya había advertido sobre la proliferación de paquetes tan pequeños.
  Creo que npm y el ecosistema de JS en general fueron víctimas de una moda.

• Discusión relacionada de la época de left-pad
  debate en Hacker News

• ¿Por qué Java sí tiene bibliotecas utilitarias confiables como Apache Commons o Google Guava, y JS no?

  En JavaScript también existen bibliotecas utilitarias confiables como Lodash. En comparación con antes, la mayoría de esas funciones ya están incorporadas en la biblioteca estándar.
  De hecho, Lodash ya ofrecía funciones pad/padStart/padEnd desde tres meses antes del incidente de left-pad.
  documentación de Lodash pad

  Creo que la causa más importante, en orden, es la cultura, luego una biblioteca estándar bien diseñada y luego la existencia o no de herramientas que eviten meter más de 300 paquetes inútiles como dependencias.

  Maven es una herramienta realmente bien diseñada —irónicamente siempre recibe críticas—, y uno de los factores secretos del éxito de Java.
  La razón por la que no hubo compromisos comerciales como los de npm es que Java cuenta con la Apache Foundation, una organización comunitaria sin fines de lucro y bien respaldada —una estructura muy poco común y en buena medida un resultado afortunado de la compleja historia legal de Java—.
  (En JS también hay muchas bibliotecas excelentes. El problema fue que la gestión de paquetes estaba demasiado centralizada y muy mal administrada).

  Google Guava se parece más a lodash, y no a left-pad.

  Antes bibliotecas como Jquery y Underscore cumplían ese papel.

• Me sigue pareciendo increíble que haya tantas empresas que no hagan un mirror interno de todas las dependencias necesarias para sus builds.
  Todo el proceso de build debería poder hacerse offline desde cero, y depender solo de la caché de descargas es dejarlo al azar.

  En mis proyectos siempre vendorizo las dependencies internamente.
  Es predecible, se puede compilar offline y el costo de almacenamiento es barato.