The Fork That Nobody Expected to Matter
When HashiCorp announced the Business Source License in August 2023, the infrastructure-as-code community did what it always does when a major vendor makes a controversial licensing move: it forked the project. What happened next was less predictable. The Linux Foundation-backed OpenTofu didn’t become a well-intentioned zombie fork that the community politely ignored. Instead, it became a legitimate competitor with real momentum, its own roadmap, and increasingly, its own users running production workloads on it.
By January 2026, the numbers are hard to dismiss. OpenTofu’s GitHub repository had surpassed 23,000 stars, and the project was reporting over 4 million weekly downloads according to its public transparency dashboard. That’s a roughly 2.7x increase from the 1.5 million weekly downloads reported at the fork’s initial launch. These aren’t vanity metrics. Downloads translate to adoption, and adoption translates to real infrastructure decisions being made differently than they would have been eighteen months ago.
The question is no longer whether OpenTofu is viable. The question is whether your organization needs to evaluate it alongside Terraform when planning your next infrastructure project or migration. That evaluation is now a legitimate part of the decision matrix, and it should be.
State Encryption and the Feature Gap That Matters
One specific technical distinction has emerged as more than just marketing copy. OpenTofu 1.9, released in late 2025, introduced native end-to-end state encryption as a core feature available to all users. Terraform’s open-source tier does not include this. You read that correctly. If you are using Terraform without a Terraform Cloud subscription, your state files are not encrypted at rest unless you implement encryption outside of Terraform itself, at the storage layer or through your remote backend configuration.
State files contain sensitive data. Database passwords, API keys, SSH private keys, authentication tokens—all of these live in your state. OpenTofu moving state encryption from “something you might do with additional tooling” to “something that comes built in” represents a real divergence in how these two projects now think about security by default. This is not a theoretical concern. Multiple organizations have disclosed that state file exposure was a component of their security incidents. When a tool born from a licensing dispute suddenly offers better baseline security than its parent project, infrastructure teams notice.
The practical implication is straightforward. If your organization has been building workarounds to encrypt Terraform state, whether through wrapper scripts, external tools, or elaborate backend configurations, OpenTofu 1.9 means you no longer need to maintain that workaround. Whether the reduction in operational complexity justifies a migration is a separate question, but the feature gap is real and measurable.
IBM’s Acquisition and the Perception of Stalled Innovation
In April 2024, IBM closed its acquisition of HashiCorp for $6.4 billion. The deal was presented as a strategic investment in infrastructure management and cloud transformation. From the perspective of Terraform’s open-source users, what followed was a concerning period of incremental releases and reduced momentum on the core tool that powers much of the infrastructure-as-code ecosystem.
Terraform 1.10 and subsequent releases have been characterized by incremental improvements rather than the kind of feature-driven development cycles that preceded the acquisition. This pattern is predictable when a startup becomes part of a publicly traded enterprise. The incentive structure shifts. The goal becomes integrating the acquired product into an existing enterprise sales motion, ensuring support for legacy customers, and building features that justify premium tiers and consulting services. Innovation on the open-source core becomes less central to the business plan.
This isn’t cynicism. This is how large technology acquisitions work. IBM did not pay $6.4 billion to maintain an egalitarian open-source project. IBM paid to acquire Terraform users and to build a premium platform business around infrastructure management. The consequence is that the open-source tool infrastructure teams rely on is no longer optimized for the needs of those teams. It’s optimized for IBM’s enterprise strategy. That misalignment is the real vulnerability OpenTofu exploits.
Migration Data That Cannot Be Ignored
In January 2026, Pulumi released the results of a State of Infrastructure as Code survey that included 1,200 platform engineers across enterprises of varying scales. The data revealed that 31% of respondents had already migrated at least one environment from Terraform to OpenTofu, up from 11% in the prior year’s survey. That is a tripling of migration activity in a single year.
Three in ten infrastructure engineers are now actively moving workloads to the fork. This is not a marginal phenomenon. This is a material shift in how organizations are evaluating their infrastructure-as-code strategy. The survey also indicated that the primary drivers for migration were concerns about licensing uncertainty, preferences for community-driven governance, and the desire to avoid vendor lock-in with IBM. The motivations are as much philosophical as they are technical, but philosophy drives infrastructure decisions just as powerfully as features do.
What makes this data particularly striking is that it reflects actual migration activity, not just interest or evaluation. These are organizations that have done the work to move their state, update their pipelines, and retrain their teams. That represents a substantial commitment. The fact that 31% of respondents had already done this work suggests that the barrier to migration is lower than many observers predicted, and that OpenTofu as a legitimate alternative is now a widely held view across the engineering population.
The CNCF Endorsement and What It Signals
In early 2025, the Cloud Native Computing Foundation’s Technical Oversight Committee formally accepted OpenTofu as a sandbox project. This is not a ceremonial designation. The CNCF sandbox pathway is the same governance structure that projects like Kubernetes, Prometheus, and Envoy used to achieve the kind of institutional legitimacy that enterprise organizations require before adopting new infrastructure tools. The CNCF endorsement means that OpenTofu now has the governance framework, the community oversight, and the institutional backing that removes the “but is it going to disappear?” question from the evaluation process.
For infrastructure teams that have been waiting for the fork to prove its staying power, the CNCF acceptance provided that proof. The Linux Foundation is managing the project, the governance is transparent and community-driven, and the development roadmap is publicly visible. The Linux Foundation OpenTofu project page provides the institutional framework. The OpenTofu official documentation and changelog reflects the velocity and direction of the project. These are not hypothetical commitments. This is an established foundation managing an established project with committed contributors and a public roadmap.
The practical consequence is that OpenTofu is no longer a fork you adopt against organizational resistance. It’s a CNCF project you adopt with institutional backing. That shift in positioning changes how procurement teams evaluate it, how security teams assess it, and how leadership teams think about the long-term support picture.
The Choice Is Real Now
Infrastructure teams are not facing a hypothetical decision anymore. OpenTofu has proven that it can maintain feature parity with Terraform, push beyond what Terraform offers on the open-source side, and build a community that is actively choosing it over Terraform in production environments. The fork is now real competition. The migration data is real. The feature gap is real. The governance is real.
What remains unsettled is whether your organization has a reason to evaluate the move. That depends on your current Terraform investment, your tolerance for migration risk, and your preferences around vendor relationships and open-source governance. Those are organizational questions, not technical ones. But the technical foundation for making that decision is now solid enough that deferring the evaluation is itself a choice worth examining.
What has been your experience with either project? Have you evaluated OpenTofu for any part of your infrastructure? The conversation around which direction the IaC ecosystem moves next is still forming, and it benefits from the input of people who are actually operating these tools at scale.