The Rise and Fall of IaC and Terraform: A Thirty-Year History

The story begins in a physics department office with servers spiraling out of control.

In 1993, Mark Burgess was doing postdoctoral research at the University of Oslo in Norway. The department’s sysadmin was drowning in shell and Perl scripts spread across dozens of workstations: every machine had subtle configuration differences, the maintenance scripts kept growing longer, and eventually no one dared touch them.

Burgess wrote a tool called CFEngine and presented it at the HEPiX conference that year. CFEngine introduced a fundamental conceptual shift: instead of step-by-step imperative scripts, you declared the system’s Desired State, and the engine would periodically compare current conditions against it and automatically correct any drift.

This theory of “Convergence” laid the intellectual foundation for modern configuration management and Infrastructure as Code (IaC). But in the 1990s, when servers were still physical assets, this kind of automation remained largely confined to academia and elite research institutions. Most enterprise data centers still relied on runbooks and manual operations.

The Cloud Wave and HashiCorp’s Big Bet

As the 2000s opened, web services scaled rapidly, and configuration management tools rode the first wave of commercialization. In March 2005, Luke Kanies transformed his consulting firm to work full-time on Puppet; Adam Jacob and others founded Opscode in 2008 and officially released Chef in January 2009.

Both inherited CFEngine’s declarative philosophy, using agents installed on every machine to continuously converge package versions, configuration files, user permissions, and service states toward the desired state defined in code — in other words, they managed “what the inside of a machine looks like.”

In June 2009, Flickr’s John Allspaw and Paul Hammond delivered their landmark “10+ Deploys Per Day” talk at the Velocity conference, establishing the cultural consensus around Dev and Ops collaboration. That October, the first DevOpsDays took place in Ghent, Belgium, and the term “DevOps” entered the industry lexicon for good.

In 2012, Michael DeHaan released Ansible, taking a different path: no agent installation required on target machines — it pushed configuration directly over SSH, dramatically lowering the barrier to adoption.

 Evolution of Infrastructure Paradigm (1993–2014)

 [1993 CFEngine] (Convergence)
   |
   v
 [2005 Puppet / 2009 Chef] (Config Management)
   |
   +--> [2012 Ansible] (Agentless)
   |
   v
 [2011 CloudFormation] (API Provisioning)
   |
   v
 [2014 Terraform] (Decoupled Core)

The DevOps movement cemented the principle that server configuration must be version-controlled and peer-reviewed. Yet as AWS cloud computing gained traction and machines could be conjured from thin air via API in seconds, engineering teams faced an escalating challenge: beyond managing what was inside a server, they now needed to automate the answer to “where do these machines come from” — the resource provisioning problem.

On February 25, 2011, AWS launched CloudFormation, bringing declarative provisioning into the mainstream cloud. Mitchell Hashimoto, then still a college student, wrote an analysis praising its architectural thinking but pointing out its limitation: deep lock-in to AWS, while existing cross-cloud packages were little more than crude API wrappers.

At the end of that post, Hashimoto left a prediction:

“CloudFormation has left a space for an open-source alternative, and I hope it will appear.”

After waiting several years for someone else to step up, he decided to build it himself.

In November 2012, Hashimoto founded HashiCorp, with Armon Dadgar joining shortly after as co-founder. Building on the experience of developing Vagrant, his earlier flagship project, the team committed to a tool strategy of single-binary executables written in Go. After shipping Packer and Consul, they officially released Terraform v0.1.0 on July 28, 2014.

The Ecosystem Moat: The Power of a Two-Layer Architecture

The freshly released Terraform v0.1.0 was bare-bones, supporting only two platforms: AWS and DigitalOcean. In the first 18 months after launch, downloads barely moved, and the team internally debated whether to kill the project.

HashiCorp chose to press on, and the reason came down to one precise architectural decision: a clean decoupling of the core engine from Providers.

 Terraform Decoupled Architecture

 +------------------------------------------------------+
 |                Terraform Core (HCL)                  |
 |  - Graph Engine (DAG)    - State File (.tfstate)     |
 +------------------------------------------------------+
         (go-plugin over gRPC, one per provider)
          |                  |                  |
          v                  v                  v
 +----------------+ +----------------+ +----------------+
 | AWS            | | Google         | | Custom SaaS    |
 | Provider       | | Provider       | | Provider       |
 +----------------+ +----------------+ +----------------+

In this architecture, Terraform Core focuses on parsing HCL configuration files, building a Directed Acyclic Graph (DAG) of resource dependencies to determine execution order, and maintaining a state file (.tfstate) that maps to real-world infrastructure. The Core itself contains zero cloud API logic — all resource CRUD operations are delegated via go-plugin over the gRPC protocol to independent Provider binaries.

This design pushed the enormous engineering effort of integrating cloud APIs out to the edges: any third-party vendor or developer who implemented the plugin interface could bring their own service under declarative management.

