Guest: Rob Hirschfeld (LinkedIn)
Company: RackN (Twitter)
Show: Let’s Talk

HashiCorp recently announced that it is changing its source code license from Mozilla Public License v2.0 (MPL 2.0) to the Business Source License (BSL) v1.1 on all future releases of HashiCorp products.

In this episode of TFiR: Let’s Talk, RackN Co-Founder and CEO Rob Hirschfeld shares his insights on this latest firestorm and how it impacts companies and the open-source ecosystem, in general.

What happened:

• HashiCorp, a publicly traded company, has a suite of very influential and important products in the industry, including Vault and Terraform.
• Up until August 9, 2023, these products have a permissive open-source license.
• This change is not retroactive. Going forward, all of the significant parts of the code bases of all of the HashiCorp products would be licensed under a business software license, which restricts the use of their products and the code.
• The code will still be available, but it can’t be used in ways that compete with HashiCorp or get embedded into other products.

After championing open source for so long, why change now?

• HashiCorp is a publicly traded company, and they have a duty to shareholders to sustain themselves.
• There are companies that are basically Terraform orchestrators, where they’ve provided an API in front of Terraform to run workloads, and then they offer that as a product. Result: HashiCorp’s Terraform has a competing product called Terraform Cloud. Its core technology is being used as a driver for competitive products. It is commercially difficult to invest in maintaining a core technology and then see other people profit from it.
• With the way the market is structured, most of the revenue for software is being directed to SaaS companies. If you’re investing a lot of time building open-source software, like HashiCorp does, other people can pick that up and use it in their SaaS. People can monetize that software very effectively and none of that flows back to the originators of the software. Result: HashiCorp is competing with their SaaS monetization play.

Impact to the ecosystem:

• There’s active discussion about forking the projects and moving them into a community-maintained system. The idea would be to create a foundation or a group of like-minded people to create and maintain the software in a collaborative style. It’s going to drift away from what HashiCorp is doing, which will create a lot of market confusion and uncertainty over time.

The real problem:

• Hirschfeld believes this is not a licensing problem. The purpose of licensing is to allow collaboration.
• The challenge is people have abused the business models and use open-source models to get market adoption, without building collaborative infrastructures.
• The company that’s running the project is not collaborating or did not set things up in a broad market situation to collaborate. They’re using collaboration-based licensing in a way where they are maintaining control of the infrastructure.
• With the predominant business model for monetizing things, it’s very hard to monetize an open-source collaborative framework if you are trying to protect the IP for that.

On project vs. product:

• A project is the codebase, the people, the collaboration, and the software bits. Once that software gets compiled into a downloadable artifact, Hirschfeld considers that a product.
• It can become indistinguishable because somebody can just compile that code and put it out there and that product is very similar to the project. The difference with a product is that you can call somebody up and they fix it. They take responsibility for the patching, building maintenance support, and all the things that actually go into making that code into actually a business-sustaining artifact.

Takeaways from this HashiCorp change:

• You need to be using abstraction to protect yourself from these changes, because they will keep coming. You need to make sure that that abstraction is flexible enough that it doesn’t become a least common denominator.
• Always ask your API layers, “How do you handle if I change a core component? How do I make sure that I can leverage the capabilities of the systems that are underneath this abstraction fully?”
• Anytime you use a product and embed it into your systems, open source or proprietary, it’s very important that 1) you are aligned with how that product is supported and monetized, and 2) you understand how to build abstractions around it and potentially have alternatives or replacements. That’s just good supply chain management.

On collaboration:

• It is much more expensive to collaborate than people realize. There’s actually a significant amount of work in building collaborative software, testing it, sustaining it, making sure that the changes don’t break, owning that code as part of the code base.
• If companies don’t walk into projects expecting that type of collaboration, then it is very hard to put that back into a project.
• In the HashiCorp example, it might be that one of their competitors wanted a feature added into Terraform to make it easier for them to govern Terraform from a SaaS perspective, but HashiCorp does not want to take that in because they don’t want to maintain it.
• What makes a project successful is getting the stakeholders who are going to drive it and invest in the code base to have a way to agree and share what those priorities are.
• The ROI on a collaborative codebase is actually significantly higher than the ROI on a single-owner codebase. That’s the magic of being able to make collaboration work, but it’s not free.

On open source:

• Open source is amazing for certain types of systems where there is shared interest and a collaborative environment to really grow and improve.
• A lot of companies today see open source as free software, and they end up building their own custom bespoke versions of systems because they’re trying to take advantage of free products.
• These people equate “open” with “free,” including vendors who’ve taken HashiCorp products and what they published as projects and embedded those projects into their business model, without anticipating or worrying about when that collaboration tax would come due.
• They forget that the life or death of any open-source project is how well the parties collaborate.
• People who are looking to use open source and embrace open source in their companies and products should evaluate, “Are they using open source where the licenses are aligned with the community? Is the sustaining motion of that software aligned with the way you’re consuming it?”

How RackN helps customers:

• RackN’s mission is to make automation shareable and collaborative. They actually had to build a huge amount of infrastructure around the automation to make it shareable, collaborative, reusable, and decomposable.
• Vendor neutrality is a major theme in how they help their customers.
• Its architecture is based on finding common dynamics and then making them repeatable across the board, but not so locked in and over-defined that it’s impossible to use.
• With abstractions, it takes a lot of deliberate design to balance control and exposure. RackN’s Digital Rebar platform enables companies to create that type of abstraction and have supply chain independence and control.

This summary was written by Camille Gregory.