Como manter um projeto open source sem se esgotar

A Open Source Guides observa que, conforme um projeto cresce, quem o mantém passa menos tempo escrevendo código e mais tempo com issues, usuários e contribuidores. Além disso, parte do trabalho não é código e pesa tanto quanto: responder, revisar, explicar, dizer não. O guia de boas práticas para mantenedores organiza esse trabalho em cinco ideias, que valem para um projeto com três estrelas ou com três mil.

Registre a visão do projeto no README ou num arquivo à parte. Ela ajuda você a manter o foco e a resistir ao crescimento sem fim do escopo. A mesma página pede que você deixe claro como as contribuições são revisadas, que tipos você aceita, em quanto tempo costuma responder e quanto tempo você tem para dar. Mantenha as conversas em público e mova para canais públicos os pedidos que chegam em privado. Atualize ou sinalize a documentação que ficou velha. O gerador de CONTRIBUTING monta uma base para isso.

Regras escritas tornam a recusa menos pessoal. Feche com rapidez as contribuições que você não vai aceitar, em vez de deixá-las paradas. Ao recusar, a Open Source Guides sugere uma sequência: agradeça, explique por que não encaixa, aponte a documentação e feche o pedido. Use modelos de issue e de pull request e um CONTRIBUTING para filtrar o que chega fora do padrão, e encaminhe quem está empolgado para tarefas mais simples, como as marcadas com good first issue.

Rotule as issues próprias para iniciantes e reconheça quem contribui com frequência dando mais responsabilidade. Divida a propriedade do projeto. Se for sair, passe o bastão ou indique um fork. E deixe que outras pessoas criem as próprias soluções por meio de forks, plugins ou APIs, em vez de aceitar tudo dentro do projeto.

Rode testes automáticos em todas as contribuições e exija que passem antes do merge. A página cita automação para releases, atualização de dependências, sugestão de revisores, issues paradas e revisão de código. Mantenha os padrões simples: regras demais viram barreira para quem chega.

A Open Source Guides é direta: o esgotamento é comum entre mantenedores. Tire férias, deixe claros os horários em que você responde e avise quando estiver ausente. Cuidar de si primeiro é o que mantém o projeto vivo.

Chega um pull request que adiciona uma funcionalidade que não cabe no projeto. Seguindo a sequência da Open Source Guides:

1. Agradecer: "Obrigado por dedicar tempo a isto, o código está claro."
2. Explicar: "O listaki é de propósito um programa pequeno, só de tarefas locais. Sincronizar com a nuvem está fora do escopo."
3. Apontar a documentação: "Está no README, na seção 'O que não faz'."
4. Fechar: "Vou fechar este pull request. Se quiser, um plugin ou um fork podem fazer isso sem depender de mim."

A resposta toma menos de um minuto para escrever e deixa a porta aberta. O ponto 2 só funciona porque o escopo está escrito no README: por isso o primeiro passo é documentar. Para quem é novo e está do outro lado, veja revisar código dos outros.