Quando a Fundação de computação nativa em nuvem (CNCF) arquivou nosso projeto OpenEBS em fevereiro de 2024, tínhamos duas opções: ir embora ou consertar os problemas identificados e nos inscrever novamente no Sandbox para começar de novo. Começar de novo é a opção mais difícil, mas é a coisa certa a fazer para os 25.000 usuários que o OpenEBS adiciona a cada mês. Aqui está o principal motivo pelo qual a CNCF arquivou nosso projeto, como o corrigimos e, ao corrigi-lo, começamos a ganhar dinheiro.
O problema da propriedade e do controlo
O cerne da nossa questão era um problema comum de governança. Cerca de 60% dos projetos da CNCF têm um patrocinador corporativo — uma empresa com fins lucrativos que financia o projeto. Quando a empresa doa o projeto para a CNCF, o projeto se torna propriedade da CNCF, e a empresa patrocinadora abre mão da propriedade e do controle.
Mas até que o projeto recrute uma comunidade, os funcionários da empresa patrocinadora geralmente ainda estão trabalhando no projeto. Muitos CEOs assumem que ainda têm propriedade e controle sobre o projeto. "Se meu pessoal está trabalhando nisso, então eu estou dando as ordens." Essa tensão de propriedade e controle levou ao nosso arquivamento e, a menos que o resolvêssemos, continuaria a ser um problema.
Como ganhar dinheiro patrocinando um projeto CNCF
Perguntamos à CNCF como resolver o problema. Um recurso útil da CNCF é o grupo de trabalho Contributor Strategy Governance do Technical Advisory Group (TAG). O copresidente Josh Berkus explica o problema e a solução mais amplos assim: "A premissa por trás do código aberto é que você pode obter adoção massiva e, então, obter receita de uma fração desses adotantes, ganhando tanto ou mais dinheiro do que vendendo software proprietário sozinho."
Essa abordagem funciona muito bem quando o software é complicado e difícil de oferecer suporte (como muitas instalações do Kubernetes).
Para o Kubernetes, uma estratégia de monetização bem-sucedida normalmente vem de uma das três fontes:
- Suporte e serviços profissionais
- Distribuições especializadas (com certificações da indústria ou integrações de plataforma)
- Um produto adjacente que fornece serviços para operar em produção em escala (como ferramentas de gerenciamento ou relatórios)
O núcleo aberto é menos comum no Kubernetes, porque você sempre está decidindo o que entra na versão de código aberto em vez da versão proprietária, e isso reintroduz o problema de propriedade e controle.
Suponha que a maioria dos seus adotantes não usaria seu software se tivessem que pagar por ele. Este é o ecossistema de adotantes que fortalece o software e dá credibilidade que a adoção massiva traz.
Para empresas e organizações maiores, pagar por suporte ou uma distribuição especializada costuma ser atraente porque encurta o tempo de colocação do produto no mercado, reduz riscos e representa apenas uma pequena parte do custo total do projeto.
Essas estratégias comprovadamente funcionam e, para nós, forneceram uma abordagem simples que justifica continuar a patrocinar o projeto sem controlá-lo.
Passando a propriedade e o controle para a comunidade
Descobrir uma abordagem de monetização para a empresa patrocinadora que não exija controle do projeto resolve metade do problema. Mas enquanto a empresa patrocinadora continua a contratar a maioria dos mantenedores e engenheiros, a tensão entre propriedade e controle continuará sendo um problema.
É aqui que a comunidade Kubernetes desempenha uma função essencial. Ao recrutar mantenedores e engenheiros da base de usuários adotantes do projeto, o projeto obtém recursos adicionais e a empresa patrocinadora consegue reduzir significativamente o custo de suporte ao projeto (dando a opção de transferir alguns dos engenheiros para trabalhar em um produto adjacente).
Crescer e manter uma comunidade requer trabalho; você não obtém uma comunidade automaticamente tendo um projeto amplamente adotado. Nossa equipe tem que se esforçar para ser inclusiva e transparente. É preciso esforço para integrar colaboradores. Também temos que participar e retribuir à comunidade Kubernetes mais ampla, e ajudar outras pessoas a terem sucesso com seus próprios projetos. Estamos apenas começando aqui, mas já podemos ver os benefícios.
O resultado
Para nosso projeto, mudamos nossa estratégia de monetização e agora temos clientes pagando por suporte e serviços profissionais. Estamos começando a recrutar mantenedores e engenheiros e vendo que há um enorme grupo de talentos que podemos chamar para ajudar.
A empresa patrocinadora estará prestes a transferir custos e, ao mesmo tempo, verá a capacidade de engenharia do projeto aumentar. Ao abrir mão do controle e da propriedade, ganhamos muito de volta. Quando terminarmos, será realmente um esforço comunitário.
O Kubernetes foi fundado com base nesses princípios — que ninguém deve possuir ou controlar a plataforma na qual a infraestrutura de amanhã será construída. Todos nós compartilharemos essa propriedade e controle.
Às vezes, esse processo é estranho ou doloroso. Às vezes, você é arquivado e tem que trabalhar para voltar. Software livre não vem de graça — temos que trabalhar juntos para construir o software, construir a comunidade em torno dele, protegê-lo e, às vezes, estamos protegendo-o de nós mesmos.
