Entering the graveyard of good software that is IBM…
As I write this on April 25th, I’m still processing the news of IBM’s acquisition of Hashicorp. When I first heard the rumors yesterday, I was worried about the future of what might be my favorite Infrastructure-as-Code (IaC) tool. It’s been clear for a while that Hashicorp has been struggling financially, posting a loss of $274 million in 2023. This likely contributed to the controversial switch to the BSL license in August 2023 and the community fork of OpenTofu. Hashicorp isn’t alone in facing these challenges; Redis has taken a similar route, leading to the Valkey fork, and Elasticsearch has also made license changes.
The Challenge of Open-Source Monetization
Many of these companies have had difficulty adequately monetizing the open-source tools they’ve created, and I’d like to dispel a common myth:
There is no such thing as “free” software.
While there is certainly a lot of software available at no cost to the user and can be modified under permissive licenses, it’s important to remember that developers are spending time writing code, and time generally comes with a cost.
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…
