Isca e troca de código aberto

Eu estava lendo este artigo e queria postar um comentário, mas senti que isso merece um artigo de resposta. Primeiro, se você não me conhece, escrevi uma tonelada de código-fonte aberto. Plataforma inteira e mais alguns. Eu acho que a visão geral que é expressa naquele artigo e muito do cotão que vejo online é simplista e perigoso.

Precisamos ser pagos

Quem vai pagar o seu salário?

As pessoas têm várias respostas para modelos de negócios de código aberto. Por exemplo, "consultoria" ou o vago "suporte". Eu sempre me pergunto se essas pessoas já tentaram vender consultoria? Ou talvez “suporte”.

As pessoas não compram essas coisas. Especialmente em uma economia em recessão. A maneira como os vendedores normalmente vendem essas coisas é a dica de que você pode violar uma licença e seria muito mais fácil se você pagasse e obtivesse a licença comercial. Vou até jogar o “apoio” de graça. Sim, você pode conseguir alguns patrocinadores se passar todo o seu tempo ao telefone. É um processo de vendas sem fim. Perseguir leads e fazer ligações. Executar esse tipo de negócio requer muita sobrecarga.

Alguns desenvolvedores usam licenças de código aberto problemáticas que podem ser aproveitadas para vendas. Mas então eles são difamados como “não são de código aberto o suficiente”. Não há vitória lá.

A Sun Microsystems pagou meu salário durante parte do meu trabalho de OSS. Eles afundaram e caíram de uma avaliação de mais de 200 bilhões de dólares, vendendo por volta de 7 bilhões. Concedido, não é porque eles eram de código aberto. Isso é apenas uma anedota e não ajudou. Pessoas reais perdem seus empregos reais porque o código aberto não dá dinheiro. Mesmo quando dá, rende muito pouco. As pessoas costumavam dizer que acaba com um pedaço menor de uma torta maior. Isso é verdade, mas aplicável apenas para os grandes jogadores e você tem duas opções: tornar-se o grande jogador ou assistir a um grande jogador obter os lucros de seu trabalho árduo.

Não me interpretem mal, não sou contra pessoas lucrando com meu trabalho ou mesmo grandes corporações. Eu faço OSS por diversão e adoro a ideia de as pessoas serem bem-sucedidas com base no meu trabalho. Mas eu entendo a frustração que muitos desenvolvedores sentem, e a ampla “defesa do código aberto” que vejo das pessoas é problemática.

Isca e troca

O ruim é o cinismo corporativo. Pegue o Google. Eles abriram o código do Android quando não havia usuários. As empresas construíram em cima dele e os desenvolvedores também. A defesa se formou em torno dele porque “é de código aberto”. Em seguida, eles lançaram o Google Play Services de código fechado, que mais tarde adicionou o requisito SaaS Firebase para algumas funcionalidades essenciais (é gratuito para isso no momento) e agora temos dependências profundas de código fechado de fornecedores disfarçadas de código aberto.

Não precisamos usar o Google Play Services se quisermos criar para Android. Claro. Mas torna muito mais difícil criar um aplicativo Android e, se você não o usar para algumas coisas (por exemplo, push, compra etc.), será banido do maior mercado Android. A grande maioria dos desenvolvedores “apenas usa”. Isso significa que qualquer pessoa que queira apagar o Google Play de seu dispositivo Android em favor de uma solução 100% de código aberto; descobrirão que têm muito poucas opções de software para aplicativos.

Pegue a pesquisa elástica. Eles eram de código aberto e estavam arrasando. Mas a AWS estava bifurcando e não ajudando muito seus resultados. Então a Elastic mudou sua licença para bloquear a AWS. A AWS iniciou seu próprio fork. Algumas pessoas difamam a Elastic nesta história, mas essas pessoas provavelmente nunca tiveram que lutar contra a Amazon pela sobrevivência de seus negócios. Nesse caso, ambos os lados armaram o código aberto em uma briga comercial.

O caso do Java é um pouco diferente. Java não era de código aberto e foi feito de código aberto mais tarde. Ele ainda manteve o IP sobre o idioma. Portanto, recebo um pouco do controle da Oracle sobre o projeto e aceito isso. É bom que haja mão firme do navio e isso tenha contribuído para o sucesso do Java. O problema com o processo do Google foi que a Oracle tentou estender seu IP para incluir as APIs. Isso foi um erro.

GPL é a melhor licença

Cerca de uma década atrás, uma startup chamada RoboVM lançou um compilador de código aberto que traduzia Java para aplicativos iOS nativos. Foi muito legal e conversei bastante com o fundador da JavaOne. Naquela época, estávamos pensando em criar nossa própria VM ou escolher uma solução como o RoboVM. Acabamos com o primeiro e construímos nossa própria VM, que era muito mais simples e mais adequada às nossas necessidades ( também é de código aberto ).

Essa decisão foi baseada em méritos técnicos e acho que valeu a pena, mas ainda tenho um grande respeito pela equipe RoboVM. Minha preocupação era a Apple. Eles quebram muitas coisas… Construir uma VM de baixo nível é um perigoso jogo de gato e rato, onde a Apple mudaria algo repentinamente e estaríamos presos. Uma preocupação secundária era a monetização. Eu entendi que a equipe RoboVM teria que pagar os salários de seus funcionários e fundadores de alguma forma. Como alguém ganha dinheiro com um compilador de código aberto? Observe que isso foi há uma década e não havia nenhum precedente como o Zig que pudéssemos considerar como modelo.

