OpenTofu lands: when a community forks back

Three weeks. That is how long it took the IaC community to go from “we have a problem with this license” to a Linux Foundation-hosted fork with a name, a governance model, a co-signing roster of real companies, and a clear roadmap. Twenty-one days.

On August 10, HashiCorp moved Terraform to the BSL. I wrote about that in the bombshell piece. On August 25, the OpenTF Manifesto pivoted from a public letter into a working project. And on September 5, the Linux Foundation announced that the project (now formally named OpenTofu) was being hosted as a neutral foundation project, with founding contributions from a long list of companies whose businesses depended on Terraform staying open.

I want to write down what this actually is, because the takes that have shipped so far are split between “vendor war story” and “license drama,” and neither of those captures the structural thing that happened.

What just shipped

The headline facts, stripped of editorializing:

• The project exists. OpenTofu is hosted at the Linux Foundation. It has a steering committee, a TSC, and a published charter. Governance is foundation-style, multi-stakeholder, not vendor-led.
• It forked from a pre-BSL Terraform release. The current target is API and CLI compatibility with the 1.x line, specifically the last MPL-licensed Terraform release. That decision matters: it means existing modules, providers, and state files just work.
• It is going back to MPL 2.0. Same license Terraform had on August 9. Real open source. OSI-approved. Not BSL, not source-available, not “open core.”
• There is a published migration path. tofu as a drop-in CLI. State file compatibility maintained. The provider tooling stays compatible because providers were never under HashiCorp’s licensing reach the same way.
• The funded contributors are real. This is not a hobby project being held together by weekend volunteers. The companies signing the manifesto are putting actual engineering headcount on it. The names that turned up in the founding contributor list are the ones who, frankly, built most of the workflow tooling around Terraform for the last five years.

That last point is the load-bearing one. Forks of major projects fail when they are vendor-fronted and underfunded. This one has neither problem.

How the fork happened that fast

I have been in this industry long enough to remember forks that took eighteen months to produce a stable release. OpenSearch from Elasticsearch took the better part of a year before anyone reasonable would put it in production. The OpenStack era had forks that died on the runway because nobody could agree on governance.

OpenTofu did the same thing in three weeks. Some of why:

The codebase was already public. This is the unsexy answer and the correct one. The MPL-licensed history is right there. Fork the repo, change the upstream reference, keep going. The legal piece is the only thing that had to move.

The community was pre-organized. The OpenTF Manifesto did the political work in the first ten days. By the time the Linux Foundation step happened, the co-signers were already aligned on what they wanted, who was contributing, and which version they were forking from.

The Linux Foundation has done this before. They have a playbook for exactly this scenario, neutral home for a forked or rescued project, multi-stakeholder governance, trademark held by the foundation not the lead contributor. OpenTofu got to skip the part where everybody argues about governance because the LF model is the governance.

The economics were unambiguous. A whole tier of companies, the ones building managed Terraform offerings, the tooling vendors, the consultancies, anyone whose product was “we run Terraform for you better than you run it yourself”, was looking at the BSL and seeing an existential threat to their business model. The motivation to coordinate was extraordinary.

That last factor is the one that I think doesn’t get talked about enough. People assume forks happen because of ideology. This one happened because of survival.

What migration is going to look like

I’ve already had three customer conversations this week that started with “okay, what does this mean for our acme-multi-cloud Terraform footprint?” The answer is more reassuring than they expected.

For most teams, migration is going to look like:

1. Pin your current Terraform version. You’re already on a pre-BSL release. Keep using it. Nothing breaks.
2. Wait for OpenTofu’s 1.x GA. The team is targeting a first stable release before the end of the year. The compatibility goal is high enough that for the bulk of real-world modules, the migration is changing a binary and re-running tofu init.
3. Validate against your provider matrix. Providers haven’t changed. The providers are still maintained by their respective vendors and the community. AWS, Azure, GCP, Cloudflare, Datadog, they aren’t affected by the core fork.
4. Re-run your CI pipelines. The plan-output pipelines I’ve been building with customers all the way through 2023 are CLI-shaped. Swap the binary, re-run the workflow. The output format and semantics are preserved.
5. Re-test your modules. Especially modules.tf-imported modules and anything that uses provider-specific behavior. The compatibility surface is wide but not infinite.

The migration is real work. It is not a rip-and-replace. It is a binary swap and a regression pass.

Why this matters beyond the license

A handful of the customer engagements I’ve been on this year had a specific anxiety baked in: they couldn’t tell their leadership how locked-in they were to any particular vendor’s licensing posture. They could enumerate AWS lock-in. They could enumerate Azure lock-in. They could not enumerate Terraform-the-tool lock-in, because the open license was so permissive that nobody had ever had to.

The BSL exposed that gap. OpenTofu closes it.

What you get from the existence of a neutral, foundation-hosted, OSI-licensed Terraform implementation is a thing that most teams don’t realize they need until they don’t have it: an exit option. If HashiCorp commercializes harder, or if the BSL gets reinterpreted in a way that’s adverse to your usage, or if there’s a future license change you don’t like, there is now a place to go that isn’t dependent on one vendor’s roadmap.

That has structural value even if you never exercise it. The mere existence of a credible alternative changes the negotiation dynamics with the original vendor. We saw this with Elasticsearch and OpenSearch. We saw it with MySQL and MariaDB. We are watching it happen here.

What I’m telling teams now

Same shape as the BSL advice, sharpened a bit:

• No production migration this quarter. Your pinned Terraform 1.5 deployments are fine. The hurry is artificial.
• Set up an OpenTofu evaluation track. Pick one of your non-critical workflows (a dev environment, a side project, an internal tool) and run OpenTofu against it as soon as the 1.x line stabilizes. Get a feel for it.
• Talk to your tooling vendors. Atlantis, Terragrunt, Spacelift, env0, every one of them is publishing a position. Find out theirs. Most of them will support both binaries.
• Don’t take sides too hard. This is going to be a coexistence story for at least the next year. Some teams will stay on Terraform. Some will move to OpenTofu. Both choices are defensible. The category is healthier with both alive.

The longer thread

The thing I keep coming back to: every category I’ve watched mature in this industry has gone through a moment where the steward of the dominant implementation tries to capture more of the value the tooling created around them, and the tooling says no. Sometimes that moment is loud and ugly. Sometimes it produces a fork that dies. Sometimes (like here) it produces a healthier structure than the one before it.

The BSL felt like the end of an era. OpenTofu is the start of one. The interesting part of the next year is going to be watching which workflows, which tooling, which conventions get inherited cleanly across the fork, and which ones quietly drift apart.

And for what it’s worth: this is the first major IaC story in my career where the community moved faster than the vendor. That’s a tell about where the center of gravity actually is.

, Sid