Formada por el trío CIQ, Oracle y SuSE, la Open Enterprise Linux Association anunciado la semana pasada está lejos de carecer de ambición. Pero en este proceso de construcción de un clon gratuito de Red Hat Enterprise Linux (RHEL), ninguno de sus miembros fundadores tiene la intención de distribuir sus propios productos de forma gratuita. Estos últimos incluso esperan sinceramente que las empresas recurran a ellos para obtener RHEL de forma gratuita y que también (¿especialmente?) estén dispuestos a pagar por sus servicios. Sin embargo, como empresas que nunca han competido exitosamente con Red Hat individualmente, se les puede perdonar que piensen que un esfuerzo colectivo marcará la diferencia. Sin embargo, en lugar de acusar a OpenELA de ser una cansada resurrección de UnitedLinux, ¿por qué no tomarse el tiempo para analizar más profundamente dónde están funcionando los esfuerzos colectivos de código abierto? ¿OpenELA fracasará donde Kubernetes tuvo éxito? ¿Qué pasa con OpenTF, un esfuerzo por revertir la decisión de HashiCorp de cambiar su licencia de Terraform a la Licencia de software empresarial (BSL)? De todas estas iniciativas y estrategias surge un punto común: el de buscar rentabilidad y olfatear buenos movimientos financieros, especialmente los que provienen de la nube.

Quizás el mayor error de OpenELA es que no logró atraer a ningún proveedor importante de nube. SuSE lleva mucho tiempo defendiendo razonablemente la posibilidad de competir con Red Hat, desarrollando su propia distribución. Pero ¿qué pasa con Oracle y CIQ? En última instancia, sus actividades con Linux se reducen a tratar de proporcionar RHEL... ¡Por menos! Las empresas que se toman en serio su infraestructura podrían preguntarse: ¿por qué comprar un clon de RHEL de un competidor de Red Hat en lugar de la propia Red Hat? ¿Cómo podría una política de TI inteligente apostar fuerte por empresas que no están bien posicionadas para mejorar o cambiar un producto que no les pertenece? Esta es probablemente una de las razones principales por las que cualquier proveedor de nube serio se subiría al tren de OpenELA. Cada uno de ellos ya tiene distribuciones de Linux atractivas que son interesantes para los clientes por derecho propio, no pálidas imitaciones de RHEL. Dado que una gran parte de los clientes globales ahora compran software a través de los principales proveedores de nube, esto puede ser un indicador claro de que OpenELA no funcionará.

Índice
  1. ¿Un futuro similar al OpenTF?
  2. Poder financiero en manos de los proveedores de la nube

¿Un futuro similar al OpenTF?

Lo mismo podría aplicarse a los firmantes de la iniciativa OpenTF. Estos últimos proponen bifurcar Terraform y crear (o unirse) a una fundación, con un desarrollo “verdaderamente de código abierto”. [...] liderado por la comunidad [...] e imparcial. El idealismo es palpable. También es completamente irreal. Es fácil mirar a Kubernetes o Linux e imaginar que debe ser sencillo aprovechar el genio colectivo de los desarrolladores, pero cualquiera que esté realmente involucrado en configurar y continuar administrando tales esfuerzos sabe lo difíciles que son estas cosas. son increíblemente difíciles y complicados. Por supuesto, se puede decir que HashiCorp tenía derecho a modificar su licencia. Pero no es una cuestión de opinión personal, es una cuestión de historia.

Tomemos el ejemplo de Kubernetes, aclamado con razón como un éxito de la comunidad. Teniendo en cuenta su origen, no hay que perder de vista que no nació porque un grupo de desarrolladores se preguntaran cómo crear un esfuerzo colectivo en torno a la gestión de contenedores. De hecho, K8 se presentó más como la estrategia a largo plazo de Google para permitir la portabilidad de múltiples nubes, el enfoque perfecto para un proveedor de nube que intenta recuperar el terreno perdido frente a un operador dominante (AWS) y un poderoso segundo lugar. (Microsoft Azure), que cuenta con una posición mucho más sólida entre las empresas. ¿Y ahora dónde está? También está dirigido por unos pocos hegemones y no por un colectivo de empresas emergentes serias. Los empleados de la firma de Mountain View han aportado alrededor de un tercio de todo el código de Kubernetes desde sus inicios. Luego le sigue Red Hat, que contribuyó con el 12% del código. En tercera posición, VMware con un 8% de contribución de código. En este contexto, es difícil ver cómo OpenTF puede prosperar sin los recursos (humanos) que aportan las grandes empresas, especialmente los proveedores de nube. Sin embargo, ninguno de ellos se comprometió a ayudarlo.

Poder financiero en manos de los proveedores de la nube

Y la lista continúa. Los mayores éxitos del código abierto -al menos los utilizados en las empresas- tienden a estar respaldados por empresas, aunque eso no garantiza el éxito. OpenStack, por ejemplo, prometía ser una alternativa de código abierto a AWS y otras nubes en un momento en el que la mayoría de las empresas (aparte de las empresas de telecomunicaciones) realmente no querían una alternativa. Querían AWS, Microsoft Azure y Google, no una forma de implementar su propia solución. OpenStack todavía existe, pero ya no es un proyecto muy popular. Todavía existe principalmente porque Red Hat lo considera una forma útil de atender a algunos de sus clientes y aprovecharlos en consecuencia. De manera similar, AWS lanzó OpenSearch para contrarrestar el control de Elastic sobre Elasticsearch. Ha comenzado a tener cierto éxito, pero solo porque AWS continúa inyectándole recursos.

No hay barra libre en el código abierto, no puedes simplemente ver si hay luz e invitarte a la mesa como un aprovechado. Se necesita dinero para financiar a los desarrolladores que contribuyen a proyectos de código abierto, y ese dinero proviene cada vez más de grandes empresas de nube, que son, con diferencia, las que más contribuyen al código abierto. Si bien no hay garantía de que un colectivo de la industria fracase, si los proveedores de la nube no están a bordo, es probable que sea un mal presagio. Estos últimos tienden a centrarse en sus clientes y no aparecerán si estos no solicitan OpenELA, OpenStack u OpenWhatever. Cuando se trata de código abierto, el éxito no está garantizado sistemáticamente.