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
2 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
Opiniões do Hacker News
Mesmo em comunidades muito fechadas, muitas vezes aceitam contribuições se você mandar um e-mail educado
Houve um desenvolvedor de open source que, cansado de assédio, chegou a desativar pull requests e várias funcionalidades do repositório, e nessa época também ganhou fama de ser uma pessoa muito difícil
Sem saber desse contexto, eu simplesmente achei que o projeto funcionava assim mesmo, procurei um pouco até encontrar um endereço de e-mail e enviei um patch informal com uma mensagem educada e sem pressão, deixando claro que ele podia usar ou ignorar
O desenvolvedor respondeu agradecendo, explicou a situação, pediu desculpas por qualquer desconforto, disse que não conhecia outra forma de lidar com aquilo além de trancar tudo daquele jeito e, claro, acabou incorporando a correção
Achei que este texto fosse tratar do problema generalizado de projetos de software livre forçarem discussões ou relatórios de bugs pelo Discord
Por uma ou duas semanas pareceu haver algum interesse em migrar para outras ferramentas, mas isso já esfriou e no fim parece que todo mundo desistiu e voltou para o Discord
O Discord não é completamente horrível, mas é efêmero e exige um web app enorme e inchado
Como um veterano de barba grisalha, gosto da postura do autor
Sou velho o bastante para lembrar da época em que eu me sentava diante dos anciões da ARPANET, quando só existia o 1 e era preciso entalhar metade deles à mão para virar 0
No jeito antigo de desenvolver software, os projetos em geral eram escritos ou mantidos por uma ou duas pessoas, e a internet inteira conhecia os endereços de e-mail delas e enviava relatórios de bugs diretamente
Alguns projetos eram discutidos em IRC ou listas de e-mail, e em geral as pessoas agiam com profissionalismo; caso contrário, eram removidas da lista ou iam parar nos arquivos de bloqueio do iirc e do pine
O ponto central é que, em qualquer momento, o grupo de desenvolvedores ativos era muito pequeno
Estou falando principalmente de pequenos utilitários como make, Sendmail, sed e awk, e até o Perl, antes de 1990, parecia ser basicamente Larry Wall e tchrist
O gcc era a exceção maluca, em que milhares de pessoas enviavam patches e, para entrar no upstream, ainda era preciso se coordenar bem com o RMS
As ferramentas novas ajudam equipes maiores a interagir continuamente, e há grandes vantagens no modelo de equipes pequenas que não se importam com qualquer pessoa da internet a menos que ela aposte um rim e envie um patch
Só que esse modelo não é vantajoso para atrair pessoas para o trabalho, então tudo bem seguir pelo modo antigo, mas a equipe será pequena e talvez seja mais difícil atrair usuários
Ainda assim, isso não é problema do usuário; eu uso software para atender meu caso de uso e o publico como open source porque talvez também seja útil para outras pessoas
Falando de forma mais concreta, open source promete apenas as quatro liberdades básicas(https://en.wikipedia.org/wiki/The_Free_Software_Definition)
Fora isso, literalmente não promete mais nada, e isso inclui não ser gratuito
Software livre e open source pode cobrar dinheiro e deve cobrar; o “free” aqui não tem a ver com preço
Tenho visto de forma até positiva os vários ataques recentes à “cadeia de suprimentos” de comunidades open source, porque, numa visão otimista, espero que isso faça as pessoas perceberem que open source não é uma cadeia de suprimentos
Mais detalhes em https://lobste.rs/s/cxwidw/no_one_owes_you_supply_chain_secu...
Se você não está pagando um fornecedor, ou não tem um contrato com garantia de cronograma, então você não tem uma cadeia de suprimentos
Quase toda licença FOSS traz a cláusula “este software é fornecido sem garantia”, e cadeia de suprimentos implica garantia, portanto FOSS não é cadeia de suprimentos
Estou cansado de vir aqui e ver “open source” sendo tratado como se tivesse “valores morais”, misturando conceitos roubados do software livre como se fossem a mesma coisa
Open source é só grandes empresas de software se aproveitando de um monte de voluntários
O pessoal de código de conduta só está aí para causar problema
Basta ver debates do tipo botão vermelho/botão azul: aquele nível de veneno só faz sentido se o botão realmente existisse ou se as pessoas gostassem de agir com maldade
Defensores bem-intencionados de código de conduta falam de liberdade de associação e liberdade de expressão
A questão é se tudo bem uma plataforma banir alguém só porque não gosta da pessoa, ou se isso deveria ser tratado apenas com a prática pragmática das listas de e-mail de “vamos ser gentis”
Claro, tudo depende de quem tem o poder de decidir, mas isso vale para qualquer projeto
Não dá para exigir participação no projeto dos outros impondo condições que contradizem os desejos da liderança e, ao mesmo tempo, querer ter liberdade de associação
Meu palpite é que, quando o autor disse “não precisa de um Code of Conduct ostensivo”, talvez quisesse dizer que, em projetos pequenos, se você só quer compartilhar algo com o mundo e deixar aberta a possibilidade de aceitar contribuições externas mais tarde, não precisa montar um código de conduta antes mesmo de enfrentar uma situação real
Não há necessidade de quebrar a cabeça com um problema puramente hipotético
O motivo de existir código de conduta é que a alternativa seria punição arbitrária para violações arbitrárias, ou então uma anarquia total de spam
Não consigo entender como as mesmas pessoas que antes pregavam netiqueta agora são tão contra clareza e comunidades saudáveis
Pensando bem, talvez seja a Goomba fallacy, e quem despreza código de conduta talvez sejam as mesmas pessoas que passavam os anos 1990 espalhando flame wars e spam na Usenet
Open source não é apenas uma escolha de licença
Foi uma reformulação do software livre para parecer mais atraente a empresas, e a essência do open source está na ideia de que desenvolver software em colaboração com o público é mais eficaz do que empresas fazerem tudo de forma fechada
Portanto, open source implica uma comunidade aberta
Se você quer apenas jogar o código para o público sob uma licença permissiva, mas não quer desenvolvimento colaborativo, claro que pode fazer isso, e esse código é open source
Abrir o código é algo bom, e você não tem obrigação de fazer mais do que isso, mas isso não é agir conforme o propósito para o qual o open source foi concebido, e ignora uma parte de sua essência
Pessoas que veem código open source e presumem desenvolvimento colaborativo não estão sendo irracionais
Esse é o objetivo do movimento open source
Tudo bem se essa suposição não se aplica ao seu software, mas quem está rompendo a norma social não são elas, e sim você
Eu penso em Stallman, no driver de impressora e em usuários serem donos do próprio trabalho, então esse tipo de afirmação sobre o propósito do open source me soa errada
https://en.wikipedia.org/wiki/The_Open_Source_Definition
Não há absolutamente nada ali sobre desenvolvimento colaborativo
As pessoas ficam emocionais e muitas vezes querem acolher novos usuários, ou usuários que não querem aprender o básico
É melhor manter uma relação separada do fórum de suporte, mas rígida, com respostas em tempo hábil e sem apego
coreboot e MrChromebox são bons exemplos; ele responde só quando necessário
Concordo, e acrescento mais uma: você também não precisa criar uma página de marketing para convencer as pessoas a usar seu software
Em vez disso, ou junto com isso, também pode explicar todas as razões pelas quais não se deve usar esse software
Quanto mais usuários, mais problemas
Um aplicativo FOSS não precisa necessariamente ser distribuído publicamente, isso é apenas uma expectativa social comum
Ser FOSS também não significa que o código tenha de ser fornecido a quem não é cliente, e quem decide quem é cliente é o desenvolvedor
FOSS incentiva vender software por dinheiro, e você pode vender até software de outra pessoa que originalmente era gratuito (veja https://www.gnu.org/philosophy/selling.en.html)
Open source com licença não livre continua sendo open source, mas não é FOSS, e o desenvolvedor não precisa ter vergonha de escolher uma licença open source não livre se quiser ganhar mais dinheiro com o software ou impor restrições adicionais que lhe favoreçam
Isso também pode ser copyleft
Em resumo, nós criamos LICENSE.md e dependemos muito disso, mas ninguém pensou em criar um SOCIAL.md
Quando alguém diz “open source”, muita gente supõe: “o autor fez isso pelas pessoas, pela sociedade e por todos ao redor, e se importa com o desenvolvimento do projeto, com adicionar novos recursos, especialmente os que eu preciso, e com melhorias para o benefício de todos os usuários. Se não fosse assim, por que tornar público?”
Mas isso é apenas a expectativa social mais comum sobre FOSS, e está longe de ser o único caso possível
A falta de distinção entre open source técnico e open source social é uma das principais causas de desentendimentos, discussões e, no fim, de burnout causado por expectativas sociais desalinhadas
Antes eu precisava explicar isso e essa diferença para uma multidão irritada, mas recentemente vi no texto de Jeffrey Paul https://sneak.berlin/20250720/the-agpl-is-nonfree/ uma comparação entre código open source e um presente
Minha explicação acabava sendo: “se você não gostou do presente ou ele não serve para você, jogue fora e esqueça”
Há apenas algumas poucas licenças aprovadas pela OSI que a FSF não considera software livre
Basta olhar a longa lista de licenças de software livre incompatíveis com a GPL em https://www.gnu.org/licenses/license-list.html
Além disso, “open source não-FOSS” não faz sentido, porque FOSS significa literalmente Free and Open Source Software
Agora ele vai quase direto para o GitHub junto com executáveis prontos para qualquer um usar, sem precisar passar por sites duvidosos ou pipelines de build estranhos
Sem “comunidade”, sem política, sem código de conduta, sem pull requests nem issues, sem wiki, sem equipe central: parece um paraíso
Hoje em dia sinto que há comunidade demais a ponto de prejudicar o próprio projeto
Indo além, não consigo me lembrar de uma única vez em que uma comunidade tenha ajudado de alguma forma um projeto open source
Se o objetivo é maximizar o controle sacrificando a qualidade, tudo bem
Só fico em dúvida se, nesse caso, faz sentido estar procurando FLOSS