Back in August, I wrote about HashiCorp’s decision to switch Terraform from MPL v2.0 to the Business Source License. I said I was watching the fallout.

Three months later, the fallout has a name: OpenTofu — which arrived faster than anyone expected.

It also has a Linux Foundation home, 140+ organizational backers, 600+ individual pledges, 18 full-time developers, and a beta release that dropped just days ago. The community response moved fast — even by open-source drama standards.

As a CTO building a new stack at DreamFlare AI, I watch this beyond intellectual curiosity. I have to make an actual decision about which IaC tool to adopt. So let me walk through what happened, where things stand, and how I think about the choice.

The Timeline #

August 10, 2023: HashiCorp announces BSL for Terraform and all products. The community reacts with a mix of anger, resignation, and “I told you so.” Within days, a group of companies — Gruntwork, Spacelift, Env0, Scalr, and others — began organizing the OpenTF initiative.

The OpenTF manifesto called on HashiCorp to return to a truly open-source license. It gathered 33,000+ GitHub stars and 140+ company endorsements. HashiCorp did not budge.

September 20: The Linux Foundation formally accepted OpenTofu at Open Source Summit Europe, marking the moment the initiative went from “community protest” to “real project.” Linux Foundation stewardship provides governance, trademark protection, and the institutional legitimacy that enterprise adopters need.

October 4: OpenTofu alpha release, forked from the last MPL-licensed Terraform codebase (version 1.6.x). The alpha functioned, but lacked its own registry — you still needed to reference HashiCorp’s module and provider registries.

November 30 (in a few days): OpenTofu 1.6.0 beta with its own public registry. This milestone makes OpenTofu viable as a standalone tool. Without a registry, you depend on HashiCorp’s infrastructure even while using the fork. With one, you’re independent.

What OpenTofu Actually Is #

OpenTofu: a fork of Terraform under the MPL v2.0 license. It uses HCL (HashiCorp Configuration Language), reads existing Terraform state files, and (for now) supports the same providers and modules. Point OpenTofu at your existing Terraform code and it runs.

That “runs” comes with an asterisk, though. The beta hasn’t reached GA. Provider compatibility testing remains incomplete. And the OpenTofu registry just launched, so module availability lags behind HashiCorp’s registry for now.

The project’s governance follows Linux Foundation norms: a technical steering committee, public roadmap, community RFCs for major decisions. This stands deliberately opposite to HashiCorp’s benevolent-dictator model — and that contrast represents the strongest selling point for organizations burned by the license change. A Linux Foundation project can’t pull a BSL switch because no single company controls the license.

The CTO Decision Matrix #

Here’s how I evaluate this for DreamFlare.

If you start fresh (like me): The choice gets genuinely hard. Terraform has the larger ecosystem, more battle-tested providers, better documentation, and years of Stack Overflow answers. OpenTofu has license certainty and community momentum but sits pre-GA.

Starting with OpenTofu means betting on the community delivering a stable, maintained fork. The 18 full-time developer commitment from backing organizations signals real investment; that’s no side project. But “18 developers committed” and “18 developers shipping features” describe different things — the project still operates in the coordination-overhead phase.

Starting with Terraform means accepting the BSL. For a startup, the BSL doesn’t restrict your usage — you’re not building a competing IaC platform. But it introduces supply-chain risk. What if HashiCorp tightens the license further? What if pricing changes affect tooling costs?

Already on Terraform: Don’t migrate yet. Seriously. Wait for OpenTofu 1.6 GA (whenever that lands) and let early adopters find the bugs. Your existing Terraform workflows don’t touch the BSL unless you commercially compete with HashiCorp. The switching cost stays low — same HCL, same state format — so you have time.

Evaluating alternatives entirely: Pulumi deserves a look. It lets you write infrastructure code in general-purpose languages (TypeScript, Python, Go, C#) instead of HCL; the trade-off runs to state management, which either goes through Pulumi Cloud or self-managed setups, and the provider ecosystem runs smaller. AWS CDK covers you well when fully committed to AWS. Azure Bicep exists if you’re Azure-only (and enjoy pain).

What I’m Actually Doing #

Full transparency: I start with Terraform for DreamFlare’s infrastructure, with a plan to evaluate OpenTofu migration once it hits GA.

My reasoning stays pragmatic. We’re a small team moving fast. I need IaC that works today, not IaC that looks great in three months. Terraform 1.6 works. The provider ecosystem works. The docs are excellent. And the BSL doesn’t restrict anything we do.

But I write our Terraform code with migration in mind. That means:

Keeping HCL standard. No HashiCorp-specific features that might diverge from the OpenTofu fork. Stick to core resource types, standard module patterns, remote state in S3 (not Terraform Cloud).

Avoiding Terraform Cloud. HashiCorp’s managed offering marks the most likely divergence point between Terraform and OpenTofu. If you’re locked into Terraform Cloud for state management, CI/CD, and policy enforcement, migrating to OpenTofu becomes a multi-week project instead of a search-and-replace.

Documenting provider versions. Pin provider versions explicitly and test them. When OpenTofu’s registry stabilizes, you want to know exactly which versions of aws, google, and kubernetes providers you need.

The Bigger Picture #

OpenTofu marks the most significant community fork in the infrastructure space since LibreOffice split from OpenOffice (which itself was the most significant fork since MySQL/MariaDB). The pattern stays constant: a corporate steward changes the deal, the community forks, and both projects coexist in uncomfortable equilibrium — drifting apart until one fades.

My prediction (and predictions come cheap, so take this accordingly): both Terraform and OpenTofu coexist for at least two to three years. Terraform retains the majority of existing users through inertia and ecosystem advantages. OpenTofu attracts new projects, especially at companies with strong open-source policies. Eventually, one pulls ahead on features — probably around state encryption, testing frameworks, or IDE integration — and that feature gap drives consolidation.

The thing I find most curious about this situation: not the technology. The governance. Can a committee-driven project iterate as quickly as a single-company product? HashiCorp’s engineering velocity on Terraform has impressed; whether 18 developers from different companies, coordinating through RFCs and steering committees, can match it — that remains the open question.

History suggests committee-driven open source works well for stable infrastructure (Linux, Kubernetes) and less well for rapidly evolving tools. Terraform sits somewhere in between. It’s mature enough that stability matters, but the IaC space still carries unsolved problems — testing, drift detection, cost estimation — that reward fast iteration.

Either way, I’m glad the fork exists. Competition in IaC tooling benefits everyone. And the license certainty that OpenTofu provides — regardless of whether I adopt it today — puts useful pressure on HashiCorp to earn their users’ trust rather than capture it through licensing.