Choosing an infrastructure-as-code tool often gets discussed as a syntax preference (HCL versus a real programming language), which misses the two criteria that actually matter long-term: the license the tool ships under, and the real cost of switching once hundreds of config files depend on it.

Terraform and the license turn

Terraform stayed open source (Mozilla Public License) for nearly a decade, the de facto reference tool for declarative IaC. In 2023, HashiCorp switched to the Business Source License (BSL), which restricts commercial use competing directly with HashiCorp itself, while remaining unrestricted for the vast majority of internal use cases. The change doesn’t stop anyone from using Terraform today; it changes the project’s governance trajectory, now fully controlled by one company, not a neutral foundation.

OpenTofu: the fork under neutral governance

In direct response to that license change, a group of contributors and companies (Gitpod, Spacelift, Harness, among others) forked the last MPL version of Terraform to create OpenTofu, now hosted under the Linux Foundation. Compatibility is near-total at the HCL language level and with existing providers:

# The technical migration is one command for most projects
tofu init   # replaces terraform init, reads the same .tf files

The real question isn’t technical but organizational: neutral governance (Linux Foundation) removes the risk of a future unilateral license change forcing another migration, at the cost of a contributor ecosystem still younger than Terraform’s and enterprise features (HCP Terraform, Sentinel) that remain HashiCorp-proprietary.

Pulumi: trading the DSL for a real language

Pulumi takes a different path: instead of a dedicated configuration language (HCL), infrastructure is described in a general-purpose programming language (TypeScript, Python, Go, Java) the team likely already knows.

// Pulumi: the host language's loops, conditionals and functions
// apply directly, no separate DSL needed
const buckets = environments.map(env =>
  new aws.s3.Bucket(`data-${env}`, { acl: "private" })
);

The real benefit: unit tests, function composition, and the host language’s own abstractions apply directly to infrastructure, without a pure declarative DSL’s limitations. The real cost, symmetrically: a real language’s expressiveness also allows writing unpredictable, imperative infrastructure if the team doesn’t impose its own discipline, which Terraform’s HCL constraint enforces by construction.

The real cost of switching tools

Migrating tools is never just syntax conversion. The state (the inventory the tool keeps of what it actually manages, covered in depth in the article on Terraform remote state and locking) has to be imported or recreated in the new tool, provider by provider, resource by resource. On an infrastructure with several hundred resources, that migration is a project of its own, not a command. That’s the structural reason the initial choice weighs more than the day’s feature comparison: exit cost quickly outweighs the initial learning cost.

A decision criterion, not a preference

Three questions, in order, settle most cases: does the team already have strong expertise in a programming language Pulumi would leverage directly, rather than learning HCL from scratch? Is the project’s governance (proprietary BSL versus a neutral foundation) a contractual or regulatory criterion in your industry? And does Terraform’s already-mature provider and community-module ecosystem (largely compatible with OpenTofu) outweigh a newer tool’s novelty for your use case? An aesthetic preference change almost never justifies reopening this decision once the tool is in production.

Takeaway

Choosing an IaC tool comes down to license and exit cost, not syntax preferences that fade after two weeks of use. OpenTofu offers near-seamless continuity with Terraform under neutral governance; Pulumi trades a constrained DSL for a real programming language, at the cost of the discipline that DSL enforced by default. Migrated state is the real cost of any later switch: it’s the criterion that should weigh heaviest from the first choice, as part of a CI/CD industrialization built to last.