O futuro do código aberto

 (blog.gitbutler.com)
19 pontos por xguru 2024-08-12 | 5 comentários | Compartilhar no WhatsApp
  • Quando Anne, nossa COO e cofundadora, era CEO da empresa alemã de alimentos Delinero, ela foi processada. O motivo foi que uma geleia de framboesa fornecida por um fornecedor foi rotulada como "Himbeermarmelade", mas na Alemanha existia a Konfitürenverordnung (regulamentação das geleias), segundo a qual algo só pode ser rotulado como "marmelade" se contiver pelo menos 20% de frutas cítricas
  • Era uma regra que contrariava o sentido usual da palavra no uso cotidiano, mas, por ser uma lei criada há muito tempo por um pequeno grupo de interessados, ainda assim precisava ser seguida
  • Dá para ver o "código aberto" atual de forma parecida. A OSI, como a Konfitürenverordnung, ainda regula rigidamente um termo que evoluiu de modo diferente do uso comum
  • Mas como avançar de forma construtiva?

Como não fazer "código aberto"

  • Quando a GitButler decidiu fazer Fair Sourcing do código do cliente e publicá-lo sob uma licença não aprovada pela OSI, pensamos bastante em como anunciar isso
  • A maioria das pessoas equipara "código aberto" a "estar público no GitHub" e, além disso, por causa das implicações um tanto arriscadas das licenças GPL/copyleft, as pessoas estão muito acostumadas a verificar qual licença se aplica
  • Também não queríamos usar um termo vago como "Source Available'd" e, para evitar confusão, usamos a palavra "aberto", mas fomos atacados por isso
  • Percebemos que um pequeno grupo muito barulhento tenta proteger e tornar esse termo mais rígido
  • "Open source" não é a negação lógica de "closed source". Existe uma lacuna entre o entendimento popular de algo publicado no GitHub e aberto à participação, e as 10 definições técnicas de "open source" regulamentadas pela própria OSI

Uma breve história do código aberto

  • Na era inicial da computação, nas décadas de 1950 e 1960, o software vinha atrelado ao hardware, então não havia necessidade de separá-los, e as empresas de hardware o distribuíam livremente
  • Nas décadas de 1970 e 1980, com a comoditização do hardware, o software passou a ter valor próprio, e grandes empresas como IBM e AT&T começaram a restringir o acesso ao código-fonte que haviam criado com investimento
  • Em resposta, Richard Stallman e outros começaram a criar seu próprio sistema operacional e suas próprias ferramentas, protegidos dos interesses corporativos, e com licenças recíprocas como a GPL forçavam IBM, AT&T e outras empresas a tornar seu software livre também caso usassem o deles

    "Se nós não podemos brincar com os seus brinquedos, vocês também não podem brincar com os nossos."

    • Eles deram a esse movimento o nome de "software livre" e criaram muitas ferramentas extraordinárias, como o Emacs e o sistema de compiladores GNU. Até hoje, elas formam a base de grande parte da computação moderna
    • O foco fundamental do movimento de software livre era garantir aos usuários a liberdade de executar, copiar, distribuir, estudar, modificar e melhorar o software. Eram liberdades que, naquele momento, estavam sendo retiradas deles pelos interesses corporativos ao redor
  • No início dos anos 1990, com o kernel Linux de Linus Torvalds, passou a existir um sistema operacional completo, e o ecossistema de software livre cresceu com a stack LAMP e outros componentes, até que as empresas também passaram a usar e depender dele
  • Em 1997, Eric Raymond publicou o ensaio "A Catedral e o Bazar", argumentando que o modelo de desenvolvimento do software livre era superior ao modelo fechado, e isso foi citado para justificar a decisão da Netscape de abrir o código-fonte do Navigator Suite
    • Quando a Netscape decidiu abrir seu código, em uma sessão estratégica em Palo Alto, Raymond e alguns desenvolvedores proeminentes de Linux e software livre concordaram em criar e usar o novo termo "open source"

    "Os participantes da reunião acreditavam que os fundamentos práticos e de negócios que motivaram a Netscape a liberar seu código eram uma forma valiosa de se comunicar com potenciais usuários e desenvolvedores de software e persuadi-los a participar da comunidade, ajudando a criar e melhorar o código-fonte. Os participantes também acreditavam que seria útil ter um rótulo único para identificar essa abordagem e distingui-la do rótulo 'software livre', de foco filosófico e político."

  • O ponto importante é que não há diferença legal ou prática substancial entre "software livre" e "open source"
    • A maioria das licenças é compatível com ambas as definições e reconhecida por ambas
    • "Open source" foi apenas uma mudança de marca, mais amigável aos negócios, para separar os objetivos políticos de Stallman e de seu movimento da praticidade de abrir software, de modo a levar mais empresas como a Netscape a adotar a abertura de código profissional
  • Ou, como o pessoal do software livre costumava dizer

    "Open source é uma metodologia de desenvolvimento; software livre é um movimento social."

