Velero tras la adquisición de Broadcom: riesgos y alternativas
Hay algo poético en el mundo del código abierto. Un día estás construyendo con libertad, colaborando entre continentes e intercambiando bromas sobre la sangría de YAML. Al siguiente, una empresa multimillonaria adquiere tu proyecto favorito y de repente te preguntas si tus copias de seguridad seguirán funcionando dentro de seis meses.
En esa situación se encuentran los usuarios de Kubernetes con Velero, la conocida herramienta de backup de código abierto, y su nuevo propietario corporativo, Broadcom.
A primera vista podría parecer una adquisición de software más, pero quien lleve suficiente tiempo en el ecosistema nativo de la nube sabe que no es tan simple. El historial de Broadcom con comunidades de código abierto parece una advertencia, y Velero podría ser el siguiente capítulo.
Así es como una conversación habitual sobre copias de seguridad en Kubernetes se convirtió en un ejemplo práctico del problema de confianza en el código abierto, y esto es lo que los usuarios están haciendo al respecto.
La herramienta de backup que gusta a todo el mundo
Si no has tenido que lidiar con la recuperación ante desastres en Kubernetes, Velero es una de esas herramientas de código abierto que simplemente cumplen su cometido. Es una solución nativa de Kubernetes para respaldar y restaurar clústeres, espacios de nombres y volúmenes persistentes. Se integra con una amplia gama de proveedores de almacenamiento, admite entornos locales y en la nube y, lo que resulta fundamental, no te encierra tras una barrera de pago.
Velero lleva años sosteniendo entornos de producción sin causar complicaciones. Es flexible, admite scripts y resulta transparente; muchos ingenieros de plataforma confían en ella lo suficiente como para automatizar por completo la recuperación de sus clústeres.
Originalmente fue desarrollada por Heptio (el mismo equipo que creó varias de las primeras herramientas de producción para Kubernetes), pasó bajo el paraguas de VMware Tanzu y, mediante adquisiciones sucesivas, acabó en manos de Broadcom. Técnicamente ahora es un producto de Broadcom, y ahí es donde empiezan las dudas.
Llega Broadcom, el gigante corporativo en el clúster
La reputación de Broadcom en los círculos de código abierto, dicho con suavidad, no es buena.
Hablamos de la misma compañía que compró VMware y Bitnami para cambiar de inmediato sus modelos de producto de formas que inquietaron a los usuarios de código abierto, con niveles de pago, cambios de licencia y proyectos comunitarios que poco a poco pasaron a ser ofertas empresariales exclusivas. Broadcom suele priorizar maximizar beneficios por encima de conservar la simpatía de la comunidad.
Por eso, cuando los ingenieros vieron que Velero pasaba a la cartera de Broadcom, la confianza no fue la reacción mayoritaria. Pocos esperaban que Velero desapareciera de la noche a la mañana. El temor era que fuera deslizándose hacia un modelo comercial cerrado, con un panel de pago aquí y una suscripción de soporte allá, esa clase de cambio gradual que convierte un pilar abierto en un producto bajo control corporativo.
Algunos ingenieros bromeaban diciendo que seguirían usando Velero hasta que se lo arrancasen de sus clústeres. Otros hablaron seriamente de crear un fork y mantener viva una versión comunitaria.
Puede sonar exagerado, pero en el mundo del código abierto responde a un patrón reconocido más que a simple paranoia.
Hacer un fork como nueva resistencia
Cada vez que una gran corporación asume un proyecto comunitario y cambia su licencia o su rumbo, se repite la misma historia y la comunidad crea una bifurcación. Terraform dio lugar a OpenTofu, Redis se convirtió en Valkey y Elasticsearch derivó en OpenSearch.
El patrón resulta casi predecible. Cuando la influencia corporativa aprieta demasiado, el ecosistema de código abierto regenera la cabeza perdida como una hidra.
Velero podría seguir el mismo camino si Broadcom endurece el control. La ventaja es que Velero ya cuenta con colaboradores ajenos a VMware y Broadcom, y su uso está muy extendido entre proveedores de nube y distribuciones. Si la empresa decidiera convertirlo en software privativo, muchos desarrolladores cualificados están preparados para crear un fork y continuarlo bajo una organización neutral como la CNCF (Cloud Native Computing Foundation).
Esa es la razón de ser del código abierto: nadie puede retener el código como rehén.
Ya hemos pasado por esto
Nada de esto es inédito, y la sensación de déjà vu en la comunidad está justificada.
Cuando HashiCorp cambió la licencia de Terraform a un modelo más restrictivo, la comunidad no se limitó a protestar. Se organizó, y en cuestión de semanas nació OpenTofu con el respaldo de la Linux Foundation. Ocurrió lo mismo cuando Redis modificó sus términos, y Amazon junto a otras compañías respondieron impulsando Valkey.
Aquellos incidentes cambiaron la forma en que los desarrolladores valoran sus dependencias abiertas. Encontrar buen software es solo una parte; también necesitas estabilidad y continuidad cuando la propiedad cambia de manos.
Eso es lo que ocurre ahora con Velero. Los ingenieros se plantean las mismas preguntas difíciles:
«¿Podemos confiar en que seguirá siendo abierto?»
«¿Deberíamos planificar alternativas?»
«¿Con qué rapidez podríamos migrar si las condiciones cambian?»
Son preocupaciones prácticas y no teóricas. El recuerdo de proyectos desaparecidos, licencias modificadas por sorpresa y API rotas sigue muy fresco.
Explorar las alternativas
Como es natural, los equipos comenzaron a evaluar alternativas por si la gestión de Broadcom se convierte en un obstáculo. Varios nombres han surgido en debates comunitarios y pruebas:
- Kasten K10 de Veeam es una opción sólida y madura para empresas. Ofrece copias consistentes con las aplicaciones y amplias integraciones de almacenamiento, aunque no es de código abierto.
- VolSync es una solución ligera basada en replicación, pensada para copias asíncronas y laboratorios, y goza de gran popularidad en entornos de GitOps.
- K8up es un proyecto de la CNCF que ofrece un operador de backup de código abierto sencillo y directo. Sigue evolucionando pero cuenta con la tranquilidad de una gobernanza neutral.
- CloudCasa es un servicio de backup independiente de la plataforma que combina flexibilidad y simplicidad. Puede integrarse con despliegues existentes de Velero o funcionar de forma autónoma, lo que brinda opciones sin tener que abandonar lo que ya funciona.
Cada una aporta ventajas distintas. Kasten K10 encaja en empresas que necesitan garantías contractuales, VolSync se adapta a quienes prefieren el minimalismo, K8up ofrece la tranquilidad de la propiedad comunitaria y CloudCasa aporta una alternativa gestionada sin ataduras exclusivas a un proveedor.
Ninguna sustituye a Velero punto por punto, pero en conjunto ofrecen caminos viables, cada una con su propio equilibrio entre apertura, coste y complejidad.
El lado humano del código abierto
Bajo los debates técnicos late una cuestión de confianza.
El código abierto implica algo más que tener acceso al código. Supone transparencia, colaboración y propiedad compartida. Quienes desarrollan eligen herramientas abiertas porque se sienten parte de un esfuerzo colectivo y no una simple cartera de clientes.
Eso es lo que preocupa a muchos respecto a Broadcom. Las adquisiciones corporativas suelen desplazar las prioridades del desarrollo impulsado por la comunidad hacia decisiones orientadas a la facturación. Los pull requests se ralentizan, los mantenedores comunitarios pierden peso y lo que era gratis para siempre pasa a ser gratis por ahora.
Eso genera frustración y desánimo.
Velero nunca fue un complemento más en Kubernetes. Se convirtió en una pieza de confianza para incontables arquitecturas. Cuando esa confianza se resiente, los equipos no se preocupan únicamente por sus copias de seguridad; se preocupan por el principio que les llevó a adoptar el código abierto desde el principio.
Fork frente a reconstrucción: el camino realista
«Bifurcar y seguir» se ha convertido en el lema recurrente en el software abierto, pero decirlo es más fácil que sostenerlo. Mantener un fork de un proyecto grande requiere coordinación, liderazgo y un compromiso prolongado. Hay que actualizar documentación, reconstruir canalizaciones de CI/CD y definir estructuras de gobernanza.
Por eso muchos desarrolladores adoptan una postura pragmática: seguir utilizando Velero mientras funcione y tener listo un plan de migración.
Quizá sea la postura acertada. La amenaza creíble de un fork suele bastar para moderar las decisiones corporativas, porque las compañías saben que si se distancian demasiado de la comunidad abierta, perderán relevancia además de prestigio.
El nacimiento de OpenTofu a partir de Terraform fue un acto de rebeldía y también de supervivencia. Lo mismo podría suceder con Velero si fuera necesario.
Cómo prepararse para lo que venga
Si ejecutas Kubernetes en producción, la mejor respuesta es prepararse sin caer en alarmismos. Unos pasos prácticos marcan la diferencia:
- Documenta la configuración de Velero con claridad. Mantén manifiestos, parámetros de backup y ajustes de almacenamiento en formatos portables.
- Evalúa alternativas con antelación. Prueba K8up, VolSync o CloudCasa en un clúster de laboratorio y familiarízate con sus flujos de trabajo antes de necesitarlos en producción.
- Vigila los cambios de licencia. Permanece atento a cualquier modificación en el repositorio, la propiedad o el esquema de lanzamientos de Velero.
- Participa en la comunidad. Cuanto mayor sea tu actividad, mayor influencia tendrán los usuarios de forma colectiva sobre el futuro del proyecto.
Si Broadcom mantiene Velero abierto, perfecto. Si no lo hace, tendrás un plan preparado.
El fork como cualidad del ecosistema
Al final, el código abierto es fuerte por su capacidad de adaptación. El fork es una cualidad esencial del ecosistema, la válvula de seguridad que mantiene vivas la innovación y la colaboración cuando el control corporativo amenaza con asfixiarlas.
La historia de Velero puede ser un capítulo más en la larga trayectoria de herramientas abiertas absorbidas por grandes empresas, pero también demuestra que la comunidad siempre encuentra una salida.
Broadcom puede ser dueña de las marcas registradas, pero no posee la confianza ni el espíritu del código.
Si llega el día en que Velero se convierta en un entorno cerrado, la comunidad de Kubernetes no se paralizará. Se adaptará, creará un fork y reconstruirá lo necesario, tal como ha hecho siempre, porque en el código abierto la continuidad proviene de la libertad de crear una bifurcación antes que de la lealtad a una marca.