É altura de os defensores do software de código aberto deixarem de lutar e aceitarem que os programadores se preocupam mais com o acesso ao software e com a facilidade de utilização do que com a pureza da sua licença.
Por Matt Asay
A guerra do código aberto terminou, por muito que alguns queiram continuar a lutar. Recentemente, a Meta lançou o Llama 2, um poderoso modelo de linguagem de grande dimensão (LLM) com mais de 70 mil milhões de parâmetros. No passado, a empresa tinha restringido a utilização dos seus LLMs para fins de investigação, mas com o seu novo serviço abriu-os; a única restrição é que não podem ser utilizados para fins comerciais. Apenas um punhado de empresas tem o poder computacional para o implementar à escala – Google, Amazon, e poucas mais.
Isto significa, obviamente, que não é open source por definição, apesar de o Meta o anunciar como tal. E já há muitas vozes críticas a pedir à empresa que deixe de lhe chamar assim. Têm razão, mas as suas preocupações são irrelevantes. Durante anos, os programadores têm votado com os seus repositórios no GitHub para escolher o que é “suficientemente aberto”. Não é que o código aberto não importe, é apenas que nunca importou da maneira que algumas pessoas esperavam ou acreditavam.
Uma breve história do código aberto
Há mais de uma década, a tendência para o licenciamento permissivo era tão pronunciada que James Governor, analista da RedMonk, declarou que “os jovens programadores de hoje estão interessados no código aberto pós-POSS. Comprometam-se apenas com o GitHub”. Em resposta, as pessoas disseram que tendências passadas como esta tinham resultado em “clustering épico” ou que “a partilha promíscua sem licença leva a doenças transmitidas por software”.
No entanto, depois de milhões de repositórios não licenciados no GitHub, não entrámos na “idade das trevas” do licenciamento de software. O software de código aberto, “ou suficientemente aberto”, está agora presente em quase todo o software, mas acaba por ter uma licença para o utilizador final.
Em resposta, o GitHub e outros criaram formas de incentivar os programadores a escolherem licenças de fonte aberta para reger os seus projetos. Todas estas medidas são suscetíveis de ajudar, mas a realidade é que não terão qualquer importância, porque o código aberto já não tem qualquer importância. Não como uma raiva contracultura contra a máquina de software corporativa, de qualquer forma. Tudo isso me levou a concluir que estamos na revolução pós-fonte aberta, onde o software importa mais do que nunca, mas o seu licenciamento importa cada vez menos.
Os dados que sustentam esta posição abundam através dos repositórios do GitHub ou das tendências de licenciamento de software de código aberto que se verificam há 20 anos. Tudo tem tendido para um acesso permissivo e tão aberto quanto possível ao código, ao ponto de a licença subjacente ser muito menos importante do que a facilidade com que podemos aceder e utilizar o software.
Fonte disponível? Não importa
Demasiados guerreiros do código aberto pensam que o licenciamento é o fim, em vez de ser apenas um meio para garantir um acesso sem restrições ao código. Continuam a preocupar-se com o licenciamento quando os programadores estão sobretudo preocupados com a utilização. E, mais do que qualquer outra coisa, o código aberto alarga o acesso a software de qualidade sem envolver equipas de compras ou jurídicas. Isto é muito semelhante ao que a nuvem fez para o hardware. A questão nunca foi o licenciamento, foi sempre o acesso.
Quando trabalhei na AWS, fizemos um inquérito aos programadores para lhes perguntar o que mais valorizavam na liderança do software de código aberto. Poder-se-ia pensar que contribuir com código para projetos de código aberto bem conhecidos viria em primeiro lugar, mas não veio. Nem mesmo em segundo ou terceiro lugar. Em vez disso, o critério número um que os programadores usaram para julgar a liderança de código aberto de um provedor de cloud foi que ele “facilita a implantação do meu software de código aberto preferido na cloud”.
Não estou a sugerir que as contribuições não são importantes, mas não são importantes pelas razões que se possa pensar. Uma das coisas que fizemos bem na AWS foi trabalhar com as equipas de produtos para as ajudar a descobrir o seu próprio interesse em contribuir para os projetos em que estavam a criar serviços na nuvem, como o Elasticache. Não nos concentrámos em obter elogios da “comunidade” (a palavra mais utilizada e mal definida em todo o open source), mas sim em colocar as equipas de produto numa posição melhor para apoiar os clientes. Adivinhe? Funcionou. Embora não seja perfeita, uma população crescente de equipas de produtos AWS está a contribuir significativamente para projetos de código aberto.
No entanto, para os programadores que utilizam esses serviços, o “código aberto” é uma preocupação secundária em relação a “Ajuda-me a ser mais produtivo e mais rápido”. O que, mais uma vez, não quer dizer que o código aberto não seja importante no nosso mundo de software na cloud. O código aberto é uma forma eficiente de aderir a normas, dando aos programadores (e às empresas) um acesso mais fácil a competências e infraestruturas comuns.
Mas não é o fim, e os defensores do código aberto entre nós têm de perceber isso. O objetivo do código aberto, da cloud, das API abertas, da excelente documentação, etc., é permitir que os programadores construam com menos fricção e mais oportunidades. O Flame 2 é suficientemente aberto para ser utilizado por 99,999% da população de programadores com acesso ilimitado? Sim. É “open source”? A questão não importa realmente.