Retrospectiva do caso Left-Pad 8 anos depois (2024)
(azerkoculu.com)- O caso left-pad continua sendo, 8 anos depois, um exemplo emblemático sobre dependências em open source e autoridade no gerenciamento de pacotes, e Azer Koçulu volta a explicar sua decisão da época
- A decisão de tornar tudo privado não nasceu de raiva nem de ganância, mas de auto-reflexão, e o contexto central foi o fato de o NPM ter quebrado regras que ele mesmo criou
- Sob pressão do Kik Messenger, ele entende que o NPM priorizou outros valores em vez da comunidade open source, e esse julgamento levou à remoção de todos os pacotes
- O alvo da remoção eram mais de 350 pacotes, mas era difícil saber o alcance real do impacto apenas por estatísticas de uso e atividade no GitHub
- Depois de executar um script do NPM, em cerca de 10 minutos vários projetos, incluindo React, quebraram, e em poucas horas o módulo foi restaurado e a situação voltou ao normal
O julgamento na época do caso left-pad
- Já se passaram 8 anos desde o caso left-pad, e Azer Koçulu considerou que era melhor evitar esse tema para poder se concentrar no trabalho de verdade
- Em 2016, ele tomou a decisão de tornar tudo privado durante um período em que passava a maior parte dos fins de semana acampando em lugares remotos sem sinal
- Ele explica que foi uma escolha que não veio da lógica, da raiva ou da ganância, mas da auto-reflexão em meio à natureza e do coração
- O princípio por trás da decisão era simples
- Se o NPM removesse um de seus pacotes quebrando as próprias regras, então, pelo mesmo critério, todos os seus pacotes também deveriam ser removidos
- Ele via o espírito por trás das regras como mais importante do que as regras em si
- Reconhece que, em outros contextos, poderia haver bons motivos para exigir a remoção de um pacote sem autorização do dono
- Mas, neste caso, ele entende que o Kik Messenger exerceu poder sobre a comunidade open source baseada no NPM com ameaças como “we’ll bang on your door” e “take down your accounts”
- Se o caso for visto apenas como “uma pessoa irritada protestando contra interesses corporativos”, perde-se de vista as datas dos e-mails e da linha do tempo, a situação de resistir sob pressão e a forma como decisões mudam em outro estado de consciência
Processo de remoção e impacto
- Do ponto de vista dele, para o NPM a remoção não foi algo repentino nem inesperado
- Primeiro ele pediu ao NPM que removesse seus módulos e aguardou resposta
- Como não definiu um prazo final, ele entende que o NPM teve a chance de ajustar a API e as ferramentas para tornar a transição mais suave
- Em vez disso, o NPM forneceu um script para remover todos os pacotes de uma vez
- Seu trabalho em open source seguia em grande parte a filosofia Unix, com pacotes pequenos que fazem uma única coisa por vez
- Eram mais de 350 pacotes, todos otimizados e testados
- Na aparência, eles não pareciam populares, o NPM não mostrava estatísticas de uso e 90% quase não tinham atividade no GitHub
- Para um usuário comum, era difícil saber que impacto tornar tudo privado causaria
- Depois de executar o script fornecido pelo NPM, ele se ausentou por alguns minutos e, em cerca de 10 minutos, um amigo avisou que o assunto estava bombando no Twitter
- Um dos mais de 350 pacotes quebrou o React e vários outros projetos
- Depois disso, ele escreveu um curto post de blog e passou adiante seu trabalho em open source, transferindo a propriedade dos repositórios do GitHub para voluntários
- Em poucas horas, o módulo foi restaurado e a situação voltou ao normal
- Alguns meses depois, ele saiu do emprego e deixou os Estados Unidos permanentemente, passando um ano em Morocco, Jordan, Türkiye e Indonesia
- O left-pad foi como um momento de morte e renascimento, em que uma parte dele profundamente ligada ao open source desapareceu e algo novo ocupou esse lugar; hoje, ele tem tanta paixão por criar e operar empresas quanto por programar
2 comentários
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.
Opiniões no Hacker News
Metade do post do blog pareceu perder o contexto, então não entendi muito bem, mas é bom que o envolvido no left-pad tenha escrito uma análise retrospectiva.
Ainda assim, a afirmação de que “o NPM deveria ter verificado se meu módulo era amplamente usado e considerado uma forma de cancelar a publicação sem quebrar nada” soa estranha. É verdade que o design do recurso de unpublish do NPM era falho, mas, se a ideia era esperar que funcionários da empresa revisassem tudo manualmente toda vez que alguém cancelasse uma publicação, isso não parece razoável. A empresa NPM não faz exatamente a curadoria do registro; ela está mais próxima de hospedá-lo como um serviço público.
Mesmo assim, é difícil culpar muito o autor. Mesmo que ele não tivesse causado o incidente do left-pad, outra pessoa provavelmente teria feito algo parecido pouco depois, e o NPM corrigiu o problema com uma política melhor de unpublish: https://docs.npmjs.com/policies/unpublish#packages-published...
Koçulu apenas executou esse comando em 22 de março de 2016, removendo todos os pacotes que havia publicado, e depois o NPM colocou a culpa de sua própria falha no autor.
Da perspectiva de alguém que evita JavaScript e seu ecossistema como se fossem a praga Visual Basic do século XXI, a parte mais interessante dessa história é que Koçulu passou um tempo afastado do mundo da tecnologia, fazendo trilhas, acampamentos e explorando caminhos incríveis, mas 8 anos depois ainda sente que precisa se explicar.
A tecnologia é como uma musa volúvel. Nós, nerds, ficamos obcecados por ela e nos desgastamos a seu serviço, mas ela sempre nos chama de volta para a luz.
Como alguém que estava lá na época do Morris worm e passou semanas trabalhando para reduzir seus efeitos, vejo um problema fundamental na capacidade de criar tecnologias que mudam o mundo com as ferramentas atuais. Quanto menos nos esforçamos para entender as falhas organizacionais e éticas da tecnologia, mais difícil fica para ela produzir mudanças produtivas nas áreas em que é aplicada.
Eu também acho que daqui a cerca de um mês, e depois de algumas centenas de falhas de compilação, vou tirar um período sabático, e fico pensando em como estará, quando eu voltar alguns anos depois, o espaço tecnológico que construí em outra escala e contexto para atender às minhas necessidades.
Talvez devesse se tornar, em alguma medida, um padrão que tecnólogos tirassem períodos sabáticos com mais frequência e mais seriedade. Assim poderíamos obter o contexto necessário para entender os dilemas éticos que pesam sobre nossas capacidades técnicas.
É um detalhe pequeno, mas a frase “a maior parte do trabalho open source seguia a filosofia Unix, e os pacotes faziam uma coisa de cada vez” é ambígua.
Como exemplo mais óbvio, normalmente ninguém considera que a libc contradiga a filosofia Unix. O debate costuma ser se comandos ou daemons fazem coisas demais, ou se não são componíveis. Um exemplo recente representativo é o systemd.
Uma libc moderna é bastante contrária à filosofia Unix. A libc do Unix tradicional era muito mais simples, e muitas funções eram apenas chamadas de sistema. Partes da libc de hoje ficavam separadas em bibliotecas distintas, como a libm, e coisas como NSS ou frameworks complexos de resolução DNS nem existiam.
Dá para dizer que o Eclipse também “faz uma coisa, que é ser uma plataforma de IDE”, mas não acho que era isso que os desenvolvedores Unix queriam dizer. Do mesmo modo, provavelmente não queriam dizer que se deveria criar uma biblioteca contendo apenas uma função de 11 linhas.
O conselho real deveria ser algo como “um programa ou biblioteca não deve tentar fazer nem coisa demais nem coisa de menos”. Como em muitas diretrizes de programação, determinar quanto é demais ou de menos exige, no fim, intuição e experiência.
Depois de ler o Lions book ou APUE, e por outro lado o manual de pthreads ou a especificação de
setlocale()do ANSI C, não parece possível concluir que ambos representam a mesma filosofia. Isso seria como considerar Ayn Rand uma representante da mesma filosofia que Epicuro, o que significaria não ter se envolvido seriamente com nenhum dos dois lados.O que ficou mais forte desse caso foi o fato de a comunidade JavaScript depender demais de dependências
Foi só cancelar a publicação de um pacote de código de 11 linhas https://en.wikipedia.org/wiki/Npm_left-pad_incident#Backgrou..., então não entendo por que houve tanta crítica. O texto também diz que ele não compreendeu completamente o tamanho da frustração que isso causaria
O NPM não tinha estatísticas de uso e quase não havia atividade no GitHub, então, do ponto de vista do usuário, não havia como saber o impacto de cancelar a publicação do pacote. Vejo a causa raiz menos no fato de akoculu ter removido o pacote e mais no excesso de dependências, nas políticas do npm e nos sistemas de build que não faziam cache nem vendorizavam o código
Azer Koçulu nunca foi um desastre para o ecossistema NPM. Ninguém obrigou ninguém a usar left-pad, e ele entrou em tantos projetos por causa de dependências transitivas bagunçadas
Por outro lado, Jon Schlinkert parece ter criado de propósito essas microlibraries e as incluído em um projeto legítimo e amplamente usado, o handlebars-helpers, sem demonstrar nenhuma disposição real de integrá-las aos projetos que as usam. Se quiser cair nessa, use handlebars-helpers; caso contrário, pare de usar essa biblioteca
O problema foi o NPM ter tomado à força o pacote dele e fornecido um script que claramente era perigoso se executado. É ridículo que Azer Koçulu tenha sido criticado
Jon Schlinkert parece o típico sujeito inconveniente movido a marketing e, pessoalmente, acho que deveria ser banido do NPM e do Github
O histórico de versões do pacote kik é estranho. Ele foi substituído por um pacote de ocupação por segurança há 9 anos: https://www.npmjs.com/package/kik?activeTab=versions
A Kik se revelou uma empresa descuidada e bastante sórdida. Também houve polêmicas envolvendo criptomoedas, mas o ponto central de que me lembro é que pornografia, especialmente material de exploração sexual infantil, proliferava no Kik, e isso também foi abordado neste episódio do Darknet Diaries: https://darknetdiaries.com/episode/93/
Desse ponto de vista, foi bem satisfatório Azer Koçulu ter mandado eles irem se ferrar
O simples fato de left-pad ser um pacote já é bem engraçado. Faz pensar em quantos bytes devem ter trafegado por CDNs, proxies, pipelines de build etc. só para usar uma função utilitária minúscula
É bom aproveitar soluções existentes, mas não entendo muito bem pensar “provavelmente existe um pacote para isso” quando se precisa fazer padding de strings
Havia também uma cultura de publicar pacotes para ganhar popularidade e GitHub stars, e desenvolvedores que insistiam que implementar por conta própria algo instalável via NPM era “reinventar a roda”. Ainda hoje trabalho bastante com desenvolvedores que preferem micropacotes mesmo para funcionalidades simples, porque para eles isso significa “menos manutenção”
Claro que os dois não são a mesma coisa, mas, com ferramentas suficientemente evoluídas, não parecem tão distantes a ponto de eu não entender por que alguém gostaria de tratá-los de forma parecida
É basicamente copiar e colar com uma etapa a mais
Há um trecho que diz: “Do lado do NPM, vi uma atitude geral de menosprezo pelos desenvolvedores, o que levou a uma série de decisões irracionais e, no fim, colocou todos os custos na minha conta”; mas parece que o NPM não aprendeu muita coisa mesmo depois desse caso
Foi bom que esse caso tenha acontecido. Name squatting é um problema real e, em situações ambíguas, deve-se escolher o caminho que menos surpreenda o usuário
A falta de estatísticas de uso também era um grande problema, assim como o fato de simplesmente poder cancelar a publicação. Infraestrutura depender de um trecho trivial de 10 linhas feito por uma pessoa opinativa também era, e ainda é, um problema real. Nessa situação, é difícil dizer que alguém foi realmente culpado; ninguém deve nada a ninguém, mas todos podem aprender com isso
Do ponto de vista de quem mantém alguns dos pacotes npm top 10, este texto faz todo o sentido
A partir de certo momento, o NPM deixou de colaborar com a comunidade. Isso se consolidou com a aquisição pela Microsoft, mas já era evidente muito antes
Havia muitas rachaduras na forma como o npm era operado, ele não colaborava bem nem com a comunidade nem com a equipe principal do Node, e a pressão rumo à sustentabilidade comercial parecia muito incômoda e coercitiva. Vários membros da equipe também tinham uma reputação um tanto ríspida
Cheguei a visitar o escritório em Oakland, e houve interações bastante interessantes; não foram particularmente positivas, mas vou deixar os detalhes de fora
Na época, a brecha de unpublish público era bem conhecida. Todo mundo culpou o left-pad por quebrar a internet, mas quase ninguém cobrou a responsabilidade do npm por ter gerenciado tudo aquilo de forma gravemente equivocada
Se minha memória não falha, o npm restaurou o pacote à força contra a vontade do mantenedor, o que, na melhor das hipóteses, mostra um distanciamento das pessoas que eles diziam servir e, na pior, também é legalmente duvidoso. Logo depois disso, eles também passaram a se importar pouco com abusos na plataforma; houve coisas como spam de anúncios do core.js, e eles não colaboraram direito com a comunidade em padrões, compatibilidade etc.
O lançamento do npm@5 foi um desastre. A introdução do arquivo de lock de pacotes não poderia ter sido pior e, pelo que me lembro, havia pressão para lançá-lo junto com a próxima versão major do Node.js. A impressão era de que a equipe do Node não esperou o npm ficar pronto, mas, considerando que o npm era uma empresa com fins lucrativos, ou pelo menos agia como tal, acho que isso acabou sendo uma coisa boa
A resposta à comunidade durante aquele período de bugs críticos intermináveis, a postura de envergonhar a comunidade que fazia pressão e a atitude de falsa devoção eram prova de que o npm já não era mais um representante do software livre e de código aberto. Não lembro se o left-pad veio antes ou depois disso, mas, na minha cabeça, ficou como parte de um mesmo processo de longo declínio do ecossistema
Hoje, os pacotes npm viraram meme de pacotinhos que fazem tarefas triviais, e todo mundo zomba disso. Em retrospecto, talvez não tenha sido o ideal. Mas o contexto importa. O npm foi o primeiro gerenciador de pacotes muito acessível para uma tecnologia nova e popular que estava surgindo, era mantido quase inteiramente pela comunidade, tinha um bom sistema de busca e era muito integrado ao espírito de “codificação social” do GitHub
Ele existia nos primórdios do Node, numa época em que nem ES5 havia, quando se usavam
vareprototype. Também não havia boas práticas de JavaScript bem estabelecidas, era antes de a Joyent entregar o Node.js à comunidade e antes de sairmos do fork Io.js e da longa estagnação do Node 0.10/0.12Ninguém sabia qual era a melhor forma de fazer as coisas
Entendo totalmente o autor. Do ponto de vista de segurança, sou realmente grato por o left-pad ter acontecido. Mesmo que essa não tenha sido a intenção do autor, ele mostrou claramente às pessoas quais riscos surgem ao depender de interesses corporativos separados da comunidade que dizem servir. Isso iniciou muitas conversas sobre segurança da cadeia de suprimentos, redundância etc., e, no longo prazo, tornou o setor um pouco melhor
O npm, e o JavaScript em geral, são principalmente vítimas da moda