Changelog Interviews – Episode #556

OpenTF for an open Terraform

with Josh Padnick

All Episodes

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.

Featuring

Sponsors

Tailscale – Simple, secure networks for teams of any scale. Built on WireGuard.

Sentry – Scheduled jobs are supposed to be predictable, but sometimes, predictable != reliable. Sentry Cron Monitoring (Beta) helps you monitor the uptime and performance of any scheduled or recurring job in Sentry. Learn more by attending this FREE webinar!

FastlyOur bandwidth partner. Fastly powers fast, secure, and scalable digital experiences. Move beyond your content delivery network to their powerful edge cloud platform. Learn more at fastly.com

Fly.ioThe home of Changelog.com — Deploy your apps and databases close to your users. In minutes you can run your Ruby, Go, Node, Deno, Python, or Elixir app (and databases!) all over the world. No ops required. Learn more at fly.io/changelog and check out the speedrun in their docs.

Notes & Links

📝 Edit Notes

We were going to link to the video where HashiCorp CEO Dave McJannet’s used the word “malicious” in regards to their strategy and actions towards the open source community, but it has been taken down. This was the link to the video with a timestamp jumping to the part in question - https://www.youtube.com/watch?v=59rEiAyYEVk&t=920s

This tweet/post from Bryan Cantrill brought this to the community’s attention.

Chapters

1 00:00 This week on The Changelog
2 01:24 Sponsor: Tailscale
3 03:54 Start the show!
4 05:00 HashiCorp changed Terraform's license
5 06:58 What is Terraform?
6 10:58 Why is Terraform important?
7 17:19 Is Gruntwork a HashiCorp competitor?
8 19:28 What if we just paid the license fee?
9 26:42 Sponsor: Sentry
10 30:45 Open source doing what it does best
11 35:13 OpenTF vs Terraform
12 39:30 What will it take to support this?
13 42:11 Adoption at the provider level
14 46:25 Capturing similar mindshare
15 52:48 Is there a merge potential?
16 56:21 Confidence in The Linux Foundation
17 58:03 Did HashiCorp see this coming?
18 1:01:03 What does a pledge mean?
19 1:06:06 What else is on the roadmap?
20 1:08:33 Do you have a release date?
21 1:09:33 Where can people gather?
22 1:14:18 No more rug-pulls!
23 1:17:00 Plans for KubeCon
24 1:18:20 Naming names behind OpenTF
25 1:19:33 Wrapping up
26 1:20:14 Outro

Transcript

📝 Edit Transcript

Changelog

Play the audio to listen along while you enjoy the transcript. 🎧

Okay, we are joined by Josh Padnick, one member of the OpenTF, that stands for TerraForm. Josh, welcome to the Changelog.

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 OpenTF, Malcolm Matalka - shout-out to Malcolm - who said you, Josh, would be a great person to talk about this topic. That being said, we were on this already, we were thinking “Yeah, we’ve 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 to find you, Josh. So shout-out to Malcolm, and happy to have you here.

So let’s get rockin’ and rollin’ 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 own side of the story, how you found out about the change in licensing, the changing shift from HashiCorp and what y’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 the 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. 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’ve 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 DevOpsy 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 as 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 HashiCorp Config Language, or HCL, which was quite elegant to use.

[07:56] 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 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 prebuilt library product… Yeah, so it was definitely a paradigm shift when it came out, and continues to be, I would say that 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? Or how much do you think it 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 I 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 “Wait a minute, no one’s gonna use this because everything has to be through HashiCorp. So I’m just going to invest elsewhere, in other technologies.” 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 code 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 or accessible without purchasing 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 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 HashiCorp’s own TerraForm Cloud product has what they call a run task, which includes like a support for OPA.

You’re getting them worked up over there, Josh. Who let the dogs out, man? [laughter]

Yeah, I was like “Hopefully you don’t hear the dogs in the background…” Alright, well, I’m gonna cash in a pause token…

Alright, let’s take a pause…

When you look at the project though - like, it’s been open source since the beginning, but it’s always had this core module. There’s been this core, and then every infrastructure usage of it has plugins, from what I understand. So there’s the core thing, and then there’s an AWS plugin, there’s an Azure plugin, there’s a pick-your-infrastructure plugin. At the core though, hasn’t HashiCorp 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 chose it before? Is it simply because all control goes back to HashiCorp? And I’m gonna revert back to point one, which is didn’t they already control core and control contributors, and kind of control –” even if it was open source, they control contribution, which is kind of like… Still the license is open source, but they control the direction of it.

