The beginning of the end for Terraform?
Entering the graveyard of good software that is IBM…
As I write this on the 25th of April, I am still reeling from the announcement of IBM’s acquisition of Hashicorp. When I first heard the rumours yesterday, I was concerned about the future of possibly my favourite Infrastructure-as-code (IaC) tool. It has long been obvious that Hashicorp has been struggling to make money, making a $274 million loss in 2023. This undoubtedly led to the highly controversial switch to the BSL license in August 2023 and the community fork of OpenTofu. Hashicorp is hardly alone in its struggles, with Redis adopting a similar approach, resulting in the Valkey fork or Elasticsearch with its license changes.
The challenge of open-source monetisation
Fundamentally, many of these companies have struggled to sufficiently monetise the open-source tools they have developed, and this is where I want to bust a myth some people seem to have:
There is no such thing as ‘free’ software
Sure, there is plenty of software that is free at the point of use and can be modified under permissive licenses and the like, but fundamentally, developers are spending time writing code, and time typically requires some payment.
I appreciate there are several hobby projects that people may contribute to in their spare time, but large open-source projects are typically supported by big tech firms contributing engineers or money to enable developers to work part or full-time on them; for example, look at the companies who pay to be members of the Linux foundation. As another example, Google is still the largest single contributor to the Kubernetes project. Google can do this because it makes money running services that rely on it, and sells a managed offering in Google Kubernetes Engine.
Hashicorp struggles with this, people have long used their free tool to orchestrate public and private cloud environments but had little reason to pay for the Terraform Cloud product even if it had some advantages.
The problem with IBM buying Hashicorp
So Hashicorp was a financial disaster even though they had good products, I have personally worked with Terraform & Packer and seen plenty of Vault implementations. A lot of companies liked Hashicorp tooling because it was inherently cloud-agnostic; for multi-cloud organisations, having a common configuration language in Terraform or a secret management solution in Vault was preferable to learning each in AWS, Azure, Google Cloud, or the multitude of other providers.
This leads me to my first concern, IBM has a conflict of interest. IBM has a cloud offering, admittedly with a 1.8% market share. Why would they want to keep developing tools that frankly benefit their competitors more than them?
My second concern, perhaps my biggest, is that IBM has a graveyard of failed acquisitions of good software companies. In recent history, their acquisition of Red Hat resulted in changes to CentOS that destroyed the market share of this once-popular distribution, anecdotally often in favour of Ubuntu LTS. This is far from the only example with Lotus Software being another from the 2000s. I simply have no trust in IBM to look after Hashicorp as a company.
So, where do we go from here?
So, the big question, much like the recent post-VMware price rises, I think there is a fork in the road. Either we continue to stick with Terraform, as IBM no doubt attempts some renewed monetisation effort to make good on their investment, or we change our IaC tool. With the latter, what are our alternatives?
Well, let’s start with the obvious: OpenTofu. This is perhaps the easiest short-term ‘fix’ for those not running cutting-edge Terraform, where they can use a compatible binary based on an earlier version.
Pulumi is another potential option, though I would have financial sustainability concerns for their business model which is similar to Hashicorp’s old model.
Crossplane is another option that generates quite a lot of noise with a Kubernetes-centric view of the world. I previously blogged a little about this approach in the context of Google’s Config Connector, showing some merit. Crossplane uses a similar ‘provider-centric’ approach like Terraform allowing easier extensibility to different platforms. Whilst the project is CNCF-backed (and going through adoption at the time of writing) the main contributor appears to be Upbound whose financial sustainability I am equally unsure of.
Another option is to ‘go native,’ with each of the big three hyperscalers offering its dedicated options: Cloud Formation with AWS, Bicep with Azure, and Config Controller in Google Cloud. The main downside I see with this approach is fragmentation. Part of the appeal of Terraform was its consistency in configuration language, with providers abstracting the vendor-specific API calls.
There are no doubt many other tools I have failed to mention, and please comment on any additional suggestions you have.
What do I think?
I believe an ‘Open Terraform’ supported in development by those who profit from it is the answer. This is sort of what’s happened with OpenTofu, which has backers such as Gruntwork. I would love to see an expansion of this support base to include all the major hyperscalers, who, in practice, are the ones making the most money from Terraform. Many of these hyperscalers are already deeply involved in developing providers that interface Terraform with their platform. Expanding this toward the tool itself doesn’t seem like a big leap; if they decide to do this, though, is anyone’s guess, especially with the news so fresh, we will have to wait and see…