Em algum momento, meus medos das políticas da Apple se materializaram e a Apple adicionou um requisito de código de bits ao direcionar algumas plataformas. O RoboVM passou muito tempo trabalhando no suporte a bitcode e decidiu fechar seu código-fonte. Eles entenderam que não podem financiar o desenvolvimento contínuo sem ele. Não tome isso como um julgamento em relação à decisão deles. Eu entendo totalmente, como eu disse, monetizar OSS é muito difícil.

A GPL protegeu a comunidade forçando o RoboVM a liberar o código para a versão final antes da migração do bitcode. Isso permitiu algumas bifurcações do código nos anos posteriores, mas ainda não foi mantido. A empresa foi comprada pela Xamarin e prontamente descontinuada, pois esta foi comprada pela Microsoft. Sem a GPL, o código poderia ser inacessível. Também forçou terceiros a publicar seu código.

A esse respeito, acredito muito na GPL em vez de licenças mais permissivas, como MIT, BSD, Apache, etc. Acho que nós, como comunidade, devemos preferir uma licença que preserve os direitos da comunidade em oposição aos direitos corporativos. Também fornece uma boa opção de monetização para o criador do projeto. Basta relicenciar como uma licença proprietária e cobrar por isso. Infelizmente, a GPL costuma ser um obstáculo para muitos desenvolvedores porque eles assumem incorretamente que é ruim para eles. O oposto é verdadeiro. A GPL é uma das melhores maneiras de preservar os direitos da comunidade a longo prazo.

As coisas mudaram?

Eu mencionei Zig antes. Existem muitos outros exemplos de fundações que foram bem-sucedidas, como SQLite, Mozilla, etc. Chegar a esse ponto geralmente é difícil e não funciona necessariamente para todos os projetos de código aberto. Por exemplo, o cURL é usado por quase todo mundo, mas não acho que veremos uma base cURL. Observe também que todos esses projetos são baseados em centros de tecnologia dos EUA. Pela minha experiência, é muito mais difícil conseguir patrocinadores em outros territórios.

Isso significa que todo código aberto deve ser um hobby ou um projeto mega abrangente?

Infelizmente, não tenho boas respostas. Mas eu tenho um problema: mais zelosos defensores do código aberto. Você não está ajudando!

O código aberto está se tornando um jogo somente corporativo. É usado como uma arma entre empresas de tecnologia em batalha. Existe um nome para isso no varejo: líder de perdas.

No varejo, um grande supermercado venderia alguns produtos com prejuízo e anunciaria esse preço incrivelmente baixo. Isso traz público que compra outras coisas pelo caminho e assim o supermercado acaba lucrando. Mas a razão para isso é abafar a concorrência. A concorrência parece cara (já que eles não podem vender com prejuízo). Eles fecham as portas e a grande empresa varejista aumenta os preços. Inicialmente, parece que conseguimos um ótimo negócio com a concorrência, mas no final acabamos perdendo. Por isso alguns reguladores proíbem tais práticas, pois acabam destruindo um mercado.

O código aberto é usado de maneira semelhante e cínica pelas grandes empresas de tecnologia. Eles formam “comunidades” contratando exércitos de profissionais de relações com desenvolvedores para criar uma máscara de entusiasmo popular. Às vezes, eles não precisam monetizar o mercado, basta manter a concorrência fora.

TL;DR

Eu amo código aberto e acho que é extremamente importante. É por isso que não devemos permitir que as corporações o transformem em armas. Precisamos de diversidade dentro do ecossistema e precisamos apoiar projetos críticos menores. A ideia de “apostilas” para projetos de código aberto ou “consultoria” não é sustentável.

As grandes corporações usam o código aberto como uma arma para lutar umas contra as outras, parece que nos beneficiamos no curto prazo. Mas, à medida que vencem, a mentalidade corporativa assume o controle e eles dobram o controle.

As soluções que sugiro são:

• Use GPL - está aqui para proteger os direitos da comunidade. Não é de admirar que as corporações não gostem.

• Não seja um puritano do OSS - pequenas empresas precisam ganhar dinheiro. Eles oferecerão SaaS, extensões de código fechado, etc. Tudo bem.

• As grandes corporações não são benevolentes - a defesa que vejo em torno dos projetos OSS das empresas FAANG (MAANG) é problemática. Eles não suportam OSS. Eles usam e alavancam isso. Não me interpretem mal, sou grato pelo código deles e é maravilhoso que eles o liberem. Mas precisamos ser cautelosos, eles têm requisitos fiduciários que podem colidir com fazer a “coisa certa” pelos padrões da OSS.

  
  

Não sei se a próxima coisa que farei será OSS. Não sei se escolherei a GPL, pois, como disse, as pessoas têm problemas com ela. Mas eu sei disso: se você é um defensor do código aberto. Abaixe a retórica. Não é útil.

Publicado também aqui .