[11:55] Yeah, so HashiCorp is the originator of the TerraForm project, and they were the controllers of it. There were literally pull requests that had sat unmerged for years, because it didn’t meet the business interests of HashiCorp. And the classic example there is encrypting TerraForm state files. That’s a natural kind of upsell thing that I think HashiCorp 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 there’s 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 NPL v2 license, and I think we all assumed “Well, it began as an NPL v2 open source license, it will always be an NPL v2 open source license.” So people accepted that HashiCorp controlled that tool, but there was an 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. 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 HashiCorp. 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. And there’s literally like two lines in 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. Like, “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 HashiCorp 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. 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 - this license is dynamic. What the interpretation of these terms could be can change depending on how that FAQ gets updated. And then whether you’re competing with HashiCorp 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, 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 HashiCorp’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.”

[15:56] So if you play that thought out, then it’s like “Okay, from a business perspective what does 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 HashiCorp changes their mind in the future? What happens if they decide “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. 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 HashiCorp’s official sign-off. Which brings me into 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’ve 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, it feels hyperbolic when I say that, but we published all these blog posts, we wrote TerraTest, 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 “How do I manage the blast radius? And what do I do about global variables? How do I set module default values? 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 TerraGrunt from HashiCorp’s perspective is you can’t use their commercial products with TerraGrunt. So TerraForm Cloud and TerraForm Enterprise - they don’t support TerraGrunt. So this really strange dynamic emerged where if a customer made the decision to adopt TerraGrunt, 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 HashiCorp’s sales team to TerraForm Cloud and TerraForm Enterprise. And so in any of our discussions with HashiCorp, it basically came out that we were viewed as a competitor to them.

So did it cross your mind, or did you have a thought of “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 HashiCorp 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 HashiCorp’s leisure, with their permission, and they have total leverage in such a negotiation. Because if they choose to say “You know what - we’ve been thinking, we don’t really like what Gruntwork’s doing, so no license for you.” Our entire business goes away overnight.

[20:15] So I don’t think we could responsibly engage them… And I also think it’s lousy for customers, too. Like, we’re now at the mercy of whatever HashiCorp 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 HashiCorp’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. From their perspective, if they’re selling compute and storage, and maybe now AI time, or whatever else their primitives are, they’re happy. They don’t care if it comes through CloudFormation, through TerraForm, through Gruntwork, through some consulting company…

And so I think from the perspective of AWS, 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… So 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 and instrument it, whatever it might be to put it in place. And Cloud, TerraForm Cloud and 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 TerraGrunt 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 TerraGrunt. 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 focused on… Whereas there are other companies like Env0, Scalr, Spacelift, that do explicitly support TerraGrunt in a first-class way. And so we haven’t really monetized it as like a service.

One paradigm of building on open source is the open source tool is free, 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. 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; we’ll support other CI systems in the future.

And then in addition, we do offer TerraGrunt support to a bunch of customers. 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.

[23:50] By contrast, I would say TerraForm the open source tool is more going from a core open source tool to a platform with TerraForm Cloud. TerraForm Cloud is essentially running TerraForm as a pipeline. And then same thing with Env0, Scalr, Spacelift, Terrateam and Digger. These are the competitors that HashiCorp was essentially targeting when they came out with this license change… Because basically, HashiCorp was saying to themselves “Hey, we’re the ones who produce this TerraForm tool. We’re paying all the costs for 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 HashiCorp had to make was a) Do we change that by making a better product? Maybe by somehow leveraging our unique position in the TerraForm ecosystem? Or b) do we cut our competitors off at the knees? And personally, TerraGrunt, we have other companies who technically are our competitors, but who are now our fellow OpenTF Consortium members who profit off of TerraGrunt, and who technically 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.

But HashiCorp’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 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; that’s what I’ve seen. We get those comments, we get those emails, we’ve seen those pull requests… And I think that’s why. 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 need for a different path forward, with OpenTF in particular.

Break: [26:35]

