The Changelog: Software Development, Open Source - OpenTF for an open Terraform (Interview)

Episode Date: September 6, 2023

This week we're talking about the launch of OpenTF and what it's going to take to successfully fork HashiCorp's Terraform. We're joined by Josh Padnick to discuss what exactly happened, how HashiCorp's license change changes things, who has been impacted by this change, and ultimately what they are doing about it.

This week on The Change Law, we're talking about the launch of OpenTF and what it's going to take to successfully fork HashiCorp's Terraform. We're joined by Josh Padnick to discuss what exactly happened, how HashiCorp's license change changes things, who has been impacted by this change, and ultimately what they're doing about it. Here's an update to bring everyone listening to this up to speed. Four weeks ago, HashiCorp switched Terraform from an open source license to the business source license, also known as the BSL. Three weeks ago, OpenTF released the OpenTF manifesto asking HashiCorp to switch back to an open source license. Two weeks ago, with no response from HashiCorp,

OpenTF created a private fork of Terraform with plans to make it public in a few weeks. And today, as of this morning, the OpenTF fork is now available on GitHub as they prep for the first alpha release. A massive thank you to our friends and our partners at Fastly and Fly. This podcast got to you fast because Fastly, they are super fast all over the world. Check them out at fastly and Fly. This podcast got to you fast because Fastly, they are super fast all over the world.

Check them out at Fastly.com. And Fly helps us put our app and our database close to our users all over the world with no ops. Check them out at Fly.io. What's up friends i'm here with one of our sponsors over at tailscale jamie tanner part of the devrel team jeremy one of the things that i used to do a lot in my home lab is i would set static ip addresses for particular devices so i could easily remember them, mainly so I can access them via SSH or via the web if the service has a web interface. But because I install Tailscale on every machine now, I don't need to do that anymore. Number one, I was able to get a short, memorable Tailnet name. And then two, each device gets assigned a machine name

based on the host name of that machine when Tailscale is initialized. And between those two features, I no longer have to remember or care about specific local IP addresses anymore. I just let DHCP do its thing and Tailscale does the rest. Yeah, you'd mentioned the enjoyment of not having to worry about IP addresses. Usually when you plug in and DHCP gives you an IP address in the range that it thinks appropriate for that particular network, that becomes a much bigger problem when you mail a machine somewhere,

when you connect from somewhere else. But having that stable, both the Tailscale IP address and the domain name and being able to get to a machine by its host name doesn't change for the network that it's on. That's somewhat rare. I mean, like prior to Tailscale, I had not had that experience. It was always having something send you a heartbeat back or fishing for it. Or if it's sitting out there behind NAT, trying to cook up a way to find that machine the first time when it comes up.

Yes, indeed. What a cool feature. I love Tailscale. I hope you listeners will check it out if you run your own home lab or you have some influence over the networking that you all do with your applications. There's so much more you can do with Tailscale at the enterprise level. Of course, we're just talking about basic home features, but these are building blocks to the magic that is Tailscale and Tailnets and all the fun stuff they enable for you and your applications, your home lab, wherever. Tailscale is awesome.

Check them out. You can do so at changelog.com slash Tailscale. Again, changelog.com slash Tailscale. That's T-A-I-L-S-C-A-L-E. Enjoy. Okay, we are joined by Josh Padnick, one member of the OpenTF. That stands for Terraform. Josh, welcome to the Change Log. Yeah, it's great to be here.

So y'all dropped a manifesto a few weeks back. Now you've dropped a fork. Lots going on in the land of Terraform. And I should say that this episode was requested by a member of Open TF, Malcolm Matalka. Shout out to Malcolm, who said you, Josh, would be a great person to talk about this topic. That being said, we're on this already. We're thinking, yeah, we got to do a show on this. It's a big conversation. And so we didn't necessarily need the nudge, but the nudge did help us find you, Josh. So shout out to Malcolm and happy to have you here.

So let's get rocking and rolling here. As I said, TF stands for Terraform. Terraform, previously open source, now business source, as HashiCorp changed the license from the Mozilla public license to a business source license earlier in August. And this caused quite the stir amongst many people and many organizations, including your own, Josh. Can you tell your side of the story, how you found out about the change in licensing, the change in shift from HashiCorp and what you all thought about it? Yeah. So one day we got this announcement that HashiCorp was making this license change and we had to start thinking about what the implications of that were. And essentially the license change said that you can continue to use Terraform and their other commercial tools in production use, as long as you, A, don't compete with HashiCorp, and B, if you do compete with HashiCorp, you can't embed or host their software. And their official line was, look, this doesn't affect most people. 99% of Terraform users are unaffected. This only affects those small number of companies that are out there actually

hosting Terraform and not contributing back to the ecosystem. And what was frustrating about that announcement is, so I'm the co-founder and chief product officer of Gruntwork. And we've contributed an enormous amount to the Terraform ecosystem. And we've produced Terragrunt and my co-founder wrote the book Terraform Up and Running. We've published all these blog posts. And so when this announcement was made, it immediately introduced uncertainty about whether we would be compliant with the license. And I can keep going with the story, but ultimately we figured out what some of the challenges with that license were. And then we reached out to some friendly competitors and we decided to band together to do something about it. If we could back up even a little bit more and talk about Terraform

itself, could you tell our audience and ourselves, maybe those of us not as DevOps-y as you are, Josh, and your company, what's so great about Terraform? Why is it powerful? Why does it have a huge community? I mean, this thing is kind of a bedrock for a lot of people's work. Can you talk about it as a project? Yeah. So Terraform came out in 2014, and it was designed to be a better way to describe what infrastructure you wanted, like on AWS or GCP or other clouds.

And to do all that is code. And it really took off because it filled an important need. It wasn't specific to one cloud vendor the way CloudFormation is for AWS. And there's one for GCP, but I forget the name. And they even created a new language called HashCorp Config Language or HCL, which was quite elegant to use. The Terraform binary experience was great. It included this ability to do a plan to say, hey, before you do what you're going to do, show me what you plan to do. And it really spawned a new era in many ways of infrastructure as code because it was open source. It was popular. It was a great user experience compared to the alternatives.

There was a growing ecosystem around it. And now really for the first time, there was a kind of a mechanism for how you could write best practices, infrastructure, and codify it in these Terraform modules, and then share them within your company or from a consulting company to other customers or as like a pre-built library product. Yeah. So it was definitely a paradigm shift when it came out and continues to be, I would say, without question, the most popular tool for deploying infrastructure in the cloud these days. Do you think if Terraform would have been business source licensed from the day one in 2014, that it would be where it is today? How much do you think would be different?

Yeah, I mean, absolutely not. When we pick a technology in its infancy, you are making an investment choice. It's almost like picking a stock. Like when I think personally about how many thousands of hours of my career have been invested in Terraform. It's like I made this investment to learn it back in 2014, 2015, and that investment has paid off well. And I'm really happy I made that investment. If at the time Terraform had been a business source license, I would have said, well, wait a minute, no one's going to use this because everything has to be through HashiCorp. So I'm just going to invest elsewhere and other technologies. So, and I'm guessing most people would have thought similarly. There's actually an interesting parallel. It's not an exact analogy, but HashiCorp released a policy as code language called Sentinel a few years ago. And the technology was

