El compromiso de Red Hat con la tecnología de open source: una respuesta a los cambios de git.centos.org

Este fin de semana pasé mucho tiempo pensando en la respuesta de nuestro sector a mi última publicación del blog. Nos llamaron malvados; me denominaron como el ejecutivo de IBM designado para convertir a Red Hat en una empresa de código fuente cerrado. Y todo eso es la parte menos ofensiva. Así que aclaremos las cosas. 

Mi nombre es Mike McGrath y soy el vicepresidente de Ingeniería de Plataformas Centrales de Red Hat. He trabajado aquí durante 16 años, pero anteriormente fui voluntario en el proyecto Fedora. La tecnología de open source y todo lo que implica esa frase son muy importantes para mí. Durante la semana pasada, varias personas expresaron muchas críticas desagradables y calumnias sobre los representantes de Red Hat que, como yo, valoran todos los aspectos de este trabajo.

A pesar de lo que se dice sobre Red Hat, nos encargamos de que nuestro arduo trabajo esté al alcance de aquellos usuarios que no son clientes de la empresa. Red Hat usa un modelo de desarrollo open source y lo seguirá usando para siempre. Cuando encontramos un error o escribimos una funcionalidad, contribuimos con nuestro código upstream. Esto beneficia a todos los miembros de la comunidad, no solo a Red Hat y a nuestros clientes.  

No se trata simplemente de seleccionar paquetes upstream y recopilarlos. En Red Hat, miles de personas se dedican a escribir códigos que posibilitan nuevas funciones, corregir errores, integrar diferentes paquetes y respaldar ese trabajo durante mucho tiempo, lo que representa una necesidad para nuestros clientes y partners. 

Nos pasamos días y noches cargando un parche a un código que ahora tiene entre 5 y 10 años o más; tenemos la capacidad de admitir en cualquier momento 3 o 4 flujos de versiones principales, al tiempo que aplicamos parches y adaptamos versiones anteriores a todos. Además, cuando desarrollamos correcciones para problemas en RHEL, no solo las aplicamos a RHEL, sino que primero las aplicamos upstream a proyectos como Fedora, CentOS Stream o el mismo kernel, y luego las adaptamos en versiones anteriores. Mantener y respaldar un sistema operativo durante 10 años es una tarea muy difícil, por lo que el trabajo que hacemos tiene un valor enorme.

Siempre enviaremos nuestro código upstream y cumpliremos con las licencias open source que usan nuestros productos, como la GPL. Hablo en serio cuando digo que respetamos las diversas licencias que se aplican a nuestro código. Me sorprendió la cantidad de personas que tenían un concepto incorrecto sobre el software open source y la GPL en particular, especialmente los observadores y los expertos del sector que creo que deberían estar mejor capacitados, lo cual fue una gran decepción. Red Hat no ha ayudado solo a definir los detalles importantes, como las licencias y los derechos de la tecnología de open source, sino también a conservarlos y mejorarlos. 

Siento que gran parte del enojo por nuestra reciente decisión respecto de las fuentes downstream proviene de quienes no quieren pagar por el tiempo, el esfuerzo y los recursos que se dedican a RHEL y de quienes desean utilizarlo de otra manera para su propio beneficio. Esta demanda de código de RHEL es engañosa. 

Tenemos que pagarles a esos colaboradores apasionados que trabajan durante largas horas e incluso noches y creen en los valores de la tecnología de open source. El simple hecho de volver a empaquetar el código que estas personas desarrollan y venderlo tal como se encuentra, sin ningún valor agregado, vuelve insostenible la producción del software open source. Eso incluye la adaptación esencial de versiones anteriores y funciones y tecnologías futuras en desarrollo upstream. Si ese trabajo se vuelve insostenible, dejará de realizarse y sufriremos las consecuencias.

Quiero poner el foco en las recopilaciones, que son distintas a las distribuciones que, por ejemplo, agregan una nueva arquitectura o una marca de compilación. Estas últimas tienen todo nuestro apoyo para expandir las funciones de Linux en lugar de imitarlas. 

