Resoluções para código aberto em 2024 – O que precisa mudar?

Nos últimos anos, o código aberto tornou-se cada vez mais polarizado. De um lado, estão aqueles comprometidos com a definição de código aberto da Open Source Initiative (OSI). Por outro lado, vários fornecedores comerciais de código aberto migraram para licenças que não são aprovadas pela OSI.

O que isso significa para o código aberto em 2024? Como pode a comunidade de código aberto proteger a sua posição e garantir que o software de código aberto continue a ser a primeira opção para novos projetos de software?

Resolução nº 1: houve uma perda de confiança no código aberto. Temos que consertar que as empresas lançam seu software sob uma licença de código aberto para obter massa crítica, aumentar suas comunidades e desenvolver uma base de clientes potenciais de forma mais eficiente. No entanto, eles veem concorrentes usando o mesmo software para criar seus próprios produtos ou serviços que concorram com eles. Muitos grandes nomes do código aberto mudaram para uma licença de código não aberto para proteger sua participação no mercado e impedir concorrentes. No entanto, também prejudicaram a reputação do código aberto em geral. Esses fornecedores desejam os benefícios que o código aberto oferece em termos de comunidade, alcance de mercado e acesso de desenvolvedores, mas não querem abrir mão de seu controle e querem bloquear os concorrentes.

Para aqueles de nós que acreditam no código aberto, isso é doloroso. O software de código aberto é valioso devido à abordagem comunitária que suporta e porque mantém o controle nas mãos dos desenvolvedores que escolhem o software. Sem confiança no código aberto como base para o desenvolvimento da comunidade e acesso ao software, todos perdem.

A resposta é que precisamos de mais abordagens de código aberto que reflitam as necessidades da comunidade, e não de uma única empresa. Temos de nos afastar do modelo de financiamento de capital de risco que exige crescimento a todo custo seguido de uma IPO ou aquisição. As fundações de código aberto representam as necessidades da comunidade e de todos os membros envolvidos. Eles podem atuar como administradores de projetos depois de atingirem essa massa crítica e representarem a comunidade de forma mais eficaz.

As empresas individuais também podem melhorar a forma como gerenciam e contribuem para a comunidade de código aberto, juntamente com suas próprias necessidades comerciais. Empresas como Confluent e DataStax são exemplos de sucesso de como separar o projeto de código aberto, gerenciado pela e para a comunidade, e os produtos direcionados aos clientes. Em 2024, mais empresas de código aberto terão de seguir o seu exemplo e construir modelos de negócio e apoio comunitário em conjunto, em vez de tratá-los como objectivos separados.

Resolução nº 2: Temos que falar sobre nossa abordagem para definir código aberto Nos últimos anos, tem havido muitos apelos para evoluir a definição de código aberto (OSD), que foi elaborada antes do advento da computação em nuvem e 'como um Provedores de serviço.

As empresas que usam licenças como a Server Side Public License (SSPL) ou a Elastic License argumentam que estão protegendo seus projetos e mantendo-os viáveis, em vez de permitir que sejam explorados por concorrentes que não pagam à comunidade. Outros argumentam que o código aberto permite que os criadores de malware e outros agentes mal-intencionados se beneficiem do software desenvolvido pela comunidade, por isso devemos restringir quem poderia potencialmente usar esses projetos. Esses argumentos têm alguns pontos positivos, mas vão contra o ethos primário do código aberto de que todos deveriam ser capazes de usar software para projetos como acharem adequado.

No entanto, o código aberto não pode ficar parado indefinidamente. O que começou há décadas com base no trabalho de um pequeno mas unido grupo de entusiastas de Software Livre e de Código Aberto cresceu e evoluiu para vários grupos com necessidades e visões diferentes. Os proponentes de licenças de origem disponível com restrições éticas ou de não concorrência não se consideram no mesmo grupo do software proprietário, onde você não tem acesso ao código-fonte e pode ser impedido de fazer outras coisas também.

O OSD fornece clareza sobre o que pode ser considerado código aberto e o que não é. No entanto, é fácil ver isto como dois campos que se enfrentam, quando a verdade é que existem muito mais opções disponíveis. Há uma enorme diferença no que você pode realmente fazer com software licenciado sob a licença BSD em comparação com AGPL 3.0. Cada uma dessas licenças existe por um motivo. A diferença é que o código aberto envolve mais do que acesso gratuito ao software, embora esse seja um grande ponto positivo para muitos que o utilizam. Em vez disso, trata-se de controle.

O código aberto deve ser muito mais do que apenas a licença usada para um determinado software; trata-se da comunidade, do modelo de governação para o futuro do projecto e do valor que o projecto pode criar ao longo do tempo. No entanto, a licença é o que fornece controle sobre como esse software pode ser usado. Sem esta discussão aberta e franca sobre o futuro do código aberto, corremos o risco de perder o que é tão importante sobre o código aberto em primeiro lugar. Sem uma forte comunidade de código aberto, corremos o risco de devolver o controle aos fornecedores sobre o que pode ou não ser feito com o software.

Resolução nº 3 – Temos que pensar mais sobre o futuro dos projetos, bons e ruins. Na indústria de tecnologia, as mudanças ocorrem o tempo todo, mas é difícil prever onde ocorrerá o próximo grande salto. Por exemplo, a IA já existia há décadas antes do lançamento do ChatGPT e a IA generativa despertou muito interesse. Para um observador externo, poderia parecer que nada estava acontecendo, mas então tudo mudou. Como uma galinha crescendo dentro de um ovo, muita coisa aconteceu antes do momento de ruptura e houve muitos desenvolvimentos e falsos começos.

O que isso significa para o código aberto? Significa responder às enormes mudanças no mercado à medida que elas ocorrem, com novos projetos atingindo um público maior do que jamais imaginaram ser possível com base no que mais está acontecendo no mercado. Isso significa que os desenvolvedores e líderes de projeto precisam entender o que pode acontecer com eles e com os projetos nos quais estão trabalhando.

Ao mesmo tempo, muitos projetos de código aberto não causam o impacto que deveriam ou caem em desuso. De acordo com uma pesquisa da Sonatype, apenas 11% dos projetos de código aberto são “mantidos ativamente” pelos seus criadores ou comunidades, e isso representou um aumento de 18% em relação ao ano anterior. Os desenvolvedores deveriam pensar em entregar o controle ao código-fonte, deixando outra pessoa assumir a liderança de um projeto? Como pode uma federação ou fundação assumir o controlo quando uma empresa ou indivíduo não consegue gerar receitas suficientes para cobrir os seus custos? E o que acontece com os projetos mais antigos que ainda são usados, mas não são mantidos ativamente?

Falar sobre sustentabilidade para código aberto envolve pensar em projetos que podem não ter uma oportunidade comercial de mercado, mas que precisam ser apoiados ao longo do tempo. Eles podem ser incorporados a outras ferramentas de software ou sistemas operacionais e precisam ser cuidados onde forem viáveis e substituídos onde não o forem. A última resolução deveria ser pensar onde você pode se envolver e apoiar contribuidores e mantenedores nesses esforços durante 2024.