The License Change That Fractured an Ecosystem
In August 2023, HashiCorp made a decision that will likely be studied in open-source governance courses for years. They moved Terraform from the Mozilla Public License 2.0 to the Business Source License 1.1, trading perpetual open-source freedom for time-limited commercial control. For most organizations, this would have been an annoying compliance question handled in a quarterly review. For the infrastructure-as-code community, it triggered something different: a fork that actually took hold.
The Linux Foundation and a coalition of companies began work on OpenTofu almost immediately. By January 2024, OpenTofu 1.0 shipped as a stable release. The speed matters here. Most forks die in the planning phase or stall in early releases. This one didn’t. Within eighteen months, we’re looking at OpenTofu 1.9 with real feature advantages over the HashiCorp maintained version, a mirrored provider registry with genuine production coverage, and migration patterns that are no longer theoretical exercises.
What made this fork different wasn’t ideology or speed alone. It was that the open-source infrastructure community had genuine, immediate skin in the game. Nobody wanted to rebuild Terraform. They wanted to keep using what they built, without license uncertainty hanging over their entire infrastructure stack.
When the Fork Actually Started Winning on Features
For the first year after the fork, OpenTofu existed in a holding pattern. Not a bad one. The project maintained parity with Terraform while establishing operational trust, building the registry mirror infrastructure, and proving that the fork could sustain itself as more than nostalgia. But parity is a defensive position. It meant the fork was justified, not compelling.
That changed in mid-2024 when OpenTofu 1.8 shipped with native provider-defined functions. This wasn’t a minor quality-of-life improvement. The community had been requesting this feature for years. Terraform hadn’t shipped it. OpenTofu did. This matters because it’s the first moment where you could make an affirmative argument to use OpenTofu for new projects, rather than just migrating away from licensing concerns.
Provider-defined functions allow infrastructure code to access capabilities that individual providers expose without requiring language changes or Terraform core modifications. In practical terms, your AWS provider can offer functions optimized for common patterns without waiting for HashiCorp’s roadmap cycle. Providers become more expressive. Code becomes less boilerplate. The fork had crossed from defensive to genuinely forward-looking.
The timing intersects with something else that happened in mid-2024: IBM closed its acquisition of HashiCorp for approximately 6.4 billion dollars. That organizational transition created what looked like an opportunity window. The community wasn’t waiting to see what IBM’s roadmap would do to Terraform governance. They were already building faster in the open fork.
The Provider Registry Became Real
The hardest part of maintaining a Terraform fork isn’t the code. It’s the providers. Terraform’s value lives in the thousand-plus providers that translate its language into actual API calls. Without provider parity, you’ve got a language with nothing to do.
The OpenTofu registry reached 2,000 mirrored providers by early 2025. This isn’t 2,000 original providers maintained by volunteers. It’s a curated mirror of the existing provider ecosystem, with OpenTofu building the infrastructure to keep them synchronized and discoverable. For AWS, GCP, and Azure infrastructure, which covers the vast majority of enterprise cloud work, functional parity exists now.
What matters is what this parity actually means in production. It means an organization running standard cloud infrastructure doesn’t face provider gaps when migrating. Edge cases exist, and specialty providers take longer. But the 80/20 case is solved. That changes the migration calculus dramatically. The blocker that killed most forks isn’t present anymore.
OpenTofu official documentation and changelog shows a project shipping regularly, with a clear release cycle and genuine feature work happening in parallel to maintenance. This isn’t a security fork that ships patches. This is a parallel implementation with its own forward momentum.
What the Actual Migration Numbers Tell Us
A Spacelift survey from Q4 2024 found that 38% of organizations using Terraform were actively evaluating or had already migrated to OpenTofu. That number sits somewhere between signal and trend. It’s not the majority, but it’s a substantial minority, and the direction matters more than the absolute figure. In October 2024, that number would have been lower. In April 2025, it will be higher. The question isn’t whether migration is happening. It’s how fast.
The survey also found that cost and license uncertainty drove 91% of migration decisions. People aren’t moving to OpenTofu because it’s technically superior in some grand sense. They’re moving because the license uncertainty introduced risk into their infrastructure decisions. The technical parity and emerging feature advantages matter, but they’re secondary to the primary driver: predictability. OpenTofu is governed by the Linux Foundation through a democratic process. That governance model has rough edges, but it offers something Terraform licensing didn’t: certainty that the rules won’t change unilaterally.
The organizations doing this work aren’t startups with infinite iteration capacity. They’re large companies with infrastructure that took years to build. The willingness to fork and migrate that infrastructure is a strong signal about how the license change landed. It wasn’t cosmetic dissatisfaction. It was significant enough to justify real migration costs.
Forecasting What Comes Next
OpenTofu 1.9 is in a position that would have seemed impossible in late 2023. The fork is stable, production-proven, feature-competitive, and gaining adoption at an accelerating rate. But none of this guarantees long-term dominance. Ecosystem questions remain.
The most likely future is fragmentation that settles into a stable equilibrium. HashiCorp maintains Terraform for organizations willing to accept the licensing model. OpenTofu maintains a parallel implementation for everyone else. Both projects keep shipping features, both maintain provider ecosystems, and the community gets to make an affirmative choice rather than accept a fait accompli.
What seems unlikely is that HashiCorp reclaims the entirety of the infrastructure-as-code market after the fork took hold. The cost of reunifying governance after genuine divergence is higher than most organizations anticipate. That trust, once fractured, regenerates slowly.
Linux Foundation OpenTofu project page shows a project with institutional backing and corporate participation from multiple vendors. That distribution of governance authority is exactly what prevents the fork from becoming another abandoned OpenStack-style tragedy.
If you’re still on Terraform and wondering whether migration makes sense, the honest answer is that the blocking issues have resolved. Provider coverage exists. The license remains a real question, not a hypothetical one. Feature development is happening in both projects, and OpenTofu has the advantage of democratic governance. The decision now lives where it should: in your organization’s risk tolerance and operational preferences, not in technical capability gaps.
What decisions is your organization making about Terraform versus OpenTofu? The survey numbers suggest many teams are actively thinking through this. I’d be interested to hear what’s driving the conversation in your infrastructure codebases.