React e a lição de bancar alguém por 10 anos

Um dev postou no Hacker News que paga a educação de uma pessoa na zona rural da Tanzânia há 10 anos. Não foi uma doação só, nem uma campanha viral. Foi um boleto mensal, por uma década. Li o Tell HN e pensei numa coisa que parece não ter relação nenhuma: o node_modules do meu último projeto React.

Calma, eu explico. Isso aqui não é um post de autoajuda. Tem a ver com o jeito como a gente consome trabalho dos outros sem pensar no prazo.

O que o Tell HN conta, afinal

A ideia é simples. Uma pessoa decidiu bancar os estudos de alguém que não teria como pagar. Manteve isso por 10 anos. Nos comentários, a discussão foi para onde sempre vai no HN: se vale a pena ajudar alguém diretamente ou doar para uma instituição, como medir impacto, o risco de criar dependência, se a dinâmica de poder fica esquisita.

Não vou entrar nesse debate. Quem é dev e lê aquilo tende a reparar em outra coisa: o que conta é a duração, não o valor. Uma doação grande uma vez só não paga dez anos de escola. O que paga é um compromisso pequeno, chato e constante.

E é aí que entra o React.

Por que isso tem a ver com React

O seu app React depende de centenas de pacotes. Roda aí:

npm ls --all | wc -l

Num projeto Next.js recém-criado, esse número já passa fácil de algumas centenas de linhas. Num app de verdade, com formulário, data fetching, i18n, testes e lint, chega a milhares.

O React em si tem a Meta por trás. Mas o resto não. A lib de formulário, o parser de datas, o plugin do Babel que alguém escreveu em 2017, o polyfill que você nem sabe que existe. Muito disso é mantido por uma pessoa ou duas, no tempo livre.

A gente já viu o que acontece quando esse compromisso quebra:

• left-pad (2016): um dev tirou 11 linhas do npm e metade da internet parou de buildar, inclusive projetos com React e Babel.
• colors.js e faker.js (2022): o mantenedor, cansado de trabalhar de graça para empresa grande, sabotou os próprios pacotes.
• core-js: o autor passou anos contando em público que o projeto, usado por uma fatia enorme da web, mal pagava as contas dele.

Nenhum desses casos foi falta de código bom. Foi falta de alguém segurando a ponta do outro lado por tempo suficiente.

Software não morre por bug. Morre quando a última pessoa que se importava cansa.

O que muda no seu fluxo de trabalho

Não vou te pedir para patrocinar todo mundo. Não dá, e não resolve. Mas dá para trocar o modo "consumo infinito" por algo mais adulto. Na prática, faço três coisas.

1. Descobrir quem você está carregando nas costas.

npx npm-fund
# ou simplesmente
npm fund

O npm fund lista os pacotes do seu projeto que têm link de financiamento (GitHub Sponsors, Open Collective). A primeira vez que rodei num projeto React de cliente, apareceram dezenas de nomes. Muitos eu nunca tinha ouvido falar. Todos estavam em produção.

2. Escolher poucos e manter por muito tempo.

A lição do Tell HN é exatamente essa. Melhor 5 dólares por mês para um mantenedor durante anos do que 100 dólares uma vez num momento de culpa. Mantenedor planeja vida com receita previsível, igual a gente. Um patrocínio recorrente pequeno vale mais que um pico isolado.

Se você trabalha numa empresa, a conversa é outra. Pega a lista do npm fund, filtra as libs críticas (as que, se sumissem, travariam o deploy) e leva para o gestor. Um valor fixo por mês para três ou quatro projetos custa menos que uma hora de incidente.

3. Pagar com tempo quando não der para pagar com dinheiro.

Contribuir não é só PR de feature. Responder issue repetida, melhorar um exemplo na documentação, reproduzir um bug com um CodeSandbox mínimo. Para quem mantém uma lib React com 2 mil issues abertas, um bug bem reproduzido é ouro.

"Mas eu não ganho em dólar"

Essa objeção é justa e eu ouço sempre. A maioria dos devs no Brasil recebe em real, e 5 dólares por mês dói mais aqui do que em San Francisco.

Três respostas honestas:

• Você não precisa começar pelo dinheiro. Tempo e cuidado contam, como falei acima.
• Se você é freelancer ou tem empresa, coloca uma linha no orçamento do projeto. Uma pequena porcentagem para as dependências críticas. O cliente nem percebe, e o projeto dele fica mais seguro.
• Patrocinar mantenedor brasileiro também vale. Tem muita gente boa aqui mantendo ferramenta usada no ecossistema React.

E tem um lado egoísta que eu não tenho vergonha de admitir: lib financiada é lib que não te deixa na mão no meio de uma migração para o React 19.

O que eu acho de verdade

Minha opinião forte: o ecossistema JavaScript criou a cultura de tratar dependência como recurso natural. Como água que sai da torneira. Você instala, usa, esquece. Quando quebra, abre issue irritado cobrando um estranho que nunca te cobrou nada.

O Tell HN me incomodou de um jeito bom porque mostra o contrário. Uma pessoa olhou para um problema longo e aceitou que a solução também seria longa. Sem foto, sem anúncio, sem hype. Dez anos de constância.

A gente gosta de falar de arquitetura que escala. Pouca gente fala de compromisso que escala no tempo. E o tempo é justamente a variável que mais derruba projeto open source. A versão 1.0 sai com empolgação. A 4.2.7, que corrige um edge case no Safari, sai com teimosia.

Parte do humor involuntário disso tudo: a gente gasta uma tarde decidindo entre Zustand e Jotai, compara bundle size em kilobytes, lê benchmark de três blogs. E nunca passa um minuto sequer olhando se a lib escolhida tem alguém que vai estar ali daqui a dois anos. Esse deveria ser o primeiro critério.

Um checklist curto antes de instalar a próxima lib

Antes de dar npm install em algo que vai para produção, eu olho:

• Quantos mantenedores ativos o repositório tem (aba Contributors, últimos 12 meses).
• Se as issues recebem resposta, mesmo que seja um "não vou fazer".
• Se existe algum financiamento, mesmo pequeno.
• Se a lib depende de outras dez libs de uma pessoa só.

Não é ciência. É só não ser ingênuo.

Para fechar

Não estou dizendo que patrocinar uma lib React é igual a pagar a escola de alguém. São coisas de pesos muito diferentes, e comparar seria desrespeitoso com a história do post. O que as duas têm em comum é mais simples: coisas que importam precisam de alguém disposto a aparecer todo mês, mesmo quando ninguém está olhando.

Escolhe um projeto. Só um. Apoia por um ano e vê o que muda. Se quiser ver o que eu ando construindo com essas mesmas libs, dá uma olhada nos meus projetos.

Um dev paga a escola de uma pessoa na Tanzânia há 10 anos. Todo mês, sem foto e sem anúncio.

Li isso no Hacker News e pensei no node_modules do meu último projeto React.

Centenas de pacotes em produção, muitos mantidos por uma ou duas pessoas no tempo livre. left-pad, colors.js e core-js mostraram o que acontece quando essa ponta se solta.

Software não morre por bug. Morre quando a última pessoa que se importava cansa.

A lição que eu tirei: constância vale mais que valor. 5 dólares por mês durante anos ajudam mais que 100 numa hora de culpa.

Roda um npm fund no seu projeto, escolhe uma lib e apoia por um ano. Escrevi mais sobre isso no blog, o link está nos comentários.

#OpenSource #React #JavaScript #DesenvolvimentoDeSoftware #Comunidade