Well, as I said on Changelog News when we talked about the fork, I said that this in my opinion, this action, action or 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 there’s hand-wringing and then there’s hand raising. Oh, that was a nice turn of phrase. I didn’t even mean to. [laughter] And you can actually – you can talk and complain, 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 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. HashiCorp 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 - what you guys were calling plugins earlier, the technical term for them in the TerraForm world is provider; most TerraForm providers are –

Sorry about that.

Oh, I saw an opportunity to be pedantic, and I took it.

And I called it that because Dave, the CEO, called it plugins.

Oh, really? [laughs] 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 guys… CEO. That’s what happens…

We’ll get into 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 6 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 HashiCorp has currently allocated to what we would call Hashi TerraForm. Or it could be even more than that, like three times.

[33:49] 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 HashiCorp controlling everything, where if you choose that path, that’s the ecosystem you’re in, and there aren’t other players and that’s the path you’re choosing.

So that’s something we’re 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 HashiCorp 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 – 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 HashiCorp’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 legal compliance is something that’s really important to us.

Anyway, 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. 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 HashiCorp. One example would be those encrypted state files, like I mentioned before. HashiCorp 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 codebase. So HashiCorp 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.

[38:20] Another example would be 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 I 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 from our consortium released a proof of concept video just a couple days ago showing how they were able to download TerraForm providers from Docker Hub, or ECR, or GitHub Container Registry.

So our first priority is compatibility, so that you can 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, really. It’s got an IPO-ed company behind it, I’m sure they’ve 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 gonna 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 HashiCorp 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 8 to 10, or maybe 6 to 10 humans at HashiCorp actually maintaining stuff… You know, unless my data is off, but that’s what we’ve seen…

Where’s that data? Is that just code contributions, o what are you looking at?

Yeah, so if you go to github.com/hashicorp/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 have actually done like a lot of contributors, there’s 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 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 HashiCorp’s internal staffing strategy… But yeah, I mean, like I said, that’s 6 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. And not only that, but 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 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 an 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, much better than it ever could have been under a single vendor.

[42:10] 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 “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? For example, you mentioned 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. In fact, HashiCorp – by the way, I hate focusing so much on HashiCorp, because what we’re really interested in is creating the best possible OpenTF. And it would be lovely if HashiCorp succeeds as a company; there’s no vendetta or negative anything against them. They’re trying to meet their business needs, we’re trying to meet hours, and we’re focused on our vision, not on tearing down another company. That being said, all these questions come back to “Well, HashiCorp did a thing that we now have to react to.” So now I will answer your question…

Okay, so HashiCorp maintains something called the TerraForm registry, and it historically has hosted TerraForm providers and TerraForm modules. And 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 HashiCorp. 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 TerraForm registry; first let’s take a look at providers… It turns out that if HashiCorp is hosting a non-HashiCorp-maintained TerraForm provider - like Azure; I think it’s not maintained by HashiCorp - then that is actually downloaded from TerraForm through GitHub rather. So 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 HashiCorp 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 HashiCorp 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 NPL-licensed Go release assets, and then you just download it from there. So it’s trivial technical workarounds, but it just creates noise.

[45:39] And then for TerraForm modules, that’s also just an HTTP 301 redirect to GitHub. And the language that they have and the terms of service update is very aggressive. 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. They host modules or providers created by others, that are just made available for there. So I’ve 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 yeah, 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.

And what about adoption, though? 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; far beyond what we expected. At this point, the OpenTF manifesto repo has, I think, 25,000 GitHub stars. And the HashiCorp 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.

It’s a lot of stars.

For our manifesto. Yeah… And you know, a star is a star…

It’s indicative of some sort, right.

Exactly. 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 came back to us a week later, after the OpenTF manifesto had been out, and they saw all the support for the companies… And I remember one customer in particular saying “Alright, so basically we stay on TerraForm 1.5.5 for a little bit…” That’s the last version of TerraForm that is NPL-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 GruntWork 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 licensed position. So there are many companies that we’ve 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. 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 that if I don’t like one of the companies I’m working with, I can just go to another company. Whereas if you choose the Hashi path 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.

[50:06] 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 the 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 HashiCorp to change their position, right?

[laughs]

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 a sort of war. And war sucks, and everyone loses from war. But sometimes wars happen. And so we really did feel like “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. 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. Like –

