Março de 2016 foi palco de um evento que escancarou a fragilidade da nossa infraestrutura digital. Um pacote 'open source' simples e quase desconhecido, com apenas 11 linhas em JavaScript, foi removido pelo próprio autor do repositório NPM — tipo a biblioteca sagrada dos programadores web do mundo todo. E isso foi suficiente para causar um verdadeiro caos no ecossistema de desenvolvimento web por várias horas.
Como algo tão minúsculo conseguiu gerar um estrago tão gigante?
A história do pacote left-pad explica tudo
O left-pad tinha uma função bem simples: adicionar caracteres do lado esquerdo de uma string para ela atingir um tamanho específico. Tipo transformar o número '7' em '007', uma tarefa trivial que qualquer dev faria em minutos.
Mas justamente por ser algo tão simples, fazia sentido não ficar reescrevendo aquelas mesmas 11 linhas toda hora. Por isso, o pacote que tinha esse código foi adotado em peso como dependência em vários outros projetos, muitos deles essenciais no universo JavaScript: Babel, Webpack, React... e por aí vai.
Na prática, o funcionamento correto de milhões de projetos acabou dependendo, direta ou indiretamente, desse pequeno pedaço de código.
O estopim: uma briga por um nome
Azer Koçulu, o dev que mantinha o left-pad (e outros pacotes), se envolveu numa disputa com a empresa Kik Messenger. A empresa queria o nome do pacote 'kik' no NPM, mesmo o pacote existindo antes da fundação da Kik. A briga ficou séria quando os responsáveis pelo repositório deram razão pra Kik e tiraram a propriedade do nome do dev, passando para a empresa sem o consentimento dele.
Como protesto, Koçulu decidiu remover todos os seus pacotes do NPM, uma lista com quase 300 pacotes, incluindo o famoso left-pad. O problema era que muitos projetos dependiam do left-pad para rodar ou instalar.
Quando o pacote sumiu do repositório, um monte de devs pelo mundo começou a ver erros ao tentar compilar ou executar suas aplicações.
Por várias horas, grandes setores do ecossistema JavaScript ficaram travados. Não que as aplicações web pararam de funcionar, mas novas instalações e deploys deram ruim, principalmente em ambientes de integração contínua, os famosos CI/CD. Aí o NPM teve que agir rápido e reinstalou o pacote sem o consentimento do Koçulu, algo que normalmente não é permitido, mas a urgência da situação não deixou escolha.
No fim das contas, foi um episódio cheio de desavenças que levantou um debate sério, tanto ético quanto técnico, sobre a governança do software livre.
O que aprendemos? Ou melhor, o que deveríamos ter aprendido?
Esse caso deixou várias lições na mesa sobre o desenvolvimento moderno de software:
- Interdependência extrema: um software aparentemente pequeno pode ser o coração de centenas ou milhares de outros sistemas.
- Falta de redundância: várias empresas dependiam de servidores externos sem ter cópias locais dos seus pacotes.
- Governança e controle: os conflitos entre devs independentes e plataformas centralizadas como o NPM podem causar impactos técnicos gigantes.
- Licenças abertas e seus limites: o left-pad estava sob a licença WTFPL — “Do What The Fuck You Want With It” — que permite basicamente fazer o que quiser com o código. Isso ajudou a reinstalar o pacote rápido, mas também mostra os riscos de software crítico sem uma responsabilidade clara.
O caso do left-pad lembra que boa parte da tecnologia que usamos no dia a dia tá sustentada por projetos open source mantidos por pessoas que, muitas vezes, não recebem nada em troca. E isso ainda é real hoje. Por isso, além de usar software livre, é fundamental apoiar — seja com grana, tempo ou reconhecimento.
Porque, no fim, toda a internet pode depender de poucas linhas de código escritas por um dev solitário no seu tempo livre.
Mas pouca gente realmente aprendeu essa lição. Essa falha ficou clara com outro caso ainda mais grave: o Log4Shell.
Log4Shell: quando tudo voltou a quebrar
Em dezembro de 2021, foi descoberta uma vulnerabilidade crítica, o CVE-2021-44228, no Log4J, uma biblioteca open source usada pra registrar eventos em apps Java. Esse bug permitia que hackers executassem código remotamente, transformando milhões de servidores em alvos fáceis.
A resposta veio rápido. Em apenas 24 horas, os mantenedores — três voluntários que ralavam no tempo livre — lançaram um patch para corrigir o problema. Mas aí veio outro escândalo: como assim uma biblioteca tão crucial para empresas bilionárias era mantida por só três pessoas não remuneradas? Gente que teve que passar a noite toda sem dormir pra evitar um caos massivo de cibersegurança?
Esse episódio só revelou de novo um padrão que já conhecemos: o coração tecnológico das maiores corporações do mundo bate graças a esforços individuais que quase ninguém reconhece, e pior, que acontecem em condições precárias. Esses devs, em vez de receberem apoio, viraram alvo de ataques injustos enquanto tentavam segurar o barco.
Como evitar o próximo “left-pad”?
A queda do left-pad tinha tudo pra ser um aviso sobre a fragilidade do ecossistema open source — que, convenhamos, é basicamente o ecossistema da internet toda. Mas, adivinha? A gente não aprendeu nada. Em vez de fortalecer essa base, as grandes techs continuaram faturando alto sem investir o suficiente pra manter essa estrutura viva.
A solução não é só fazer forks ou guardar backups dos pacotes. As pessoas do código aberto e do desenvolvimento web estão pedindo:
- Financiamento estável: patrocínios, fundos públicos e modelos que paguem direitinho quem mantém os projetos.
- Governança comunitária: nada de deixar um projeto vital na mão de uma pessoa só.
- Auditoria e manutenção constante: criar padrões mínimos de segurança, testes e atualizações regulares.
- Cultura da dependência consciente: parar de importar pacotes só porque é mais fácil, mesmo que sejam trivialidades.
Ver 0 Comentários