This meant HashiCorp didn’t need its own team to cover every cloud platform one by one — the ecosystem would grow itself. CloudFormation was locked to AWS; Puppet and Chef focused on in-machine configuration. Terraform’s decoupled architecture made it the only provisioning tool with a real shot at spanning every cloud provider. That wasn’t just technical elegance — it was a strategic gamble that traded architecture for ecosystem scale.

The inflection point arrived in late 2016. As contributors surpassed 750 and Providers grew to dozens, Terraform downloads began doubling month over month. In September 2017, HashiCorp launched the Terraform Module Registry, consolidating community and official templates into a modular ecosystem.

The plugin ecosystem created powerful network effects: for emerging cloud platforms and SaaS services, “shipping an official Terraform Provider” became a prerequisite for breaking into the enterprise market. Major vendors poured resources into maintaining their plugins, cementing Terraform’s status as a de facto industry standard.

The major public cloud providers shifted strategy accordingly: AWS launched the general-purpose-language-based AWS CDK in 2019; Microsoft introduced Azure Bicep; and Google Cloud phased out its own Deployment Manager, adopting Terraform as the core backend for infrastructure management.

In June 2021, Terraform shipped version 1.0 with a compatibility promise. On December 9 of the same year, HashiCorp went public on Nasdaq (ticker: HCP), with a market capitalization approaching $15 billion on its first day of trading.

The License Storm and the OpenTofu Fork

Going public subjected HashiCorp to the relentless pressure to deliver revenue growth every quarter, pushing it toward the classic tension of open-source business models. Open-source software accumulates enormous trust among engineers, but the commercial returns are easily siphoned off by the platforms built around it.

This kind of commercial conflict is hardly rare in the open-source world. The tension between original authors bearing R&D costs and cloud providers harvesting the revenue has played out repeatedly:

For HashiCorp, the primary commercial threat came from collaboration platforms built around the Terraform CLI — commonly called TACOS platforms (Terraform Automation and Collaboration Software) — including Spacelift, env0, Scalr, Gruntwork, and Harness.

These startups offered remote execution, state locking, PR previews, and access controls, competing directly with HashiCorp’s flagship paid product, Terraform Cloud / Enterprise, for enterprise subscriptions.

On August 10, 2023, Armon Dadgar announced that all products, including Terraform, would switch future versions from the more lenient Mozilla Public License (MPL 2.0) to the Business Source License (BSL 1.1), explicitly prohibiting use of the software to offer commercial products that directly compete with HashiCorp.

The decision immediately sent shockwaves through the community and ecosystem. On August 15, affected vendors and community members co-signed the “OpenTF Manifesto”, demanding that HashiCorp reverse the relicensing decision or face a fork.

The dispute exposed a stark clash of two positions:

• Community and ecosystem vendors: Terraform became a standard thanks to thousands of external contributors and an industry-wide Provider ecosystem. HashiCorp harvested the ecosystem’s value and then unilaterally changed the license terms, betraying a long-standing open-source commitment.
• HashiCorp’s business position: CEO Dave McJannet stressed in interviews that the new license remained fully open for the vast majority of end-user enterprises. The restrictions targeted “competitors profiting directly in the market we built,” and he questioned whether commercial rivals were hiding behind a foundation’s neutral image to protect their own business interests.

The two sides could not reconcile. On September 20, 2023, the Linux Foundation formally accepted the fork and renamed it OpenTofu, backed by over 140 organizations pledging full-time development resources.

The architectural design revealed its double-edged nature at this historical turning point: the “core and Provider separation” that once propelled Terraform’s rapid adoption now became the natural launchpad for a fork. Because the vast Provider and SDK ecosystem largely retained its original licenses, the OpenTofu team only needed to take over the core engine and build a compatible Registry mirror to inherit the full plugin ecosystem accumulated over a decade.

On January 10, 2024, OpenTofu 1.6.0 shipped as its GA release. In April of the same year, the two sides exchanged cease-and-desist letters and clashed over code provenance. In April 2025, OpenTofu officially entered the Cloud Native Computing Foundation (CNCF) Sandbox.

At the center of the storm, co-founder Mitchell Hashimoto had already stepped back from day-to-day operations and formally left HashiCorp on December 14, 2023, turning to independent open-source projects focused on the public good and nonprofit stewardship.

The Big Acquisition and Strategic Convergence

The switch to BSL failed to reverse the market’s downgrade of HashiCorp’s growth outlook. On April 24, 2024, IBM announced an acquisition of HashiCorp at $35 per share in cash, representing an enterprise value of approximately$6.4 billion. The deal closed on February 27, 2025.

The acquisition created a notable echo in the history of IT automation:

 The Consolidation into IBM

 [2015] Red Hat acquires Ansible
 [2019] IBM acquires Red Hat ($34B)
 [2025] IBM completes HashiCorp acquisition ($6.4B)
   |
   v
 Two generations of automation
 (Ansible & Terraform) unite under IBM.

In 2015, Red Hat acquired Ansible, the defining tool of the configuration management era. Red Hat itself was then absorbed into IBM in 2019. A decade later, Terraform — the defining tool of the cloud provisioning era — followed the same path. Two generations of tools that each drove a paradigm shift in operations ultimately converged within IBM’s enterprise software portfolio.

