É seguro dizer que o software de código aberto teve um impacto profundo no mundo. Do Linux ao GNU e ao ecossistema Apache, grande parte do cenário tecnológico atual é alimentado de alguma forma por ferramentas que foram desenvolvidas colaborativamente em público.
Estamos no processo de construir uma comunidade de código aberto para Apache Polaris (Incubating) com a Apache Software Foundation (ASF), e gostaríamos de compartilhar algumas ideias sobre o poder do código aberto, por que ele importa e como começar um projeto de código aberto. Mas primeiro, precisamos definir o que realmente é código aberto.
O Verdadeiro Significado do Código Aberto
Por um lado, código aberto significa simplesmente qualquer software para o qual o próprio código-fonte é "aberto" ou publicamente disponível. Essa é a definição mais restrita. Mas, como você pode esperar, a realidade é muito mais sutil. Correndo o risco de simplificar demais, postulamos que há duas nuances principais que importam: licenças de código aberto e governança de código aberto.
A licença de código aberto dita o que uma pessoa tem permissão para fazer com o código. Essas licenças variam do extremo mais permissivo do espectro, como MIT e Apache ("Faça o que quiser, mas não pode nos processar, e por favor inclua os direitos autorais e algumas outras informações"), ao extremo mais restritivo, como a Licença Pública Geral ou GPL ("Você deve sempre incluir o código-fonte e também qualquer coisa de código fechado que você vincular a este código e enviar aos clientes agora é legalmente obrigada a ser de código aberto, haha!").
Em algum lugar no meio está a Business Source License ou BSL ("Você é livre para usar isso, desde que não esteja ganhando dinheiro vendendo, porque somente nós temos permissão para fazer isso"). Indivíduos são bem aconselhados a gastar tempo se familiarizando com as opções de licença que existem e escolher uma que funcione melhor para suas necessidades.
A governança de código aberto então dita as regras de como uma determinada base de código aberto ou projeto evolui ao longo do tempo, configurando uma estrutura para como a comunidade que desenvolve o projeto interage e colabora. Normalmente, um dos aspectos mais críticos da governança de código aberto é quem decide o que acontece com o projeto.
Existe um ditador benevolente, como o Linux antigamente? Existe uma única empresa conduzindo tudo como a dbt Labs ou a Redpanda Data? Existe um grupo de proprietários confiáveis que coletivamente tomam decisões de alguma forma como fazem com o Apache? Se houver um grupo de proprietários confiáveis, quem se torna um proprietário?
Há muitas perguntas a serem respondidas ao considerar uma abordagem de governança, e nenhuma abordagem é necessariamente melhor que a outra. Tudo depende de quais são seus objetivos para o projeto ao longo do tempo.
Escolhendo o que funciona para suas necessidades
Depois que você tiver uma noção do que é código aberto, a próxima pergunta a se fazer é por que abrir o código da sua base de código em primeiro lugar? Embora existam muitas motivações potenciais, algumas das principais são:
- Mais contribuidores: Com software de código aberto, o número de desenvolvedores trabalhando em um projeto é mais direcionado por quanto interesse da comunidade ele gera, em vez da quantidade de financiamento disponível para contratar engenheiros.
- Mais perspectivas: Assim como muitas coisas na vida, a exposição a um conjunto mais diverso de perspectivas e ideias geralmente leva a melhores resultados.
- Mais adoção: Quando o desenvolvimento de software é conduzido pela comunidade e colaboração, é muito mais provável que resulte em padrões estáveis que vejam ampla adoção do que múltiplos esforços concorrentes de código fechado.
- Mais bem: Ao tornar seu software aberto, você contribui para o bem maior, construindo algo de valor e oferecendo-o gratuitamente.
Por outro lado, há razões pelas quais você pode não querer trabalhar com código aberto:
- Menos controle: Embora isso dependa muito do modelo de governança, o objetivo com muitos modelos de governança de código aberto é evitar que qualquer principal exerça muito controle sobre a direção de um projeto. A comunidade vem primeiro.
- Menos vantagem privada: Quando você dá a fonte de graça, pode ser mais desafiador monetizar, embora existam licenças voltadas para negócios como a BSL que tentam encontrar um equilíbrio entre aberto e fechado.
- Menos velocidade: Isso não é de forma alguma um dado adquirido com software de código aberto, mas ao abrir o desenvolvimento para uma comunidade maior, e em particular ao enfatizar as necessidades da comunidade sobre a necessidade de se mover rapidamente, isso pode potencialmente resultar em desenvolvimento de código aberto se movendo mais rápido do que o desenvolvimento de código fechado proporcional. No entanto, isso também pode ser compensado pelo grande número de contribuidores ativos se o projeto crescer o suficiente.
Depois de tomar a decisão de abrir o código, os próximos passos dependem muito da abordagem que você quer adotar. Vamos nos concentrar na abordagem com a qual estamos mais familiarizados: abrir o código por meio da ASF.
Por que a Apache Software Foundation?
A ASF existe para fornecer software para o bem público. Seu ethos central é o conceito do poder da comunidade sobre o código, conhecido como o "jeito Apache". Essa filosofia enfatiza a importância de uma comunidade saudável, colaborativa e engajada no sucesso e na sustentabilidade de um projeto de código aberto, em vez de focar somente no código em si. Milhares de pessoas ao redor do mundo contribuem para os projetos de código aberto da ASF todos os dias, tornando a ASF uma das maiores fundações de código aberto.
A ASF é uma instituição de caridade pública sem fins lucrativos, corporação de membros 501(c)(3), que fornece suporte legal, de branding, imprensa, arrecadação de fundos, infraestrutura e mentoria comunitária comprovada para os muitos projetos Apache. Desde o lançamento inicial do Apache Hadoop, a ASF hospeda muitos projetos de código aberto vinculados ao ecossistema de big data.
O Apache Iceberg é um dos muitos projetos de código aberto neste ecossistema que exemplifica o poder da comunidade por meio do crescimento acelerado de contribuições de diversas perspectivas e origens. No contexto do ecossistema de big data, o Apache Iceberg é uma peça importante porque define uma especificação para abstrair arquivos como tabelas de uma forma que fornece garantias de confiabilidade, otimizações de desempenho e pode ser integrado a muitas outras ferramentas no cenário.
O Apache Iceberg também inclui uma especificação padronizada para gerenciar e organizar metadados sobre tabelas Iceberg. No entanto, o Iceberg não fornece uma implementação de catálogo de referência porque excede o escopo do projeto. Para completar a solução Iceberg, fazia sentido ter uma implementação de catálogo de código aberto "próxima" ao Iceberg no Apache. É por isso que o Polaris pousou como um podling na incubadora ASF.
O Processo da Incubadora Apache
O Apache Incubator é um gateway para projetos de código aberto que buscam se tornar parte do ASF. Ele ajuda esses projetos de entrada (chamados de "podlings") a adotar o estilo Apache de governança e operação, ao mesmo tempo em que os orienta pelos serviços ASF disponíveis para esses projetos para que eles possam se tornar projetos ASF de alto nível. Há instruções claras e detalhadas para todo o processo no Incubator Cookbook, mas daremos uma visão geral dos principais destaques aqui.
A melhor maneira de começar é encontrar um campeão, embora não seja obrigatório, para ajudar a guiar o projeto. Este é alguém do Incubator PMC (IPMC) que está interessado em ver seu projeto chegar ao ASF e está disposto a ajudar a guiá-lo pelo processo e defender sua causa.
No nosso caso, JB Onofré é o campeão do Polaris. Se você já fez algum trabalho no mundo Apache (ou mesmo se não fez), há uma boa chance de que você já conheça alguém no IPMC — há 284 membros do PMC no momento em que este artigo foi escrito, e eles são tipicamente pessoas que estão profundamente envolvidas em projetos de código aberto do Apache há vários anos, então suas redes comunitárias são geralmente bem grandes.
Se você encontrar alguém que você conhece nessa lista, vale a pena entrar em contato para ver se eles têm alguma sugestão para você sobre a melhor forma de proceder. Mesmo que eles não estejam em posição de agir como um campeão, eles podem conhecer alguém que esteja. Se você descobrir que não conhece ninguém, a melhor coisa a fazer é simplesmente enviar um e-mail diretamente para a lista de discussão do IPMC, se apresentar e apresentar seu projeto, e deixá-los saber que você está procurando por alguém que possa estar disposto a ser um campeão.
Depois de ter um campeão alinhado, o próximo passo é começar a redigir uma proposta de Incubadora seguindo o modelo de proposta de podling. As propostas incluem seções descrevendo o projeto, explicando como os objetivos do projeto se alinham com os da ASF, abordando preocupações comuns com os podlings propostos e listando as pessoas que são desenvolvedores ativos no momento. A proposta será usada para fornecer uma visão geral do projeto e ajudar a justificar por que você acredita que ele pode ser um bom ajuste no ecossistema Apache.
Outra parte fundamental da proposta é a lista de mentores. Mentores são membros do IPMC que, assim como o campeão, se voluntariam para ajudar a guiar e treinar o podling durante o processo de incubação. Seu campeão pode ajudar você a encontrar alguns mentores adequados se você não tiver conexões.
Uma vez que sua proposta esteja redigida, o próximo passo é levá-la ao IPMC para discussão. Uma forte ênfase é dada ao alinhamento do podling com a comunidade sobre a filosofia do código, diversidade demonstrada de contribuição de múltiplas empresas ou organizações patrocinadoras e uma abertura colaborativa em todos os aspectos do trabalho.
Como parte da discussão, o comitê pode solicitar alterações na proposta. No nosso caso, acabamos fazendo algumas pequenas alterações na lista proposta de committers para se alinhar mais de perto com a convenção comum. Se houver preocupações significativas com a proposta, alterações mais drásticas podem ser necessárias, ou o próprio projeto pode precisar gastar mais tempo se preparando e voltar outra hora.
Supondo que a discussão do IPMC prossiga de forma agradável, então em algum momento será apropriado iniciar uma votação. Seu campeão pode ajudar você a saber quando é um bom momento para iniciar a votação, e provavelmente será a pessoa a fazê-lo (embora tecnicamente qualquer pessoa envolvida na proposta de podling possa). A votação dura pelo menos 72 horas e será uma votação majoritária computada entre os votos vinculativos lançados pelos membros do IPMC.
A convenção típica do Apache é iniciar uma votação somente quando parece haver consenso geral entre as partes em discussão. Quando esse processo é seguido, geralmente há uma chance razoável de que a votação oficial seja aprovada. Mas se não, as partes dissidentes terão que fornecer feedback construtivo, e o projeto pode voltar com uma nova proposta mais tarde, depois que as deficiências forem abordadas.
Caso a votação seja bem-sucedida, seu defensor e mentores ajudarão você a orientar a logística de configuração do projeto na infraestrutura do Apache: repositório GitHub, listas de e-mail, documentação e suporte jurídico.
Neste ponto, o foco muda para aumentar a comunidade do projeto e adotar o jeito Apache. Isso inclui dar suporte a novos contribuidores e fazê-los crescer para committers e, eventualmente, membros do PMC, publicar lançamentos de podling regulares, manter a documentação e refinar consistentemente tanto o código quanto o processo de lançamento para melhor atender às necessidades dos usuários finais.
Quando o projeto atingir maturidade suficiente, seu campeão ou mentores podem recomendar ao IPMC que o projeto está pronto para graduação. Se o IPMC votar afirmativamente, então o projeto se forma na Incubadora e se torna um novo Apache Top Level Project (TLP).
O poder do Código Aberto
Ao doar coletivamente o Polaris para a ASF e ter indivíduos de várias empresas contribuindo, há uma comunidade mais ampla para apoiar sua inovação contínua. Vemos o código aberto como o futuro do desenvolvimento de software, capacitando os desenvolvedores a inovar mais rápido com serviços poderosos dos quais toda a indústria se beneficia. Ao priorizar a transparência, promover a colaboração e encorajar a iteração rápida, o código aberto rapidamente se tornou uma maneira de fato para os usuários impulsionarem o progresso tecnológico por meio de um esforço coletivo de conhecimento compartilhado.
