Código aberto não significa comunidade aberta
(blog.feld.me)- Software de código aberto já podia ser distribuído antes de (D)VCS usando páginas HTML, arquivos txt, tarballs via FTP e apenas um contato por e-mail, e ainda era código aberto mesmo sem uma comunidade pública
- Ter uma mailing list ou canal de IRC já era sorte, mas pull request, issue, wiki, core team e Code of Conduct não eram requisitos essenciais do código aberto
- O Sourceforge ofereceu CVS/SVN e mailing lists quase de graça, facilitando o desenvolvimento em público, e depois o git venceu a disputa entre DVCS, fazendo o mundo convergir para o GitHub
- Depois do GitHub, manter software de código aberto passou a parecer trabalho não remunerado, incluindo lidar com issue, pull request fora de escopo, reclamações, demandas e até a gestão de grupos de chat, o que pode levar a burnout e perda de controle
- Um projeto não precisa ser desenvolvido publicamente; é possível desligar o issue tracker e as pull requests, usar um servidor git bare e tocar código aberto sozinho ou com um pequeno grupo de confiança
O peso da manutenção depois do GitHub
- O GitHub fez o código aberto parecer trabalho não remunerado para quem mantém projetos
- Depois de lidar no trabalho com tickets, reuniões com stakeholders, roadmap, política, distrações, prazos, métricas, KPI, mudanças de requisito, standup, one-on-one, Agile e Waterfall, a pessoa ainda chega em casa com notificações de código aberto se acumulando
- As issues se acumulam, chegam pull requests que redesenham o software em direções fora do escopo do projeto, e aumentam as reclamações e exigências
- Quando surgem grupos de chat e uma “comunidade”, a pessoa mantenedora ainda assume a responsabilidade de administrar gente impaciente e lidar individualmente com essas pessoas
- Como resultado, o código aberto vira uma segunda profissão, e quem mantém o projeto pode sofrer burnout e até perder o controle e a direção do próprio projeto
Voltar a operar de forma simples
- Alguns projetos são grandes e complexos demais e exigem gestão de equipe, mas isso é exceção, não o caso mais comum
- Se você está irritado porque pessoas novas e bots de IA estão roubando sua atenção, pode voltar ao jeito antigo
- Você pode desligar o issue tracker e as pull requests, ou operar um servidor git bare apenas para publicar o código
- Também pode trabalhar com um pequeno grupo de pessoas que você realmente conhece e em quem confia, ou tocar o projeto totalmente sozinho
- Você não precisa permitir que desconhecidos invadam seu espaço, nem adotar um Code of Conduct performático ou uma política de LLM só para constar
- Para que algo seja “código aberto”, não é obrigatório que seja desenvolvido em público
- Use as ferramentas que quiser, crie o que gostar, faça um code drop às 2 da manhã no Natal, e não se deixe arrastar para um sistema operacional que parece uma mistura de incubadora tecnológica com creche
1 comentários
Opiniões no Lobste.rs
Foi por causa desse tipo de pensamento que criei https://casuallymaintained.tech/, e gostei bastante
O exemplo mais famoso é o SQLite, que rejeita contribuições externas
Considerando que ele é usado até em aplicações de missão crítica como aeronaves da Airbus, é uma política razoável
O SQLite é open source, então você pode copiá-lo à vontade e usá-lo sem restrições, mas não é um projeto de contribuição aberta (
open-contribution)Para manter o SQLite em domínio público e evitar a mistura com código proprietário ou licenciado, eles não aceitam patches de quem não enviar uma declaração dedicando sua contribuição ao domínio público
É uma perspectiva bem refrescante
Talvez o autor esteja certo, e talvez estejamos exigindo demais dos mantenedores
Pode ser que o que esteja quebrado não seja o open source em si, mas a inflação de expectativas sobre o que o open source deveria oferecer
O aspecto social do GitHub também pode ter sua parcela nisso. Quanto mais estrelas e usuários comuns um projeto acumula, maior fica a pressão para satisfazer as novas pessoas que chegam para ver o projeto
Isso se torna especialmente perigoso quando o interesse e as demandas da comunidade não combinam com a visão inicial de quem criou o projeto
Texto relacionado: Git without a Forge: https://www.chiark.greenend.org.uk/~sgtatham/quasiblog/git-no-forge/
É uma abordagem sólida, e eu gostaria que mais gente a adotasse como padrão
Construir uma comunidade ou assumir certos tipos de responsabilidade deveria ser uma atitude excepcional e intencional
A parte em que ele chama código de conduta e política de LLM de sinalização de virtude parece um pouco deslocada, mas entendo por ser um tema sensível
Mas, se você coloca isso num repositório de uma pessoa só, sem usuários, sem comunidade e sem intenção de criar uma, aí vira sinalização de virtude
Num repositório que eu uso sozinho, não preciso de um código de conduta para mim mesmo
Eu realmente espero que essa discussão ganhe força e leve a um consenso que funcione na prática
Há muitas formas de criar software e de contribuir de maneira saudável
Só que elas podem não ser compatíveis entre si, podem não atender ao padrão elevado do open source, podem ter o custo da visibilidade e da popularidade, ou usar mecanismos diferentes como licença, self-hosting e não aceitar contribuições de código
Seria ótimo encontrar juntos um bom caminho que coloque diversão e justiça em primeiro plano no software comunitário
O estado descrito no texto é o estado natural de todo projeto open source pessoal recém-criado por alguém que não é famoso
Todos nós temos vários projetos que funcionam assim
O problema está em as pessoas não saberem o que querem obter de um projeto, ou acharem que administrar um projeto popular seria legal sem considerar direito o custo disso
Aí começa a busca por atenção, seja de forma consciente ou não
A frase “o GitHub transformou todo o open source em um emprego não remunerado para mantenedores” só é verdadeira se você deixar
Tirando a promessa vaga de fama, na maioria dos casos o GitHub não tem muita alavancagem para fazer você trabalhar em algo que originalmente não queria fazer
Isso está certo
Eu já tive um projeto que ficou um pouco popular, e foi estressante lidar com relatórios de bugs e pull requests para funcionalidades que eu não queria
Teria sido bom poder ler um texto desses naquela época
Além disso, também vale a pena ver https://gist.github.com/richhickey/1563cddea1002958f96e7ba9519972d9
Concordo fortemente com este texto no caso de projetos pequenos
Mesmo projetos maiores, quando são mais bem-sucedidos, muitas vezes não começam como comunidades abertas desde o início
Muitos dos projetos de que gosto começaram a ser desenvolvidos dentro de grandes organizações, e o ponto principal é que elas de fato usavam ativamente esse software internamente
Então os mantenedores já estavam sendo pagos
Seja um projeto pessoal ou uma equipe interna, software feito para resolver problemas cotidianos do próprio desenvolvedor parece ter mais sucesso e ser menos exploratório do que software feito em busca de fama ou monetização