Código aberto e a era do GitHub

  • A definição e o marketing da expressão "open source" datam de 1998, ou seja, de mais de 25 anos atrás. Então, o que aconteceu com o código aberto e com o desenvolvimento de software nesses últimos 25 anos?
  • Especialmente nos últimos 10 anos, o GitHub e o estilo de desenvolvimento de software inspirado no GitHub tiveram um impacto enorme sobre o código aberto
  • Em 1998, o objetivo era convencer empresas a adotarem software aberto; hoje, quase todo software open source é escrito ou patrocinado por empresas
  • Uma das maiores mudanças foi a "padronização do workflow de desenvolvimento", especialmente liderada pelo GitHub
  • Antes, havia uma grande diferença entre projetos de software aberto e projetos corporativos, mas agora quase não há diferença
    • Todo mundo usa Git
    • Quase todo mundo usa pull requests (ou merge requests, ou qualquer outro mecanismo que copie essa funcionalidade)
    • A maioria das equipes usa alguma forma de GitHub Flow (desenvolvimento baseado em trunk, GitLab Flow etc.)
  • Agora, a única diferença real é se o repositório é público ou não. Há 25 anos havia muito atrito no processo, mas hoje quase não é preciso mudar o processo para abrir o código

Qual é o próximo passo do código aberto?

  • Agora que quase todas as empresas usam e produzem software open source, será que o movimento de código aberto (software livre) venceu?
  • Hoje existem dois grandes problemas no mundo do código aberto: a "sustentabilidade dos desenvolvedores" e a questão de saber se o open source comercial é viável

O problema da sustentabilidade dos desenvolvedores

  • À medida que passamos a depender fortemente de código aberto, surgiram problemas de sustentabilidade e manutenção. O caso recente do backdoor no XZ Utils é um exemplo famoso
  • Quase todos os mantenedores sofrem com burnout e assédio. Ganhar dinheiro escrevendo e mantendo software open source é quase impossível
  • A maioria dos desenvolvedores e mantenedores de open source hoje é patrocinada por grandes empresas
    • Se você olhar para Linux, Git, Ruby, React etc., a maior parte dos contribuidores de projetos open source importantes é empregada profissionalmente por patrocinadores corporativos como GitHub, Microsoft e Red Hat
  • É difícil para um desenvolvedor manter projetos como o XZ Utils e, ao mesmo tempo, garantir um sustento digno
    • Em vez de uma única empresa pagar o desenvolvedor, o ideal seria que milhares de empresas pagassem pequenas quantias a mantenedores profissionais
  • O principal problema é que hoje não existe uma boa forma de fazer isso
    • Há iniciativas promissoras como GitHub Sponsors, Thanks.dev, Liberapay e Tidelift, mas elas ainda não resolveram a questão dos incentivos adequados para que empresas contribuam financeiramente
  • A Sentry vem impulsionando uma nova iniciativa chamada OSS Pledge, e a GitButler planeja participar quando ela for lançada em outubro
  • Mas ainda não sabemos se abordagens como essa conseguirão resolver o grande e crescente problema da sustentabilidade dos desenvolvedores no ecossistema open source