quite well done. It was well documented. It was really exciting when it came out, but it was not open source. In fact, it wasn't even usable like or accessible without purchasing like Terraform cloud or Terraform enterprise. Somehow you had to pay money to get it. And so it never took off. Then an alternative open policy agent or OPA came on the scene. I don't have a personal opinion on that, but which technically is better or worse, but it's just a fact that OPA has become the dominant policies code standard. It's open source. And in fact, even Hosh Corp's own Terraform Cloud product has what they call a run task, which includes like a support for OPA. You're getting worked up over there, Josh. Who let the dogs out, man? Yeah, I was like, hopefully you don't need the dogs in the background.

All right, well, I'm going to cash in a pause token. All right, let's take a pause. When you look at the project though, right? Like it's been open source since the beginning, but it's always had this core module right like there's been this core and then every infrastructure usage of it has a plug-in for what i understand like so there's the core thing and then there's an aws plug-in there's a azure plug-in there's a you know pick your infrastructure plug-in at the core that hasn't hashi corp always controlled core even from a contributor level, one?

And then two, I guess, what's the big deal about it being business source license? Why does that matter now? And why would you have not chosen before? Is it simply because all control goes back to HashiCorp and I'm going to revert back to point one, which is then they already control core and control contributors and kind of control, even if it was open source, that, you know, they control contribution, which is kind of like, it still licenses open source, but they control the direction of it. Yeah. So HashiCorp is the originator of the Terraform project and they were the controllers of it.

There were literally pull requests that have sat unmerged for years because it didn't meet the business interests of HushCorp. And the classic example there is encrypting Terraform state files. That's a natural kind of upsell thing that I think HushCorp probably wanted to put into their paid version of Terraform. And so they chose not to merge that into the open source version. And it was a very frustrating community experience. You can find the pull requests and it was like all these like, hey, is anyone ever going to do anything with this PR? So they created this project. They have every right to control it. The challenge was that it was presented as being under an MPL v2 license.

And I think we all assumed, well, it began as an MPL v2 open source license. It will always be an MPL v2 open source license. So people accepted that HashaCorp controlled that tool, but there was a increasingly thriving ecosystem of tooling built on top of that. The main issue with the license change is number one, it's a rug pull. None of us were expecting that. We would not. And when I say us, I mean, people in this ecosystem who had built tooling with Terraform. And as a result of the rug pull, we were caught off guard and we didn't know whether we were in compliance or whether we were welcome or not welcome. And so that actually leads me into the problems with the license when we had

some time to think about it. So the first problem is that it was vague. They used the word, they said, you can't compete with HashCorp. Okay. So what does it mean to compete? You can't embed Terraform. What does it mean to embed? You can't host it. Okay, what does it mean to host? And then it was kind of weird because they're using a generic business source license, pejoratively called the so-called BS license. there that are unique to Terraform. Everything else is generic. And it's those two lines that say, hey, the only production use that you can make of this is if you're not competing with HashiCorp and you don't host or embed Terraform. So then, of course, everyone was in the same boat. Are we competing with HashiCorp? If we're competing in one product line, but not another, does that constitute competing? What if we compete in the future? What if we were competing, but we no longer compete? And so then HushCorp began this discussion forum thread where people were asking all these questions and they answered all these questions.

And then they also produced an FAQ. And then the FAQ, they even said, this is binding. Like you can treat this as legally significant as you interpret the license so the real license is not just the business source license it's actually the business source license plus the faq which gets updated from time to time and so that's the second problem it's this license is dynamic what the interpretation of these meet of these terms could be can change depending on how that FAQ gets updated. And then whether you're competing with Hasha Corp can change depending on what your business is doing or what their business is doing. And then they even had to clarify, well, no, no, no. If

you're not competing with us today, then you're greenlit to use this now. And if we compete with you in the future, then your historical usage is okay. Well, the problem with that is the third problem. It's subjective. So who decides whether you're competing today or not competing today? And ultimately what it all boils down to when you really think through the dynamic

is you have to get HashCorp's permission to do anything. If there's even a hint of ambiguity, the only realistic way to proceed as a business is to get their official sign off to say, yes, what you were doing is okay, or what you were doing will require a license and here's what it will cost. So then if you play that thought out, then it's like, okay, from a business perspective, what is my world as a member of the Terraform ecosystem look like? I now need to think about when I'm choosing to invest in this tool, Terraform, and offer

services on top of it, what happens if Hasha Corp changes their mind in the future? What happens if they decide, no, no, no, we are competing. What happens if we license Terraform from them, but they decide they want to increase the price? What happens if they have new owners and the new owners have a different interpretation of that FAQ? And if you think about presenting those scenarios to an investor or to an acquirer,

those are non-starters for any startup. Like it's this huge amount of risk that you'd have to be taking on. And the only practical way to eliminate that risk is to get Hasha Corp's official sign-off. Which brings me to the final conclusion of this thought process, which is that I personally do not want to be an active participant in an ecosystem where everything I do needs to be blessed by one party. And if they don't bless it, then I'm basically screwed and out of business. I'm not interested in participating in that type of dynamic. And as

we found with the OpenTF initiative, there are thousands of people who are also not interested in participating in that type of dynamic either. Would you consider Gruntwork a competitor to HashiCorp? You know, that is such an interesting question because we were like coopetition for a while. On the one hand, Gruntwork probably did more to promote Terraform than almost any other company other than HashiCorp. I mean, that feels hyperbolic when I say that, but we published all these blog posts. We wrote TerraTests, the official, or I guess not official, the most popular testing framework for Terraform. We created Terragrunt, which is a way to use Terraform at scale, also open source and sits on top of Terraform. Like I said earlier, my co-founder,

he wrote the book Terraform Up and Running. Our whole business model is working with teams who want to adopt Terraform and giving them best practices and getting them up and running with all the things that they need to do. We call it DevOps foundations. So in that sense, we were in every way supporting Terraform. But what was interesting about all of that is because we wrote Terragrunt and because we felt Terragrunt was the better way to launch your infrastructure and to manage it. It's not obvious when you start, but when you start to think through like, eh, how do I manage the blast radius? And what do I do about global variables? And how do I set module default values? And how should I organize my folder structure?

That's where Terragrunt starts to become useful. So we did almost no marketing of it. It took off as a project. And the problem with Terragrant from HushCorp's perspective is you can't use their commercial products with Terragrant. So Terraform Cloud and Terraform Enterprise, they don't support Terragrant. So this really strange dynamic emerged where if a customer made the decision to adopt Terragrant, they immediately opted out of using Terraform Cloud or Terraform Enterprise. And therefore, our humble open source tool, which we really have not done much to monetize in all candor, was now considered a competitor by HashaCorp sales team to Terraform Cloud and Terraform Enterprise. And so in any of our discussions with Hasha Corp, it basically came out that we were viewed as a competitor to that.

So did it cross your mind or did you have a thought of like, well, what if we just do what they want and just negotiate a licensing fee or something? Or was that just off the table because of the principles? It certainly crossed our mind. But again, I just was imagining this annual ritual where we approach Hasha Corp on bended knee, we kiss the ring and we beg for favorable licensing terms. And if that is the state that we are in as a business, then we are

not an independent business. We are operating at Hasha Corp's leisure with their permission. And they have total leverage in such a negotiation because if they choose to say, you know, we've been thinking, we don't really like what Gruntwork's doing, so no license for you, like our entire business goes away overnight. So I don't think we could responsibly engage them. And I also think it's lousy for customers too. Like we are now at the mercy of whatever HashaCorp decides to do, whether or not we think that's

in the best interest of customers. And so we have to toe the line in every way. And I would just rather not contribute our value to the world of equipping teams with DevOps best practices on AWS with HashaCorp's permission. I'd rather do what we think is best according to our own judgment

