Left-Pad (2024)

• O caso left-pad é um exemplo emblemático que mostra o conflito entre regras e valores na comunidade open source, no NPM e entre empresas
• A decisão de excluir os pacotes surgiu não de lógica, raiva ou ganância, mas de sinceridade e princípios internos
• Quando o NPM cedeu às exigências do Kik Messenger e quebrou as próprias regras, o autor optou por remover todos os seus pacotes
• Depois do caso, sua paixão pelo open source mudou, e seu interesse migrou para novas áreas como negócios, marketing e gestão de equipes
• O caso left-pad se tornou uma oportunidade para desenvolvedores e para o setor de startups repensarem a essência do open source e a complexidade da tomada de decisão

---

Contexto do caso e da decisão

• O autor compartilha experiências e reflexões pessoais 8 anos após o caso left-pad
• Na época do ocorrido, ele passava a maior parte do tempo em meio à natureza, sem sinal, em um processo de autorreflexão, e a decisão de apagar os pacotes foi tomada nesse contexto
• Essa decisão partiu não de julgamento lógico, raiva ou ganância, mas de um princípio interior: "se o NPM quebra as próprias regras, então todos os meus pacotes também devem ser apagados"
• Mais do que um "adepto rígido de regras", ele valorizava o espírito das próprias regras
• Em uma situação em que empresas como o Kik Messenger ameaçavam e exerciam poder sobre a comunidade open source, o NPM ignorou as regras que definiu para si mesmo e priorizou os interesses corporativos

A estrutura do conflito entre NPM e comunidade

• O autor não tinha medo das ameaças do Kik, mas o NPM tinha medo de perder o Kik
• Interpretar o caso simplesmente como "um homem furioso resistindo a uma grande empresa" é uma visão reducionista que ignora o contexto do caso, o desenrolar no tempo e o peso da decisão
• Mesmo não sendo algo repentino nem inesperado, o lado do NPM demonstrou, de forma geral, uma postura autoritária em relação aos desenvolvedores e, por meio de uma sequência de decisões incoerentes, transferiu toda a responsabilidade ao autor

Estrutura dos pacotes e impacto

• O trabalho open source do autor era composto, em sua maior parte, por mais de 350 pacotes divididos em pequenas funções, seguindo a filosofia Unix
• Na superfície, quase não havia sinais de uso, mas como o NPM não divulgava estatísticas de uso, não era possível medir o alcance do impacto
• Os usuários não tinham como saber o efeito real da remoção dos pacotes, e o NPM também não se esforçou para investigar o impacto nem para evitar problemas causados por remoções indiscriminadas

Mudanças e crescimento após 8 anos

• Alguns meses depois do caso left-pad, o autor deixou seu trabalho principal e saiu dos Estados Unidos, buscando o próprio caminho em novos ambientes como Marrocos, Jordânia, Turquia e Indonésia
• Ele passou por um momento quase como a morte de sua paixão pelo open source e outro de renascimento com novos interesses
• Hoje, dedica-se com a mesma paixão que tinha pela programação a diversas áreas, como negócios, marketing, operação de empresas e gestão de equipes
• Deixando a mensagem de que a vida continua, o caso left-pad permaneceu como uma oportunidade de revisitar decisões livres, os valores da comunidade e a complexidade do processo de tomada de decisão

[ndrgrd]

Foi um incidente de grande impacto, mas mesmo sem ler o texto do autor do pacote, acho que a culpa maior não foi dele, e sim das empresas e dos sistemas envolvidos.

[GN⁺]

Comentários no Hacker News

