Redis contra as conspirações de trilhões de dólares

Recentemente, o Redis mudou sua licença, e montanhas de desinformação se seguiram, sem mencionar uma bifurcação impulsionada pela empresa de nuvem de um trilhão de dólares AWS. Entre essa desinformação está a declaração sincera, mas incorreta, de Steven J. Vaughn-Nicols de que a mudança do Redis “significa que os desenvolvedores não podem mais usar o código do Redis”.

Isto simplesmente não é verdade. Para 99,9999999999999% dos desenvolvedores, seus direitos sob a licença permanecem exatamente os mesmos que permaneceriam sob a mais permissiva das licenças de código aberto. O que é faz O que significa é que empresas de nuvem de trilhões de dólares como a AWS não podem mais aceitar o código do Redis sem contribuir de volta.

A AWS, depois de anos obtendo grandes lucros com o Elasticache (seu serviço Redis), entrou em pânico e iniciou uma bifurcação (Valkey), recrutando outros para não ter que arcar com todos os custos. A empresa aprendeu essa lição cara com seu fork Elasticsearch, OpenSearch. Para que você não pense que se trata de uma vitória da comunidade sobre as corporações, tenha em mente que esta “comunidade” é mais como uma conspiração de empresas tecnológicas de biliões de dólares que asseguram um fornecimento constante de software barato ou gratuito, para o qual não contribuem praticamente com nada. Os membros do clube trilionário têm fundadores que valem mais do que as avaliações de mercado da Redis e todos dos chamados vilões de código aberto combinado.

É hora de pararmos de fingir que as principais nuvens (e uma em particular) não são diretamente responsáveis ​​por esta bagunça. A história do Redis pode ser sobre lucro, mas é o clube de um trilhão de dólares que detém o grande saco de dinheiro.

E os desenvolvedores?

Vamos primeiro ser claros: os desenvolvedores são amplamente imunes às alterações de licença do Redis. Os únicos desenvolvedores que são “prejudicados” pelas mudanças que o Redis fez são aqueles que trabalham para as empresas de nuvem (e mesmo eles, com uma exceção, não contribuíram em nada). Um comentarista do Hacker News deixa isso bem claro:

Para meu próprio uso em minha empresa ou projeto como pessoa física:

• Posso ter acesso total à fonte, cloná-la e modificá-la? SIM
• Posso fazer uma solicitação pull para melhorá-lo? SIM
• Posso baixar, usar e ter gratuitamente na minha empresa mesmo que meu projeto seja comercial e esteja ganhando dinheiro com o uso do Redis? SIM
• Posso criar um produto que utilize Redis como tecnologia gratuitamente na minha startup? SIM …
• Posso git clone / make / make install é como antes? SIM …
• Posso revender o Redis como um serviço pegando o código-fonte e executando-o na minha nuvem sem uma licença paga? NÃO (boo hoo hoo)

Captou isso? A única coisa – literalmente, a única coisa – que um desenvolvedor não pode fazer com o código Redis é construir um serviço de nuvem gerenciado, a menos que queira contribuir com a infraestrutura usada para executá-lo. Isso é código aberto? Não, não de acordo com a definição de código aberto. Mas é o Dia do Armagedom para os desenvolvedores, como está sendo retratado? Não.

Além de poder modificar e distribuir o código Redis, considere a realidade de que a maioria dos desenvolvedores não deseja fazer isso: o que eles querem é um ótimo código que continuará a ter suporte e ser aprimorado ao longo do tempo. É aqui que o investimento da Redis Inc. é tão importante. A inovação no Redis não veio da AWS (com uma exceção que observarei abaixo), da Microsoft ou do Google. Toda a conversa sobre o desenvolvimento comunitário de projetos de código aberto é principalmente um mito. As empresas que aderiram ao fork do Redis não fizeram quase nada para levar o Redis ao seu estado atual.

Considere Salvatore Sanfilippo, que fundou a Redis. Você pensaria que alguém assim, que teve um impacto tão tremendo no Redis, seria apoiado pelos forkers, certo? Nem tanto, como alerta nosso comentarista do Hacker News:

Antirez (Salvatore) tem 21 mil seguidores e 9 patrocinadores que doam no GitHub. NOVE! Nem 10, nem 50, nem 1.000 patrocinadores… São 9 – um carpinteiro que perdeu um dedo no trabalho ainda pode contá-los.

A propósito, nenhum desses patrocinadores é fornecedor de nuvem. Claro, é muito possível que eles não se importem mais com Sanfilippo, já que ele não está mais envolvido com o Redis, mas também nunca o apoiaram enquanto ele estava construindo o Redis.

O que os desenvolvedores mais precisam é de um ótimo código que possam acessar, usar e confiar abertamente para serem bem mantidos. Redis não tirou isso deles. Tudo o que o Redis fez foi tentar manter o acesso do desenvolvedor ao seu código e evitar que as nuvens desviassem os meios para investir nesse código.

Alteração de licenças, mas por quê?

Vaughn-Nichols aponta para um padrão: “Uma empresa fará seu programa usando código aberto, ganhará milhões com isso e então – e somente então – trocará de licença, deixando seus colaboradores, clientes e parceiros em apuros enquanto tentam agarrar bilhões.” Ele está “cansado disso”, mas as empresas que ele está castigando também estão. Ninguém faz esse tipo de mudança a menos que esteja sob coação.

Vaughn-Nichols sugere que o problema é que essas empresas “confundiram o 'código aberto' com um modelo de negócios”. Ele está errado sobre isso também. O problema é que as nuvens confundiram o código aberto com um bem comum do qual poderiam extrair e não contribuir.

