O compromisso da Red Hat com o open source: resposta às mudanças no git.centos.org

Passei muito tempo caminhando neste fim de semana pensando na reação do nosso setor ao meu último post. Já fomos chamados de maus; fui chamado de executivo da IBM encarregado de tornar a Red Hat código fechado, e isso é só a parte "boa". Portanto, vamos esclarecer as coisas. 

Meu nome é Mike McGrath e sou vice-presidente de engenharia de plataformas básicas da Red Hat. Estou aqui há 16 anos e, antes de começar a trabalhar, fui voluntário no Projeto Fedora. O open source e tudo o que isso implica são muito importantes para mim. Na última semana, vi muitas pessoas dizerem muitas coisas indelicadas e inverdades sobre profissionais da Red Hat que, como eu, valorizam muito esse trabalho.

Apesar do que está sendo dito atualmente sobre a Red Hat, fazemos com que nosso trabalho árduo seja facilmente acessível a quem não é cliente. A Red Hat usa e sempre usará um modelo de desenvolvimento open source. Quando encontramos um bug ou escrevemos uma funcionalidade, contribuímos com nosso código upstream. Isso beneficia todos na comunidade, não apenas a Red Hat e nossos clientes.  

Nós não simplesmente pegamos os pacotes upstream e os recriamos. Na Red Hat, milhares de pessoas passam tempo escrevendo código para habilitar novas funcionalidades, corrigindo bugs, integrando pacotes diferentes e oferecendo suporte durante muito tempo. Isso é algo que nossos clientes e parceiros precisam. 

São horas e noites que passamos realizando a transferência de um patch para código que agora tem entre 5 a 10 anos ou mais; a qualquer momento, oferecemos suporte a três a quatro fluxos de lançamentos principais e aplicamos patches e fazemos a transferência em todos eles. Além disso, quando desenvolvemos correções de problemas no RHEL, nós não apenas as aplicamos ao RHEL: primeiro elas são aplicadas nas versões upstream, em projetos como Fedora, CentOS Stream ou no próprio projeto kernel, e depois fazemos a transferência deles. Realizar a manutenção e o suporte de um sistema operacional por 10 anos é uma tarefa árdua. O trabalho que fazemos é de enorme valor.

Sempre enviaremos nosso código upstream e respeitaremos as licenças open source usadas pelas nossas soluções, o que inclui a GPL. Quando digo que respeitamos as várias licenças open source que se aplicam ao nosso código, estou falando sério. Fiquei chocado e desapontado ao ver quantas pessoas entenderam tão errado a respeito do software open source e d GPL em particular, principalmente observadores do setor e até mesmo veteranos que acho que deveriam saber mais. Os detalhes são importantes, como as licenças e direitos open source, e são coisas que a Red Hat ajudou não apenas a formar, mas também a preservar e evoluir. 

Acredito que grande parte da indignação com nossa decisão recente sobre as fontes de downstream vem daqueles que não querem pagar pelo tempo, esforço e recursos dedicados ao RHEL, ou daqueles que querem reformulá-lo para gerar lucros próprios. Essa demanda por código do RHEL é falsa. 

Precisamos pagar as pessoas para fazer esse trabalho, aqueles colaboradores empenhados que acreditam nos valores do open source. Simplesmente reempacotar o código que essas pessoas produzem e revendê-lo como está, sem valor agregado, torna a produção desse software open source insustentável. Isso inclui o esforço crítico de transferir trabalho e funcionalidades e tecnologias futuras em desenvolvimento upstream. Se o trabalho se tornar insustentável, ele será interrompido, e isso não é bom para ninguém.

Gostaria de mencionar especificamente os recriadores, diferentes das distribuições, que podem, por exemplo, adicionar uma nova arquitetura ou sinalizar a compilação (damos suporte total para você expandir os recursos do Linux, em vez de imitá-los). 

Houve uma época, não muito tempo atrás, em que a Red Hat encontrava valor no trabalho realizado por recriadores como o CentOS. Enviávamos nossos SRPMs para o git.centos.org em um pacote organizado que facilitava a recriação. Nós até removemos a marca para eles. Recentemente, determinamos não haver valor em ter um recriador downstream. 

A ideia geralmente aceita de que essas recriações gratuitas são apenas funis que produzem especialistas em RHEL e se transformam em vendas não é realidade. Gostaria que vivêssemos nesse mundo, mas não é assim que as coisas realmente acontecem. Em vez disso, encontramos um grupo de usuários, muitos dos quais pertencem a grandes organizações de TI, que desejam a estabilidade, o ciclo de vida e o ecossistema de hardware do RHEL sem precisar oferecer suporte para administradores, engenheiros, escritores e muitas outras funções que o criam. Esses usuários também decidiram não usar uma das muitas outras distribuições do Linux.

Em um ecossistema open source saudável, competição e inovação andam lado a lado. Red Hat, SUSE, Canonical, AWS e Microsoft: todas criam distribuições do Linux com esforços de desenvolvimento de ecossistema e branding associados. Essas variantes utilizam e contribuem com código-fonte do Linux, mas nenhuma afirma ser "totalmente compatível" com as outras.

Em última análise, não encontramos valor em uma recriação do RHEL e não temos nenhuma obrigação de facilitar as coisas para os recriadores; é uma escolha nossa. Isso me leva ao CentOS Stream, onde há imensa confusão. Reconheço que esta é uma mudança em uma longa tradição na qual fomos além, e isso pode causar certa confusão. Essa confusão se manifestou com acusações de que teríamos adotado código-fonte fechado e supostas violações da GPL. Existe o CentOS Stream, o resultado binário, e o CentOS Stream, o repositório de origem. Na fonte do gitlab do CentOS Stream são compiladas as versões do RHEL, abertas para todos verem. Chamar o RHEL de "código-fonte fechado" é categoricamente falso e impreciso. O CentOS Stream se move mais rápido que o RHEL, então ele pode não estar no HEAD, mas o código está. Se você não conseguir encontrá-lo, é um bug. Fale conosco.

Também oferecemos gratuitamente Red Hat Developer Subscriptions e Red Hat Enterprise Linux (RHEL) for Open Source Infrastructure. A subscrição de desenvolvedor oferece o RHEL gratuitamente para desenvolvedores e permite o uso em até 16 sistemas, também sem custos. Ele pode ser usado por indivíduos para seu próprio trabalho e por clientes do RHEL para o trabalho dos funcionários. O RHEL for Open Source Infrastructure visa oferecer aos projetos open source (afiliados ou não à Red Hat) acesso gratuito ao RHEL para suas necessidades de infraestrutura e desenvolvimento.

Por fim, gostaria de falar com todas as empresas open source existentes, não importa se vocês já usam open source atualmente ou se estão considerando migrar para um modelo open source. De qualquer forma, a Red Hat "chegou lá" e espero que muitas empresas open source consigam ter sucesso como nós temos. Você pode decidir por si se as recompilações downstream são relevantes para você e se você quer facilitar ou não o processo.

A simples recriação do código, sem agregar valor ou alterá-lo, representa uma ameaça real para as empresas open source em todo o mundo. Essa é uma ameaça real ao open source, e uma ameaça com o potencial de reverter o open source a uma atividade exclusiva para hackers e amadores.

Nós não queremos isso e eu sei que os membros da nossa comunidade, clientes e parceiros também não. A inovação acontece no upstream. Usar o conhecimento prévio de outras pessoas para criar algo novo é a essência do open source. Continuaremos a impulsionar a inovação, nos apoiar reciprocamente e seguir em frente.