The Fork Has Matured Into Something Real
I remember sitting in a Slack thread in August 2023 when HashiCorp announced the Business Source License change. The conversation shifted from “this is unfortunate” to “we need a plan B” almost immediately. That fork, OpenTofu, backed by the Linux Foundation, was supposed to be a protest project. It was supposed to fracture, fade, or get acquired back into the fold. Instead, it’s become the thing no one fully predicted: genuine competition.
By this January, OpenTofu had crossed 23,000 GitHub stars and reported over 4 million weekly downloads. That’s not marginal adoption. That’s not consultants kicking the tires. That’s infrastructure teams at scale making a deliberate choice to move workloads to a different tool. When the fork launched in late 2023, OpenTofu was pulling around 1.5 million weekly downloads. The growth trajectory tells you everything you need to know about where the market’s head is at.
What makes this different from previous tool fragmentation is that OpenTofu didn’t just copy Terraform and call it a day. The project has shipped features that matter. The 1.9 release introduced end-to-end state encryption natively, something that still isn’t available in Terraform’s open-source distribution. That’s not a small thing when you’re managing sensitive infrastructure state across environments.
Why the Market Share Shift Happened So Fast
The Pulumi State of Infrastructure as Code survey from January 2026 asked 1,200 platform engineers a straightforward question: have you moved workloads off Terraform? Eleven percent said yes last year. This year, 31 percent have migrated at least one environment. That’s a threefold jump in twelve months. That velocity tells me something fundamental shifted in how teams evaluate their tooling.
Part of this comes down to trust in roadmap direction. When IBM closed its acquisition of HashiCorp for $6.4 billion in April 2024, the enterprise market cheered. IBM gets Terraform, Vault, Consul, and all the rest. But for open-source teams, the question became obvious: what does enterprise ownership mean for the velocity of open-source development? The subsequent Terraform 1.10 releases have been incremental. That’s not necessarily a flaw, but it’s a signal. Teams started asking themselves whether they wanted to bet their infrastructure automation on a tool where the parent company’s financial incentives might not align with rapid open-source feature work.
The other part is legitimacy. In early 2025, the Cloud Native Computing Foundation’s Technical Oversight Committee formally accepted OpenTofu as a sandbox project. That’s the same pathway Kubernetes, Prometheus, and other projects used to establish themselves as enterprise-grade tools. When the CNCF vouches for a project’s governance model and technical direction, it changes the conversation at procurement and architecture review meetings. You can now point to institutional backing and say, “This isn’t going away.”
The State Encryption Story Matters More Than You Think
Let me walk through why native end-to-end state encryption is a bigger deal than the feature announcement cycle suggests. Terraform state files contain everything: database passwords, API keys, private IPs, encryption keys themselves. They’re the crown jewels of your infrastructure. The standard approach has always been to store them in remote backends like S3 with encryption at rest, and to use Terraform Cloud for managed state with encryption in transit and at rest. But that means trusting that backend. It means your state sits somewhere encrypted by someone else’s key.
OpenTofu’s native encryption changes the model. Your state gets encrypted before it leaves your environment, with keys you control. That’s a fundamentally different security posture, and for regulated industries, for teams operating in sensitive domains, or for organizations that have had to justify their state management practices to compliance auditors, that’s worth the migration cost alone. I’ve been in rooms where engineers had to explain why they trusted their Terraform state to a third party. OpenTofu removes that conversation entirely.
Terraform 1.10 hasn’t answered this. The roadmap signals suggest the team is focused on other areas. That gap is real, and teams with strict compliance requirements are exploiting it.
What This Means for Your Career and Your Team’s Direction
If you’re an infrastructure engineer or platform architect right now, you’re at an interesting inflection point. Terraform expertise was a safe bet for the last five years. It still is, because Terraform isn’t going anywhere. But Terraform is no longer the default assumption. When you’re interviewing, evaluating tools for a new project, or thinking about where to invest your learning time, you need to actually evaluate both projects on their merits rather than defaulting to the incumbent.
What I’m seeing from teams that have made the jump is that they rarely regret it. The migration friction is real, but it’s usually less painful than expected. The OpenTofu documentation is solid, the tooling for state migration exists, and the community is actively helping each other through the transition. That’s the mark of a project with real momentum, not just users.
The harder question is what to tell junior engineers on your team. Do you invest in Terraform knowledge or split focus toward OpenTofu? Honestly, you’re not really picking one or the other. The core concepts are identical. State management, resource declarations, provider relationships, all of that is transferable. What matters is that you pick one tool for your production workloads and commit to understanding it deeply. If you’re starting fresh without strong legacy reasons to stick with Terraform, the case for OpenTofu is getting harder to ignore.
The Choice Isn’t Binary Anymore
The fork is now real competition, but competition doesn’t mean mutual destruction. Some teams will standardize on OpenTofu and never look back. Others will stick with Terraform because they’re locked into Terraform Cloud or because their existing automation is deeply invested there. What matters is that the choice exists, and it’s forcing both projects to earn their position in your infrastructure stack.
If you want to dig into the details, the OpenTofu official documentation and changelog gives you the complete picture of where the project is heading, and the Linux Foundation OpenTofu project page has the governance and backing information that matters for enterprise evaluation.
This is a good problem to have as an infrastructure community. Competition keeps both projects honest about what they’re delivering. The teams I know who’ve thought deliberately about this choice, rather than just inheriting a tool, tend to be happier with their decision, whatever direction they picked. That deliberation is worth your time. What’s your current thinking on this?