Contribuir pra open source não é só código: uma jornada de SRE na BrasilAPI

Há algumas semanas decidi fazer uma coisa que sempre fica pra "depois": escolher um projeto open source de verdade, clonar, entender por dentro, e tentar contribuir com algo que importasse. Não queria um projeto de brinquedo — queria um que já estivesse em produção, com gente de verdade dependendo dele.

Escolhi a BrasilAPI.

Escolhi um projeto que eu mesmo já tinha dado 👍 numa issue, anos atrás, sem imaginar que um dia ia voltar pra ajudar a resolver.

O que é a BrasilAPI

Se você já precisou de um CEP, um CNPJ, a tabela FIPE, ou os feriados nacionais num projeto, talvez já tenha usado sem saber. A BrasilAPI nasceu de um problema bem concreto: a API de CEP dos Correios não tem CORS habilitado. Ou seja, um site não consegue chamar ela direto do navegador — o próprio navegador bloqueia, por segurança.

A solução foi simples e genial: criar um "tradutor" que busca o dado em fontes públicas (Correios, Banco Central, IBGE, INEP…), organiza num formato único e devolve com a porta destrancada pra qualquer site consumir.

Hoje são quase 30 domínios diferentes, perto de 90 rotas, sem banco de dados próprio, sem custo de infraestrutura, mantido inteiramente por voluntários. Next.js, hospedado na Vercel, cache agressivo, tudo pensado pra custar zero.

Ela não inventa dado — ela traduz burocracia em JSON.

Por que open source importa

É fácil tratar open source como "código de graça". Mas o que realmente sustenta um projeto como esse é confiança distribuída entre um bando de gente que nunca se viu pessoalmente. Alguém mantém uma dependência às 23h depois do trabalho. Alguém revisa um PR no fim de semana. Ninguém está sendo pago pra isso — e, mesmo assim, milhares de aplicações em produção dependem desse trabalho silencioso.

Open source não é "código de graça" — é confiança distribuída entre estranhos.

E é justamente aí que mora o risco: quando ninguém tem tempo de olhar, coisas importantes ficam esquecidas. Foi exatamente isso que encontrei.

O desafio (e a lição de humildade que vem com ele)

Comecei do jeito óbvio: rodei o projeto localmente, explorei os endpoints, e fui caçando problemas. Achei alguns de verdade — um endpoint retornando erro desde que a fonte de dados dele saiu do ar, uma divergência entre a versão do Node testada e a que roda em produção, um conjunto de dependências com falhas de segurança conhecidas.

Abri issues bem documentadas pra cada um, com evidência, causa raiz e proposta de solução.

E aí veio a parte que mudou meu jeito de trabalhar: ao procurar se já existiam discussões sobre esses problemas, busquei só nas issues do projeto — nunca nos pull requests. Resultado: descobri, tarde, que duas das três correções já existiam, uma delas havia sido proposta por um mantenedor três meses antes da minha issue, e estava simplesmente esquecida, sem nenhuma revisão.

Fiz a pergunta errada primeiro: "o que está quebrado?" A certa era: "o que já foi tentado?"

Não foi uma duplicação de código — foi uma duplicação de atenção. Mas a lição ficou: num projeto com histórico, a primeira pergunta nunca é "o que eu posso corrigir", é "o que já está em andamento e só precisa de um empurrão".

Um prisma de SRE

A parte que mais me interessou foi olhar o projeto com os olhos de quem cuida de confiabilidade, não só de quem escreve feature. SRE não pergunta só "isso funciona?" — pergunta "o que me garante que isso continua funcionando, e eu confio nessa garantia?".

Foi assim que encontrei o achado mais interessante da jornada: em 20 dos 42 arquivos de teste do projeto, havia um erro de lógica sutil. A checagem que deveria "pular o teste só se a fonte externa estiver fora do ar" tinha um bug de ordem de execução — e sempre concluía "está fora do ar", mesmo quando estava tudo normal. Resultado: uma boa parte da suíte de testes nunca rodava de verdade, silenciosamente, há meses. Os testes passavam — só que não testavam nada.

Achei também que o projeto roda os testes automáticos numa versão do Node diferente da que está em produção. E que, ao revisar um PR de atualização de dependências, descobri que o próprio sistema de checagem automática do projeto nunca monta a versão "pronta pra produção" — só a versão de desenvolvimento. Ou seja, uma mudança que quebrasse especificamente a versão final passaria sem ninguém notar.

A pergunta de SRE favorita: e se o que te avisa que está tudo bem também estiver quebrado?

Nenhum desses achados é glamouroso. Nenhum vira manchete. Mas são exatamente o tipo de coisa que, sem alguém olhar com essa lente, fica invisível até o dia em que quebra de verdade, em produção, sem aviso.

Lições aprendidas

Resumindo o que eu levo dessa jornada, de forma prática:

• Busque em pull requests, não só em issues, antes de reportar qualquer coisa. Metade do trabalho pode já estar feito.
• Não confie só no diff. Baixe o código, construa, rode de verdade. Uma mudança grande pode "parecer certa" na leitura e ainda assim esconder uma falha que só aparece rodando.
• Evidência + causa raiz + proposta vale muito mais que uma reclamação. "Está quebrado" não ajuda ninguém a agir; "está quebrado, aqui está a causa, e aqui estão as opções" sim.
• Nunca repita um feedback que já foi dado. Leia a thread inteira antes de comentar — duplicar atenção é tão ruim quanto duplicar código.

Formas de contribuir (além de escrever código)

Se você está pensando em dar o primeiro passo em open source, a dica mais honesta que posso dar é: contribuir não é só código.

• Revisar um PR esquecido pode valer mais do que escrever um novo. Muita correção boa simplesmente não teve ninguém olhando.
• Testar de verdade antes de comentar — instalar, rodar, confirmar — é uma forma de contribuição que poucos fazem, e que gera confiança imediata.
• Documentação e observações de processo (como "esse teste não está testando nada" ou "falta validar a versão final antes de mergear") têm impacto tão real quanto uma feature nova.
• Confirmar um bug com dado fresco, numa issue antiga que ninguém tocou há meses, já ajuda a comunidade a saber o que ainda é relevante.

A contribuição mais valiosa que fiz nessa jornada não foi código — foi atenção.

Fechamento

Não comecei essa jornada sabendo Next.js de cor, nem conhecendo a fundo a BrasilAPI. Comecei só com curiosidade e disposição de investigar antes de agir. Foi o suficiente pra encontrar problemas reais, destravar correções esquecidas, e aprender bem mais sobre confiabilidade de sistemas do que eu esperava.

Se você também quer dar esse passo: escolha um projeto que você já usa (vai ser mais fácil entender o contexto), leia as issues e os PRs antes de abrir qualquer coisa nova, e vá com curiosidade antes de pressa. O resto aparece no caminho.

Esse artigo é baseado em contribuições reais ao projeto BrasilAPI — issues e revisões de PR feitas em novembro de 2026.