·
The BSL license change was the crack. The IBM acquisition was the earthquake. Now the IaC landscape is fracturing.
In February 2025, IBM completed its $6.4 billion acquisition of HashiCorp. Terraform, the tool that defined infrastructure-as-code for a generation of DevOps engineers, is now an IBM product. And it's been operating under the Business Source License since August 2023.
Those two facts - a restrictive license and a new corporate owner - have pushed a significant chunk of the Terraform community to start looking elsewhere. Firefly's State of IaC 2025 survey found Terraform still holding a 62% market share - but only 47% of users planning to stick with it. (A separate, widely circulated figure puts 38% of Terraform users actively evaluating alternatives; we could not trace it to a primary source, so treat it as directional.) OpenTofu, the open-source fork, is where much of that energy is going. The IaC landscape hasn't been this fractured since before Terraform won.
If you're an AWS-focused team still running Terraform, it's worth asking: is this still the right tool, or are you staying out of inertia?
The timeline matters because the license change and the acquisition are two separate events, and each one removed a different reason to stay.
August 2023: HashiCorp switched Terraform from the Mozilla Public License (MPL 2.0) to the Business Source License (BSL 1.1). The BSL prohibits using Terraform to build competing products or services. For most end users, this changes nothing day-to-day. But it killed the "Terraform is open source" argument that made it feel safe to bet on. You're now building critical infrastructure on a tool whose license terms are controlled by a corporation that can change them again.
September 2023: The Linux Foundation announced OpenTofu, a fork of Terraform at the last MPL-licensed commit. Harness, Gruntwork, Spacelift, env0, Scalr, and others backed it, with formal pledges from more than 140 organizations and a starting commitment of 18 full-time developers. The fork was credible from day one.
February 2025: IBM closed the HashiCorp acquisition for $6.4 billion. Terraform, Vault, Consul, Nomad, Packer, Vagrant - all IBM products now. IBM's track record with acquisitions (Red Hat notwithstanding) gives the community pause. The concern isn't that IBM will break Terraform tomorrow. It's that the incentive structure changed. IBM paid $6.4 billion and needs to justify that spend. Enterprise licensing, feature gating, and ecosystem lock-in are the obvious levers.
The BSL alone wouldn't have caused this. Plenty of developers use BSL-licensed software without issue. But the license change signaled a philosophical shift, and the acquisition amplified it.
If you build a platform, managed service, or internal developer portal that wraps Terraform, you need to evaluate whether you're creating a "competitive offering" under the BSL. The language is deliberately vague. Most internal tools probably don't qualify, but "probably" isn't a word you want in your legal risk assessment for a core infrastructure tool. CloudFormation, CDK, Pulumi, and OpenTofu all have licenses that don't require this analysis.
HashiCorp as an independent company had one revenue model: sell HashiCorp Cloud Platform and enterprise support. IBM has a different playbook. IBM's history includes acquiring companies, integrating their products into IBM's enterprise sales motion, and gradually deprecating anything that doesn't fit. Maybe Terraform is too big for that treatment. But Terraform's community isn't waiting around to find out.
OpenTofu reached general availability in January 2024 under the Linux Foundation and has kept a steady release cadence since - version 1.12 shipped in May 2026. The 300%-growth and near-10-million-download figures that circulated in early 2026 are hard to pin to a primary source, but the direction isn't in dispute: the fork is actively maintained, foundation-governed, and not a toy that will die in six months. If you're going to keep writing HCL, OpenTofu removes the license and corporate risk while keeping your existing code working.
The users evaluating alternatives aren't all going to the same place. The migration paths depend on your stack, your team, and what you actually need from IaC.
This is the option that gets dismissed too quickly. CloudFormation is verbose, yes. The feedback loop is slower than terraform plan, yes. But it has properties that matter more in 2026 than they did in 2019:
terraform plan, but it requires running it - CloudFormation drift detection can run on a schedule.Here's what a production VPC looks like in CloudFormation. It's more verbose than HCL, but it's explicit, self-contained, and has no external dependencies:
AWSTemplateFormatVersion: '2010-09-09'
Description: Production VPC with public and private subnets
Parameters:
Environment:
Type: String
Default: production
AllowedValues: [production, staging]
Resources:
VPC:
Type: AWS::EC2::VPC
Properties:
CidrBlock: 10.0.0.0/16
EnableDnsSupport: true
EnableDnsHostnames: true
Tags:
- Key: Name
Value: !Sub ${Environment}-vpc
PublicSubnetA:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.1.0/24
AvailabilityZone: !Select [0, !GetAZs '']
MapPublicIpOnLaunch: true
PrivateSubnetA:
Type: AWS::EC2::Subnet
Properties:
VpcId: !Ref VPC
CidrBlock: 10.0.10.0/24
AvailabilityZone: !Select [0, !GetAZs '']
Outputs:
VpcId:
Value: !Ref VPC
Export:
Name: !Sub ${Environment}-vpc-id
No providers to configure. No backend to set up. No state file to protect. Deploy it with aws cloudformation deploy and move on.
If your objection to CloudFormation is the YAML verbosity, CDK is the answer. It generates CloudFormation templates from TypeScript, Python, Java, Go, or C#. You get the reliability of CloudFormation with the expressiveness of a real programming language:
const vpc = new ec2.Vpc(this, 'ProductionVpc', {
maxAzs: 3,
natGateways: 1,
subnetConfiguration: [
{ name: 'Public', subnetType: ec2.SubnetType.PUBLIC, cidrMask: 24 },
{ name: 'Private', subnetType: ec2.SubnetType.PRIVATE_WITH_EGRESS, cidrMask: 24 },
],
});
Five lines. Three AZs. Public and private subnets. NAT gateway. Route tables. Internet gateway. All generated as CloudFormation and deployed through the same engine. CDK gives you loops, conditionals, inheritance, and composition - the things people miss in raw CloudFormation YAML.
If your team has years of Terraform modules and you don't want to rewrite them, OpenTofu is the path of least resistance. It's a drop-in replacement for Terraform with the original open-source license. Swap the binary, keep your code.
The risk with OpenTofu is long-term divergence. As Terraform and OpenTofu evolve independently, feature parity will erode. You're betting that the Linux Foundation and the contributor community can keep pace with an IBM-funded Terraform team. Right now, that bet looks good. In three years, it might not.
Pulumi lets you write infrastructure in TypeScript, Python, Go, C#, or Java - like CDK, but not locked to AWS. If your infrastructure spans multiple clouds, Pulumi is the strongest alternative. The downside: smaller ecosystem than Terraform, and you're adopting another vendor (Pulumi the company). But the license is Apache 2.0 and the engine is open source.
| CloudFormation | CDK | OpenTofu | Terraform | Pulumi | |
|---|---|---|---|---|---|
| License | AWS service | Apache 2.0 | MPL 2.0 | BSL 1.1 | Apache 2.0 |
| Multi-cloud | No | No | Yes | Yes | Yes |
| State management | AWS-managed | AWS-managed | Self-managed | Self-managed | Managed or self |
| Language | YAML/JSON | TS/Python/Go/Java/C# | HCL | HCL | TS/Python/Go/Java/C# |
| Day-one AWS support | Yes | Yes | Varies | Varies | Varies |
| Corporate risk | AWS (your cloud provider) | AWS | Linux Foundation | IBM | Pulumi Inc. |
Four months on, the April picture has held. Terraform is still under the BSL 1.1 at IBM, and nothing in IBM's public messaging suggests that changes. OpenTofu keeps shipping on schedule - 1.12 arrived in May 2026 - and the migration story remains "swap the binary, keep your code" for most codebases. Firefly has since opened up a 2026 edition of its State of IaC survey if you want fresher adoption numbers than the 2025 report cited above. Nothing we have seen since April changes the recommendation below.
If your infrastructure is 100% AWS - and for most startups and mid-size companies, it is - CloudFormation or CDK is the safest long-term bet. You're already paying AWS. CloudFormation is included. The state is managed. The license is not a concern. New services work on day one.
If you have existing Terraform code and can't justify a rewrite, move to OpenTofu. It's the same code, the same workflow, and an open-source license. Do it now, before the two forks diverge further.
If you're multi-cloud, Pulumi gives you real programming languages without the BSL baggage.
What I wouldn't do is start a new project on Terraform in 2026. The BSL makes the license story worse than every alternative. The IBM acquisition adds corporate uncertainty. And the alternatives have matured to the point where the ecosystem advantage - Terraform's real moat - is eroding.
The IaC landscape is fracturing, and that's not necessarily a bad thing. Competition is healthy. But if you're sitting on a Terraform codebase and waiting for things to settle, you might be waiting a long time. The ground has already shifted.
Published by Yaw Labs.