and not with their permission. That all makes complete sense to me, Josh. What's curious about that is you are equipping people on AWS, which to me, isn't that a similar relationship, you to AWS? You know, it's an interesting point. I guess with AWS, we're purely additive.

Like from their perspective, if they're selling compute and storage and maybe now AI time or whatever, whatever else their primitives are, like they're happy. They don't care if it comes through cloud formation, through Terraform, through grunt work for some consulting company. And so I think from the perspective of AWS, like our mission as a company is basically to make it easier to get up and running on AWS as either a startup or an enterprise. It's really hard to do. So I feel like we're a pretty positive influence on the AWS ecosystem. And there's really nothing we're competing with. Like we're not offering our own cloud compute in competition with AWS, but we do maybe offer alternative ways

of configuring AWS than maybe AWS themselves does. This Terragrunt, if I understand clearly, this is something you all put out there. It's open source. Your business relies upon it as how you institute services for clients, but you don't sell it by nature. So you're not monetizing the code, you're monetizing the people, hours behind the scenes

to install an instrument, whatever it might be, to put in place. And cloud, Terraform cloud, an enterprise does not support it. Do they have a competing proprietary plugin that is only sold and only licensed? What's the scenario?

Yeah, so Terragrant is focused, like I said, on helping people use Terraform at scale. And there are companies out there that offer a pipeline solution on top of Terragrant. We ourselves have a lightweight pipeline solution. It is a pretty good one in our opinion, but it's not like the primary thing that our company is pre, but then there's some sort of platform that you can purchase to log into to kind of manage usage of that tool in a more robust way. We offer more of a framework. So like our Terragrunt solution is basically a really nicely packaged set of GitHub actions that we help to keep updated so that you can easily run Terragrunt as part of a GitHub Actions pipeline

and we'll support other CI systems in the future. And then in addition, we do support, we do offer Terragrunt support to a bunch of customers. Often, like we have some huge customers using Terragrunt and they've got thousands of engineers and they need to do some crazy things. And so we work with them to make sure they're supported and to add the features that they need

and things like that. But yeah, by contrast, I would say Terraform, the open source tool is more the like going from a core open source tool to a platform with Terraform Cloud. Like Terraform Cloud is essentially running Terraform as a pipeline. And same thing with MZero, Scalar, Spacelift, Terra Team, and Digger.

Like, these are the competitors that Hasha Corp was essentially targeting when they came out with this license change. Because they were basically saying, Hasha Corp was saying to themselves, hey, we the ones who who produce this terraform tool we're paying all the costs for the ecos for like the the core infrastructure and for the tool itself and here are these companies out here profiting from it and some of them doing quite well and honestly the uncomfortable truth that's kind of come out in the course of this whole license change debacle is that terraform Cloud just isn't as competitive with some of the alternatives out there. And so one of the key philosophical decisions that Hushpro had to make was, A, do we change that by making a better product, maybe by somehow leveraging our unique competitive, like our unique position in the Terraform ecosystem?

Or we, do we cut our competitors off at the knees? And personally, like with Terragrunt, we have other companies who are technically our competitors, but who are now our fellow OpenTF consortium members who profit off of Terragrunt and who technically, you know, compete with us. But I don't really worry about them. I'm just focused on making sure we're providing a good product to our customers and a good experience. And if they're able to profit, then that's great. The Hasha Corp's perspective is different. They're saying, hey, it's not fair that those other companies are profiting off our hard work. And rather than leveraging that unique position in the ecosystem as the creator of the tool that everyone's using, they're just disabling competitors outright.

So that's why it's kind of an offensive action, honestly, and not in the spirit of the open source license under which it was originally released and surprising. And I think that's why it's caused so much outrage, I guess, I mean, among so many different people. Outrage feels like a strong term. I don't want to use hyperbole or anything like that. But yeah, I mean, people are angry about this one I've seen. Like we get those comments, we get those emails, we've seen those pull requests. And I think that's why. Like this was not in the spirit of open source it's not the foundations or underpinnings that you need for a rich community and that's why we felt there was a a need for a different path forward

with open tf in particular So I'm here with Ian Withrow, VP of Product Management at Sentry. So Ian, you've got a developer-first application monitoring platform. It shows you what's slowed down to the line of code. That's very developer-friendly and is making performance monitoring actionable. What are you all doing that's new? What's novel there? Traditionally in errors, what's the strength of Sentry is we've taken not a stream of errors and said,

hey, go look at this, like all these error codes are flowing into SEDS. We actually look at them, we try and fingerprint them and say, hey, we've actually grouped all these things. And then we give you everything you need within Sentry to go and solve that error and close that out. And that's, I think, driven tons of value for our users. And traditionally, if you look at performance, it's not that thing. It's looking at certain golden signals, setting up lots of alerts,

maintaining those alerts, grooming those alerts, and then detecting them. And then maybe you have a war room and you try and look at traces, or maybe you realize, oh, it's this engineering team that owns it. And maybe they'll look at logs, whatever they have available. Performance is very rotated on detection and then isolating to where the problem may exist. And root causing is often an exercise left to the user. Good performance products provide a lot of context and details that an experienced engineer or DevOps professional can kind of parse and make sense of and try and get to a hypothesis of what went wrong. But it's not like

that century error experience where it's like here's the stack trace here's all the tags oh we see it's like this particular set segment of code and ian did the commit that changed that code and do you want to fire your issue and assign it to ian like it's not like that crisp kind of tight workflow that we have errors this is breadcrumbs right and we said hey maybe there's no reason why we could do this for performance. Let's try. Okay. So you took a swing. You tried. Describe to me how that trial works. If I go to my dashboard now and I enable APM on my application, what are the steps? Largely because we kind of encourage you to go and set up transaction information when you set up Sentry. You probably,

as a user, probably don't need to do much. But if you skip that step, you do need to configure to send that data in your SDK. And what happens is we start now looking at that information. And then when we see what we call a performance issue, we fingerprint that and we put that into your issues feed, which is already where you're looking for error issues. Right. It's not a separate inbox. This is the same inbox.

The same inbox. Yeah. Now, we obviously give logical filters. And if you just want to look at those, we do that. And for newer users, sometimes we detect, hey, you've probably never seen this before. We do things because we know we build for mass market that bring your attention to it. But it's the same workflow you have for errors today. So you don't have to learn something new to take advantage of these things. So you asked the experience. So last fall, we did the experiment, the first one, which we called M plus one. And we didn't know how it was go, honestly. But people liked it. Like we kind of know people like it when they start tweeting and saying nice things about it. And so, yeah, it got traction. Very cool.

So if your team is looking for a developer first APM tool to use, check out Sentry. Use our code to get six months of the team plan for free. Use the code changelogmedia. Yes, changelogmedia. Six months free of the team plan. Check them out at Sentry.io. Again, Sentry.io. That's S-E-N-T-R-Y dot I-O. well as i said on changelog news when we talked about the fork i said that this, in my opinion, this action, action and reaction is an example of the

open source community doing what it does best is rallying support behind an open source tool that has a ton of value. And sure, maybe there's some outrage, maybe there's some backlash, people getting angry and hand wringing, but, but there's hand-wringing and then there's like hand-raising. Oh, that was a nice turn of phrase. I didn't even mean to. And you can actually, you can talk and complain or, and, or you can step up and do something about it. And forking and maintaining a fork of terraform is no small matter.