Hubo un tiempo, no hace mucho, en que Red Hat se benefició del trabajo realizado por recopiladores como CentOS. Enviamos nuestros SRPM a git.centos.org en un paquete ordenado que los hizo fáciles de recopilar, e incluso les quitamos la marca. Hace poco, determinamos que no hay ningún beneficio en hacer recopilaciones downstream. 

La postura generalmente aceptada de que estas recopilaciones gratuitas son solo productos que generan expertos en RHEL en masa y que se transforman en ventas no es una realidad. Ojalá viviéramos en ese mundo, pero no es así como sucede realmente. En cambio, descubrimos un grupo de usuarios, muchos de los cuales pertenecen a grandes o enormes empresas de TI, que quieren la estabilidad, el ciclo de vida y el ecosistema de hardware de RHEL sin apoyar realmente a los encargados de mantenimiento, los ingenieros, los escritores y todos aquellos que contribuyen a su creación. Estos usuarios también decidieron no usar una de las muchas otras distribuciones de Linux.

Para tener un ecosistema open source saludable, es necesario que la competencia y la innovación vayan de la mano. Red Hat, SUSE, Canonical, AWS y Microsoft crean distribuciones de Linux con un trabajo asociado de desarrollo de ecosistemas y de marcas. Todas estas variantes utilizan el código fuente de Linux y contribuyen con él, pero ninguna afirma ser "totalmente compatible" con las demás.

En definitiva, consideramos que las recopilaciones de RHEL no aportan valor y no estamos obligados a facilitarles el trabajo. Eso me lleva a hablar de la enorme confusión que existe con respecto a CentOS Stream. Reconozco que se trata de un cambio en una larga tradición que superó todas las expectativas, por lo que tal confusión es comprensible. Nos acusaron de convertir Red Hat en una empresa de código cerrado y de cometer presuntas infracciones de la GPL. Existe CentOS Stream como producto binario y CentOS Stream como repositorio fuente. La fuente de gitlab de CentOS Stream es donde desarrollamos las versiones de RHEL, con tecnología de open source al alcance de cualquier persona. Llamar a RHEL "código cerrado" es una declaración totalmente falsa e incorrecta. CentOS Stream funciona más rápido que RHEL, por lo que es posible que no esté en HEAD, pero el código está ahí. Si no lo encuentra, es un error, así que comuníquese con nosotros.

También ofrecemos suscripciones a Red Hat Developer y Red Hat Enterprise Linux (RHEL) for Open Source Infrastructure sin costo. La primera incluye RHEL gratuito para los desarrolladores y permite el uso de hasta 16 sistemas sin costo, beneficios que pueden aprovechar los usuarios particulares para su propio trabajo y los clientes de RHEL para el trabajo de sus empleados. RHEL for Open Source Infrastructure está diseñado para brindar a los proyectos open source (ya sea que estén afiliados a Red Hat o no lo estén) acceso a RHEL gratuito para sus necesidades de infraestructura y desarrollo.

Finalmente, me gustaría dirigirme a todas las empresas de tecnología de open source, ya sea que su código actualmente sea open source o esté considerando implementar ese modelo. Desde cualquier punto de vista, Red Hat logró su objetivo, y espero que muchas empresas de la misma clase puedan tener éxito como nosotros. Ustedes mismos pueden evaluar si las recopilaciones downstream son útiles para su empresa, y es su decisión facilitarlas o no. 

La simple recopilación del código, sin agregar valor ni hacerle algún cambio, representa una amenaza real para las empresas open source en todas partes del mundo, hasta tal punto que tiene el potencial de convertir el open source en una actividad exclusiva para aficionados y piratas informáticos.

No queremos eso y sé que los miembros de nuestra comunidad, los clientes y los partners tampoco lo quieren. La generación de innovaciones ocurre de manera upstream. La tecnología de open source se trata justamente de crear a partir del trabajo de otros. Sigamos impulsando la innovación, apoyándonos unos a otros y avanzando.