Os códigos de conduta (CoC) se tornaram padrão em grandes comunidades de desenvolvimento de software open source: do Debian e Fedora ao kernel Linux e Python. Normalmente, esses documentos definem como colaboradores devem se comportar, explicam consequências para assédio ou má conduta e estabelecem canais de denúncia. A ideia é criar ambientes mais acolhedores, especialmente para grupos menos representados.
Mas Eric S. Raymond, autor do clássico The Cathedral and the Bazaar e um dos fundadores da Open Source Initiative (OSI), acredita que os CoC falharam completamente. Em uma publicação recente no X (antigo Twitter), ele descreveu os códigos como “uma insanidade social infecciosa que gera drama, política e trabalho negativo”.
Segundo Raymond, os CoC não protegem as comunidades, mas servem como armas para quem quer causar confusão. Sua recomendação é: “Se o seu projeto tem um, delete. Se for obrigado a ter, substitua por uma frase simples: ‘Se você for mais incômodo de lidar do que suas contribuições justificam, será ejetado.’”
Entre anarquia e burocracia
Para Raymond, o problema não está em pedir respeito, mas na tentativa de regular tudo em excesso. Ele afirma que quanto mais detalhadas as regras, maiores as superfícies para manipulação e disputas internas. O argumento reacendeu um debate antigo: as comunidades de software precisam de normas claras para manter a inclusão, ou essas normas sufocam a espontaneidade e criam burocracia?
A fala tem impacto porque vem de alguém que ajudou a moldar o conceito moderno de “open source”. A OSI, fundada em 1998 por Raymond e Bruce Perens, consolidou a Open Source Definition, referência mundial até hoje para definir o que é ou não open source. Desde então, o equilíbrio entre liberdade criativa e responsabilidade coletiva é um dos temas centrais do movimento.
É improvável que grandes projetos abandonem seus códigos de conduta, mas o post de Raymond serve de alerta sobre o risco do excesso de burocracias em projetos que poderiam ir mais longe se o caminho não tivesse tantos bloqueios.
De toda forma, não existe solução “tamanho único”. Projetos diferentes pedem arranjos diferentes. O ponto de equilíbrio costuma nascer de três elementos: clareza (o que é aceitável e o que não é), proporcionalidade (como agir com coerência agora e no futuro quando algo sai do trilho) e legitimidade (quem decide, como e por quê). Sem isso, qualquer política, seja um CoC detalhado ou a frase única sugerida por Raymond, arrisca ser inócua ou arma de ocasião. O desafio real continua sendo o mesmo que move o open source desde os anos 1990: maximizar a colaboração e reduzir o atrito, apenas com o necessário para que as pessoas possam… escrever código.
Contribua com para o Diolinux se manter independente e crescente: seja membro Diolinux Play!