"Ninguém se importa se você contribui." Foi o que um amigo do Postgres me disse durante um almoço na KubeCon quando sugeri que contratar colaboradores do Postgres poderia ser um ponto de venda para os clientes. O comentário dele me surpreendeu porque durante anos acreditei no dogma do código aberto de que as contribuições de alguma forma qualificavam desenvolvedores e fornecedores a lucrar desproporcionalmente com os projetos. Isso, apesar da evidência esmagadora do contrário.
Por exemplo, ninguém se beneficiou mais do código aberto do que a AWS, mas, relativamente falando, ninguém contribuiu menos. A AWS começou a mudar, o que eu comemorei . Mas depois de falar com meu amigo, agora me pergunto se isso importa. Pode fazer os funcionários se sentirem melhor que seu empregador "retribua", mas não parece fazer a menor diferença para os clientes. Principalmente. Vale a pena falar sobre esse "principalmente".
Facilite
A AWS há muito se autointitula como o melhor lugar para executar software de código aberto, e o sucesso de seus clientes parece apoiar essa afirmação. O código aberto tem sido fundamental para a ascensão da AWS por quase 20 anos. De fato, quando eu gerenciava a equipe de marketing e estratégia de código aberto da AWS, fizemos uma pesquisa para descobrir o que os clientes mais se importavam em código aberto. Eram contribuições ou outra coisa? As contribuições entraram na lista, mas o determinante número um da "liderança" do código aberto, de acordo com os desenvolvedores entrevistados, era tornar "fácil a implantação do meu software de código aberto preferido na nuvem".
Em outras palavras, as empresas têm uma quantidade limitada de tempo; elas preferem fornecedores que removem o fardo de gerenciar suas próprias implantações de software de código aberto, independentemente de esses mesmos fornecedores serem contribuidores ativos para os projetos em questão.
Esta pesquisa em particular não envolveu clientes da AWS e, de fato, tenho certeza de que os resultados seriam os mesmos se você perguntasse aos desenvolvedores que usam o Microsoft Azure, o Google Cloud ou qualquer outro serviço de nuvem. Por mais que você ou eu possamos pensar que as contribuições para o código aberto importam, os clientes só querem fazer as coisas o mais rápido possível, pelo menor custo.
E ainda há argumentos a favor da contribuição para projetos de código aberto.
As contribuições fazem parte do produto
Voltando ao meu amigo Postgres. Embora ele tenha dito que os clientes podem não se importar que tal e tal mantenedor trabalhe para sua empresa, ter colaboradores-chave permite que sua empresa ofereça excelente suporte aos clientes.
Em um projeto administrado pela comunidade, como Postgres ou Linux, isso não significa que um empregador em particular pode ditar o roteiro, acelerar correções de bugs, etc., mas significa que eles influenciam o roteiro. Mais importante, significa que eles entendem o código e a comunidade ao redor dele e, portanto, estão melhor posicionados para saber como tecer correções de curto prazo para o cliente no projeto principal sem assumir dívida técnica. Isso também significa, mais simplesmente, que eles entendem como dar suporte ao uso do código por um cliente porque eles conhecem esse código intimamente, de maneiras que um estranho intrometido simplesmente não conhece.
Além disso, embora isso aconteça raramente, caso uma empresa veja a necessidade de bifurcar o projeto para o bem-estar do cliente a longo prazo, ter colaboradores e mantenedores principais os posiciona para ter sucesso com um fork. Esta é uma das razões pelas quais a AWS tem uma chance muito maior de sucesso com o fork do Redis, Valkey. A AWS há muito emprega uma das principais mantenedoras do Redis, Madelyn Olson.
Novamente, os forks raramente acontecem, mas contribuir para um projeto de código aberto é uma apólice de seguro sólida para os clientes de um fornecedor. Isso é algo para comercializar para os clientes? Não. É um trabalho de bastidores que, em última análise, cria um produto melhor, mas "nós contribuímos" não é um recurso do produto.
