Why We Are Not Supporting OpenTF

Background

On August 10, HashiCorp changed the license to their previously “Open Source” projects to a Business Source License (BSL), making them now “source available” for all future releases. We discusssed in detail reasons and motivations for this change here.

On August 15th, the OpenTF Manifesto was released. The punchline is that they want HashiCorp to revert the license for Terraform to a true Open Source license or the consortium of pledgees will support a fork of Terraform to be managed by a foundation.

Our Take

We feel that the OpenTF Manifesto presents the new license in a distorted way that favors the for-profit companies most impacted by the license change, and that the potential cost to the Terraform ecosystem is too high if a fork were to happen. Furthermore, as an affected party, we do not mind licensing Terraform to embed it within our own solution given the large supporting ecosystem that HashiCorp has built and maintains.

Let’s unpack this statement*.

*The following is not legal advice, please consult with an attorney familiar with the specifics of your situation.

Biased and distorted presentation of the license

• 1) In the opening section of the manifesto “Our concern: the BUSL license is a poison pill for Terraform”, they state:

“…now every company, vendor, and developer using Terraform has to wonder whether what they are doing could be construed as competitive with HashiCorp’s offerings.”

This feels quite inaccurate. The only companies that need to worry about the license change are those with production products that are “offering the Licensed Work to third parties on a hosted or embedded basis which is
competitive with HashiCorp’s products.”

There were initially some valid questions around some specifics, namely, what happens if HashiCorp releases features that overlap with your previously published tool? That being said, after HashiCorp’s CTO released “binding” answers to some of these FAQs, it seems clear that the only folks who this affects are those that sell software to other companies, where that software competes with HashiCorp’s Terraform Cloud and Terraform Enterprise products and hosts or embeds Terraform (either the source code or the CLI binary).

Notably, the three largest companies that most-directly compete with HashiCorp’s managed Terraform offerings, Spacelift, Env0, and Scalr, all have made multi-million dollar pledges to support a fork of Terraform (13 FTEs for five years between these three companies). Their employees and founders have been some of the most vocal contributors to and amplifiers of the OpenTFManifesto.

• 2) Citation of benefits of a fork that would have been as true in 2021 as they are today.

The OpenTF Manifesto cites as key reasons for a fork being the creation of a Terraform that is “Truly Open Source”, “Community-driven”, “Impartial”, and “Layered and modular”. These are all valid concerns with Terraform core, and really any corporate-owned OSS project, but these problems with the Terraform core repository are not new. Getting community PRs accepted into the HashiCorp ecosystem has been slow for years, and they have always not added certain enterprise-style features into the core (like any corporate owned OSS tool would).

The only material change over the past ~14 days, in our opinion, is that certain business’s have had their margin profile change.

The potential ecosystem cost of a fork is very high

Should a fork happen, the main Terraform branch might not sit idly by. HashiCorp could feel forced to strengthen its position and introduce incompatible differences in new releases of Terraform and major-cloud providers. This would in the best case scenario cause the community a lot of extra work to adopt new major releases of Terraform, and in the worst case lead to a schism in compatability between the major release and the fork.

A schism like this would be devastating for the tool’s adoption (Which branch of Terraform should I use? What are the differences? Forget it, I’ll just go with an alternative) as well as pure open source projects that support Terraform (Which branch do I write for? Do I support both and increase the work needed to maintain the tool?). It could also lead to enormous duplication of effort, with parallel maintanence of registries, providers, and Terraform core needed in perpituity.

Even in the case where a fork happens and HashiCorp continues with business as usual, it feels like a large duplication of effort for the entire community given that the main beneficiares of a fork are simply different for-profit entities and their users.

In summation, a fork could be very, very costly to the Terraform community.

HashiCorp Enables the Terraform Community through Significant Investment

Key aspects of the Terraform community are maintained by HashiCorp with a significant associated cost.

They enable literally billions of provider downloads a year, free module hosting (which our organization leverages as a key distribution mechanism), and billions of Terraform binary downloads.

The aformentioned efforts do not include the maintanence of major cloud Terraform providers and Terraform core itself. Needless to say, HashiCorp invests significantly in the community on an on-going basis and will continue to do so.

Counter-argument: Does the move to BSL not stifle competition?

Many Terraform Cloud alternatives, specifically Spacelift, Env0, Scalr, and Digger, have developed innovative tooling and features for Terraform management. At the same time, they have done so drafting off the large ecosystem investments that HashiCorp has made. To be clear, there is nothing wrong with this approach, and it is a smart business strategy so long as one can continue to draft with near zero costs.

The license change at least raises the cost to operate for Terraform Cloud/Enterprise competitors. These costs will likely be passed on to their own customers in some form. This could be through higher pricing structures as licensing fees hit their margins or less choice as some businesses pivot away from Terraform management altogether (this later response would most stifle competition of course).

One other thing to remember is that HashiCorp is a business as well, and so it is unrealistic to expect them to continue running net losses while competitors, unencumbered by the fixed-costs needed to maintain and run Terraform community assets, directly target them. While it is not ideal that offerings in this space will almost certainly get more expensive as ecosystem costs are borne more uniformly, it would also not be ideal if HashiCorp becomes a non-viable entity.

Conclusion

From our perspective, the potential cost of a major division in the Terraform community could be extremely costly and potentially devastating to Terraform’s future. HashiCorp’s continuing with the BSL does not affect > 99% of Terraform users; the primary OpenTF Manifesto writers have a vested profit motive, however, and have presented the situation quite differently.

We see a fork of Terraform being far costlier for the community than a handful of companies having their for-profit business model changed, and as a result do not support the OpenTF project.

—

What did we miss? Let us know in the comments below!

If curious about our own bias, our company builds a product that embeds the Terraform CLI and has some overlapping features with Terraform Cloud, namely drift detection, and so are affected by the BSL change for releases of Terraform beyond 1.5.5.

—

dragondrop.cloud’s mission is to automate developer best practices while working with Infrastructure as Code. Our flagship OSS product, cloud-concierge, allows developers to codify their cloud, detect drift, estimate cloud costs and security risks, and more — while delivering the results via a Pull Request. For enterprises running cloud-concierge at scale, we provide a self-hosted management platform. To learn more, schedule a demo or get started today!