• Sinceramente, sinto que não entendi bem metade deste post de blog, como se estivesse perdendo algum contexto, mas gosto do fato de que o "cara do left pad" esteja organizando o ocorrido
  Dito isso, a afirmação a seguir parece meio estranha

  Mas ainda não entendo por que o NPM não investigou o quanto meus módulos eram usados e não pensou em uma forma de lidar com o unpublishing sem quebrar nada
  Claro, a forma como o NPM tratava unpublish era mal projetada, mas o que o autor está dizendo soa como se ele esperasse que alguém verificasse manualmente toda vez que alguém desse unpublish. Essa expectativa não parece razoável. Vejo o NPM não como uma organização que faz curadoria do registro, mas como uma entidade que presta um serviço público
  Ainda assim, é difícil culpar o autor; se ele não tivesse provocado o "incidente do left-pad", provavelmente outra pessoa teria feito isso em pouco tempo. O NPM corrigiu o problema e também criou uma política de unpublish melhor
  Nova política de unpublish do NPM como referência

  • Você diz que não entendeu metade deste post de blog
    Acho que isso acontece porque você ainda não leu al-Ghazali.
    (Essa é a parte mais arrogante e egocêntrica do texto)

  • O contexto pode ser visto na Wikipedia sobre o incidente do Npm left-pad

  • Em 18 de março de 2016, o CEO da npm, Isaac Z. Schlueter, enviou um e-mail para a Kik Interactive e para Koçulu informando que transferiria manualmente a propriedade do pacote kik para a Kik Interactive
    Quando Koçulu expressou decepção com a decisão da npm e disse que não queria mais participar da plataforma, Schlueter forneceu a ele um comando para excluir todos os 273 módulos que havia registrado
    Koçulu executou esse comando em 22 de março e removeu todos os pacotes que havia publicado
    O autor apenas executou um comando que o próprio NPM havia instruído, mas depois o NPM jogou toda a responsabilidade em cima dele

  • A empresa NPM não faz curadoria do registro NPM
    Na prática, faz sim, por exemplo recebendo relatos de vulnerabilidades de segurança e avisando os usuários, ou removendo pacotes maliciosos

  • Quando eu usava Sourceforge, havia uma política de que era obrigatório pedir autorização antes de excluir um projeto
    Depois do left-pad, entendi perfeitamente o motivo

• Um comentário menor, mas

  Meus projetos open source em geral seguiam a filosofia Unix, desenhando os pacotes para fazerem apenas uma coisa por vez
  Ninguém diz que a libc viola a filosofia Unix. A discussão costuma surgir quando comandos ou daemons têm funções demais (systemd é o exemplo clássico), ou quando têm baixa composabilidade

  • Acho que o caso left-pad mostrou que a granularidade dos pacotes NPM tinha ficado pequena demais, a ponto de o overhead superar de longe os benefícios da simplificação dos pacotes

  • Ninguém diz que a libc viola a filosofia Unix
    Na verdade, muita gente já sugeriu isso, e eu mesmo acho que está certo
    A libc moderna é totalmente diferente da filosofia Unix tradicional
    As libcs antigas eram mais simples, várias funções eram separadas em bibliotecas como a libm, e não existiam coisas complexas como DNS

  • O contraponto ao 'do one thing' é que essa única coisa precisa ser feita por completo
  • A filosofia Unix era uma diretriz para criar um ambiente poderoso de programação interativa em minicomputadores de 16 bits
    A libc que uso hoje no celular tem 1MiB, 16 vezes maior que a do Unix tradicional
    A conclusão é que pelo menos 90% da libc vai contra a filosofia Unix
    Se você ler o Lions Book ou APUE e depois olhar o manual de pthreads ou a especificação ANSI C de setlocale(), verá que são filosofias completamente diferentes
    Se acha que são a mesma coisa, isso é prova de que não leva realmente a sério nenhuma das duas
  • A "filosofia Unix" é uma filosofia inútil, e pode até ser nociva
    Porque o significado de 'one thing' não é claro, então na prática não ajuda em nada e só provoca discussões
    Eclipse também pode ser visto como fazendo 'uma coisa só', que é ser uma IDE, mas claramente não era isso que os desenvolvedores Unix queriam dizer
    Também não significa que você deva criar uma biblioteca cheia de funções de 11 linhas
    O conselho real deveria ser algo como: "não faça programas ou bibliotecas fazerem nem coisas demais, nem coisas de menos"
    Definir o que é demais e o que é de menos acaba sendo uma questão de experiência e sensibilidade

• Obrigado ao akoculu por ter escrito isto
  Acho que este incidente foi um exemplo claro da comunidade JavaScript, isto é, de um ecossistema dependente demais de dependências
  Não entendo por que tanta gente o culpa tanto
  Ele apenas deu unpublish em um pacote com 11 linhas de código, e provavelmente não conseguiria prever completamente os efeitos colaterais disso
  O próprio autor menciona no texto

  O NPM também não mostrava bem as estatísticas de uso, e quase não havia atividade no Github
  Do ponto de vista do usuário, era difícil saber o impacto de despublicar o pacote
  Em vez de buscar a causa raiz no unpublish do akoculu, acho melhor procurá-la no excesso de dependências, nas políticas do npm e na falta de cache/vendorização nos sistemas de build
  Veja o wiki sobre o contexto do incidente

