 Hi, this is Yoho Sapin Bhartiya, and welcome to another episode of TFI. Let's talk. And today we have with us once again Rob Herschfeldt, CEO and co-founder of Racken. And today we are going to talk about the license change at Hashi Carp, where they have moved their products from open source licenses to a business source license, which of course is not in a sense open source. It's a controversial topic and blog sphere is already flooded with journalists writing their opinions. We want to steer clear of all that controversy and focus on people that really matter, people like customers that we serve, people like the whole ecosystem that is built around these technologies. So Rob, can you just quickly tell us what happened here? I'd be happy to swap. And I like the framing here. I think a lot of these open source controversies are very interesting to the industry, wonks, and more confusing than anything else to the end users and people who try and consume the technology. And so I'm happy to try and sign some light there. What happened is ultimately very simple. Hashi Corp, which is a publicly traded company, has a suite of very influential and important products in the industry, had been effectively been an open core company up until last week. So the core products that they build their business on, things like Vault and Terraform, they have a long list of them. Those are the two most well known. Those products had been in with the permissive open source license up until last week. And then last week, Hashi Corp made a decision to change the license, which is a going forward action. They can't do this retroactively, but going forward, all of the code bases or significant parts of the code bases of all of the Hashi Corp products would be licensed under this business software license, which restricts the use of their products and that code. The code is still available, but you can't use that code in ways that compete with Hashi Corp or get embedded into other products. And so it's a pretty restrictive license from the perspective of what the market, how the market had been using these formally open source projects. And how do you draw a line between a project and a product as these things can become confusing at times? It has always been a challenge to do that. A project is really the code base. It is the simplest way I like to think of it. It's the people, it's the collaboration, it's the software bits. But once that software gets compiled into a downloadable artifact, I consider that a product. Now, there's a lot of times when it's indistinguishable because somebody will just compile that code and then put it out there and then the product is very similar to the project. But the difference with a product is that you end up being able to call somebody up and then fix it. And they take responsibility for the patching, the fixing, building, maintenance, support, all the things that actually go into making that the code into actually a business sustaining artifact. If you don't want to do that from an open source perspective, what you would do is you would take that source code and you would build your own copy of it. You create your own binary. And that very, very, very, very few people ever choose to do. It's one of the reasons companies like Red Hat and Kinautical exist in SUSE, because they are literally taking the Linux source code which is open and anybody could build a copy of Linux and a lot of people do for that project. But most companies consume it through somebody who's gone through the effort to build and compile a distro. And we have actually similar arguments to what we're talking about with HashiCorp going on in the Linux community around Sentos or around Elastic and Redact and even back in the Docker days. A lot of what we're going to talk about probably feels very Docker and Big Docker, the company and Little Docker, the project. Very similar dynamics going on here. You and I, we have recorded so many episodes on this topic. We ran actually a show with Dirk Honda and we covered this topic and he had some great insights on this topic as a veteran in open source word. We actually, you and I talked about the whole Red Hat thing where they made changes to Sentos. What I do want to talk about with you is that we used to hear about this thing at a smaller scale, but now it's happening at a much larger scale. What do you think is driving companies who were once champions of open source to take such steps? One of the challenges is there's two market sources here that are really difficult to navigate for any company. And it's very important to remember HashiCorp is a company and they're publicly traded. They have a duty to shareholders to sustain themselves. And, you know, people can read their public filings and see how much, literally how much money they make from selling these products and how much money they sell. They make from selling services, supporting the products. But there were two challenges here. One of them is that their product, the code, the products, the things they've built are widely embedded in other people's products, either in a way that you can't see or a lot of times in a way that you do see. So for Terraform specifically, there's a number of 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. And so from Terraform, Terraform, HashiCorp has a competing product called Terraform Cloud. And so literally its core technology is being used as a driver for competitive products. And I'm using Terraform as an example. Their core technologies are being used in competitive situations for them. And that's commercially very difficult for you to invest in maintaining a core technology and then see other people profit from it. It's sort of the idea for open source, but if it's too one-sided, open source falls apart. The other component here is that the way the market is structured at the moment is very difficult to be a software company. Most of the revenue for software is being directed to SaaS companies. And so one of the challenges here is that if you're spending a lot of investment time building software, like HashiCorp does, and then other people pick that up and use it in their SaaS, this has been a common argument against what Amazon does and how Amazon's done in other open source scenarios. A lot of times you can monetize that software through the SaaS very, very effectively. And none of that flows back to the originators of the software. So they were sort of getting hit in a double squeeze. Their competitors were embedding their software and taking advantage of it. And they were competing with their SaaS monetization play. And that's a hard thing to watch happen. Some companies can, but it's a hard thing to watch happen. And it's not the similar. I think similar dynamics are happening to other companies like Red Hat that have worked very hard to have an open source brand, but then that openness allows competitors to come in and take revenue from them. And I should say take revenue is from the perspective of the vendor in this case. The competitors might have different feelings based on the way they perceive open source or what they're trying to do in market or what they're actually building. But it's not hard to see somebody working, spending a lot investment in this software, seeing it as a taking. And I hear both side of stories. When I talk to these companies, I do hear and see their side of stories as well. And even if they may or may not admit, the issue is becoming that some of these licenses were written in the ages when software was downloaded and installed on Clan Machine. You had to give changes back when you redistribute the code. You're kind of restricted or allowed by the license to do so. But in the cloud centric world, where most of things are being offered as software service, it has changed everything as you no longer have to distribute anything. So you're not kind of compelled to release that changes or to get actively involved with the communities. Actually, the fact is that most of these companies, they are actively involved because their own product rely on these projects. But license is becoming a critical kind of piece here. What used to be a model for collaboration is not being weaponized. Don't you think that we may actually need new licenses which are written for modern SaaS cloud centric world? Because as companies are coming out with their own licenses, it reminds me the early days of Linux kernel itself. When I talk to him, we were like, there are so many licenses that it was really hard to see which licenses compatible with what. So when the Kano GPLv2 came out, he liked the license because it makes things so easier. You don't have to go to a lawyer for these licenses. What do you think organizations like OSI or FSF should do to come up with the kind of license which is created for modern SaaS centric world? But the challenge is that most of these SaaS players are also big stakeholders. So it will be more or less like working against their own interests. So it's a very complicated field. It is not as simply as saying, hey, you know what, the cloud is taking away all your businesses or it's saying that, hey, by changing license, you are eliminating your contributors. It's much more complicated than that. But I want to hear your thoughts on that. What do you think about coming up with new licenses? It's a really good question and very thoughtful. I don't think that this is a licensing problem. I think that this is a cross of business markets and business models more than a licensing problem. The purpose of the licensing is to allow collaboration. And they do a very good job of allowing collaboration. The challenge we have, and I think people have abused the business models and created used open source models to get market adoption without building collaborative infrastructures, right? HashiCorp in this case owns just like we have the same problem. Every example we've named so far, the company that's running the project isn't collaborating, didn't set things up in a broad market situation to collaborate. And so it's not a shame on them, it's just that they're using a collaboration based license in a way where they are maintaining control of the infrastructure. And so I think what goes on here is that those licenses are very well structured if you have something that is inherently a multi-author collaborative good, right? And I've been involved in a lot of projects where that worked. It was very important and it was a driver for how things went. The challenge that we have is the predominant business model for monetizing things is SaaS at the moment. And so it's very hard to monetize an open source collaborative framework if you are trying to protect the IP for that. And so SaaS makes, when you're doing a SaaS, nobody cares about the license, it's a service. And so what that allows people to do is they take a business model where nobody cares about the license, they only care about the APIs and the cost of the service and how well it's run. And the license is completely lost in that case. And so what happens is the SaaS is then able to use these collaborative licenses in ways that frankly aren't collaborative. And that's the essence of the challenge here. And it leaves a company that is looking for using SaaS as its main monetization strategy or even open sources main monetization strategy. You have to be able to have a go-to-market where you are able to basically provide something that people want to buy from you on top of what that tech is. And there's lots of great examples where that works really well. Linux is a fantastic example of that type of community programming languages. Some of the UX frameworks. There are lots of good examples of places where we've seen collaboration and synergies around that. But even things like ARM now are coming under some scrutiny on how it's taking its work and then providing licenses for those things. And this always is going to come back. It's a recurring theme that people who are looking to use open source and embrace open source in their companies and their products, which is everybody, needs to be aware of are they using community open source where the licenses are aligned with the community or are they consuming something where they're not aligned. And I think that's the fundamental question here is not whether the licenses are good or bad. It's a question of is the market aligned? Is the sustaining motion of that software aligned around the way you're consuming it? And if you're out of alignment on that, then you need to really be evaluating what you're doing with that software and what the longevity of that software is. Since we're talking about ecosystem, what kind of impact is this going to have on the ecosystem ecosystem of partners folks like Rack and who not only leverage things like Terraform, but you folks also actively engage and contribute to some of these open source product that you rely on. A much bigger problem that I see is also what kind of impact there is going to be on customers, which are of course customers of Hashi at the same time customers of companies like Rack and who are using these technologies. What does it mean for them? Oh my goodness. This is an interesting ball of yarn to untangle because right now there's active discussion of forking the projects that Hashi Corp has had to move them into a community maintained system. So the idea would be you would fork it before the license changed and then you would create a foundation or a group of like-minded people to actually create the software, maintain the software in a collaborative style. And in a lot of cases, the Hashi Corp products, the projects behind the products, have enough ecosystem behind them that you could actually now create a collaborative group of maintainers for those projects. Now it's a fork, so it's going to drift away from what Hashi Corp is doing and that's going to create a lot of market confusion and uncertainty over time because all of a sudden we start having to ask questions of are these compatible. If I'm using the Hashi Corp Terraform, is it going to work with the open? There's certainly not going to be able to use the trademark for Terraform, but I'm going to call it open Terraform for the moment. Open TF, let's do that because that might survive trademark scrutiny in the future. And so the binary compatibility of those things will drift and it really has to drift. And so you get questions of do all the providers that exist work with both platforms? Does Hashi Corp make changes to the Terraform code so that it isn't compatible because they're trying to force customers to choose? It really creates a lot of confusion for people in the market who are used to using these products and in all likelihood almost as a requirement those things will drift. Now it's possible that the collaborative effort will fade because all of a sudden a lot of the business models that people have assumed they could embed Hashi Corp products into their own products and SaaS services. Those things are now in question and they might be going to look for alternatives. They might also be I think what Hashi Corp would like is calling them up and getting licenses so that they actually are in compliance and continue to stay on the code base. And the market will do some of each of those things. The bigger challenge here is how replaceable are those products and what companies can actually do to make substitutions. One of the things that I found is that when we design rack end design software we work really hard to identify abstraction points and ensure that when we are using tools we've built abstraction points in front of them. Sort of more foundational pieces like a machine rather than a Dell HP Lenovo or a VM or a cloud like we wrap those things in front of resource brokers. So we work to build abstraction points into everything we do and the most durable customers that we've seen in these cases and as I've worked across the industry for decades now the most durable actions are when you identify tools that you're using and then provide an abstraction layer in front of them to isolate you from these types of changes. Because at the end of the day what we're seeing Hashi Corp doing right now is not a surprise. It's something that watching the market even before they went public there was a risk potentially growing I would argue a growing risk that they would need to take an action like this in market. And so anytime you use a product and embed it into your systems open source or proprietary it is very important that you understand you have an alignment with how that product is supported and monetized and that you understand how to build abstractions around it and potentially have alternatives and replacement. That's just good supply chain management. And so one of the takeaways here is right everybody using any product should understand that supply chain. As an advocate of open source I always believe that open source or these licenses are more about people. It's about enabling people to collaborate. It's not that much about hey you know what you can see the code. It's more about how you can get involved how you can make good better. And I remember you know when Linus said that you know what all I care about is that if you make any changes to my code I just want those changes back. It's all about collaboration. But collaboration is not cheap especially if you're investing or if you are kind of engaging in a code based written by some different company. It's a lot of work. Since you folks reckon play a big role in this ecosystem. What does that mean for company of your size to get involved to collaborate on these kind of projects and products. Oh my goodness. What you're hitting is something that I observed back when I was in the open stack board and all the open source work I've done. It is much more expensive to collaborate than people realize because you have to be prepared to take somebody else's change and incorporate it into your system and then you have to when you take that change you take the responsibility of maintaining that code forever and make sure it doesn't break other people. There's actually a significant amount of work in building collaborative software in testing it sustaining it making sure that the changes don't break right owning that code for forever right as part of the code base if somebody just does a drive by change. So you know one of the things that we found when we built rack end because our mission is to make automation shareable and collaborative that is literally rack ends mission in the very simplest terms but to make that happen we actually had to build a huge amount of infrastructure around the automation to make it shareable and collaborative and reusable and decomposable all those things were required to build to fulfill our collaboration mission and one of the things that you see in these cases is if companies don't walk into projects expecting that type of collaboration this is why foundations and doing foundations early is important then it is very very hard to put that back into a project. In the Hashi Corp example it might be that one of their competitors wanted a feature into Terraform to make it easier for them to govern Terraform from a SAS and Hashi Corp is not going to want to take that in because they don't want to maintain it they might not be able to test it there's all sorts of challenges here and so we we definitely see that as being a barrier to creating the type of collaboration people want. One thing I have to say about Terraform specifically that was brilliant is that they used a plugin model so that they didn't have a lot of collaboration challenges across their plugins and one of the things that made Terraform just so amazingly powerful is that the Amazon cloud provider Amazon doesn't have to collaborate with Google to do their right so Hashi Corp has been the neutral piece with the tool and then the plugins don't require collaboration except within an individual team and and that actually is part of the the benefits of how those product that that specific project gained so much momentum because it didn't require the collaboration and this is why I think that your point and bringing up the question about collaboration is so essential here because the things that work really well are understanding what parts of the project the codebase you can have collaboration around and how those are going to work and it actually might be one of the things that makes an open TF project very hard to do because the people fostering that project actually might quickly figure out that they can't collaborate around certain parts of the around the codebase because they each have different needs for it but you know that is what makes a project successful in short is getting the stakeholders who are going to drive and invest in the in the codebase to be able to have a way to agree and share what those priorities are and that is literally the life or death of any of these open source projects is how well they collaborate right one of the things that makes Linux work is Linux is that arbitrator and helps drive forward how all those things work and you know we often talk about that I think people consistently forget how hard collaboration is and on the flip side of it what we see with rack n is they also forget how strong the ROI is on collaboration so you know when we see teams collaborating when building the infrastructure to do that type of collaboration the ROI on the collaborative codebase is actually significantly higher than an ROI on a single owner codebase and that's part of the magic of being able to make it work but it's not free. I mean I am a big proponent of open source but the fact is this is also the reality we live in the word of appropriate open source codebase I would love to see more and more code open source but the reality is that these kind of things where companies will change your license will continue to happen I feel that maybe we are going through a transition just like the early days of open source and companies are trying to find a balance between SaaS and the old license that were written in for the old word but once again I want to focus on customers that how are you folks at rack and helping your customers so they don't have to worry about these changes which I said I feel will continue to happen. Oh my goodness that's an important question and vendor neutrality is actually a major theme for what we try to do and for how we help our customers and what our customers ask right it's a big part of what they want to be able to do with supply chains and so the simple model for us is to always evaluate the abstraction of the tool or the thing doing the work right Terraform is a provisioner Ansible is a configuror right that those patterns are actually pretty universal and so when when rack and our architecture is based on buying those common dynamics and then making them repeatable across across the board but not so locked in right it's a challenge just abstractions is that you can over define an abstraction and and make it impossible to use right you end up with a least common denominator and so what I would what I would suggest based on our experience with customers is be very very careful and ask hard questions about if you are using and you need to be using a abstraction to protect yourself from these changes because they're that you're right they do keep coming you need to make sure that that abstraction is flexible enough that it doesn't become a least common denominator thing you should always be asking 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 and that ultimately is the big question here right that insulates you from these types of changes is you need an abstraction and then the abstraction has to be leaky enough that you can always go back into what's under that abstraction and fully leverage it because a least common denominator abstraction like we've tried to do with cloud before terraform over and over and over again those least common denominator abstractions really fall apart very quickly and that's fundamental to rack ends architecture is this this sort of recognition that complexity is not something you can remove from systems we actually embrace complexity and so at the core of everything reckon is built is this idea that we have really strong abstractions and those abstractions are very easy to break through and then set the machines that are at the base so the abstractions are helpful from a control perspective but they're very weak from an exposure perspective and that balance has been essential to making rack end able to control literally any type of infrastructure on the planet but it takes a lot of deliberate design and I think that you know even for people you know who aren't racking customers who are listening to this problem that this discussion can come back and look at the abstractions that they've been building think about how how much it's you know limiting them and find abstractions that are better and if you're missing abstractions and you're you're panicking because you know all these changes to open source projects you depended on are now exposing you know brittleness in your infrastructure the first thing to do is to actually build those abstractions up and we're always happy to talk to people and show people what we've been doing and we're very proud of the platform called digital rebar that we've built that enables companies to create that type of abstraction and have supply chain independence and control even as they have very dynamic infrastructure and I just want to hear from you that are you worried about these changes or you feel that yes this is just a transition phase and think we'll settle down or you think that companies are being pushed to a corner do you sass and we will see more and more of this we may when they turn to proprietary source software what are your thoughts on this I am worried in that I think that we we have to reset what we expect open source to be and I think that you know we open open source is a amazing place for certain types of systems where that you have a shared interest in a collaborative environment to really grow and improve and I think that there are places where those are those are very powerful forces I think that we we see a lot of companies who are seeing open sources free software and they end up building their own custom bespoke versions of you know systems because they're trying to take advantage of free products and right everything we've done we've come back to this idea of collaboration collaboration collaboration right and so there's I do think there's some warning signs that people look at free software or open software is free and then they make a copy and they forget to collaborate what is your expectation from open source actually if you are using open source software you should be thinking through how am I collaborating with the community around that software and and collaboration might be I've paid a vendor to you know standardize and be my voice but you know that's that's an important thing with people they need to be looking at open sources as a point of collaboration and getting the benefit of collaboration and that's that is really the way we need to think about it I do I do believe right now there's a lot of people who who hear open or hear open and think free and then including vendors who've taken you know we're talking about HashiCorp who've taken a lot of HashiCorp products but HashiCorp thinks of as products what they published as projects and then embedded those projects into their business model without without antecedent you know maybe maybe not worrying about when when that collaboration tax would come to Rob thank you so much for a very pragmatic and once again the focus is on customer discussion to to also realize that this is the new reality but the more important thing is how do we help customers navigate through some of these challenges thanks for all those insights and as usual I would love to chat with you again soon thank you I'm looking forward to it Swat thank you