When HashiCorp switched Terraform’s license from MPL to BSL in August 2023, the infrastructure-as-code community erupted. Within weeks, the OpenTofu project was announced under the Linux Foundation, promising to maintain a truly open-source alternative. Nearly two years in, I think it’s time to take an honest look at how that fork is going — because the answer is more nuanced than either cheerleaders or skeptics predicted.
The State of OpenTofu in Mid-2025#
OpenTofu has shipped several significant releases since its 1.6 GA launch in January 2024. The project has established a steady release cadence, an active contributor community, and — critically — broad support from the ecosystem of providers and modules that make Terraform/OpenTofu actually useful.
The headline feature that’s gotten the most attention is state encryption, which was one of the first major divergences from upstream Terraform. This is a genuine improvement — storing infrastructure state in plaintext has always been a security concern that the community complained about for years. OpenTofu tackled it head-on, and the implementation is solid. Client-side encryption of state files with support for multiple key providers (AWS KMS, GCP KMS, OpenBao) addresses a real pain point.
Other additions include improved variable validation, early support for for_each on provider configurations, and various performance improvements to the planning engine. None of these are revolutionary on their own, but together they signal a project that’s doing the unglamorous work of improving developer experience incrementally.
Provider Ecosystem Health#
This was always going to be the make-or-break question for OpenTofu. Terraform’s value was never just the core engine — it was the vast ecosystem of providers that let you manage everything from AWS VPCs to Datadog monitors. If providers didn’t work with OpenTofu, the fork would be dead on arrival.
The good news: compatibility has been remarkably high. The major cloud providers (AWS, Azure, GCP) work without issues. Most community providers have adopted dual compatibility. The OpenTofu registry is growing, and the team has done a good job of maintaining backward compatibility with Terraform configurations.
The nuance: some HashiCorp-authored providers are starting to diverge in ways that create friction. Nothing breaking yet, but the gap is widening. Teams considering a migration need to test their specific provider configurations rather than assuming everything will “just work.” I’ve been advising teams to set up parallel planning runs during migration — run both terraform plan and tofu plan and diff the outputs before committing.
Who’s Actually Migrating?#
In my conversations with DevOps teams across Europe, the migration pattern is interesting. New projects are increasingly starting with OpenTofu — the license clarity makes procurement and legal conversations much simpler, especially in organizations that have policies about BSL-licensed software. For greenfield work, there’s really no downside.
Existing Terraform users are more cautious, and reasonably so. Migration is technically straightforward (swap the binary, update CI configurations), but the organizational change management is non-trivial. Teams need to update documentation, retrain muscle memory on CLI differences, and — most importantly — decide whether to pin to OpenTofu or maintain the option to switch back.
The enterprises I’ve seen commit to OpenTofu tend to have strong opinions about open-source licensing and/or have been burned by vendor lock-in before. The ones staying with Terraform tend to be HashiCorp customers who value the commercial support and Terraform Cloud integration. Both are rational choices.
The Broader IaC Landscape#
OpenTofu’s emergence has energized the broader infrastructure-as-code space in unexpected ways. Pulumi continues to gain traction with its programming-language-first approach — writing infrastructure in Python, TypeScript, or Go rather than HCL appeals to developers who’d rather not learn another DSL. AWS CDK occupies a similar space for AWS-only shops.
Then there’s the new generation of tools like System Initiative that are rethinking infrastructure management from scratch, with collaborative visual interfaces and reactive change engines. It’s early days, but the innovation in this space is encouraging.
What I find most healthy about the current landscape is that teams actually have choices now. Two years ago, if you wanted declarative multi-cloud infrastructure management, Terraform was essentially the only game in town. Today, you have OpenTofu for the open-source path, Terraform for the commercial path, Pulumi for the programming-language path, and emerging alternatives for teams willing to be on the cutting edge.
My Take#
OpenTofu has exceeded my expectations. I wasn’t sure a community fork could maintain the velocity and quality needed to be a credible Terraform alternative, but the project has proven it can. The governance is transparent, the release quality has been high, and the contributor base is diverse enough to be sustainable.
That said, I worry about the long-term divergence challenge. As OpenTofu and Terraform evolve independently, the “easy migration” story will eventually break down. Teams will need to commit to one or the other, and that commitment gets harder to reverse over time. If you’re making this decision now, think carefully about your organization’s values around open-source licensing, your need for commercial support, and your tolerance for ecosystem risk.
For what it’s worth, my personal infrastructure projects have all moved to OpenTofu. The state encryption alone was worth the switch, and I sleep better knowing my tooling can’t have its license changed out from under me. But I’m not dogmatic about it — the right choice depends on your context.
The Terraform fork was a test of whether the open-source community could effectively respond to a licensing change by a major vendor. So far, the answer is a cautious but genuine yes.