Projetos open source brasileiros começaram a recusar patrocínio de nuvem

O e-mail chegou educado e generoso: crédito de infraestrutura suficiente para rodar toda a CI do projeto por dois anos, sem contrapartida escrita, com renovação automática. O mantenedor de uma biblioteca de processamento de dados usada por várias empresas no Brasil leu duas vezes e recusou.

"Não tinha contrapartida escrita", ele disse ao TFN. "Era esse o problema."

O mecanismo

Ninguém compra um projeto open source com patrocínio de CI. O que o patrocínio compra é dependência operacional, e dependência operacional vira poder de veto sem que ninguém precise exercer poder de veto.

Funciona assim. O projeto migra o pipeline para a infraestrutura patrocinada, porque é grátis e é melhor do que o que havia. Em seis meses, os scripts de build assumem particularidades daquele ambiente. Em um ano, a documentação de contribuição começa por "crie uma conta em". Em dois anos, sair custa um trimestre de trabalho de alguém que não tem um trimestre de trabalho sobrando.

Nesse ponto, nenhuma decisão precisa ser imposta. Basta que uma proposta seja inconveniente para o patrocinador e o custo político de levá-la adiante já é alto demais para um projeto mantido por três pessoas em fim de semana.

O que os quatro decidiram

Os mantenedores ouvidos pelo TFN, responsáveis por projetos com adoção relevante no país, chegaram a regras parecidas por caminhos diferentes.

A primeira é aceitar dinheiro, não serviço. Transferência para um fundo do projeto pode ser usada para pagar qualquer fornecedor. Crédito de plataforma só pode ser usado naquela plataforma, e é essa a diferença inteira.

A segunda é limitar o patrocínio a uma fração do custo total. Um projeto cujo pipeline inteiro é pago por uma empresa está em posição diferente de um projeto em que aquela empresa cobre 30%.

A terceira é publicar o valor recebido e a origem, sem faixa de estimativa, com número. "Se a gente não pode publicar quanto recebeu, tem alguma coisa errada com o que foi recebido", disse uma das mantenedoras.

A quarta, e a mais dura de sustentar, é manter o build reproduzível fora da infraestrutura patrocinada. Alguém precisa rodar o pipeline completo em uma máquina neutra, periodicamente, e consertar o que quebrar. É trabalho chato e é a única coisa que garante que a porta de saída continua aberta.

O contra-argumento

Existe e é forte: projeto sem dinheiro morre, e projeto morto não tem governança para proteger.

Um dos entrevistados foi honesto sobre isso. Recusar o crédito custou ao projeto uma fila de CI mais lenta e a perda de dois contribuidores que se cansaram de esperar build. A comunidade ficou menor. A independência ficou intacta e a independência não escreve código.

Não há resposta limpa aqui. Há uma pergunta que a maioria dos projetos nunca faz antes de aceitar: se este patrocínio acabar de um dia para o outro, quanto tempo levamos para voltar ao estado anterior?

Quando a resposta é "uma semana", o patrocínio é dinheiro. Quando é "um trimestre", já não é.

O que mudou no ambiente

Duas coisas explicam por que essa discussão apareceu agora.

A primeira é a onda de mudanças de licença dos últimos anos, que ensinou a uma geração inteira de mantenedores que a licença de hoje não é a licença de amanhã, e que quem controla a infraestrutura tem assento na conversa sobre essa mudança.

A segunda é mais prática. O custo de rodar CI para projetos que envolvem qualquer coisa com modelo de machine learning subiu muito. Onde antes um patrocínio de infraestrutura era um bônus, agora ele é a diferença entre existir e não existir. E aí o poder que vem junto é grande de verdade.