Is it, Josh? I mean, this is people putting a stake in the ground because supporting this, a project of this size, we're talking to serious efforts, aren't we? Yeah, that's a really excellent point. In fact, that has probably been the biggest objection that we've heard in the community is, Hey, Terraform is huge. Hasha Corp is huge. How can a ragtag team of different companies possibly have enough resources to really deliver here? And what's so interesting about that is if you actually look at the GitHub contributor history for Terraform core, or maybe the GitHub contributor history for the Terraform

AWS provider, which happens to be maintained by HashiCorp. Most Terraform providers, so like what you guys were calling plugins earlier, the technical term for that in the Terraform world is provider. Most Terraform providers are- Sorry about that. Oh, I saw an opportunity to be pedantic. Hey, I called it that because Dave, the CEO called it plugins. Oh, really? Okay. So I was just following suit. So the CEO, current CEO of HashiCorp was calling them plugins.

So I'm like, okay, I'll follow suit. I didn't know they were called providers. Yeah. Well, see, business guy is CEO. That's what happens. We'll get to the weeds there. We're not there yet, but we'll get there. So HashiCorp, if you look at the GitHub contributor history of Terraform Core

and let's say the Terraform AWS provider, as best we can tell, there are anywhere from six to 10 people contributing who are employed by HashiCorp, which is not to say they're necessarily full time on it. I'm just stating the fact that I observe of the number of humans contributing to these two assets. The OpenTF community, as of now, has already committed to 19 full-time employees working on just Terraform core alone. And so this could represent as little as twice the resources that our understanding is that AshCorp is currently allocated to what we would call Hashi Terraform, or it could be even more than that, like three times. And not only that, but this is an opportunity to go from being a single vendor-led project, which is primarily there to serve the interests of that vendor, to a community-driven project whose improvements will

be driven not by any one vendor, but by a consortium of vendors. And that's essentially what OpenTF is. It's really a consortium of vendors who candidly are all competing with each other, but have come together to create this underpinning, this foundation of a community and a tool that we can all use that's truly open source and has an unambiguous license so that we can all compete with each other on a level playing field on fair terms. And then customers can choose whatever they think the best service is out there. But it's a totally different vision from one tool and one vendor like HoshCorp controlling everything, where if you choose that path, that's the ecosystem

you're in. And there aren't other players there. That's the path you're choosing. So that's something we all were passionate about. We've built good products. We have many happy customers. We don't want to just say, oh, we'll, I guess, do whatever HashaCorp tells us. We wanted to live in a world where there's a vibrant foundational piece of infrastructure that we feel good about that we're using, not one that we feel like really sketchy about. So how divergent then do you imagine OpenTF will become from Terraform Hashi

over the next year, two years? Is there a goal to like, because I think compatibility until you have critical mass of adoption on OpenTF, compatibility is probably a big aspect of what you guys are after, right? Yeah, that's a great point. So one of the, there are a few kind of core tenants of our vision. And one of them is of course, a clear, unambiguous open source license. Another one is backward compatibility. And what that specifically means for us is that any bug fixes that are reported either to us or that we see to Terraform we would like to implement fixes for. I should also say it's extremely important to the group

to remain compliant with HoshCorp's license. So we cannot just go to their repo and copy code improvements just because they're available. We are still working with our lawyers to figure out what information can we legally glean from what happens there? And where do we need to just not even look so like legal compliance is something that's really important to us anyway more to your point about compatibility so that's bug fixes then for new features that hashi terraform releases like i just said we cannot just copy their implementation yeah but our understanding is that we can copy the interface and we can do our own implementation and make it interface compatible. So to the greatest extent possible, we want to make OpenTF a drop-in replacement

for Hashi Terraform. And then once we feel like we've really achieved that expectation where people feel like, hey, this project is pretty stable. I can use this. I'm happy with it. The other kind of big thread that we have is a community-driven RFC process for whatever improvements people want to see in OpenTF that could never make their way into HoshCorp. So one example would be those encrypted state files, like I mentioned before. So HoshCorp never wanted to merge that PR.

And now this is an opportunity for OpenTF to figure out the right way to do encryption on state files, what all the potential pitfalls could be, go through a proper RFC process, get that merged. And now it's a superset of what HashiTF would be. Another example would be better importing from the Go code base. So HashaCorp also made this sort of pivotal decision a while ago to lock down a lot of the internal libraries of Terraform under a specific package in Go so that they were difficult to access. And that meant that you couldn't really use Terraform as a library. You could really only use it as a CLI tool. And for those of us who are

building things like pipeline solutions that operate Terraform or Terragrunt or whatever, we have to go through this awkwardness of using the CLI tool when what we'd really like to do is just access the Go library directly. Another example would be downloading providers from any registry. So right now, HashiCorp forces you to downloading providers from any registry. So right now, HashiCorp forces you to download providers from their registry. And if you've written a custom provider, like maybe you've got some custom API, and you want people to be able to write Terraform code for your custom thing, this understanding I need to check. But my understanding is that you can't host that provider except with HashiCorp's paid services. I might be wrong on

that. So definitely need to check on that. But in either case, with a community driven process, we can now allow users to download their providers from any registry. In fact, someone even released from our consortium, released a proof of concept video just a couple of days ago showing how they were able to download Terraform providers from like Docker Hub or ECR or GitHub container registry. So our first priority is compatibility so that you could just do a drop-in replacement for Hashi Terraform. But once we feel like we've really met that expectation, then we want to start focusing on our own set of innovations around this community-driven RFC process. It's got to take a lot to support this

project, right? It's got an IPO company behind it. I'm sure they got tons of engineers working on this. What will it take in your eyes to support this, to carry forth that vision and the compatibility side and obviously the innovation side? What's it going to take? Yeah. I mean, it's a really good question and it just takes people and focus and determination. Like I was saying earlier, if you look at Oshcorp as a big IPO company, putting lots of resources into Terraform, that sounds something that maybe couldn't be replicated. If you look at the reality that there's like eight to 10 or maybe six to 10 humans at HashiCorp actually

maintaining stuff, you know, unless my data is off, but that's what we've seen. Is that just, where's that data? Is that just code contributions or what are you looking at? Yeah. So if you go to the like github.com slash HashiCorp slash Terraform, and you look at the contributors for the last two years. There's of course, hundreds of contributors, but if you look at people who've actually done like a lot of contributors, there's like four people that have done the bulk of them. And if you do the same exercise for the Terraform AWS provider, GitHub repo, it's again, like four people. And even then two of whom are mostly leading the effort and then two of whom are contributing a lot less.

So I'm not privy to Hasha Corp's internal staffing strategy. But yeah, I mean, that's like I said, six to 10 people. And we've got double that or triple that, depending on which end of the range you're at, focused on just the Terraform core piece. So, and not only that, but like, these are, this is a group of vendors whose existence depends on the success of OpenTF. So you can imagine the level of motivation at making this a fantastic project that is the best way to use, you know, what used to be called Terraform. We've put an enormous amount of thinking into the right way to do things. And in fact, we were very deliberate in not releasing a early unpolished version of a fork. So you'll notice there is no fork available right now.

There is one internally that we've been working on. That's where all these demos that we've been publishing are coming from. But we haven't released it to the public because we want people to have a good experience with it. So there's product thinking, there's explicit commitments to full-time employees on the OpenTF manifesto that people have contributed. And most importantly, there's determination to see it through and make it succeed and capture the opportunity to actually make Terraform,

