The Moment Everything Changed
When HashiCorp shifted Terraform to a Business Source License in August 2023, they didn’t just create a licensing dispute. They created the conditions for a genuine fork that infrastructure teams now have to take seriously. I watched this happen in real time across the organizations I work with, and I can tell you: the conversation shifted from “should we fork?” to “when do we migrate?” somewhere around late 2024.
What makes this different from other open-source forays is that OpenTofu wasn’t created by a handful of developers in a garage. The Linux Foundation backed it. Major cloud providers aligned behind it. And by the time OpenTofu 1.9 shipped in late 2025, it had moved past being a protest fork and became a genuinely competitive alternative with features that Terraform’s open-source tier simply doesn’t offer.
The numbers tell part of the story. OpenTofu’s GitHub repository crossed 23,000 stars by January 2026, with over 4 million weekly downloads. That’s not a rounding error. That’s adoption at scale. Compare that to where the project stood at its launch with roughly 1.5 million weekly downloads, and you’re looking at a tool that’s finding real use in real environments.
The Feature Advantage: Where OpenTofu Pulled Ahead
OpenTofu 1.9 introduced native end-to-end state encryption. Think about that for a moment. Your Terraform state file contains secrets, database passwords, API keys, and everything else that could compromise your infrastructure if exposed. For years, the standard practice in Terraform’s open-source version was to either store state in remote backends that provide their own encryption or build custom encryption layers around state management. It wasn’t elegant, and it created real operational friction.
With OpenTofu 1.9, you get encryption baked into the core tool. No middleware layer needed. No additional complexity. Just state files that are encrypted by default. This is the kind of feature that makes sense the moment you ask yourself why it wasn’t there from the start. For teams managing sensitive infrastructure, this matters.
Terraform 1.10, released around the same time, took a more measured approach. The updates were incremental. Performance improvements, some bug fixes, refinements to the existing workflow. Nothing wrong with that, but nothing that made you sit up in your chair either. There’s context here worth noting: HashiCorp’s acquisition by IBM closed in April 2024 for $6.4 billion. That kind of acquisition often changes priorities at the open-source level. Enterprise features start looking more attractive than foundational improvements to the open-source core.
The Governance Question: Why CNCF Acceptance Matters
Here’s something that rarely gets the attention it deserves: OpenTofu achieved CNCF Technical Oversight Committee acceptance as a sandbox project in early 2025. That’s not a small thing. It means the same governance pathway that gave legitimacy to Kubernetes, Prometheus, and other projects that now run critical infrastructure worldwide is now behind OpenTofu. That shifts how enterprise procurement teams think about the tool.
When you’re trying to convince your security team or your legal team to adopt something, having CNCF acceptance in your back pocket changes the conversation. It’s not perfect armor, but it carries real weight. It means independent oversight, clear governance structures, and a pathway toward long-term sustainability that doesn’t depend on any single company’s licensing strategy.
If you’re new to infrastructure as code and evaluating tools right now, this is worth understanding early. Governance matters. Not because it’s exciting, but because it directly impacts whether a tool will still exist and be maintained five years from now. CNCF acceptance gives OpenTofu that assurance in a way that self-governance alone never quite can.
The Migration Conversation: What the Data Shows
A Pulumi survey of 1,200 platform engineers in January 2026 found something that would have seemed unlikely two years ago: 31% of respondents had already migrated at least one environment from Terraform to OpenTofu. Nearly a third of respondents. In the prior year’s survey, that number was 11%. You’re looking at nearly a tripling of migration activity in a single year. That’s not experimental anymore. That’s adoption.
But here’s what I’d caution anyone considering a migration: this doesn’t mean you should move everything tomorrow. What it does mean is that the fork has matured to the point where staying on Terraform is now a deliberate choice rather than the default. You should have reasons for staying beyond inertia. You should know what you’re choosing and why.
The migration path itself has gotten smoother. OpenTofu maintains compatibility with existing Terraform state files. You can start with a single environment, understand the workflow, and make incremental decisions. You don’t have to bet your entire infrastructure on the move. Start small. Build confidence. Move additional workloads as you gain familiarity. That’s the sensible approach, and the improving tooling and documentation now supports it.
Getting Started: Where to Look and What to Learn First
If you’re just starting with infrastructure as code and trying to understand whether OpenTofu or Terraform makes sense for your situation, the first place to go is the OpenTofu official documentation and changelog. Read through it. Not all of it. But the getting started section and the basic workflow. You’ll get a sense of how the tool thinks about infrastructure. The documentation is genuinely well-written, and that matters for a tool you’re learning.
Beyond that, the Linux Foundation OpenTofu project page gives you the governance and project status context. Useful background, but not where you learn to do the actual work. That comes from hands-on experience: writing your first module, managing state, understanding how variables and outputs work. Those fundamentals are what actually matter.
Here’s where I’ve landed after watching this play out: both tools are now legitimate options. The fork is no longer theoretical. The competition is real. Organizations are making deliberate choices, not defaulting to what they’ve always used. That’s healthier for the infrastructure as code ecosystem, and better for anyone learning the craft, because it means both tools are actively being developed with feedback from large-scale users. If you’ve been hesitant about infrastructure as code because of licensing concerns or feature gaps, things have genuinely improved. What matters isn’t choosing perfectly on your first try. It’s starting, learning, and making informed decisions as you go deeper into the work.