It’s only been about four months since the OpenTofu project was announced as a direct response to HashiCorp’s controversial switch of Terraform to the Business Source License (BSL). Now, with the release of OpenTofu 1.6, we have a production-ready, generally available fork that’s positioning itself as the community’s answer to a fundamental question: who owns infrastructure-as-code?
I’ve been watching this unfold with a mixture of cautious optimism and professional concern. After all, when you’ve spent years building pipelines and modules around a tool, a licensing change isn’t just corporate politics — it’s a direct threat to your workflow.
What OpenTofu 1.6 Actually Delivers#
Let’s cut through the narrative and look at what shipped. OpenTofu 1.6 is essentially a drop-in replacement for Terraform 1.6, which is exactly what the community needed as a starting point. The project maintains full compatibility with existing Terraform state files, modules, and providers. If you have a terraform binary in your CI pipeline, swapping it for tofu should be largely seamless.
The release includes the usual suspects: support for testing with tofu test, S3 state backend improvements, and the provider-defined function framework that was in the Terraform 1.6 pipeline. But the real story isn’t about features — it’s about governance and momentum.
The project is now under the Linux Foundation, backed by companies like Spacelift, env0, Scalr, and Gruntwork. That’s not just moral support; these are companies that have built their businesses around Terraform workflows and have a material interest in keeping the ecosystem open.
The BSL Question Isn’t Going Away#
HashiCorp’s move to BSL last August sent shockwaves through the infrastructure community, and rightly so. The BSL essentially means you can use Terraform freely unless you’re offering a competing service — but the definition of “competing” is vague enough to make legal departments nervous.
I’ve talked to several teams at mid-size companies who are genuinely unsure whether their internal platform engineering setups could be considered “competitive” under the BSL. When your infrastructure tooling requires a legal opinion to deploy, something has gone wrong.
This isn’t unique to HashiCorp, of course. We saw similar concerns with Redis, MongoDB, and Elastic changing their licenses. But Terraform occupies such a foundational position in modern infrastructure that the impact is amplified. It’s the kind of tool that becomes invisible — you don’t think about it until it breaks or, in this case, until someone changes the rules.
What This Means for Your Existing Pipelines#
If you’re running Terraform today, you don’t need to panic. HashiCorp hasn’t changed the license retroactively (they can’t), and for most teams doing internal infrastructure work, the BSL doesn’t apply. But if you’re planning ahead — and you should be — here’s my practical take:
For internal teams: Keep an eye on OpenTofu but don’t rush to migrate. The 1.6 release is solid, but the real test comes with 1.7 and beyond, when the projects start to diverge. You want to see that OpenTofu can innovate independently, not just track HashiCorp’s releases.
For platform teams building internal tools: This is where it gets murky. If you’re building an internal developer platform that wraps Terraform, you should at least evaluate OpenTofu as a risk mitigation strategy. Having a migration plan doesn’t mean you have to execute it.
For vendors and consultancies: If you offer Terraform-related services, you need a clear understanding of where you stand with the BSL. OpenTofu gives you an unambiguous fallback.
The state file compatibility is crucial here. It means you can experiment with OpenTofu in a staging environment without committing to anything. Just point it at your existing state and see what happens. In my testing, the migration is as boring as it should be — which is exactly the kind of boring I like in infrastructure tooling.
The Bigger Picture: Open Source Sustainability#
What I find most interesting about the OpenTofu story isn’t the technical details — it’s what it says about the state of open-source business models. HashiCorp built an incredible company on open-source tools, went public, and then decided the open-source model wasn’t working for them. You can argue about whether they were right to do that, but you can’t deny they’ve created a template that makes other companies nervous.
Every time I adopt a new open-source tool now, I find myself asking: what’s the exit strategy if the license changes? That’s a sad question to have to ask, but it’s a pragmatic one.
OpenTofu represents one answer: if you build a big enough community around a tool, the community can sustain it independently. But that only works when enough companies step up with real resources — developers, infrastructure, money. The Linux Foundation backing helps, but the proof will be in whether OpenTofu can attract and retain contributors over the next year.
My Take#
I’m cautiously bullish on OpenTofu. The 1.6 release is exactly what it needed to be: boring, compatible, and stable. The governance structure is sound, and the backing companies have real skin in the game.
But I’ve also been around long enough to see forks fizzle out. The initial energy is always high — it’s sustaining that energy through the unglamorous work of bug fixes, security patches, and documentation that separates viable projects from abandoned ones.
For now, I’m running OpenTofu in my personal projects and keeping Terraform in production at work. I’ll revisit that decision when OpenTofu 1.7 lands and we can see whether the project is charting its own course or just playing catch-up.
The infrastructure-as-code space is healthier for having this competition. Whatever happens with OpenTofu specifically, the message to every open-source steward is clear: your community is an asset, not a liability. Treat it accordingly.