La empresa SUSE ha propuesto a la comunidad de openSUSE el poder colaborar de una manera más estrecha a la hora de desarrollar SUSE Linux Enterprise y openSUSE Leap
Hace unos días (el pasado 9 de abril de 2020) llegaba un correo a la lista de correo del proyecto openSUSE en el que se hacía una propuesta a la comunidad de openSUSE por parte de SUSE de tener una colaboración más estrecha entre ambos proyectos.
El hilo derivado de este correo ha traido muchas respuestas de la comunidad que se hacen preguntas y quieren más información. ¿Pero qué es lo que se proponía en ese correo? En resumen SUSE quiere acercar posiciones con la comunidad de openSUSE y propone una serie de cambios.
Cambios que quieren ser beneficiosos para ambas partes y que llevaría la relación entre SUSE y openSUSE a un nuevo nivel. Traduciré aquí en el blog una parte del correo con la propuesta realizada y trataré de dar algo más de información.
El correo en cuestión empezaba diciendo algo así:
Hoy tengo noticias interesantes y una propuesta para transmitir: SUSE quiere dar un paso más en la apertura hacia la comunidad de openSUSE y sugiere llevar la relación entre openSUSE Leap y SUSE Linux Enterprise a un nuevo nivel.
De manera interna se llama a esta idea «Closing the Leap Gap» y propone fortalecer y unir más:
- las comunidades de desarrolladores, al centrarse en openSUSE Leap como una plataforma de desarrollo para las comunidades y para socios industriales.
- las comunidades de usuarios, al aprovechar los beneficios de una base de código empresarial estable y la velocidad de las contribuciones de la comunidad.
- las bases de código de openSUSE Leap y SUSE Linux Entreprise (SLE), no solo compartiendo el código fuente, sino también ofreciendo los binarios de SUSE Linux Enterprise para ser incluidos en openSUSE Leap.
La propuesta incluye un enfoque de tres pasos:
- Combinar las bases de código para la intersección de openSUSE Leap 15.2 y SUSE Linux Enterprise 15 SP2 tanto como sea posible sin pérdida de funcionalida o estabilidad. (SUSE ha comenzado un proceso de limpieza en la parte de SUSE Linux Enterprise)
- En paralelo al clásico openSUSE Leap, crear una nueva versión que aproveche los binarios de SLE, lo que daría a luz una versión intermedia temporal para el mes de octubre de 2020.
- Publicar openSUSE Leap 15.3 con los binarios de SUSE Linux Enterprise ya incluidos de manera predeterminada (asumiendo que haya acuerdo en la comunidad con esta propuesta).
Y continuaba el correo con unas entrevistas a diferentes personas involucradas en el desarrollo de SUSE, que exponían razones y ventajas de dicho acuerdo. Ya digo que la comunidad se está expresando en dicho hilo y las respuestas al correo son numerosas.
Por mi parte, en hilos tan largos me pierdo, además de que mi inglés llega un momento que «hace tope» y ya no me entero de nada! Así que he decidido enviarle un correo a un desarrollador de SUSE que trabaja en hacer de YaST una herramienta todavía mejor que es canario y que quizás me podía informar mejor y aclararme dudas.
¡Muchas gracias a Ancor por la respuesta y por su tiempo! Gracias a él me ha quedado más claro y trataré de explicar aquí con mis palabras su explicación.
Como ya sabéis desde hace unas cuantas versiones openSUSE Leap tomaba partes del código base de SUSE Linux Enterprise (SLE) para construir una distribución comunitaria que se alineaba con las publicaciones de SLE.
Esto reducía tiempo de desarrollo en cada nueva versión de openSUSE Leap, además hacía que openSUSE Leap disfrutara de una estabilidad que otorgaba el que un código común desarrollado por SUSE para el entorno empresarial y comercial.
openSUSE Leap y SLE compartían un código común, y después cada cual compilaba ese código de manera independiente para crear las dos distribuciones. openSUSE utiliza la instancia de Open Build Service y SUSE una instancia propia. Por lo que finalmente las distribuciones serían diferentes. Además de que en openSUSE se incorporaría toda la paquetería comunitaria.
Con esta nueva propuesta SUSE quiere que tanto SLE como openSUSE Leap compartan ya no solo una parte de código, sino los mismos binarios. Por lo que a la postre serían prácticamente idénticas (salvo pequeños detalles) y después cada cual tendría su paquetería propia, como hasta ahora.
Para hacerlo quieren que en la próxima versión de openSUSE Leap 15.2 que ahora mismo está en desarrollo, desarrollar paralelamente a openSUSE Leap una versión temporal llamada Jump como prototipo de conjunción de binarios entre ambos proyectos.
Si todo saliera bien, se continuaría así en próximos lanzamientos de openSUSE Leap, y se abandonaría ese proyecto temporal que sería Jump. En la wiki de openSUSE hay una página creada en inglés con las preguntas más frecuentes (FAQ) al respecto de este proyecto:
SUSE siempre ha mantenido una estrecha colaboración con la comunidad de openSUSE y ha habido una franca confianza entre ambos proyectos. Son muchos los desarrolladores de SUSE que colaboran en aspectos de openSUSE, además de ofrecer infraestructura para el proyecto en forma de servidores y financiación.
Así que espero que esta propuesta venga a beneficiar a ambas partes y hacer que ambos proyectos sigan adelante fortalecidos de la unión de ambos ahora también en este aspecto.
Espero haber aclarado algo las dudas, y las informaciones al respecto de esta nueva propuesta de SUSE a la comunidad de openSUSE. Si alguien tiene alguna corrección e información extra, para eso son los comentarios, para el aporte!
Victorhck in the free world 
Suena «bien», pero… no sé… me supone más control por parte de SUSE que de la misma comunidad y eso la verdad no creo que sea nada bueno, para muestra ahí está el trago amargo que está pasando ahorita KDE porque una empresa planea aumentar sus ganancias a costillas de la comunidad del software libre…
Tampoco entiendo el motivo, si al final serán el mismo sistema, y además, libre, ¿no dejaría de poder «cobrar» por su versión empresarial?
¿Cuál será la diferencia entre SLE y openSUSE ahora?
¿En qué le conviene a SUSE este cambio?
No sé, demasiadas preguntas están en mi cabeza.
Por el momento tomaré esta «sugerencia» con pinzas porque además, en el correo original se habla de que SUSE pospondría su versión 15.2 hasta el 2 de julio… igual que lo ya anunciado por openSUSE hace dos días…
Hola Muurh,
Lo primero, es que cualquiera puede descargarse de manera gratuita la version de SUSE Linux Enterprise. El modelo de negocio no es vendiendo software (eso no funciona bien con software libre ni con open source), el modelo de negocio es ofreciendo soporte, es decir, si tu usas Leap y tienes un problema y no sabes solucionarlo o no puedes, puedes pedir ayuda a la comunidad, si tienes suerte alguien estará interesado en ofrecer ayuda voluntariamente y arreglar el problema.
Una empresa que depende de software no puede esperar a que un voluntario le arregle el problema, hay empresas que cuentan cada minuto de servidores caídos en miles de euros.
Por eso, esas empresas pagan a una empresa, en este caso SUSE, para que si tienen un problema, tengan a un especialista siempre respondiendo según SLA (service license agreement, acuerdo de servivios prestados) del tipo, resolución de X problema en 7 días laborales, resolución de Y en 24h, etc.
Ahora bien, puedes descargar SLE gratis, pero no acceder a los repositorios de SUSE gratis, esos repositorios sólo están disponibles para clientes. No porque contengan algo privado (el codigo fuente es el mismo que el de Leap), sino porque es una instancia que mantiene disponibilidad, tiempo de respuesta, etc, que es caro de mantener, y si toda la comunidad accediera a ellos, sería demasiado gasto.
Entonces la comunidad accede a los repositorios/mirrors que son mantenidos por la comunidad (openSUSE) mientras que los clientes acceden a los repositorios/mirrors de SUSE.
Quedando claro esa parte, ¿por qué quiere SUSE acecar Leap y SLE más?
En primer lugar porque cada bug encontrado en Leap en software incluido en SLE, es un bug que afecta a los dos, y también a los clientes. Entonces, quieren que sea más fácil arreglar el bug en los dos sistemas, y lo sería si ambos tienen los mismos binarios, no sólo el código. Además, tampoco haría falta hacer dos build (SLE y Leap) y lanzar un isospost de cada uno en openQA para verificar que un parche funciona. Porque si ambos son el mismo binario, un cambio en el código fuente de SLE y tes en SLE, bastaría para propagar el binario a Leap. Y en Leap sólo sería necesario testear el software de la comunidad que no está incluido en SLE.
La parte que crea sospechas, es la de que los binarios de Leap que vienen de SLE, se construyan en la instancia interna de SUSE. Esto, que parece que SUSE quiere el control, es una imposición para ciertas certificaciones internacionales. No es decisión de SUSE, si fuese sólo por SUSE, no tendrían problema en construirlos en build.opensuse.org.
Además, el mundo empresarial/comercial es mas complejo. No sé si conocéis los «embargos de seguridad». Para evitar que un atacante pueda aprovechar una vulnerabilidad disponible en varios sistemas, todas las partes afectadas firman un acuerdo de confidencialidad. De forma que todas se informan las unas a las otras, después todos arreglan el problema, y después todos liberan el parche al mismo tiempo.
Eso, tampoco puede hacerse en build.opensuse.org.
Espero que haya aclarado algo.
¡Un saludo!
Hola!
Muuchas gracias por tu explicación clara y detallada del complejo tema técnico que hay detrás.
Para mí ha quedado mucho más claro.
Saludos!!!
Ya puesto así suena de otra forma; entonces veremos qué pasa. Gracias, tu respuesta fue de lo más amena y útil.