or what we're now calling OpenTF, youTF, much better than it ever could have been under a single vendor. It's one thing to be able to support the fork and the co-contribution to make it work. The obvious second part of that is adoption. Just like any open source project, you have to have people willing to use it. Clearly, you've got some upset people out there about the license change and that's going to bring in at least some on the initial stint where there's a lot of, in quotes, drama happening or just a lot of potential outrage and they want a viable open alternative.

But what about the adoption at the provider level? Like, for example, you mentioned uh hashi terraform being the core being compliant with that and then providers like aws for example and mentioning the contributors there what will it take to keep those providers in sync will you have to fork those providers too or will you just provide updates to those providers because they're probably potentially open. Some of them are open. How does that look from the footprint

of what you really have to manage from an adoption and keeping update that's not core? Yeah, that's an excellent question. And in fact, HashaCorp, by the way, I hate focusing so much on HashaCorp because what we're really interested in is creating the best possible open TF. And it would be lovely if HashiCorp succeeds as a company, like there's no vendetta

or negative anything against them. You know, they're trying to meet their business needs. We're trying to meet ours and we're focused on our vision, not on tearing down another company. That being said, all of these questions come back to, well, Hasha Corp did a thing that we now have to react to. So now I will answer your question. Okay. So Hasha Corp maintains something called the Terraform Registry, and it historically has hosted Terraform providers and Terraform modules. I think it also hosts policies and one other thing. And they just announced earlier today, I don't know if they announced it,

but they updated the terms of service and some folks in OpenTF pointed it out that only the Terraform binary can access the Terraform registry managed by HashaCorp. And so what they're trying to do is say, if you're using OpenTF, you can't use the Terraform registry. And what's so interesting about that is it is mostly, in my opinion, designed to create noise and confusion. Because if you look at the technical details of what's happening with the provider registry, or the Terraform registry, first, let's take a look at

providers. It turns out that if HashaCorp is hosting a non-HashaCorp maintained Terraform registry. First, let's take a look at providers. It turns out that if HashaCorp is hosting a non-HashaCorp maintained Terraform provider, like Azure, I think is not maintained by HashaCorp, then that is actually downloaded from Terraform through GitHub rather. So like you connect to the registry, they do a 301 redirect and they send you to GitHub. And you're literally just downloading a binary that is a GitHub release asset. It's just that you have to be going through the Terraform, HashaCorp Terraform registry to do that. So the only real impact that this announcement has is that you can't download a provider that's managed by HashaCorp directly, like the Terraform AWS provider. And there's a trivially easy solution to work around that, which is OpenTF will put up some kind of mirror registry that hosts their MPL licensed and go release assets. And then you just download it from there. So it's like trivial technical workarounds, but it just creates

noise. And then for Terraform modules, that's also just a HTTP 301 redirect to GitHub. And the language that they have in the terms of service update is very aggressive. Like you can't copy this content, you can't do anything, even though they are not even the owners of the content in many cases, like they host modules or providers created by others that are just made available for there. So I found that to be disingenuous. And on the OpenTF side, we will take our resources and we will create a parallel registry that hopefully has a better UX and works just fine with OpenTF and will probably work just fine for Terraform as well. So, you know, we'll play the game. It's a stupid game, but I guess we'll have to play it. These are not technically hard things to do. But yeah, that's just sort of the situation we find ourselves in. What about adoption though? Like how do you capture similar mindshare and desire for support of OpenTF that Terraform currently obviously has? Well, at least in the current, currently, like more recent currently, it may be a sliding scale at this point. Yeah, it used to happen. Yeah. So first of all, we've seen amazing levels of support, like far beyond what we expected.

You know, at this point, the OpenTF manifesto repo has, I think, 25,000 GitHub stars. And the HashaCorp Terraform repo has 38,000 GitHub stars. And we have existed for less than three weeks. You said 25,000 stars? 25,000 GitHub stars. Yeah. That's a lot of stars. For our manifesto.

Yeah. And you know, a star is a star. It's an indicator of some sort, right? Exactly. Like people care about this. And we actually were about to sign a large enterprise customer at Gruntwork. And when this BS license news came out,

they put the sales contract on hold. And they said, hold on, we need to figure out what this means for us. And they said, hold on, we need to figure out what this means for us. And they came back to us a week later after the OpenTF manifesto had been out and they saw the support for the companies. And I remember one customer in particular saying, all right, so basically we stay on Terraform 1.5.5 for a little bit. So that's the most recently, that's the last version of Terraform that is MPL licensed, and you can still use that without any limitations. And then going forward, it sounds like OpenTF will

be the better project anyway. So I've seen that reaction from multiple run or customers. I've seen that from customers of our competitors that have shared that in the OpenTF kind of internal Slack workspace. And we've seen that on Twitter, or I guess it's called X now. So I think at the end of the day, this is a battle for hearts and minds. And when you're choosing a technology, you're not only choosing the specific features that are implemented or the specific brand of the company that implemented it, you're opting into a whole ecosystem. And we firmly believe, and not only that, you're also opting into a license position.

So there are many companies that we found that are structured where they have internal teams that are technically selling their DevOps modules or their Terraform practices to other internal teams? And is that considered competitive? I think in HashiCorp's FAQ, they directly address that and they say, no, no, that's not. But again, you still have that ambiguity and that subjectivity. So for companies that are nervous about being in violation of their license, one of the things that OpenTF offers is clear, unambiguous license compliance. Like there's just no question about it.

You don't have to have a meeting to see if you can use it. And then the second thing that we think makes OpenTF a lot more competitive is the ecosystem. If you look at the number of companies that have signed that manifesto, which stands at like 110 at this point, it is kind of a who's who of companies and projects in the Terraform ecosystem. And personally, if I were, let's say, a CTO of a startup and I was choosing my infrastructure strategy, I would want to choose the tool that has support from 100 different companies. So if I don't like one of the companies I'm working with, I could just go to another company. Whereas if you choose the HashiPath at this point, you're really locked into Hashi.

And I'm sorry to say, and again, I'm not here to bash them, but the whole reason this debacle began in the first place was because their Terraform cloud and Terraform enterprise tool was just not that competitive with the alternatives. So it's like, in a way you're locking into the very ecosystem or to this monopoly, which only exists because it wasn't serving customers well in the first place. So those are just some arguments, but just to pad the list, OpenTF is also in the process of joining the Linux Foundation. We also plan to be a member of the Cloud Native Computing Foundation, the same foundation that governs Kubernetes. Like I've said earlier, we expect to staff the project with around 20 full-time employees.

We're committed to full compatibility with Hashi Terraform to the extent that we can do that. And then, of course, we're committed to the community-driven improvement process with RFCs. So at the end of the day, we don't really care whether we're right or they're right. We want to, of course, conduct ourselves professionally and respectfully. But what we're really focused on more than anything else is offering the best possible packaging and version of OpenTF that we think is just going to be the better tool to choose for the job at the end of the day.

So the initial manifesto prior to this fork was a two-step thing, wasn't it? The very first, your heart's desire was for Hashi Corp to change their position, right? Wasn't that what it said? Like, that's what you guys would prefer to happen. That's right. And if that doesn't happen, then fork away. Is that right? That's exactly right. And because let's face it, a fork is, is a sort of war and war sucks and everyone loses from war, but sometimes wars happen. And so we really did feel like, you know, look, if we can avoid a war, but still get our needs met, that is a better outcome. But if we can't avoid a war, then we're committed to providing the best possible option for customers to have a great experience with what used to be Terraform.

