The Fork That Became a Movement
Back in August 2023, HashiCorp made a decision that rippled through the infrastructure-as-code community like a stone dropped into still water. They changed Terraform’s license from Mozilla Public License 2.0 to the Business Source License, a move that essentially closed the door on certain commercial uses of the open-source version. For years, Terraform had been the de facto standard for managing cloud infrastructure across every major provider and thousands of smaller platforms. People built entire operational cultures around it. Then, overnight, the terms changed.
Within weeks, the Linux Foundation stepped in and created OpenTofu as a community-driven fork. At first, most of us in the industry treated it like a necessary protest move, important symbolically, but probably destined to remain the smaller sibling. We were wrong about that. What started as a principled stand has grown into genuine competition with real technical differentiation. The shift from ideological fork to legitimate alternative happened quietly, but by late 2025, when OpenTofu 1.9 shipped with native end-to-end state encryption, infrastructure teams suddenly had to confront a question they thought was settled: which tool do I actually want to run in production?
The Technical Inflection Point: State Encryption Changes the Calculus
State files are the nervous system of infrastructure-as-code. They contain sensitive data: database passwords, API keys, private IPs, certificate details. In Terraform’s open-source distribution, state encryption has always been optional and partial. You can encrypt data at rest if you’re willing to manage it yourself or pay for Terraform Cloud, but the native capability was never baked into the free tier. OpenTofu’s engineering team recognized this gap and made it a priority. Version 1.9 introduced end-to-end state encryption that works out of the box, no external tooling required, no premium tier gatekeeping.
If you’re new to infrastructure automation and trying to understand why this matters, think of it this way: you’re building a system that will store every password and token your infrastructure needs to function. You want that locked down from the moment the file is created to the moment it’s read. Terraform’s approach required you to solve that problem yourself. OpenTofu solved it for you. That’s not flashy. It’s not exciting. But it’s exactly the kind of decision that separates tools built for the open-source community from tools built for a company’s commercial interests.
The Numbers Tell a Story About Trust and Adoption
Statistics can obscure as much as they reveal, but the trajectory of OpenTofu adoption is worth sitting with for a moment. When the fork launched in late 2023, download volumes were modest. By January 2026, the project had surpassed 4 million weekly downloads, compared to roughly 1.5 million in those early months. The GitHub repository crossed 23,000 stars. These are not vanity metrics. They reflect actual infrastructure teams running actual production workloads on OpenTofu instead of Terraform.
More telling is what the Pulumi State of Infrastructure as Code survey revealed in January 2026. They asked 1,200 platform engineers whether they’d migrated any environments from Terraform to OpenTofu. A year earlier, 11% said yes. In 2026, that number had climbed to 31%. That’s a threefold increase in migration activity. These aren’t experiments or proof-of-concepts. Teams have committed enough to move production infrastructure. You don’t make that decision lightly. You make it because you believe the tool will serve you better.
The credibility boost came in early 2025 when the CNCF’s Technical Oversight Committee formally accepted OpenTofu as a sandbox project. This matters more than it might sound. The same governance pathway that brought Kubernetes and Prometheus into institutional legitimacy was now available to OpenTofu. Enterprises with procurement processes and governance committees, the kinds of organizations that take infrastructure tooling very seriously, suddenly had a clear signal that this project had the backing and oversight they require.
The Terraform Side: IBM’s Influence and the Incremental Path
HashiCorp’s acquisition by IBM closed in April 2024 for 6.4 billion dollars. IBM is an enterprise software company. IBM understands how to sell expensive licenses to large organizations. IBM’s playbook typically involves moving profitable products up-market, toward bigger deals and more comprehensive platforms. This doesn’t mean Terraform will atrophy. IBM has every incentive to keep it robust. But it does suggest a particular strategic direction, and that direction is not “move as fast as possible on the free-tier open-source version.”
Terraform 1.10’s release cycle has reflected this dynamic. The improvements have been solid and competent, but largely incremental. New functions, stability enhancements, provider integration refinements. Nothing that moves the needle on fundamental capability gaps. If you’re a solo practitioner or a small team, 1.10 is perfectly serviceable. But if you’re evaluating your infrastructure platform choices today, the innovation energy is clearly flowing elsewhere. OpenTofu’s roadmap is written by the community. Terraform’s roadmap is written by a public company with shareholders to answer to. Those are different forces.
Practical Guidance for Teams Making the Choice
If you’re beginning your infrastructure-as-code journey or reassessing your tooling, here’s what I’d encourage you to think through. First, understand what lock-in actually looks like for you. Terraform and OpenTofu are largely compatible at the configuration level. Code written for one will usually run on the other with minimal changes. The lock-in exists in provider ecosystems, state management patterns, and team expertise. It’s not insurmountable, but it’s real.
Second, start with a non-critical environment. Pick a small staging infrastructure or a development cluster. Try OpenTofu on that workload for a few weeks. Read through the OpenTofu official documentation and changelog to understand what’s changed since the fork. Understand the governance model by reviewing the Linux Foundation OpenTofu project page. This is not about ideological purity. It’s about making an informed decision with real operational data from your environment.
Third, think about your team’s comfort level and your organization’s risk tolerance. Terraform has been the industry standard for longer. Hiring people who know Terraform is easier. If you’re in a large enterprise with strict change control processes, you might be moving slowly either way. But if you’re in a position to adopt emerging tools, and if state encryption out of the box matters for your security posture, the choice becomes clearer. The fork is real. The competition is genuine. The question is no longer whether OpenTofu can be trusted to run production infrastructure. It’s whether your specific situation calls for it.
The infrastructure-as-code landscape has shifted, and what started as a license dispute has turned into a genuine platform choice with real stakes. I’d be curious to hear from teams who have made the migration. What prompted the decision, and what surprised you in implementation? The infrastructure community benefits from this kind of competition, and from people willing to share what they’ve learned. Send me a note or leave a comment if you’ve worked through this choice.