Por Favor, Não Pergunte se um Projeto de Código Aberto Está Morto
A tensão entre mantenedores de código aberto e usuários surge quando as pessoas perguntam se um projeto está “morto”, especialmente em repositórios que parecem silenciosos ou têm issues sem resolução. Os comentaristas argumentam que os usuários precisam razoavelmente saber se o software é mantido antes de depender dele, enquanto os mantenedores enfatizam que não devem suporte contínuo e podem se sentir pressionados ou desanimados por essas perguntas. Muitos propõem sinais de status mais claros nos READMEs, melhor tooling no GitHub (arquivamento, badges, caminhos de sucessão) e formulações mais cuidadosas para alinhar melhor as expectativas de ambos os lados.
Se Perguntar “Este Projeto Está Morto?” é Falta de Educação
- Muitos argumentam que é uma pergunta perfeitamente razoável, até necessária: os usuários precisam saber se é seguro depender de uma biblioteca, especialmente para correções de segurança e mudanças disruptivas a montante.
- Outros dizem que formulações como “morto/abandonado” carregam carga emocional e soam acusatórias; eles sugerem um texto neutro como “status atual de manutenção” ou “está sendo mantido ativamente?”
- Vários comentaristas acham que o exemplo específico da questão no artigo foi educado, e que rotulá-lo como “pressão” ou “falta de educação” foi uma reação exagerada, nascida de estresse e burnout.
Manutenção, Ecossistemas e Software “Pronto”
- Alguns dizem que o software pode estar “pronto” e não precisar de commits frequentes; a falta de atividade não é, por si só, um problema.
- Outros contra-argumentam que, em ecossistemas como Node/npm ou APIs que mudam rapidamente, a degradação e os problemas de segurança em dependências tornam a manutenção contínua essencial.
- Debate sobre “code rot”: alguns culpam plataformas em mudança e a má compatibilidade com versões anteriores, em vez do código original.
Forks e Sucessão de Projetos
- Muitos consideram o fork a solução padrão quando um mantenedor não responde ou não se interessa por PRs.
- Desvantagens apontadas: múltiplos forks parcialmente mantidos, “sucessor” अस्पष्ट, fragmentação social e rebases dolorosos se o projeto original mais tarde voltar à vida.
- Outros observam que projetos importantes (Linux, BSDs, suítes de escritório, engines de navegador) surgiram de forks; o fracasso da maioria dos forks é visto como normal.
Expectativas, Comunicação e Recursos do GitHub
- Sugestão repetida: declarar claramente o status e as expectativas no README/CONTRIBUTING (por exemplo, “finalizado”, “apenas correções de segurança”, política para PRs, atitude em relação a forks).
- A flag de arquivo do GitHub é vista como uma forma útil, mas pouco usada, de indicar inatividade; alguns querem mecanismos mais ricos de status/badges e interfaces para destacar forks ativos.
- Vários dizem que desativar issues/PRs é apropriado se você não quer interação.
Responsabilidades e Saúde Mental
- Há amplo acordo: mantenedores não devem nada contratualmente aos usuários; usuários e contribuidores também não devem nada aos mantenedores.
- Ainda assim, muitos enfatizam educação básica, gratidão e ofertas de ajuda ou patrocínio.
- Alguns veem o artigo como um sinal de burnout e aconselham dar um passo atrás em vez de publicar regras prescritivas e emocionalmente carregadas do tipo “não pergunte”.