Well, that was gonna be my question, was “Has there been any conversations between Hashi and anybody from OpenTF?”

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?” What if they would have said “Okay, we’ll go back to NPL. Sorry, everybody. That was bad.” But you guys had probably already had your fork in a private repo, and were 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. So forking was our plan B, but we were prepared for Plan B. And then, when their deadline came and went, it’s all systems firing for monitoring 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, NPL comeback. We would like to join the OpenTF initiative”, is there a potential of a merge? I mean, you said war at this point. So it doesn’t sound like that would be on the table.

You know, it is a war of ideas, but not of people. So if we are pushing OpenTF into the Cloud Native Computing Foundation, where it will be governed by a consortium of vendors. If HashiCorp 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’s no bad blood there. Do I think that’s going to happen? No. [laughs]

What about a merge? “Come back, just one TerraForm path forward…” Could there be a merge? Or is that also a step too far?

[53:48] You know, in theory that could happen. But in practice, I know that there are people internal to HashiCorp 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 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”, it’s the same thing. They’re gonna 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 into the DevOps world - this was like 2012, 2013, 2014 - I was looking at CI systems and I discovered Jenkins. And I thought “Oh, this is cool”, for the time; 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 it was like “Oh, this clearly looks like the lesser project.” 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 HashiCorp TerraForm, 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 in the short-term, I absolutely expect HashiCorp will have some neat feature improvements that aren’t going to be in OpenTF 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 kinds 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 had mentioned, and the CNCF? Would you have to apply and incubate and graduate, or what will would the situation be?

Oh, Linux Foundation is in process right now. As far as I know, basically we’re just going through the motions administratively. Then it 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 gonna happen? 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 the 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. 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.

Yeah. Well said.

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.

[58:02] In a game of chess, you often think moves ahead, right? And I’ve gotta imagine that this may be 4D chess, who knows what version it might be… But I’ve gotta 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. 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 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 – like, they’re a different paradigm of things. Like, 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 a consortium of competitors to collaborate so well with each other. It’s hard to capture this spirit in words, but prior to this announcement, there was this group of companies that I had seen from afar, but never interacted with, because why would you interact with your competitors, right? Maybe you encounter them on a sales deal, but you’re not gonna collaborate with them; 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. We all joined, 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’s been no infighting; there has been no tension. It’s 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’re able to unlock delivering that value.

So like I said before, it’s a highly skilled, well financed, capable, coordinated group of companies, and my guess is that HashiCorp 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 the manifesto. It seems that four of them - not GruntWork, honestly, but GruntWork is right up there at the top… But 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 enough 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’d like to take pledges, and we’ll see what happens.”

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… And what it means when you list the FTEs is that you’ve allocated budget to hire those folks.

[01:02:00.08] I’m speaking of 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, you 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. How clear is that from your perspective? You’re on the inside.

Yeah. So I can speak for Gruntwork, actually, about why did we not contribute FTEs. So Gruntwork 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 an impact to our roadmap than maybe it would be for them. 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 meaningful.

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 100% definitely contributing employees to this.”

Yeah. I didn’t bring this up to call out Gruntwork, by any means. My point was more of like, a lot of these signups, I wonder how strong your confidence is that these aren’t supporters in name only. Obviously, you have some who 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 gonna look like as it goes on.

I can 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 absolutely real.

Well, that’s a lot of companies. I was trying to think of another analog… You had your Hudson and –

Jenkins, yeah.

…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 mindshare, and OpenSearch doesn’t, even though OpenSearch is the open source fork of Elasticsearch. The difference being 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 - proof’s in the pudding; here we are, fork announced, but not released. We don’t know if people are going to actually adopt it. But it appears that you have some momentum, the differences 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, as 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, a core tool for deploying infrastructure. So that’s the other part, too; you can’t just swap it in. 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.

[01:06:05.19] So have we hit the roadmap on the head specifically? I know you mentioned some of the stuff that you 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 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, opentffoundation/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 customers 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 of that, but that’s not quite ready. We need a clear RFC process, we need to release 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 codebases to work with, and all these folks who are 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, or that way.” So we’re being really thoughtful about the fact that 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 how soon do you think a release will be available? Month, 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. 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 OpenTF 1-dot-whatever, that would probably be a failure. But yeah, we also aren’t doing it tomorrow… 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 - now, they obviously probably heard about this change, because information travels quickly, but they’re fired up, in positive ways. And maybe something that ways, too. They’re like “You know what - if they’re well funded”, to quote you, what 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?

