Comunidade open source: mito ou realidade?

Lembre de seu projeto de código aberto favorito, e as chances são boas – muito boas – de que um pequeno número de colaboradores seja responsável pela grande maioria do desenvolvimento significativo. As probabilidades são tão boas que a maioria desses colaboradores trabalha para apenas um ou alguns fornecedores. É dessa forma que funciona o código aberto hoje, e como tem sido nos últimos 20 anos.

Então isso significa que o código aberto é realmente apenas um software comercial com outro outro nome? Não. Mas significa que o estereótipo popular de uma comunidade ampla se unindo para criar software é um mito. A realidade do código aberto é diferente do mito, mas ainda é uma boa alternativa positiva ao software comercial.

Por que apenas alguns desenvolvedores pagos pelo fornecedor fazem quase todo o trabalho?

Treze anos atrás, procurei em pesquisas acadêmicas que mostravam como o navegador Firefox da Mozilla e o Apache HTTP Server eram desenvolvidos por um pequeno grupo de colaboradores. Enquanto profissionais focavam em temas como correções de bugs, o trabalho de desenvolvimento central para esses e praticamente todos os outros projetos era feito por um talentoso grupo.

Hoje, uma análise de Fintan Ryan, da Redmonk, sobre projetos hospedados na Cloud Native Computing Foundation, mostra que nada mudou. O Kubernetes é o mais famoso locatário da CNCF, com o Google e a Red Hat contribuindo com a maior parte do código, mas os outros projetos CNCF menos conhecidos seguem esse mesmo padrão. De fato, talvez a única surpresa real nesse fato de contribuições concentradas é que o padrão permaneceu constante por tanto tempo.

Olhe para qualquer projeto da CNCF, e você verá que praticamente todas as suas contribuições vêm de menos de dez pessoas. Na verdade, se você aprofundar mais, verá que a maioria do trabalho é feita por apenas duas pessoas em qualquer projeto.

Como Ryan escreveu: “É justo dizer que, para quase todos os projetos do CNCF, fornecedores específicos respondem pela maior parte do trabalho de desenvolvimento que está sendo feito. Isso não quer dizer que isso seja algo ruim. É apenas uma declaração da realidade. Embora a ampla comunidade em torno dos projetos possa ser grande, o número de contribuidores principais significativos é relativamente pequeno, e o número de colaboradores verdadeiramente independentes é ainda menor. Esse padrão é comum em muitos projetos de código aberto.”

Não apenas “muitos” projetos de código aberto – todos eles. Não consigo pensar em um contra-exemplo significativo. Para projetos grandes e diversos como o Linux, se você descascar os contêineres gerais e contar os contribuidores para os subprojetos, verá o mesmo fenômeno: alguns desenvolvedores, quase todos empregados por fornecedores, geram uma grande porcentagem das contribuições principais.

Quanto ao motivo pelo qual a maioria desses desenvolvedores seria financiada por fornecedores, isso também é fácil de explicar: os desenvolvedores também precisam de renda e só podem contribuir muito se forem pagos para isso. As empresas, seguindo seu próprio interesse corporativo, empregam desenvolvedores para trabalhar em projetos que ajudam seus negócios.

Fornecedores inteligentes entendem como usar isso para sua vantagem. A Red Hat, por exemplo, dedicou parte de sua mais recente chamada de ganhos para promover suas contribuições do Kubernetes (perdendo apenas para o Google). Como o CEO Jim Whitehurst argumentou, essas contribuições permitiram que a Red Hat influenciasse o roteiro da Kubernetes, bem como melhor atendesse seus clientes. Contribuições, em suma, dão uma vantagem competitiva na venda de Kubernetes.

O que “comunidade” realmente significa para código aberto

O conceito de “comunidade” que alimenta o open source é apenas uma quimera? A resposta fácil é “não”. Mas essa também é a resposta difícil. O código aberto sempre funcionou dessa maneira.

O interessante é quão fortemente as “regras” centrais de participação de código aberto persistiram, mesmo que o open source tenha se tornado procedimento operacional padrão para uma enorme faixa de desenvolvimento de software, seja por fornecedores ou empresas que criam software para atender às suas necessidades internas.

Embora possa parecer que esse modelo de contribuição de fonte aberta que depende apenas de alguns contribuidores principais de grande parte do código não seria sustentável, o oposto é verdadeiro. Cada fornecedor pode ter interesse particular em apenas alguns projetos, comprometendo o código com aqueles, enquanto “livre” em outros projetos para os quais deriva menos valor estratégico. Dessa forma, o código aberto persiste, mesmo que não seja tão “aberto” quanto os proponentes às vezes sugerem.

O código aberto é diferente de um produto proprietário? Afinal de contas, ambos podem ser categorizados por contribuições de poucos ou até mesmo apenas um fornecedor.

Sim, o código aberto é diferente. De fato, a diferença é profunda. Em um produto proprietário, todo o compromisso é ditado por um fornecedor. Em um projeto de código aberto, especialmente conforme licenciado sob uma licença permissiva, como o Apache 2.0, há sempre a opção de um novo desenvolvedor ou fornecedor entrar e alterar esse equilíbrio. O Kubernetes é um ótimo exemplo: o Google começou como o único contribuidor, mas a Red Hat (e outras) rapidamente seguiram.

Em suma, há pouco a temer e muito a celebrar em como funciona o código aberto. De fato, é precisamente essa busca auto-interessada de benefícios corporativos (ou pessoais) individuais que deve manter o florescimento do código aberto nas próximas décadas.

Como deve ser evidente 20 anos após a ascensão do código aberto, o modelo funciona tanto no nível da comunidade quanto no nível do fornecedor. Será que vai funcionar por mais 20? Sim.