So, and just one other interesting postscript to that. HashiCorp has not even uttered the phrase OpenTF. So they didn't even respond. And of course, that's deliberate. Obviously, they know about it. Well, that was going to be my question was, has there been any conversations between Hashi and anybody from OpenTF? No. Because the time lapse between the manifesto and the fork was pretty short. I mean, we're

talking a couple of weeks, maybe. Yeah. And so I'm thinking over here, like, okay, were you guys serious about them changing? Like, what if they would have said, okay, we'll go back to MPL and sorry, everybody, that was bad. But you guys are probably already had your fork in a private repo and we're getting started on stuff. Well, the threat of a fork had to be credible in order for our request for them to revert, to be meaningful. And so forking was our plan B, but we were prepared for plan B.

And then when their deadline came and went, then it's all systems firing for launching the fork. What if six months down the road, HashiCorp sees the light and they're like, holy cow, OpenTF is legit. Everyone's using it. We're losing market share. This was a big mistake. BSL be gone.

MPL come back. We would like to join the OpenTF initiative. Is there a potential of a merge? You said war at this point, so it doesn't sound like that would be on the table. It is a war of ideas, but not of people. We are pushing OpenTF into the Cloud Native Computing Foundation, where it will be governed by a consortium of vendors. If Hoshpurp wants to participate as one of those vendors,

they would be most welcome to do so in accordance with all the governance processes there. So there is no bad blood there. Do I think that's going to happen? No. What about a merge? What about a merge? You know, come back just one Terraform path forward.

Could there be a merge? Or is that also a step too far? You know, in theory that could happen, but in practice, I know that there are people internal to Hasha Corp who lobbied heavily to pursue this direction. And those people need to save face and not say, oh yeah, I guess I was wrong. Sorry about that. So it just human psychology dictates just like Vladimir Putin invading Ukraine for no apparent reason and not being able to come out and say, oh gosh, that was a mistake. Like it's the same thing. You know, they're going to stay the course until there's a clear winner.

Now, that being said, I do think there will eventually be a winner. And I'm feeling pretty good about the OpenTF side, to be honest. A parallel that we've often referenced internally is Jenkins versus Hudson. So I don't know if you guys remember, but when I first came onto the DevOps world, this was like 2012, 2013, 2014, I was looking at CI systems and I discovered Jenkins and I thought like, oh, this is, this is cool for the time. You know, now Jenkins is in a different place, but it was only in like the deep bowels of the documentation that I saw a reference to Hudson. And then I went to the website and I was like, oh, this clearly looks

like the lesser project. And, and then I kind of forgot about it. And only now have I started thinking about the fact that what happened is Oracle bought Hudson or somehow acquired the rights to Hudson and changed it from an open source project to a proprietary project. The community forked it into Jenkins and Jenkins took off and Hudson withered and basically has no relevance today. I don't think it's going to be quite that stark for Asher Corp to reform, but I do contemplate the power of thousands of companies working on a CNCF backed, truly open source version of a key foundational piece of modern infrastructure versus one company's version of that.

And, you know, in the short term, I absolutely expect HushCorp will have some neat feature improvements that aren't going to be an open TF right away. So there will be some growing pains in the beginning, just like with any project. But in the long run, frankly, I'm really excited about the kind of things that we can do that weren't possible before. And I have come to believe that it's ultimately going to prove to be kind of a fatefully bad decision for them. I think there are better ways of solving the problem that they had than cutting off competitors at the knees. And unfortunately, the horse has left the barn at this point. And I guess we'll see how things play out. What's the level of confidence you have in the Linux Foundation

stuff you'd mentioned and the CNCF? Would you have to apply and incubate and graduate or what would the situation be? Linux Foundation is in process right now. As far as I know, that is basically we're just going through the motions administratively.

That was also considered an important stepping stone to getting into the cloud native computing foundation. I'm not personally intimately familiar with the next steps there, but what I've seen from the internal discussions is like, we already are celebrating the win that we're going to be part of the CNCF. So unless there's something I'm not picking up, my understanding is that that's something we would expect at this point to happen. It's not like something we're hoping for. It's like something that's already expected.

What gives you the inclination that that's going to happen? Like with the Linux Foundation being a done deal or in process that the CNCF is obvious or what? Well, with the CNCF in particular, they actually made an announcement that many of their projects rely on Terraform components. And that with a new business source license, that was no longer a tenable position. And they needed to find an alternative set of components. And this cuts to the heart of the licensing issue, right? Vague, subjective, dynamic. Yeah.

You can't have projects that are using a license that's vague, subjective, and dynamic. You want the opposite. You want clear, objective, and static for your licenses. And so I think the CNCF has multiple projects that all rely on Terraform, and they need to figure out a solution to that problem. So it's in their own interest for their existing projects to see OpenTF flourish. In a game of chess, you often think moves ahead, right? And I got to imagine that this may be 40 chess,

who knows what version it might be. But I got to imagine that HashiCorp made some sort of plan and executed that plan. Sometimes when you make plans like that, you think of worst case scenarios and you don't always think through, obviously, all worst case scenarios. you don't always think through obviously all worst case scenarios do you think that your legitimacy and your well formation and all the preparedness you seemingly

have and obviously to some degree we're hearing it from you directly that that's the truth do you think that this is a surprise to them i i do. If you'll notice, there has not been this level of backlash for any of their other products. I've not heard of Open Vault or Open Packer or Open Console or Open Nomad. And I think those are different. They're a different paradigm of thing. Those are basically services. You can put them in a black box and they have an interface and they do a thing and you can host them and you can upgrade them. But Terraform is a language. So it's not a component of your architecture.

It is a tool used to deploy your entire environment. And so it's more foundational when the license of Terraform changed. And I'm sure that they anticipated some blowback, but I'm guessing they did not anticipate this group of companies that I had seen from afar, but never interacted with. Cause like, why, why would you interact with your competitors? Right? Maybe you encounter them on a sales deal, but I mean, you're not going to like, and collaborate with them, like by nature, by definition, they're a competitor. But what this announcement did was it created a common interest among all of us. And it was like this big party in Slack. Like we all joined and, and we were all working together with each other and everyone was contributing to the cause of helping to support OpenTF. So I think we've worked really well together as a consortium.

There have been, there's been no infighting. There has been no tension. It's like it is an environment where we all recognize that we have a huge amount of value to add to the world. And if we can just unite to establish a solid OpenTF, then we are able to unlock delivering that value. And so, like I said before, it's a highly skilled, well-financed, capable, coordinated group of companies. And my guess is that Hasha Corp was caught off guard by how well we've executed, how quickly we've executed, and how much support there was for some of the ideas that we put forth in our manifesto. What does a pledge mean? So you have 134 companies that have co-signed a manifesto. It seems that one, two, three, four of them, not grunt work, honestly, but grunt work is right up there at the top.

Four of them have actually said specifically the cost of five or four or three full-time engineers. And then a lot of them just say development, community, open source efforts. I just wonder, are they on the hook here? Is this just a nice thing to put your name behind, but you're not actually going to help out? I mean, obviously with over 100, some of those are going to help out.

But I'm wondering, is this real support or is this just, it's popular to put your name on this manifesto, we like to take pledges and we'll see what happens. Yeah, no, it is real. Those companies already have job postings for those roles. It's popular to put your name on this manifesto. We like to take pledges and we'll see what happens. Yeah, no, it is real. Those companies already have job postings for those roles. They've been posting some resumes inside the consortium Slack, in fact.