• O histórico de versões do pacote kik é estranho
  Há 9 anos ele foi substituído por um pacote de contenção de segurança
  Histórico de versões do pacote kik

  A maior ironia de tudo isso é o pacote kik
  O pacote kik que a Kik queria tanto acabou não servindo para absolutamente nada
  E a empresa Kik acabou se revelando um lugar descuidado e problemático
  Houve controvérsias relacionadas a cripto, e a empresa também é mencionada discretamente como plataforma de circulação de pornografia infantil e coisas do tipo
  Veja o episódio 93 do Darknet Diaries
  Por isso, acho até satisfatório que Azer Koçulu tenha recusado a Kik com tanta firmeza

  Então a conclusão é que tudo isso... no fim das contas não significou nada?

• O simples fato de left-pad existir como pacote já é bem engraçado
  Por causa de uma única função de preenchimento de string, uma quantidade enorme de bytes trafegou por CDNs, proxies, pipelines de build etc.
  Concordo com aproveitar bem soluções existentes, mas é difícil entender como se chegou ao ponto de pensar "deve existir um pacote para isso" para uma função que só preenche o começo de uma string

  Parte da discussão na época serviu para despertar as pessoas da obsessão cega dos desenvolvedores web por micropacotes
  Havia também uma cultura de lançar pacotes por popularidade e por github stars
  E, por outro lado, era forte a cultura de evitar implementar qualquer função por conta própria se ela pudesse ser instalada via npm
  Muitos desenvolvedores com quem trabalho ainda hoje preferem até pacotes simples assim
  Para eles, a lógica é que "reduz a carga de manutenção"
  Uma realidade bastante irônica

  A implementação original do pacote também parece induzir uma operação ineficiente O(n^2), e não O(n)
  Veja a wiki

  Existe mesmo uma grande diferença de qualidade entre consultar uma função utilitária dentro do projeto de outra pessoa e usar um pacote já espalhado por todo o ecossistema?
  Não são a mesma coisa, mas em um ambiente com tooling suficientemente maduro, acho que as duas abordagens na prática não estão tão distantes

  Essa busca por reaproveitar código ao máximo, essa obsessão de que copy-paste é algo ultrapassado

  Será que isso não é parecido com a IA?
  A realidade de perguntar de novo para a IA, com inúmeros prompts, algo que poderia ser resolvido com uma busca simples
  Uma estrutura que só adiciona uma etapa desnecessária ao C&P

• A filosofia Unix é "faça uma coisa bem feita"
  O left-pad falhou na segunda condição (fazer bem)
  Fiquei surpreso com a quantidade de projetos que usavam essa implementação ingênua sem questionar
  Uma implementação mais otimizada poderia ser ao mesmo tempo mais rápida e menor

  Não conheço tão bem a cultura JavaScript, mas lembro que existia uma tendência competitiva de aumentar números de downloads no npm
  left-pad tinha 1,4 milhão de downloads por semana, is-even tinha 160 mil
  Alguns adicionavam micropacotes às dependências por brincadeira, outros para inflar indicadores de popularidade da biblioteca
  Também havia vozes contrárias a colocar pacotes como is-even dentro de bibliotecas populares baseadas em react
  Por causa de um princípio rígido do tipo "se existe para importar, importe, mesmo que você possa escrever isso sozinho"
  História relacionada: Por que o pacote is-odd foi instalado quase 3 milhões de vezes em uma semana

  Fiquei curioso sobre um exemplo de 'implementação não ingênua (nonnaive implementation)'

