The License Change That Started Everything
If you were paying attention in August 2023, you remember the exact moment HashiCorp announced it was moving Terraform to the Business Source License. The internet did what it does best: collectively lost its mind. After years of treating Terraform as the de facto standard for infrastructure-as-code, suddenly the thing that powered your entire deployment pipeline came with strings attached. The BSL move wasn’t technically closing Terraform off, but it felt close enough, and the infrastructure community’s reaction was swift and righteous.
The Linux Foundation stepped in quickly. OpenTofu emerged as a fork, maintaining the MPL 2.0 license and the promise that Terraform would always be genuinely open. For a moment, it looked like classic open-source drama: the noble rebels against the commercial overlords. But here’s what separates this story from past forks that withered on the vine – this one actually executed. Two and a half years later, OpenTofu isn’t a relic maintained by three people in their spare time. It’s grown into something that deserves serious consideration for new projects and migrations alike.
Where OpenTofu Has Pulled Ahead
Let’s talk concrete capabilities because that’s where the rubber meets the road. By late 2025, OpenTofu 1.9 shipped with provider-defined functions and state encryption that Terraform’s concurrent releases simply didn’t have. These aren’t theoretical advantages. Provider-defined functions mean you can extend your IaC logic in ways that previously required ugly workarounds or external scripting. State encryption addresses a legitimate security concern that’s been nagging infrastructure teams for years, especially in regulated environments where compliance auditors ask uncomfortable questions about sensitive data in your Terraform state files.
The provider ecosystem matured faster than most people expected. By early 2026, the OpenTofu registry had mirrored over 2,000 providers. That’s not just small projects either – we’re talking about the major cloud providers, widely-used SaaS integrations, and most of the obscure stuff you actually need in production. The GitHub repository crossed 23,000 stars, which in open-source circles means “this isn’t a vanity project anymore.” More tellingly, commit frequency from the OpenTofu maintainers has exceeded HashiCorp’s Terraform contributions for several consecutive months, suggesting a genuinely active development cycle rather than maintenance mode.
One detail that rarely gets mentioned but matters enormously: the OpenTofu community has been willing to make opinionated decisions about what should be in core versus what belongs in providers. HashiCorp has to maintain backward compatibility with years of architectural decisions, some of which probably shouldn’t have shipped in the first place. OpenTofu gets to learn from those lessons, which shows in how the tool actually feels to use.
The IBM Acquisition Muddied the Water
Here’s where the narrative gets interesting from a strategic standpoint. In mid-2024, IBM acquired HashiCorp for 6.4 billion dollars. On paper, that sounds like validation that HashiCorp built something valuable. But enterprise customers started asking legitimate questions almost immediately: what does IBM actually want to do with Terraform? The answer from IBM’s product leadership has been vague enough to make risk committees nervous.
A 2025 Pulumi survey found that 41% of platform engineers now list IaC tool licensing uncertainty as a top-three risk factor in their toolchain planning for 2025-2026. That’s a significant chunk of the infrastructure community saying “I’m worried about my core deployment tool.” When licensing uncertainty becomes a material business risk factor, it changes decision-making in ways that licensing advocates at HashiCorp didn’t anticipate. Large organizations started treating OpenTofu differently – not as a nice-to-have alternative, but as legitimate insurance against lock-in.
The awkward truth is that IBM’s stewardship has been competent but uninspiring. There haven’t been dramatic feature cuts or sudden license changes since the acquisition closed, which is good. But there also hasn’t been any enthusiastic communication about Terraform’s open-source future, which is terrible from a perception standpoint. Perception, rightly or wrongly, is half the battle in infrastructure tooling.
Real Migration Numbers Tell the Story
The survey data from 2025 shows what’s actually happening in production environments. Of infrastructure teams actively evaluating OpenTofu, 34% had completed a full migration from Terraform, with another 28% reporting partial migration in progress. That’s more than six in ten teams that started exploring OpenTofu and committed to some level of switch. These aren’t theoretical users or hobbyists – these are practitioners who spent real time evaluating both tools and made deliberate decisions to move workloads.
What’s interesting about this migration cohort is that it’s not uniform. Some teams are doing greenfield projects on OpenTofu and keeping legacy infrastructure on Terraform. Others are betting everything on OpenTofu for all new work. A smaller subset is doing full migrations, which tells you something important: the compatibility is good enough that teams aren’t afraid to move existing code. That’s the bar that separates a credible alternative from a fork that lives on the fringes.
For detailed information about OpenTofu’s capabilities and roadmap, OpenTofu official documentation and changelog is the authoritative source. The feature velocity and polish visible there would have seemed impossible when the fork started.
Making the Decision in 2026
So where does this leave you if you’re starting a new infrastructure project or considering a migration? The honest answer is: it depends, and that’s actually progress. Two years ago, the decision was simple – use Terraform or explain yourself. Today, both tools have matured enough that the calculus is genuinely more complicated.
OpenTofu makes sense if you’re building for the long term and want to eliminate licensing uncertainty from your operational risk profile. If you have compliance requirements around state encryption, or you’re drawn to the extra capabilities in the 1.9 release, that’s a legitimate reason to pick it. If your team values active community governance over corporate stewardship, that’s valid too. Most importantly, if you’re tired of wondering what IBM’s next move is, OpenTofu removes that variable entirely.
Terraform still makes sense in specific scenarios. If you’re deeply invested in HashiCorp’s ecosystem – Terraform Cloud, Sentinel, the TFE suite – you’ve already made choices that pull toward Terraform. If your organization has existing standardization and the switching costs legitimately outweigh the benefits, that’s a rational decision. If you work somewhere that requires “official HashiCorp support” as a procurement checkbox, well, that’s what you get.
The encouraging thing is that this is no longer a binary choice. The fork has matured. The ecosystem works. Real teams are running real infrastructure on both tools. The infrastructure-as-code space is healthier when multiple options compete on merit rather than inertia, and I think that’s genuinely good for everyone who actually has to keep systems running at 3 AM, which I assume includes most of you reading this.
What’s your experience been with either tool lately? I’m curious whether anyone has actually done a migration in either direction and what moved the needle. The data tells one story, but real-world operational experience tells a different kind of truth entirely.