Okay. And what it means when you list the FTEs is that you've allocated budget to hire those folks. I'm speaking to the ones who don't have the FTEs. Of the 134, you have four with FTEs, and that's great. And then you have Gruntwork, which obviously y'all are putting a lot into it, and you're not one of the four with FTEs, but you're obviously developing. But then you have a bunch of companies that have signed on, and it's not clear to me if they're going to actually do anything, or how clear is that from your perspective? You're on the inside.

Yeah. So I can speak for Gruntwork actually about why didn't, why did we not contribute FTEs? So Gromark in particular is fully bootstrapped. We don't have any outside investors and we have an ambitious product roadmap and we felt that we're not as big as some of the other companies on that list. And that allocating a couple salaries for us is more of a impact to our roadmap than maybe it would be for them. That being said, that was our thought process about whether we could publicly contribute FTEs at this time. That being said, we also see a lot of business opportunities with OpenTF. And if we think that there's a return there, like for example, offering OpenTF support, then sure, we'll go ahead and fund the hires. I'd love to do that. Actually, we just wanted to make

sure that our pledge was, was meaningful. So I do have to wonder how many other people intend to maybe do something, but stop short of officially committing because they weren't yet in a position to say we're a hundred percent definitely contributing employees to this. Yeah. I didn't bring this up to call out grunt work by any means. My point was more of like, are the, you know, a lot of these signups, I wonder how strong your confidence is that these aren't, you know, supporters in name only. Yeah. Obviously you have some who put, they've bellied up to the bar and they're there for it, but there's a lot of companies here, but are they all going to actually participate? I don't know what

that's going to look like as it goes on. I could tell you internally, those contributions are real. Those job postings have been linked. People have applied, interviews have taken place, reach outs have taken place. Yeah, those are real from every data point that I've seen. They're, they're absolutely real. Well, that's a lot of companies. I was trying to think of another analog. You had your Hudson and Jenkins example. The one that I thought of that's more recent and closer to the same, but isn't the same, it would be Elasticsearch and OpenSearch. And just in the zeitgeist, I'm not close to either of those two scenarios, but in my just talking with developers, it seems like Elastic still has the mind share and OpenSearch doesn't.

Even though OpenSearch is the open source fork of Elasticsearch, the difference being is that that's largely an AWS effort with a few other people helping. And it seems like the difference here, if you are successful with OpenTF, which, you know, proof's in the pudding, here we are, fork announced, but not released. We don't know if people are going to actually adopt, but it appears that you have some momentum. The difference is being you have broad, diverse support of many orgs, whereas OpenSearch was pretty clearly an AWS response to Elasticsearch. Yeah, I think that's a good point. The other distinction I would draw is OpenSearch or Elasticsearch is, like I was saying earlier, kind of a black box service.

People don't write programs in Elasticsearch. You call an Elasticsearch interface to read and write data. Terraform is different. It just is. It is a language. It would be akin to Go or Java or Python announcing it's going to be used under a business source license. But don't worry, as long as you don't compete with Python, you're free to use it. It would make you question everything that you've written in Python, all of your Python tools. It is not a black box service.

It is a language, like a core tool for deploying infrastructure. So that's the other part too. You can't just swap it in. It's like, it's this layer in your technical sediment and it's very painful to reach in and rethink that entire layer. And so that's why I think there's such a blowback of support for OpenTF. So have we hit the roadmap on the head specifically? I know you mentioned some of the stuff that y'all have figuring out still or wanting to do. And backwards compat for a while is very important. What else is on the roadmap here? You have the Linux Foundation stuff. I'm sure governance is top of mind. That's all as joining a foundation and the Linux Foundation stuff. I'm sure governance is top of mind. That's all as

joining a foundation and the RFC process. But anything else that's planned or in the works that you want to talk about? Well, so first of all, there is a GitHub repo, OpenTF Foundation slash roadmap that has the roadmap in it as a GitHub project. And you can see what we're working on there. And really the focus right now is on getting to OpenTF 1.6.0. And we're product people thinking backward about what type of experience we want our customer to have. And so when we think about what's necessary for that OpenTF 1.6.0 release, we know that we need the OpenTF Git repo public instead of private.

We need to have a community involvement process. So some process for contributions or guidelines for contributions, some approach to how we're going to port features from Hashi Terraform to OpenTF. And then for the release itself, we need a better documentation site. So we've already got a draft going in that, but that's not quite ready. We need a clear RFC process. We need to release a 1.6.0 alpha. We need to make sure our testing is in place. We need a clear release process. It sounds like

based on what happened today, we're going to need a registry mirror. So it sounds like a lot, but we have existing code bases to work with. And all these folks on, or working on the dev side, they're all ramped up on this already, in addition to all the new people that we're hiring for all this. So things are moving pretty quickly. But yeah, the team at OpenTF is very committed to doing things right. The last thing that we wanted to do was publish a janky kind of like half thought out release that when people try it out, it's like, oh, great. It says OpenTF, but it doesn't work in this way and that way. So we're being really thoughtful about the fact that like, this is the

tool you're going to use for infrastructure. And we take that commitment very seriously. It's a lot of work to do, but what's the, how soon do you think a release will be available? Months, weeks, new year? Yeah, it's a great question. We made an internal decision not to commit to a release date, but only to publish our roadmap and our progress because it's like time scope quality, right? You get to pick two and we don't know how much time things will take. And so rather than commit to a date and then scramble to meet it and potentially compromise quality, we're committing to transparency and to ongoing progress. That being said, there is an absolute sense of urgency

to get something out there. I think if it's 2024 and we're finally announcing, you know, OpenTF, OneDot, whatever, that would probably be a failure. But yeah, we also aren't doing it tomorrow, you know. So the best way to see the timeline is to go to the roadmap repo, look at the progress, and see what we've done and what we're in the process of doing. Well, if somebody's coming to this podcast for the first time or

one of the first times, they're kind of hearing the depth of the information behind this. And obviously, they've probably heard about this change because information travels quickly. But they're fired up in positive ways. Maybe some negative ways, too. They're like, you've probably heard about this change because information travels quickly. But they're fired up in positive ways. Maybe some negative ways, too. You know what? If they're well-funded, to quote you, which you said before, and they're hiring, what's that process?

Do you have a page you can go to? Is it these other companies that are hiring folks? How is employing folks to work at OpenTF or on OpenTF actuating? Give a call to action. Where can people go? You know, that is a great question. And it makes me realize we should have that call to action right on OpenTF.org. And I will propose that to the consortium after this podcast.

Okay. As far as what to do right now, here's the thought process. You could see the small list of companies that have explicitly committed full-time employees. You can go to their careers websites. They've named the positions something like open source engineer and look at the companies, see which one you like the best, or maybe apply to more than one and apply for the role and begin the conversation. There is enormous enthusiasm for the project. So if you're someone who's passionate about writing open source and about maintaining a key part of the modern infrastructure stack as open source, there's about 20 great opportunities for you.

You mentioned communication and stuff like that too. Maybe rather than pointing to a job posting or an application or something like that, maybe where is the conversation happening? Is there an open Slack? Is there a Discord? How can people participate with this enthusiasm? Yeah, so there's a Reddit community, but it hasn't really gotten that much traction, to be honest. Most of the interaction seems to be, the Reddit community, if you're interested, is reddit.com slash r slash OpenTF. Most of the interaction, though, has been on the GitHub repo. So there's pull requests and there's GitHub discussions there. And then internally, we have a very active Slack workspace, but it wouldn't make sense to make that public, unfortunately. Yeah, but I think, you know, we've seen,

