El fork de Terraform ocurrió en 2023: HashiCorp cambió la licencia a BSL y la comunidad respondió con el manifiesto OpenTF. Entonces la pregunta sonaba inquieta — ¿es siquiera seguro apostar por un fork? Para 2026 quedó obsoleta. OpenTofu vive bajo la Linux Foundation, sigue siendo un reemplazo drop-in con el mismo HCL y los mismos providers, corre la versión 1.11 en producción y cuenta a Allianz y Fidelity entre sus adoptantes. La pregunta se volvió pragmática: no si se puede, sino cuándo el fork ya es la mejor opción.
De «arriesgado» a «opción por defecto»
OpenTofu no es un clon que va a la zaga. Es un motor aparte con la misma sintaxis pero su propia trayectoria. Drop-in aquí es literal: el mismo HCL, los mismos providers del registro, el archivo .terraform.lock.hcl no se renombra, el bloque terraform {} se acepta tal cual. La CLI es tofu, la governance es comunitaria bajo la Linux Foundation y no de un único proveedor. Para un proyecto nuevo la barrera de entrada es cero, y la licencia MPL 2.0 (OSI) despeja la cuestión de BSL con los abogados de inmediato, sin salvedades.
Dónde el fork superó al upstream
El titular de los dos últimos años: OpenTofu no solo mantiene la paridad — en algunos puntos va por delante del original.
Cifrado nativo de state y plan (desde 1.7) — un bloque encryption {} con AWS/GCP KMS u OpenBao, sin sops ni GPG externos. Terraform no tiene nada nativo aquí. Early evaluation (1.8) permite variables dentro del bloque backend {} y en module.source — configuraciones de backend dinámicas, imposibles en el upstream. for_each en providers (1.9) pliega el multirregión en un solo bloque en vez de alias escritos a mano. El bloqueo nativo en S3 (use_lockfile, sin DynamoDB) llegó en OpenTofu 1.10 — una release antes que Terraform 1.11. Esto ya no es un reemplazo gratuito, sino un motor que resuelve problemas que el original no puede.
El lock-in es asimétrico: quedarse también es una apuesta
Un mito común: migrar es un riesgo y el statu quo es seguridad. En realidad la compatibilidad es de una sola vía. Terraform → OpenTofu va fluido: herramientas de migración, un plan con cero cambios. La vuelta es dolorosa — si usaste las funciones únicas, el state cifrado y los backends dinámicos son sencillamente incompatibles con el original. Así que no hacer nada también es una decisión con consecuencias: cuanto más tiempo un equipo permanece sobre un motor BSL y acumula piezas específicas de HCP (Stacks, Sentinel), más caro resulta el desenredo posterior.
Migrar es más barato que el miedo a migrar
Un caso real: 8 mil líneas, 12 módulos, tres entornos, un backend en S3 + DynamoDB, GitHub Actions — el cambio llevó unas cuatro horas, y la mayor parte de ese tiempo se fue en reescribir la CI, no el código. El esquema: primero aplicar todos los cambios pendientes y respaldar el state — se migra desde un estado limpio. Luego, de forma coordinada, borrar el archivo .terraform.lock.hcl en todo el equipo a la vez, o un compañero con un lock file de Terraform choca con conflictos de hash. Después, tofu init y tofu plan, que debe mostrar cero cambios — ese es el gate de go/no-go: un diff significa que no se migra, se investiga. El último paso es cambiar setup-terraform por setup-opentofu en el pipeline. Y nunca mezclar binarios sobre un mismo state: tras tofu apply todos los ingenieros y la CI pasan a tofu, o se cuela un drift silencioso.
Dónde Terraform sigue ganando
Un contrapunto honesto: el fork no es una respuesta universal. Quedarse en Terraform es racional si hay una inversión profunda en HCP Terraform y Sentinel, donde el ecosistema de políticas y orquestación está atado al proveedor; si se necesitan Stacks para orquestar muchos workspaces y OpenTofu aún no tiene equivalente; si hace falta la integración oficial de MCP para agentes de IA — Terraform la tiene, el fork todavía no de forma oficial, y eso cuenta al construir pipelines con agentes; si se necesita soporte enterprise de IBM y el equipo legal acepta BSL. Es una elección racional, no conservadurismo.
La regla de decisión para 2026
Para un proyecto greenfield el valor por defecto es OpenTofu: barrera de entrada nula, licencia OSI, funciones que van por delante en algunos puntos, sin exposición a BSL. El fork ya compensa cuando no hay lock-in en HCP y se valoran el cifrado nativo del state, los backends dinámicos y la ausencia de dependencia del proveedor. Quedarse en Terraform tiene sentido solo con un compromiso profundo con HCP Stacks, Sentinel o MCP — o con una exigencia firme de soporte del proveedor. La era de un único estándar de IaC terminó y empezó la era de la elección; y en 2026, para la mayoría de los proyectos nuevos, la elección deliberada se inclina hacia el fork.