After the acquisition closed, the Terraform product line underwent strategic consolidation. On December 10, 2025, the team officially announced it was archiving CDK for Terraform (CDKTF), discontinuing the approach of writing Terraform in general-purpose programming languages and refocusing development resources on the HCL core. In March 2026, HCP Terraform retired its legacy free tier, switching entirely to a strict managed-resource metering model.

Three Years After the Fork: Two Diverging Paths

September 20, 2026 marks exactly three years since the Linux Foundation formally accepted OpenTofu. Three years is enough to answer the question most people had at the time: can a community fork actually survive?

By the numbers, the answer is yes. After entering the CNCF Sandbox in April 2025, OpenTofu continued to grow. By mid-2026, it had surpassed 10 million cumulative downloads, with its Registry listing over 3,900 Providers and 23,600 modules. Fidelity Investments and other enterprises have publicly shared their experience adopting OpenTofu in production.

More telling is the substantive divergence in technical direction. Starting with version 1.7, OpenTofu has shipped features that the Terraform CLI still lacks: native State Encryption, Provider-level for_each, and OCI Registry support introduced in version 1.10. Ephemeral resources, added in version 1.11, are the exception — HashiCorp had already shipped a feature of the same name in Terraform 1.10 in November 2024.

State Encryption is particularly significant — Terraform’s state file still stores database passwords and API keys in plaintext. The community’s encryption request dates back to 2015 on GitHub, yet HashiCorp closed the 2016 formal proposal as “not planned” in 2024, and the concern remains unresolved to this day.

The market picture has settled into a split: “existing deployments stay on Terraform; new projects go to OpenTofu.” Across the broader IaC market, Terraform still holds a dominant position at roughly 30 to 60 percent market share.

But on some collaboration platforms, OpenTofu already handles over 60 percent of execution volume, and its share of newly created workspaces sits at around 72 percent. Most existing teams have not migrated, but new projects are accelerating toward the open-source camp.

Under IBM’s stewardship, Terraform is heading in a different direction: archiving CDKTF, tightening the free tier, aligning the enterprise edition with IBM’s semiannual release cadence, and launching a public preview of Infragraph in May 2026 — a visual infrastructure graph product aimed at building new monetizable value on the observability layer.

The architectural prediction from three years ago has been validated: the decoupled design of core and Provider was both the key to Terraform establishing a decade-long standard and the fundamental reason the fork could achieve independence so quickly. The architecture born to scale the ecosystem ultimately gave that ecosystem the freedom to walk away.

Epilogue: Is IaC the End of the Line for Operations Automation?

As the dust settles on the Terraform licensing dispute and ownership saga, a deeper architectural reflection is emerging in the infrastructure space: has the IaC paradigm — declaring state in static text files — reached the limits of what it can do?

The Ceiling of Static Files

The most compelling challenge comes from Adam Jacob, co-founder of Chef. He founded System Initiative in 2019 and stated bluntly at its product launch:

“The path we’ve been on, which is to use the same approach and tools that we use to build applications to build infrastructure, is a technological dead end.”

Jacob’s argument strikes at the operational core of IaC. In Terraform’s model, engineers write the desired state of their infrastructure into static .tf files, commit them to a Git repository as the single Source of Truth, then run plan to diff and apply to execute changes.

The problem is that real cloud resources don’t sit still and wait for your commands. Someone edits a security group rule through the console. Auto Scaling adds or removes machines. The cloud provider silently upgrades an underlying component. All of this happens outside Terraform’s line of sight.

When the state declared in .tf files, the snapshot recorded in .tfstate, and the actual state of the cloud begin to diverge, you get what is known as State Drift.

Drift is manageable on Day 1 — initial provisioning. But once you enter Day 2 — monitoring, scaling, upgrades, incident response, and the full scope of ongoing operations — the gap only compounds. Engineers must repeatedly run terraform plan to detect drift, then decide whether to update the code or force-overwrite the current state. This back-and-forth cycle gradually becomes a synchronization bottleneck for operations.

Jacob argues that the real way out isn’t writing better static files — it’s replacing the entire interaction model: swap the traditional Plan/Apply workflow for a live, bidirectional Digital Twin that continuously reflects actual state, rather than checking only when a human presses a button.

From CFEngine at the University of Oslo in 1993, through Terraform’s rise, split, and acquisition, the central challenge of infrastructure engineering has never changed: how to build reliable abstractions that tame the dynamic complexity of underlying systems.

Terraform, through its elegantly decoupled plugin architecture, established an industry standard that held for a decade. But it was precisely this design — distributing control across the Provider ecosystem — that ensured no single company could permanently own what it had built.

Whether the future of infrastructure management lies in real-time dynamic models, declarative code, or AI-driven autonomous processes, this thirty-year arc makes one thing clear: what determines the staying power of a foundational tool has never been just syntax or features. It is whether the architecture can sustain, over the long term, the balance of trust among developers, ecosystem partners, and commercial interests.