[01:10:08.05] 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. [laughs]

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.” 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.

Well, 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’s 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/r/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. We also have an email address, pledge [at] OpenTF.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 like the best place to send folks for now? There’s got to be a conversation happening, so you’ve gotta be capturing that. It can’t just be desperate 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 a joke.

And what is X? What is going on? [laughter]

What’s X, yeah.

I know, I know… Honestly, whenever I think of X, I just think of a combination of X and Twitter…

Well, let me encourage you to capture something then, because – I mean, you’ve 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 it 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 put words in somebody’s mouth… But they he did say the word “malicious”. It seemed to have been a failure on how to organize 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 – or not my call to action, my action item, for after this podcast.

There you go.

We’ll make a list.

We like to give people things to do when they’re done here… [laughs]

Yeah, yeah. See, I have come here, and now I have homework.

Yeah, exactly.

That doesn’t seem fair. [laughter]

[01:13:58.16] 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’ve 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 how do we stop another rug pull? Are you guys thinking about this? Because what if OpenTF becomes like OpenAI, open in name only? What if 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 by-laws, or something, that “We’re never going to undo this”?

We’ve done exactly that. So one of the requirements of joining Cloud Native Computing Foundation and the 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 Sijbrandij I think his name is; it’s called Open Core Ventures, or something like that. And he published on Hacker News a blog post promoting this idea of like an open pledge, or open court 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. We’re entering an era of open source where we’re still figuring out what the social contract is. With an open source project it’s community and it’s 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 one actor. But I feel like this Business Source License thing is a way of thinking that is new to me, and is not comfortable to me. Even if we’re on a project that I didn’t have a vested interest in, I would not want to participate in a project that had a Business Source License. So I guess 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 reframe that game as “Oh, we’re being taken advantage of”, but instead, they can say, “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 stuff.

[01:16:49.19] I’ve only got one more question, too. The other one I’ll save for our Plus Plus folks. And it may be more homework for you… [laughter] KubeCon’s coming up soon, November, and it seems like a lot of – it’s Cloud Native Computing Foundation, that’s what KubeCon/Cloud-Native Con, that’s the… It’s been a double-named conference forever. We just shortened it to KubeCon, because - less words, obviously. What’s your plan? Do you have a plan to have a presence there that’s unique, and fun, and captures – I mean, you’re going to have a lot of captive audience. If you’re gonna gain some steam before 2024, that’s the place to do it, to have a plan. Do you have a plan?

It’s good a 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 just haven’t focused on the marketing efforts for OpenTF, personally. There’s a plan to make a plan.

No, no, 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. So I just don’t know what the status is, unfortunately. But I should know. And so I will add that as the third to-do on my list.

There you go. [laughs]

The first item is to unmute it; don’t mute it anymore. And then don’t only focus on 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, and I was trying to do that earlier… So the companies at the top are kind of in order of who was leading this initially. And so the initial group of the consortium was, of course, Gruntwork, and then Scalr, Env0, Spacelift, Terrateam, Digger, and then later on CloudPosse joined, Massdriver… And we’ve had some other names, like big names that recently became kind of involved with the consortium, but aren’t yet ready to make it public. It should be any day now, so I’m really kind of eager to mention them. But yeah, those are the key players in the TerraForm ecosystem, in addition to the 100+ other companies that are listed there. And check them out; they’re all great products, and even though we’re competitors, we can all do well at the same time, and 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, I will certainly follow up with you on the homework, and… [laughter] Yeah, thank you so much. This was great.

We love giving ideas here… And homework, but we love giving ideas as well. [laughter]

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 gonna give them homework, because then they wouldn’t come on the show.

That’s right. They’d be like “I’m not coming on that show…”

It’s more of a rug pull move, you know? It’s a bait and switch. We know you like those, Josh…

Where have I heard that before…? [laughs]

We know you like those…

[laughs]

Changelog

Our transcripts are open source on GitHub. Improvements are welcome. 💚

Player art
  0:00 / 0:00