• Sou mantenedor de um pacote npm popular
  Consigo me identificar muito com isso
  Em algum momento, o npm começou a se afastar da colaboração comunitária
  Ficou ainda mais consolidado após a aquisição pela Microsoft, mas já havia muitos sinais antes disso
  Havia várias coisas irritantes na forma como o npm operava, na postura pouco cooperativa com a comunidade e com a equipe do Node, no foco excessivo em comercialização, na reputação de alguns integrantes e em vários outros aspectos
  Lembro de ter visitado o escritório em Oakland, mas a interação daquele dia não foi tão positiva, então não vou entrar em detalhes
  A brecha do unpublish era um problema que todos conheciam na época
  Todo mundo culpava apenas o autor, num tom de "o left-pad quebrou a internet", mas acho que o problema real era mais a má administração do npm
  Se não me falha a memória, o pacote foi restaurado à força contra a vontade do mantenedor, o que foi uma medida totalmente dissociada da comunidade que o npm dizia representar (e no mínimo esquisita também do ponto de vista legal)
  Depois disso, o npm quase não demonstrou interesse em administrar abuso, spam etc. (como o spam de anúncios do core.js), e quase não participou de discussões com a comunidade sobre padrões e compatibilidade
  O lançamento do npm@5 também foi um grande fracasso, e a introdução do lockfile gerou uma enorme confusão
  (Na verdade, considero que a equipe do Node acertou ao lançar sem esperar o npm ficar pronto)
  Naquela fase, a comunicação com a comunidade foi um desastre, com bugs grandes, culpa jogada na comunidade e atitudes arrogantes
  Isso mostrava que o npm já não representava mais o espírito do open source
  Não lembro com clareza se o left-pad veio antes ou depois disso, mas naquele período todo o ecossistema passava por uma longa fase de estagnação e confusão
  Os pacotes npm são vistos como se até funções triviais pudessem virar pacotes independentes (quase como um meme), mas, olhando o contexto, o npm foi o primeiro gerenciador de pacotes realmente acessível para uma tecnologia emergente popular, operado com forte participação da comunidade e integrado de forma orgânica ao Github
  Era o começo do Node, antes mesmo do ES5 e da época de var e prototype, antes de a Joyent entregar o Node.js à comunidade, antes do fork Io.js e antes do longo período de estagnação do Node 0.10/0.12
  Era uma época em que ninguém sabia muito bem quais eram as boas práticas
  Entendo muito o lado do autor
  Do ponto de vista de segurança, o caso left-pad foi um grande despertar para a realidade de separação entre empresas/comunidades dentro do ecossistema e para a segurança da cadeia de suprimentos, ainda que de forma não intencional
  Isso desencadeou discussões importantes sobre redundância e segurança
  Acho que, no fim, a indústria melhorou por causa disso
  Foi interessante reler isso depois de tanto tempo

  O npm não foi o primeiro gerenciador de pacotes de nenhuma linguagem, e muita gente já alertava sobre a quantidade absurda de pacotes tão pequenos assim
  Acho que o npm e o ecossistema JS como um todo acabaram virando vítimas da moda do momento

• Discussão da época sobre o left-pad
  Discussão no Hacker News

• Por que Java tem bibliotecas utilitárias confiáveis como Apache Commons e Google Guava, mas JS não?

  JavaScript também tem bibliotecas utilitárias confiáveis como Lodash. Em comparação com o passado, a maioria dessas funções hoje já está na biblioteca padrão
  Na verdade, o Lodash já oferecia pad/padStart/padEnd desde 3 meses antes do incidente do left-pad
  Documentação do pad no Lodash

  Acho que as causas mais importantes, em ordem, são cultura, uma biblioteca padrão bem projetada e a existência ou não de ferramentas que impeçam alguém de enfiar mais de 300 pacotes inúteis nas dependências

  O Maven é uma ferramenta realmente muito bem projetada (ironicamente, embora viva sendo xingada), e um dos fatores secretos do sucesso do Java
  O motivo de não haver concessões comerciais como no npm é que o Java conta com a Apache Foundation, uma base comunitária sem fins lucrativos e bem estruturada (algo muito raro, e um resultado feliz da complicada história jurídica do Java)
  (Também existem ótimas bibliotecas em JS. O problema foi a gestão de pacotes excessivamente centralizada e mal administrada)

  Google Guava é mais parecida com lodash e diferente de left-pad

  Antigamente, bibliotecas como Jquery e Underscore cumpriam esse papel

• Acho impressionante quantas empresas não espelham internamente todas as dependências necessárias para seus builds
  Todo o processo de build deveria poder ser feito offline, a partir do zero, e depender só do cache de download é contar com a sorte

  Nos meus projetos, eu sempre vendorizei as dependencies internamente
  Fica previsível, dá para buildar offline, e o custo de armazenamento é baixo