we also have an email address pledge atentf.org that people can email. And we've gotten lots of emails from that. So those are the three main ways. But probably GitHub issues or GitHub discussions or pull requests is the best option at this point. So do you think Fireship.io sent folks to your GitHub discussions? Is that what we should do too? Is that the best place to send folks for now? There's got to be a conversation happening, right? So you've got to be capturing that.

It can't just be disparate throughout the socials. Well, I mean, there are lots of conversations on LinkedIn, X. I haven't really seen any on Threads. It seems like it's mostly LinkedIn and X. What is Threads?

What's that? What is Threads? It was that? What is Threads? What is Threads? It was a joke. And what is X? What is going on? What is X? I know. I know.

Honestly, whenever I think of X, I just think of a combination of X and Twitter. Let me encourage you to capture something then. Because, I mean, it's got to be, you got to have some sort of place to send folks to. Because there's a moment happening right now. And to be clear, even on this podcast, we do have a week delay. So this is not live. So you've got at least one week before these words are spoken to people and they're hearing my words right now. So you've got a week.

But I would encourage you to define that and let us know. We could put in the show notes, but that should be like one of your other priorities because community is something that HashiCorp seems to have failed upon. The CEO has spoken in a video about using the word malicious in regards to their community efforts and how those things work. I'm not going to directly quote that. I'll just link to the video in the show notes and let people make their own decisions because I don't want to like put words in somebody's mouth. But he did say the word malicious. It seemed to have been a failure on how to organize the community considering this fork that's not what the community wanted obviously based upon your inertia so your priority should be capturing where that community should be

at and it's fine to have socials but you should make a place where people can hang out yeah that's a great point that is my second call to action for, or not my call to action, my action item for after this podcast. We like to give people things to do when they're done. Yeah. I see. I've come here and now I have homework. Yeah. That doesn't seem fair. Well, wherever it is, wherever you decide, we will link up in the show notes. So if you're listening to this and you're like, I got to talk to Josh and the gang, I want to get involved with OpenTF and you're not sure where to go, just check the show notes.

The priority link will be there for you to get involved. In the conversation, my only last question is like, how do we stop another rug pull? You know, like, are you guys thinking about this? Because what if OpenTF becomes like OpenAI, you know, like, are you guys thinking about this? Because what if OpenTF becomes like OpenAI, you know, and the open and name only? What do you guys change your mind and decide you don't want to be OpenTF, you want to be closed TF? Have you thought about that? Like, can you put that into your bylaws or something like we were never going to undo this?

We've done exactly that. So one of the requirements of joining Cloud Native Computing Foundation, Linux Foundation is you have to commit for all time to being open source. And we're prepared to make that commitment. There's also a venture capital firm I saw funded by the CEO and founder of GitLab, Sid C. Brandy, I think his name is. It's called like OpenCore Ventures or something like that. And that he published on Hacker News, a blog post promoting this idea of like an open pledge or OpenCore pledge, where you're essentially making a public pledge to always keep your project permanently open source. So I think it's a good question. It's we're entering an era of open source where we're still figuring out what the social contract is with an open source project, its community and its maintainers. I always thought

that contract was once open source, always open source, unless there's some really malicious thing going on. And then you'll just target that, that one actor. But I feel like this business source license thing has, is, is a way of thinking that I'm, is new to me and is not comfortable to me. Like even if it were on a project that I didn't have like a vested interest in, I would not want to participate in a project that had like a business source license. So I guess, you know, we'll see how things play out. What I'm hopeful for is that open source becomes something where it is a clearly understood part of a company's business model, whether it's for lead generation, recruiting, or being a free tier. And companies know the game that they're playing. And they don't, they don't reframe that game as,

Oh, we're being taken advantage of, but instead they can say, Oh, this is what the dynamic is. When you do open source competitors can and will use it against us, but we have a privileged position as the creators of this tool. And here are the many ways in which we're going to leverage that to build an amazing thriving business. That's what I'm hopeful will be the future of this tool. And here are the many ways in which we're going to leverage that to build an amazing, thriving business. That's what I'm hopeful will be the future of this stuff. I've only got one more question too. The other one I'll save for our Plus Plus folks.

But it may be more homework for you. KubeCon's coming up soon, November, right? And it seems like a lot of it's cloud native computing foundation that's what kubicon slash cloud native con that's the it's been a double named conference forever we just shortened it to kubicon because less words obviously what's your plan do you have a plan to to have a presence there that's that's unique and fun and captures i mean you're going to have a lot of captive audience if you're going to gain some steam before 2024 that's unique and fun and captures. I mean, you're going to have a lot of captive audience. If you're going to gain some esteem before 2024, that's the place to

do it. So have a plan. Do you have a plan? It's a good place to launch. Yeah. Oh, man. So another item from my list, unfortunately. Make a plan. So I don't know. I'm not saying there is no plan. I'm just

I haven't focused on the marketing efforts for OpenTF personally. There's a plan there is no plan. I haven't focused on the marketing efforts for OpenTF personally. There's a plan to make a plan. No, no, no. It's just there's multiple people doing multiple things at once and I'm not plugged in to every detail of every item.

So the marketing channel, I kind of mute that in Slack. And so I just don't know what the status is, unfortunately. But I should know. And so I will add that as the third. There you go. First item is to unmute it. Don't mute it anymore. And then don't only put it in the marketing channel.

This is like a business level plan, in my opinion. Well, this highlights a good point, though, Josh. Maybe a good time quickly before we close down here to name some of the other folks who are involved because your business isn't the only one running this. So yeah, I was trying to do that earlier. So the companies at the top are kind of in order of who is leading this initially. And so the initial group of the consortium was of course grunt work and then uh scaller m0 spacelift tear team digger and then later on cloud posse joined mass driver and we've had some other names like big names that uh recently became kind of involved with the consortium, but aren't yet ready to

make it public. Like it should be any day now. So I'm really kind of eager to mention them, but yeah, those are the, the, the key players in the Terraform ecosystem, in addition to the a hundred plus other companies that are listed there. So yeah. And then check them out. They're all great products. And even though we're competitors, there's, we can all do well at the same time. And, you know, there's a lot of value to add in the world. Very cool. Amen to that. Well, thanks so much for joining us, man. Yeah. Thanks guys. This was a lot of fun. Well, um, I will certainly follow up with you on the homework and, um, but yeah, thank you so much. This is, this was great.

We love giving ideas here and homework, but we love giving ideas as well. Yeah. It's good that you don't mention that when you're reaching out to the guest. We don't like people to know that we're going to give them homework because then they wouldn't come on the show. That's right. I'm like, I'm not coming on that show. It's kind of a rug. It's more a rug pull move. You know, it's a bait and switch. We know you like those. Where have I heard that before? We know you like those.

Well, it is official. Terraform has been forked. And the organization OpenTF is not only legitimate, but well-organized and well-supported, getting the support of not only prominent members in open source, but also organizations that leverage and have vested interest in an open Terraform, but also the Linux Foundation and the possibility of the CNCF. This is big. We also have a bonus few minutes for our Plus Plus subscribers,

so stick around for that. If you're not a plus plus member, you can do so at changelog.com slash plus plus. Ten bucks a month. Hundred bucks a year. No ads. Directly support us. Get closer to that cool metal. And of course, bonus content.

Once again, a massive thank you to our friends and our partners at Fastly, Fly, and also TypeSense. And the beat freak in residence, Brayton Massacylinder, brings those beats every single week, and we love them, and we hope you love them too. That's it. This show's done. We will see you on Friday. Thank you. Outro Music