La pregunta sale ya en todas las revisiones de infraestructura, y las respuestas que hay en internet son mayoritariamente propaganda. La versión útil es más estrecha: qué cambió, a quién afecta de verdad y qué cuesta elegir mal.
Qué cambió, con precisión
HashiCorp movió Terraform de una licencia de código abierto a la Business Source License. Esa licencia permite usar, modificar y redistribuir, con una restricción: no puedes usarla para ofrecer un producto competidor de los de HashiCorp. Pasado un periodo definido, cada versión se convierte a una licencia de código abierto.
La palabra que hace el trabajo es "competidor", y la razón de que esto armara tanto ruido es que no está definida con precisión. Para la abrumadora mayoría de las organizaciones, que usan Terraform para gestionar su propia infraestructura, no cambió nada y es improbable que cambie. Para las empresas cuyo producto incluye ejecutar Terraform por cuenta de clientes, la restricción es real e inmediata.
La Linux Foundation adoptó después la bifurcación comunitaria, OpenTofu, que es genuinamente de código abierto bajo una licencia permisiva y está gobernada por una fundación en vez de por una empresa. HashiCorp ha sido adquirida desde entonces por IBM, lo que cambia el contexto corporativo sin cambiar la licencia.
A quién afecta de verdad
Usuarios finales que gestionan su propia infraestructura. No eres un producto competidor. Puedes seguir usando Terraform indefinidamente, y la licencia no es tu motivo para moverte. Si decides moverte, hazlo por otra razón, como una preferencia de gobernanza o una funcionalidad concreta.
Fabricantes de software cuyo producto lo incorpora o lo ejecuta. Si vendes una plataforma que ejecuta Terraform por cuenta de clientes, la restricción te aplica plausiblemente y la respuesta segura es OpenTofu. Este es el grupo al que apuntaba la licencia, y varios de esos fabricantes se movieron de inmediato.
Consultoras y proveedores de servicios gestionados. El medio turbio. Ejecutar Terraform como parte de entregar un proyecto a un cliente es usarlo para gestionar infraestructura, lo cual está bien. Construir una plataforma productizada alrededor para muchos clientes empieza a parecer otra cosa. Si tu modelo de negocio está cerca de esa línea, consigue una opinión jurídica en vez de una de un blog, y ten en cuenta que OpenTofu elimina la pregunta por completo, que es una razón legítima para preferirlo.
Organizaciones reguladas con reglas de compra sobre licencias. Algunos compradores del sector público y regulados tienen políticas que excluyen dependencias que no sean de código abierto, lo que lo decide por ti al margen de los méritos técnicos.
Compatibilidad y divergencia
OpenTofu se bifurcó de una versión de Terraform y sigue siendo muy compatible: el mismo lenguaje de configuración, el mismo formato de estado, el mismo protocolo de proveedores. Todo el ecosistema de proveedores funciona con los dos, porque los proveedores son programas separados que se comunican por una interfaz definida, y los registros de módulos son interoperables.
Para la mayoría de las configuraciones, migrar es cambiar qué binario llama tu pipeline.
La divergencia es real y va creciendo, eso sí. Los dos proyectos han publicado funcionalidades que el otro no tiene, y cada ciclo de versión añade un poco más. Entre las adiciones notables de OpenTofu están el cifrado de estado en reposo y algunas capacidades de evaluación temprana. Terraform ha seguido añadiendo las suyas, y parte de la funcionalidad de su ecosistema está atada a la plataforma de HashiCorp.
La consecuencia práctica: la compatibilidad de hoy es alta, la de dentro de tres años es una conjetura, y cualquier funcionalidad que adoptes y que exista en uno solo de ellos es una decisión de quedarte. Consulta la comparación de funcionalidades vigente en el momento de decidir en vez de fiarte de un resumen, porque esta es la parte que envejece más rápido.
Migrar es barato, volver lo es menos
Pasarse a OpenTofu es genuinamente sencillo para un entorno típico. Instala el binario, apunta tu pipeline a él, ejecuta un plan y confirma que sale vacío, y súbelo. Haz copia del estado primero, cosa que deberías estar haciendo igualmente. Para la mayoría de los equipos esto es una tarde.
La asimetría es la parte en la que hay que pensar. En cuanto adoptas una funcionalidad exclusiva de OpenTofu, volver significa quitarla. En cuanto un proveedor o un módulo de tu cadena de suministro se vuelve prioritariamente de OpenTofu, tus opciones se estrechan. Eso no es un argumento contra moverse, es un argumento para decidir a conciencia en vez de derivar.
Unas comprobaciones prácticas antes de migrar: confirma que todos los proveedores que usas están disponibles, comprueba que tus herramientas de integración continua y cualquier herramienta de política o de coste del pipeline admiten el binario al que cambias, y verifica que tu backend de estado funciona sin cambios. Los patrones de estado y pipelines de Terraform en AWS se aplican igual a cualquiera de las dos herramientas, que es parte de por qué el cambio es barato.
Lo que recomendamos, por situación
Ya estás en Terraform, una sola organización, sin preocupación de licencia. Quédate. La migración tiene coste y hoy no tiene beneficio para ti. Revísalo si aparece en un solo lado una funcionalidad que necesites.
Empiezas de cero. Ligera preferencia por OpenTofu. La gobernanza por fundación elimina una categoría de riesgo futuro, la compatibilidad es alta, y no hay coste de migración cuando no hay nada que migrar.
Construyes un producto encima. OpenTofu, y deja de pensar en ello.
Compras públicas o reguladas con requisitos de código abierto. OpenTofu, decidido por ti.
Ya invertiste en la plataforma gestionada de HashiCorp. Quedarse es coherente. La integración de la plataforma es lo que estás pagando, y fragmentar tus herramientas para defender una postura cuesta más de lo que ahorra.
Elijas lo que elijas, la decisión que más importa es la de debajo: tu estructura de módulos, tu organización del estado, la disciplina de tu pipeline y tus pruebas. Eso determina si tu código de infraestructura es mantenible, y es idéntico en las dos. Un equipo con buen diseño de módulos y pruebas reales del código de infraestructura estará bien con cualquiera. Uno sin eso sufrirá con las dos.
Lo que se olvida
- Fija la versión. Uses la que uses, fíjala en el pipeline y en la configuración. Un binario sin fijar que se actualiza solo es la forma en que un plan produce una sorpresa.
- Los proveedores se licencian aparte. El proveedor del que dependes tiene su propia licencia y su propio mantenedor, y eso es una cuestión de cadena de suministro independiente de esta elección.
- El estado es el activo valioso. Las dos herramientas leen hoy el mismo formato. Protege el estado, haz copias, y que una migración no sea la primera vez que pruebas restaurarlo.
- No ejecutes las dos. Un equipo usando binarios distintos contra el mismo estado está pidiendo una incompatibilidad sutil en el peor momento.
- La documentación también diverge. Una respuesta encontrada en internet puede describir el comportamiento de la otra herramienta.
Qué hacer esta semana
Ejecuta un plan con los dos binarios contra una pila de no producción y compara la salida. Si es idéntica, cosa que en la mayoría de los entornos ocurrirá, has establecido que la elección es reversible hoy y puedes decidir por motivos de gobernanza en vez de técnicos. Es un experimento de media hora que quita casi toda la ansiedad de la decisión. Lo hacemos durante la revisión de plataforma de un proyecto cloud.