Por que seu projeto de código aberto definitivamente não deve ser o próximo Kubernetes

Não existe uma definição única de sucesso em projetos de código aberto.

Todo mundo está em código aberto nos dias de hoje. A Microsoft acaba de lançar seu software 3D Movie Maker sob uma licença de código aberto. O Spotify tem uma série de projetos que lançou e para os quais contribui, e acaba de anunciar um fundo para apoiar mantenedores de projetos. Há até código de mecanismo de jogo da Idade Média (1998) sendo de código aberto.

VEJO: Kit de contratação: desenvolvedor back-end (TechRepublic )

Com esses projetos e milhões de outros disponíveis, é uma pergunta justa a se fazer… por quê? Ou melhor, por que a grande maioria desses projetos é importante e para quem? A maioria dos projetos, afinal, nunca será Kubernetes.

Depois de mais de duas décadas em código aberto, no entanto, estou começando a perceber que esta é a pergunta errada.

O exemplo do fogo de artifício

Veja o Firecracker, um projeto de microvirtualização de código aberto que a AWS lançou em 2018. O Firecracker foi quase universalmente saudado como uma tecnologia legal… e depois praticamente desapareceu da vista do público. Escrevi sobre alguns sucessos iniciais da comunidade, mas mesmo isso (Weave Ignite para melhorar a facilidade de uso do Firecracker, entre outras coisas) veio de um parceiro próximo da AWS. Para dar ao Firecracker mais peso na comunidade, sugeri que a AWS seguisse o Google e abrisse a governança em torno do Firecracker, não apenas seu código.

AWS não ouviu, mas, não pela primeira vez, minha opinião não parecia importar. (Essa é uma maneira educada de dizer que talvez eu estivesse errado.)

Avanço rápido para 2022, e o Firecracker está sendo usado silenciosamente em muitos lugares legais. Digo “silenciosamente” porque, bem, por que alguém gritaria sua infraestrutura dos telhados? Mas quando perguntei, alguns usuários interessantes surgiram, como Stripe, Fly.io, System Initiative e muito mais. Claro, ainda é verdade que a maioria dos colaboradores do Firecracker são empregados pela AWS.

Mas mesmo que o Firecracker continuasse sendo uma comunidade de um (AWS), sem dúvida valeria a pena. Na verdade, foi basicamente isso que argumentei enquanto trabalhava para a AWS, indicando que havia motivos claros voltados para o cliente para o Firecracker de código aberto, independentemente do envolvimento da comunidade. O código aberto garantiu que o Firecracker funcionasse bem com a comunidade Linux e possibilitou “ganhos compostos de produtos” mais apertados para os clientes.

Milhões de fogos de artifício

Agora jogue este exemplo do Firecracker vezes os mais de cem milhões de repositórios GitHub (e outros de código aberto). Não se trata de ser o próximo Kubernetes. Para cada projeto de código aberto, trata-se de atender às necessidades do desenvolvedor individual, de uma empresa ou de uma comunidade mais ampla.

Às vezes, essas necessidades podem ser grandes. Em uma conversa que tive com o líder de engenharia da Lyft e fundador da Envoy, Matt Klein, ele enfatizou que, “Para a maioria das pessoas que abrem algo, é na verdade um negativo líquido” porque “se eles não investirem nisso, se não fazer todas essas coisas [like PR, marketing, and hiring], eles vão apenas jogar algo por cima do muro.” Para Klein, obter um envolvimento significativo de todo o setor na Envoy ajudou a fazer o projeto valer o investimento que ele (e, por extensão, Lyft) havia feito.

VEJO: Mais de 40 termos de código aberto e Linux que você precisa conhecer (TechRepublic )

Mas, sem dúvida, nem todos precisam obter esse tipo de retorno. No caso do Firecracker, o código aberto e apenas a colaboração dos clientes teria sido suficiente, como raciocinei. Para o Google, por outro lado, que estava tentando promover uma realidade multicloud por meio do Kubernetes, ele precisava ser grande. Cada projeto terá diferentes necessidades e diferentes medidas de sucesso.

Então você não é o próximo Kubernetes? Isso é bom. Nem você é o próximo Firecracker? Bem também. Para desenvolvedores de código aberto, a chave é descobrir o que um projeto saudável significa para suas necessidades específicas e não se distrair com as definições de sucesso dos outros.

.