O problema do open source comercial

  • Desenvolvedores cresceram amando open source e comunidades abertas, então, quando começam empresas e projetos, naturalmente querem que eles também sejam abertos
    • Mas, assim como no caso dos mantenedores individuais, também existe um problema de sustentabilidade empresarial no open source
  • Como mostram os casos do Elasticsearch e do Redis, quando se investe tempo e dinheiro para desenvolver software profissionalmente, existe o risco de grandes empresas como a Amazon usarem esse trabalho para competir diretamente com quem o criou
  • Muitos criadores profissionais querem investir em software sem que, mais tarde, isso seja usado contra eles
    • Isso significa ser criativo com licenciamento ou fechar o código-fonte
  • Eu acredito que o movimento Fair Source é uma solução excelente e necessária para esse problema crescente, e que ele preenche a lacuna no ecossistema open source que, nos últimos anos, vem causando cada vez mais problemas e confusão
    • Trata-se de um novo termo para projetos profissionais que são amplamente permissivos, têm código-fonte disponível e contam com participação da comunidade do GitHub. Acho que é uma solução urgentemente necessária para incentivar que mais projetos, antes mantidos em privado, sejam tornados públicos

O futuro da colaboração

  • O futuro do código aberto não é apenas "Open Source" e as 10 Konfitürenverordnung da OSI
  • É uma combinação de Open Source possível e valioso para todos, de Fair Source necessário para investimentos seguros, e de financiamento coletivo em larga escala para bibliotecas abertas e projetos fundamentais importantes
  • Precisamos tornar sustentável a manutenção de bibliotecas open source importantes e aceitar e normalizar uma classe sustentável de licenças comerciais com código-fonte disponível
  • Devemos abrir o código com licenças da OSI sempre que possível e da forma mais permissiva possível e, acima de tudo, transformar o código fechado em algo do passado
  • O que você pode fazer agora
    • tornar softwares fechados em Fair Source e
    • se você depende de open source, aderir ao OSS Pledge

Leituras relacionadas

5 comentários

 
bus710 2024-08-13

Vivendo em um mundo capitalista, a realidade é que não dá para se dedicar exclusivamente ao open source. Por outro lado, penso que, se for uma biblioteca ou utilitário realmente importante, seria bom que houvesse mais patrocínio das empresas.

Utilitários de desktop/terminal no espaço do usuário têm especialmente dificuldade para receber esse tipo de apoio. Se for kernel, as grandes empresas dão bastante suporte; se for mobile, a comercialização via app store funciona bem; e, em áreas como web ou firmware, costuma haver alguma análise de mercado antes do desenvolvimento, então a preocupação é menor. Já os softwares e bibliotecas que usuários comuns usam sem perceber tendem a ser mais difíceis até de definir barreiras de entrada, então parece realmente muito difícil ganhar dinheiro com eles. O open source é bastante ativo, mas ainda assim não é fácil dar um passo além.
 
bus710 2024-08-13

Como alguém que ama software de código aberto e o usa com prazer, espero que as pessoas que trabalham duro nos bastidores, desenvolvendo com dedicação para o benefício de muitos, também possam ser devidamente beneficiadas por meio da definição adequada de licenças.
 
chabulhwi 2024-08-13

No texto de Drew Devault intitulado 'So you want to compete with or replace open source (Então você quer competir com ou substituir o open source?)', aparece a seguinte passagem.

From https://drewdevault.com/2024/07/…:

Nevertheless, the revolutionary economics of FOSS are based on collaboration, and are incompatible with competition.

No software livre e de código aberto, há benefício mútuo quando colaboradores de organizações diferentes cooperam entre si, mas no fair source software há pouco ou nenhum motivo para que outros colaboradores cooperem de graça em favor de um indivíduo ou organização que desfruta de uma posição monopolista.

De todo modo, eu também acho que fair source é melhor do que closed source, e também não quero ver mantenedores de software open source querendo ser recompensados pelo próprio esforço e não conseguindo.

Ainda assim, duvido que o fair source consiga desfrutar, como o open source, do benefício de receber contribuições de desenvolvimento gratuitas. E quando alguém distribui seu software como open source, essa pessoa precisa ter em mente que pode não receber compensação financeira de nenhum usuário e que esse software pode acabar virando um 'almoço grátis' para as grandes empresas de nuvem.