Esta é uma das razões pelas quais tenho insistido para que o OSI cumpra sua missão e introduza copyleft forte para software em nuvem. Dê aos desenvolvedores (corporativos ou não) os meios para proteger a liberdade de seu código e veremos menos software disponível na fonte. É simples assim.

Enquanto isso, o garfo Valkey nos diz que as nuvens têm medo de perder o trem da alegria Redis, para o qual pouco contribuíram. Novamente, estou falando principalmente de uma nuvem específica (AWS).

A ironia é que Redis é uma das poucas áreas em que a AWS realmente contribui. Citei regularmente o trabalho impressionante de Madelyn Olson, mantenedora do Redis, como exemplo diário para a AWS. Parte disso é porque Olsen é incrível. A outra razão é que ela era praticamente o único exemplo que a AWS tinha. Como ela observou recentemente, “trabalhei no Redis em meu tempo livre”. Isso não quer dizer que ela nunca trabalhou no Redis para AWS, mas também expõe a realidade da engenharia de código aberto na AWS. Um grande motivo pelo qual os engenheiros da AWS contribuem pouco em relação aos seus pares em outras nuvens é que a liderança da engenharia vê pouco valor em fazê-lo. Isso começou a mudar em algumas equipes (como as equipes RDS/Aurora que perceberam que era do seu interesse fazer mais pelo Postgres), mas elas são a exceção, não a regra.

Não acredite em mim? Apesar do novo amor da AWS pela Linux Foundation por meio do fork Valkey/Redis, seria difícil encontrar contribuições proporcionais a quanto dinheiro a AWS ganha. Basta dar uma olhada nos devstats do CNCF.

Realmente, escolha um projeto. Que tal Kubernetes? AWS é o maior fornecedor de Kubernetes, faturando bilhões. No entanto, as suas contribuições são liliputianas em comparação com o Google ou a Red Hat. As contribuições do Kubernetes da AWS estão atrás da DaoCloud Network Technology Co. Ltd. e logo à frente da The Scale Factory Limited. Provavelmente, você nunca ouviu falar de nenhuma dessas empresas, mas elas contribuem quase tanto quanto a AWS.

O mesmo se aplica ao Prometheus, OpenTelemetry, etc. A AWS baseia-se nesses projetos para fornecer um serviço de nuvem, mas não está entre os 5 primeiros em contribuições para o OpenTelemetry ou mesmo entre os 20 melhores em contribuições para o Prometheus. Em qualquer projeto de código aberto que você possa citar (com exceção dos poucos que a AWS lançou), a AWS ganha coletivamente dezenas de bilhões de dólares sem contribuir nem mesmo com dezenas de milhares de linhas de código.

Isso é de alguma forma uma violação do código aberto? Não, de jeito nenhum. Mas é a razão para a “puxada do tapete de código aberto” que as pessoas criticaram o Redis.

Que tal alguma obsessão pelo cliente?

Para que você não pense que sou tendencioso por meu antigo empregador, você pode estar interessado em saber que esse era meu refrão constante quando dirigia a equipe de estratégia e marketing de código aberto na AWS. A última coisa que fiz antes de deixar a AWS foi escrever um artigo de seis páginas sobre por que e como a AWS poderia oferecer melhor suporte a seus parceiros de código aberto. Meu argumento era que a AWS deveria investir mais profundamente no código e no sucesso comercial de seus parceiros de código aberto, tornando assim mais lucrativo para essas empresas manter seu software de código aberto.

Eu acreditava na época, e ainda acredito, que isso protegeria a cadeia de suprimentos de código aberto da AWS e, ao mesmo tempo, atenderia melhor os clientes. Nenhum cliente realmente deseja Valkey (o fork do Redis) ou OpenTofu (o fork do Terraform) ou OpenSearch (o fork do Elasticsearch). Eles querem a versão original, “cheia de gordura”.

Realmente não é difícil descobrir como garantir que os clientes continuem a obter Redis, Elasticsearch, Terraform, etc. completos. As nuvens podem aprender como fazer parcerias melhores. Para ser justo, alguns já o fazem. Vamos usar o Elasticsearch como exemplo. Há muito tempo, o Google Cloud apoia empresas de código aberto e parceiros da Elastic para oferecer uma excelente experiência do Elasticsearch. A Microsoft também contribuiu ativamente através de código e dinheiro para o código aberto, incluindo uma parceria expansiva com a Elastic. AWS? Bem, ela escreveu alguns posts no blog que se retratavam como vítima e depois bifurcou o Elasticsearch, em um movimento profundamente desobcecado pelo cliente.

Para ser justo com a AWS, sua adesão aos Princípios de Liderança apoia e complica seu relacionamento com o código aberto, como escrevi. A abordagem “obcecada pelo cliente” seria fazer parceria. Mas para “entregar resultados”, a empresa sente necessidade de controlar. Isso torna a parceria mais difícil.

É um dilema, mas por que o dilema interno da AWS deveria ser transformado em um problema para empresas de código aberto que já estão fazendo a maior parte ou todo o trabalho árduo de desenvolvimento de software? A AWS fez algumas melhorias, que comemorei, mas ninguém deveria vê-las como um herói de código aberto no fork do Redis.

Por enquanto, só podemos imaginar um mundo em que as nuvens contribuam para as comunidades existentes, em vez de bifurcar essas comunidades quando as suas capitalizações de mercado de biliões de dólares são ameaçadas pela perspectiva de colaboração. É fácil se você tentar.