La donación de Broadcom a la CNCF: reacciones comunitarias y confianza en el open source
En el enésimo episodio de grandes tecnológicas buscando redención, Broadcom vuelve a situarse bajo los focos, esta vez para contener daños más que por mérito innovador. La compañía anunció hace poco la donación de una utilidad de diagnóstico para Kubernetes a la Cloud Native Computing Foundation (CNCF), presentándola como un gesto de buena voluntad y compromiso con el código abierto. Suena impecable, pero no convence a todo el mundo. Para amplios sectores de la comunidad de Kubernetes y del software libre, el movimiento parece más bien un truco de prestidigitación disfrazado de generosidad.
Un poco de contexto ayuda a entenderlo. Broadcom adquirió VMware en 2022, una operación de dimensiones descomunales que sacudió el universo de la infraestructura corporativa. Junto con VMware venía un catálogo de herramientas muy apreciadas por los desarrolladores, entre ellas Bitnami y el proyecto de código abierto Harbor. Avanzamos hasta 2025 y la gestión de Broadcom ya ha dejado un regusto amargo en muchos equipos.
La decisión de retirar las imágenes públicas de contenedores de Bitnami en Docker Hub a principios de año, una maniobra que rompió canalizaciones de CI/CD de la noche a la mañana y encendió los ánimos técnicos, sigue muy fresca en la memoria colectiva. Por eso, cuando Broadcom sale a copar titulares hablando de su apoyo al software libre, resulta comprensible que surjan sospechas inmediatas.
¿Qué se está donando en realidad?
El gran anuncio de Broadcom gira en torno a la donación de una herramienta para Kubernetes a la CNCF: en concreto, una utilidad de diagnóstico para etcd pensada para depurar y monitorizar el almacén clave-valor del que depende todo clúster. Sobre el papel, es práctica. En la realidad cotidiana, la comunidad duda de su relevancia real.
El tratamiento en prensa añade más fricción. Un usuario de Reddit tardó poco en subrayar que gran parte del artículo donde se anunciaba la "donación" elogiaba a Harbor, un proyecto que VMware ya había transferido a la CNCF allá por 2018. Aquello ocurrió años antes de la llegada de Broadcom, con lo que cabe preguntarse qué pinta en una nota de prensa de 2025.
Un participante lo resumió sin tapujos: "No pueden donarlo otra vez. No tuvieron nada que ver con eso, así que ni tiene sentido mencionarlo". Golpe directo.
Otros fueron igual de claros. Un lector propuso un titular alternativo: "Broadcom intentando a la desesperada ganar puntos con poco esfuerzo ante la comunidad a la que está perjudicando a diario". Las palabras son duras, pero reflejan el sentir de bastantes profesionales.
La pauta del abandono corporativo
Al rascar bajo la superficie, lo que parecía un gesto desinteresado adquiere tintes de recorte de gastos envuelto en celofán open source. Varios miembros de la comunidad de Kubernetes coinciden en que las aportaciones de Broadcom al código abierto suelen seguir una misma secuencia: prescinde de los equipos internos encargados de mantener las utilidades y acto seguido entrega el repositorio a la CNCF o a otra fundación. El objetivo parece buscar ahorro interno antes que enriquecer al colectivo.
"Ellos también las siguen usando un poco", apuntó un desarrollador en alusión a las herramientas donadas. "Simplemente no quieren pagar a ingenieros que mantengan lo que han donado". Es el equivalente digital a dejar un sofá viejo en la puerta de una asociación benéfica esperando que otros paguen la factura de la tapicería.
Y la comunidad se percata enseguida. Quienes desarrollan software detectan de inmediato cuándo un proyecto ha quedado estancado. Un usuario compartió el historial de confirmaciones en GitHub de Kapp (otra herramienta asociada en su momento a VMware): seis meses completos de inactividad seguidos de un par de cambios "sospechosamente sincronizados" justo antes de la donación. Resulta difícil no interpretarlo como un lavado de cara de última hora para la galería.
Por qué esto genera tanto malestar
La comunidad de Kubernetes y del código abierto tiene motivos sobrados para su escepticismo, nacidos de vivencias reales y muy cercanas.
El repliegue de Bitnami fue un golpe durísimo para los equipos que dependían de la disponibilidad pública de esos contenedores, mucho más grave que una simple molestia de configuración. Broadcom habilitó vías de acceso privado bajo pasarelas de pago o sobre plataformas privativas, dinamitando el carácter abierto y gratuito del proyecto. Un paso así frena la adopción y quiebra la confianza al mismo tiempo.
Si a eso le sumas la escalada desorbitada en las tarifas de licencias de VMware tras completarse la compra, la impresión dominante es que Broadcom está transformando el software corporativo en un club privado reservado a quienes cuentan con presupuestos millonarios.
Un usuario condensó la táctica en tres palabras: "Adoptar, extender, extinguir". El viejo manual de la era clásica de Microsoft: asumir una herramienta libre, adaptarla lo justo a las necesidades propias y dejar languidecer el caso de uso comunitario sin hacer demasiado ruido.
Ni siquiera parece evidente que Broadcom aspire a ser un buen ciudadano del código abierto. Otro comentario sostenía: "Broadcom apoya el código abierto solo para retener a ingenieros de primer nivel que se marcharían si no tuvieran esa libertad". Bajo esa lectura, el software libre se tolera por pura conveniencia, nunca por convicción.
¿Qué coste tiene esto en realidad?
Podría resultar tentador restarle importancia a la polémica, puesto que las empresas reajustan sus planes estratégicos con frecuencia. No obstante, cuando esos giros comprometen la fiabilidad y supervivencia de infraestructuras ampliamente extendidas, las consecuencias se sienten de verdad.
Kubernetes es una pieza vertebral de la computación en la nube actual. Cuando las piezas de su ecosistema quedan obsoletas de pronto, se bifurcan en forks o se encierran bajo llave, el impacto sacude a infinidad de equipos, desde pequeñas startups hasta grandes corporaciones.
Y cuando gigantes como Broadcom recurren a las donaciones de código como escaparate publicitario sin invertir en el personal, el mantenimiento continuo y la transparencia necesarios, debilitan el ecosistema y erosionan su propio crédito. Lo preocupante es el mensaje cultural de fondo, que trasciende a cualquier utilidad concreta.
¿Puede Broadcom recuperar la confianza de la comunidad?
No resulta imposible, pero el camino será empinado. Si Broadcom desea recuperar credibilidad en el entorno del código abierto, tendrá que hacer algo más que publicar notas promocionales amables. Necesita explicar con claridad por qué transfiere sus proyectos y si los sigue explotando de forma interna. Le conviene invertir en una relación genuina con la comunidad en lugar de limitarse a trámites legales de cesión, y sostener a los mantenedores en vez de soltar el código y marcharse. También tendría que dejar de monetizar recursos que antes eran de libre acceso sin poner a cambio un valor equivalente sobre la mesa.
Y lo más decisivo: debe abandonar la pretensión de que estos movimientos responden al altruismo. La comunidad técnica es despierta, está muy interconectada y no se deja engañar con facilidad.
Conclusión
La donación de Broadcom a la CNCF puede considerarse apoyo formal al código abierto en lo estrictamente técnico, pero en la práctica se parece más a un lavado de imagen corporativa. Cuando los antecedentes recientes de una firma acumulan promesas incumplidas, servicios retirados y subidas de tarifas, soltar un paquete de código no reinicia el marcador.
Los desarrolladores no buscan notas de prensa pulidas. Exigen herramientas estables, hojas de ruta transparentes y respeto hacia la comunidad. Mientras Broadcom no demuestre que puede ofrecer eso, cada nueva donación será recibida con desconfianza y distancia, una desconfianza que parece del todo justificada.