Terrateam/OpenTofu

Ben Rometsch chats with Malcolm Matalka, co-founder of Terrateam, to discuss the company’s inception and its eventual shift to open source. Together, they discuss how his frustrations with the click ops approach prompted Malcolm to create his own team to disrupt the system and pave the way for much more innovative methods. He opens up about the challenges they faced due to the licensing changes of HashiCrop and how it led to the creation of OpenTofu. The two also emphasize the undeniable dynamic of community-driven projects and how they offer people options and opportunities to adjust, transform, and collaborate.

---

Introducing Malcom And The Terrateam

Welcome back, everybody. Everyone I know is talking about DeepSeek, and all my muggle friends are phoning me up and saying, “What the hell is going on? Should I short Nvidia?” To which I say, “I'm not going to tell you whether to do that or not.” Everyone is going mad about DeepSeek. I get to speak to Malcolm Matalka, who has nothing to do with neural networks at all but is still going to have a ton of interesting stuff to talk about. Malcolm, do you want to briefly introduce yourself and Terrateam?

We've got nothing to do with LLMs or AI, unfortunately, but we are open source. We can relate that to DeepSeek.

That's true. How open are they? Maybe that's a bonus question to complete at the end of this.

I'm a co-founder of Terrateam. It's me and my other cofounder. What we are is an infrastructure as a code orchestration tool where we focus heavily on staying inside of a user's workflow. They shouldn't feel like they're interacting with us directly much. They should feel like they're accomplishing their task. Specifically, we focus on Terraform and OpenTofu.

We also have Pulumi support. We focus mainly on GitHub right now, but we're also expanding to GitLab. Effectively, what your experience is like is you install us, set us up, and then as you make changes to your infrastructure as code, we automatically perform workflow steps for you to help you understand what change you're making, making sure people are approving it, and then making sure it's deployed.

There's a lot to unpack there. I'd like to go through things chronologically, but I guess the starting point to that is your background is where you've worked at the two most well-known tech startups in Northern Europe.

That sounds right.

As a software engineer at Klarna and Spotify. How did you get into infrastructure as code? How’s your past experience with Terraform? What's that story?

I've been professionally working as a software engineer since I was nineteen, so a bit ago. In that context, I was the main tech person at a small startup. You had to do the infrastructure as well as the code for it. Those two went hand in hand. I've always been close to the infrastructure. As a software engineer that I am, I tend to try to be as far away from a customer as possible a lot of the time.

I'm working in a lot of spaces. At some point, I decided that I'd love to move to Europe. I had a friend who was working at Klarna at the time. I managed to move to Sweden through that. What we were doing was this cool migration from their old system to a new system, which is challenging to do because you have to be disciplined about it. That involved a lot of low-level infrastructure management as well.

This is while they were operating at scale, I guess.

We had a countdown, not like a visible clock or anything like that, but Christmas is when stuff goes nuts for Klarna. That's online payments, and that's when people are buying a lot of stuff. As they've expanded, I'm sure Cyber Monday and all that are the bigger days, but at that time it was Christmas. We were at the beginning of the year and we saw Christmas 2012 is coming, so we got to be ready to handle this scale. All the work we're doing is trying to migrate to a system that can handle that scale.

A lot of that, when you're going to a new system, is also managing infrastructure. That is where I got my first team lead experience in managing infrastructure. It was ad-hoc there at that time. We were migrating to using Chef as well but it was all data center. If you speed up in time, you get more into the cloud. When I was at Spotify, I also had a similar role of focusing mostly on databases, but they were in the data center at that point as well. After that, I decided to do my own consulting work. That was taking ideas, I was in the biotechnology space, and taking things that scientists worked on and trying to turn them into products. That involved some infrastructure as well as coding, a bit of both.

In that case, I was working on so much stuff. I needed some way to manage all the infrastructure. By this point, Terraform was pretty big. I started using Terraform for that. The path there is once you start doing this, you need to manage it. You need to automate it. There's a lot of other tools out there. There's the one from the creators of Terraform and there are other competitors. My cofounder and I have been working with this stuff and we got frustrated that you often had to go to a UI to manage the infrastructure.

You're writing the code to manage infrastructure, but then you have to go to a UI to do anything with that. The whole point of writing code for infrastructure as code is so you don't have to go to a UI. We call that click ops and it's an anti-pattern. We felt that these other folks were making effective click ops for your infrastructure that you're trying to avoid click ops with. We thought we could do it better by integrating the whole thing into a code workflow.

This is an idea or a layer that's sitting on top of or in front of Terraform, down.

Yeah. Here's what a workflow looks like for a general user. You create some changes to your dot-TF file and you create a pull request. Terrateam is in the GitHub app that gets events that you created that pull request. We examine the pull request and we say, “We see that there are Terraform changes in here.” We determine what operation you want to perform on it, and whether you can perform that operation. We have RBAC rules, whether the prerequisites for that operation have been met, and we perform that operation for you.

The OS open source is not a business model, but it is great when it aligns with how you think things are just work in business.

You see that result in your pull request. You move on with the workflow to maybe get approvals from people. You move on from there. You as the user only experience creating a pull request, seeing some output, getting approvals, and then merging the pull request or performing a specific IC operation, and then we're all behind the scenes, making sure all that's happening.

Just so people are clear, how is that different from what you're buying from HashiCorp around this part of the engineering world?

For one, we support more integrations. They're focused on Terraform as the makers of that. We support Terraform, Open Tofu, and now Pulumi as well. The big difference between us, whether it be HashiCorp or any of the other folks out there is we are entirely configured inside the repository through a configuration file. That has cool effects in that if you want to see when a change was made to your configuration and who made it, you look at the Git history.

If you want to test the new configuration, make a branch and run that branch with the operation you want and see what the change was. If you're happy with it, you've merged it back. There's incredibly low overhead in how you're interacting with the system. We do have a UI, but we've intentionally focused on making it not bare bones but more focused on consuming information that maybe you cannot get through a pull request.

We focus on making the experience next to your code at every step of the way. Whereas these other ones, you have this other experience where you have to go in and configure your repository, for example. You cannot have two repository configurations existing side by side, because once you change it, that's now what it's configured as, and there's no concept of this branch having this configuration and that branch having this other one.

In terms of the genesis of Terrateam, was that a project you started with the intention of it becoming a commercial business, or was that an itch you were scratching because you didn't like the click ops nature of your existing workflows?

It’s the former. Looking back on it, there's almost a bit of naivety and arrogance on the part being like we can do it better and we think this is the better way to do it. Let's make it. There's another tool called Atlantis, which is very similar to ours but it has some pretty big differences. We started looking at that because that's also open source and seeing it like, “Can we turn this into what we think the ideal thing is?” It turned out we didn't feel confident that that could meet our needs. We then decided to start from scratch.

I always think of that. There's that quote, “We didn't do this because it's easy. We did this because we thought it would be easy.”

It's like the opposite of the JFK quote.

Getting Into The Open Source Realm

That was something that you started hacking on yourself. Can you explain it also a little bit? Most things end up with software engineering this state that's important and needs to be managed somewhere. Terrateam itself is open source code. You can run it completely. You can get the majority of that value out by running that yourself, Did you have this design and idea in the future for this being something that you guys would host and that people would pay for that hosting?

The open source thing is interesting for us in that we started out entirely proprietary and closed source. It was not until recently that went open source. I don't know what it's like inside of a lot of startups, but it was a contentious decision where it's probably what we disagreed with the most, whether or not to do it, how to do it, what we thought the benefit would be like.

We're open core, so there are a few features that we think are very meaningful only to larger organizations that you need an enterprise license for. We had a lot of discussions about which are those features and why should we choose them versus other features. This open source thing was not the original intent. We got there through through like the circuitous route and decided it was the right thing to do.

Was there any particular event or circumstance that caused that or was it something you'd always been talking about a little bit in the background? What was it that pushed that over the line, that decision?

There's an ideological part to it where we consume so much open source software. We think a lot more people should be open source. We also read a book called The Software Paradox. Have you read Software Paradox?

No, I haven't.

The thesis of it is that the value of software itself is going to zero and it's about the services around it or doing a SaaS on top of it, like managing it for people, which is where a lot of value comes from. That impacted us quite a bit. We thought that if we could make it work inside of a business, this would be a meaningful contribution to the community. We're also bootstrapped.

In truth, there's an element of making it like a marketing tool as well. It's a way to get it in front of a lot more people. There's a way you can talk about open source, so you cannot talk about proprietary. To be honest, as a business, we need to eat as well. There was an element of how can we fulfill this ideological view, as well as make it function inside of a business.

How long ago did you make that big commit push to GitHub to push most of it public?

In December of 2024.

Did you feel like that changed the dynamics of sales conversations that you were having with people?

For me, I'm in a lot fewer sales calls, but I spend a lot of time interacting with the community. For me, it made it a lot easier to talk to people about their options. We spend a lot of time on Reddit, for example. You want to be able to give someone a solution that solves their problem without also coming off like vendor spam and being disingenuous in using this. Being open source helped to be able to talk to people in a more open and honest way like, “Here's the thing. You can use it however you want. Just to be clear, here are the limitations on what functionality is there. Beyond that, just do it. I hope it solves your problem. If you have any questions, come ask.” It makes it so much easier to talk to people.

I know exactly what you mean. One of the magic powers of especially being open core or having a commercial open source business is we see that all the time. It legitimizes what you're saying. If you're clear about the contracts between you, the third party, and where your proprietary boundaries lie. If those are fair, as the average person on the street would see it, then it's like a superpower.

Part of how we've always thought about Terrateam is we want to be as transparent, open, fair, and honest as possible with everyone we interact with. The open source element makes it easier because all the code is transparent. Even our open core features, the enterprise ones are still source available. Everything is in the repository. You can go look at them and see them. It aligns with how we think business should be done as well. I think the OS open source isn't a business model, but it's great when it aligns with how you think things work in business.

If you think about you were still completely proprietary and I'm thinking about this from one of your customers' point of view, there's a huge amount of risk there. The planners have all their infrastructure running through a bit of your code and maybe some of your state management for them. In terms of the level of systemic risk of that company ceasing to exist, there are probably not many more extreme examples you could think of.

Even if you're a potential user and you never read the code, the fact that you have the option is valuable. You don't know what the future holds, and being able to inspect that and look at it and understand that you can use it however you need to in the future if you have to remove this whole class of risks as such an important layer in your business.

I see that a lot with a lot of the people that come on this show as guests. If you consider the solution and the platform from their customer's point of view, what they're worried about, and what their concerns are, the open source, open core, or source available aspects of that address a huge number of those concerns. Some people don't consider or they don't see it because sometimes it's difficult to put yourself on the other side of the table in terms of those conversations.

You mentioned you don't know what the future holds. This is a nice segue into something that I wanted to discuss in terms of the license changes that HashiCorp made to Terraform in particular, and how you've experienced that because you're involved quite heavily now in OpenTofu. I guess that's affected Terrateam as a platform as well.

For those people who are maybe tuning in and aren't quite aware of exactly what happened, can you give us a very brief history of Terraform pre-license changes, post-license changes, and the communities? That's a big question, but how the communities reacted to that? Were you involved in Terraform in terms of contributing to the open source platform prior to these license changes? Where were you guys in that regard?

The quick history there is we weren't involved so much in contributing to the CLI itself. There's some drama behind that in that at one point, HashiCorp said we don't have time to review community contributions. We're not going to do that. There's a disincentive involved there.

They got overloaded with issues and PRs and stopped work, which I can understand. I'm not blaming them for this. They just got overloaded.

It depends on how you want to interpret how this was going. I don't have much of an opinion there. I think that being open source means you give people the freedom to do a lot. If you cannot keep up, there's an opportunity for somebody who can. That being said, at some point, they decided that it was best if they modified the license to go from an open source license, which was Mozilla Public License 2, to the next version that was going to be BUSL, which is the Business Source License.

That is a source-available license and not an open source license. Not only that but they also went to the license change and they added a bunch of amendments to it around the specifics of how you could use the tool. One of the specifics there was that if you build a product that competes with their Terraform product, you're not allowed to use Terraform.

What would Terrateam have become, would they have been included in that list?

Yeah, because if you're using Terrateam, you don't need Terraform Cloud.

I see. It's not even a gray area.

We're not alone. This whole industry had popped up because Terraform was so useful to the world. The pie is big enough for plenty of companies and the competition makes everyone better in our view. This whole industry had popped up around that and they were impacted too. We all put our differences aside. We all like each other quite a bit and decided to make a fork of Terraform called OpenTofu that takes the version before the license change and forks it from there. We were a founding member of that along with several other companies. It is an open source version of Terraform.

It is entirely compatible with Terraform. There are only a few things that are very new where you might have to decide whether you want to use it if you care about switching back and forth. It's the same code base starting from 157, which was last year. They also have a clean room development system where when Terraform comes out with a new feature, they have all these firewalls in place. Someone uses the feature and then reads the docs and then explains to somebody else, “Here's what the feature means.” Nobody looks at the code. They try to understand the feature and how it's documented and then implement it from there.

That's unusual. I haven't heard of that before, especially where GitHub is concerned. Going back a little bit, am I right in saying that no one was expecting that license change? Was there any warning that was going to happen on the HashiCorp side?

No warning. Even if you look at the language, for example, one of the ways that HashiCorp was able to do the license change is they require a CLA when you contribute code. The CLA says we want the CLA so that we can continue to provide this as open source forever. On paper, giving a lot of lip service to the fact that this will always be open source.

All of a sudden, you wake up one morning or open Hacker News or whatever and it's like license change. Can you talk a little bit about how long did it take for you and the other commercial and open source folk in that ecosystem to get together and decide to hit the fork button? I guess everyone is bashing.

The fork button, we did have for a few days. That day, we all got together and started talking and made some group chats to talk in. The initial thing was that we wanted to say, “Here's why we think this is a bad idea. There's a lot of support around Terraform. Please make it open source again.” One thing that is maybe a little bit lost is that all of their open source solutions had the license change, but the community only got upset over Terraform. One of the big reasons for that is because you'll get Vault, Nomad, and these other options. They're like services that you use and run and then all your functionality comes from what HashiCorp puts in those.

Terraform is closer to a programming language where the value is in the ecosystem of the community. You have a lot of people called providers. That's a library for Terraform that made these providers that have helped Terraform grow because it's made it more useful. Hashicorp turns around and says, we're the only ones that can benefit from this ecosystem. A lot of people and I'm sure some people didn't like that Vault and Nomadic changed, but a lot of what made the community upset was around Terraform specifically because it's such a community-centric project.

It's interesting as well because I guess people doing MBAs in twenty years will argue about what the value was of that community provider stuff. In my opinion, a huge proportion of it. They can go and do the AWS and the Azure stuff, but all the stuff that the long tail of services that people had contributed those provider definitions to that because that was part of the beauty of Terraform. It's like you knew that unless it was something super esoteric or new, it was going to get managed for you. That didn't have anything to do with people being paid by HashiCorp to write that stuff.

It's like if Python one day was like, “We're going business license because enough of our users aren't contributing back to us.”

It is not a good idea to put your business at the whim of somebody else’s licensing decision.

You cannot run Python programs that people are contributing to.

Another thing too is a lot of the rhetoric around this was focused on you have these companies that are using Terraform and not contributing back, like calling us reloaders. What's also frustrating is a lot of people who were in those companies said, “I worked as a consultant for years before this company and I told people to use your products. I contribute back. Maybe I'm not on the commit list, but I am part of why Terraform became successful.” It's unfair to start claiming that because I don't have a commit in there somehow I haven't contributed.

The Machismo Around Commit History

That's a good point. That's a great point that doesn't come up often enough when we're talking about this stuff. It's interesting because I feel the same. I work on OpenFeature on the governance. I'm on the governance board and I've been involved almost since its inception. If you were to look at the raw data in GitHub, you would think that I've had virtually no involvement in that project.

I understand that it's hard, but it's an easy thing to quantify, pull their commit data out of all the reports in that GitHub organization, and see how many have got my public key associated with them and it will be very few. I don't know what the quiet word is, I need to be careful here, but there's a little bit of machismo about like, “How many commits have you got?” You're right, it's like, “I can have zero but I could have done more for the project than you did because I could have put it into seven Fortune 500 companies.”

It's one of those things where it's when you're in some heated situation and you need to make your point, it's easy to go to the thing that data exists for and is easy to calculate. It's a lot harder to talk about this more in the ether thing that you did that is very clear, it adds value, but you cannot point to a number that got higher directly because of something you did.

That's a downfall of these open source communities. It's interesting as well. You're seeing the almost exact polar opposite of this with what's happening with WordPress and Matt Mullenweg who hasn't had commits in the project as far as I understand it for years and years. I don't want to go down that road but doing all this stuff.

He has all the power. It's this thing about where the influence, control, power, and all that stuff lie in these communities? You're right, commit history is telling a bit of that story. Maybe in some projects, they tell a lot of that story but there's a huge number of circumstances where you don't want to be taking too much notice of them.

You guys have it together and the obvious thing to do is we're going to take the latest version of Terraform, roll it back to the last commit before that license change, and then push that to a new repository, and then that will be a thing that we can all contribute to. Did you immediately start discussing how that would be governed and the governance structures around that project?

Yeah. Because of the context of this license change with which OpenTofu was made, everyone knew that it was important to be able to give the community of users a guarantee about the future license. From the first day, as far as I can remember, the goal was to get it into Linux Foundation and CNCF. Those have requirements on you can only have open source projects in there.

Additionally, there's no CLA when contributing to OpenTofu. There's no legal mechanism, except if you had wanted to try to find every single committer and get their permission, which isn't feasible in a large project. Additionally, there's this idea that we want to give the world this guarantee about the future of this and it being open source. Something like the Linux Foundation comes with a structure for governance, so we don't have to figure it out ourselves.

I hadn't considered it as like, you don't need to do too much thinking around that. It's like we just need these two stamps of approval or we need to be on these two pathways. That's all we need to do because everyone knows, or people generally know that if it's CNCF or the Linux Foundation if it's under those umbrellas, they are open sourcing in the truest sense of the word. Was there a decision explicitly to do both of those as opposed to one?

One is a path to the other if you fit into that other one. You go to Linux Foundation and then you can go into these specifically we're like a cloud-native tool.

I see. Was there an immediate unanimous agreement amongst the stakeholders in those early discussions? Were there people wanting to go down different routes at all?

Not that I can remember. Everyone thought that it was a recognized name. There's a lot of trust there. Given this situation, trust is what you want to give people the most. A part of it also comes with the fact that it cements that this is a community project, the whim of a single vendor. You do guarantee more community involvement that way as well, or you guarantee that if you're part of the community, you want to be involved. There's a pathway for you to do that as well.

Exploring The Actual Technical Work

In terms of the actual technical work that needed to be done as part of that fork, how easy or hard was that? I'm presuming it's more than a search and replace for HashiCorp and the name Terraform. Were there a lot of hooks into their infrastructure and their services that were, I guess all that build systems and stuff there must have been some surprise, or some private stuff in there. How much work was that?

The biggest thing was we'd mentioned this provider registry and model registry before, which is something that HashiCorp hosts, and they do not allow non-Terraform binaries to hit that. We'd be in breach of license if we didn't or if we did that. Standing up all that infrastructure was probably one of the largest efforts there, which is fundamental to using the product. You need access to these providers. When you do a Tofu in it, it has to download the providers that you've specified that you want from somewhere.

That's analogous to a package repository like NPM.

It has searchability and documentation generally on there. You can see exactly, here are some examples of how to use it, and so forth. It's a centralized place where you can discover the things that you need.

Did you need to get those provider contributors to re-push all their stuff into some package position that you'd built or were you able to copy all that stuff off what was the pre-open source version of Terraform?

‍

We didn't have to go out to individual providers or people developing providers. The index is available. It's about how you serve that index that needed to be built.

It's interesting. I mentioned WordPress, but a lot of the Hullabaloo is around exactly that. It's interesting because the codes are all there, but who owns the thing that's serving those WordPress, whatever they call plugins or whatever? You're talking about the same issue.

In this case, too, it's not necessarily that serving this data is on a per-request level technically challenging. It's that the scale is quite large. You have millions of downloads of certain providers per week or month. You need to immediately be able to serve people at that scale.

How did you do that? Who paid for that? Did you reach out to folk like Cloudflare and say, “Can you give us a few terabits of bandwidth?” What was that?

I forget. We talked to Cloudflare and Fastly. Honestly, I don't remember which one was at the end. Both of them were very generous. The upside of being a real open source project, especially a big community one. All these companies benefit from open source, an alternative to Terraform. They were happy to offer us some service at a certain level to provide that open source functionality. That was great.

How long was it from that fork point to people legitimately reliably using OpenTofu instead of Terraform like in a production environment? At what point would you have said where one dot zero is a multifaceted service?

The first GA build came out five months later, and then two months after that version came out. That had no new functionality. Effectively, here's the version using all of our stuff and this is what we're going to build on.

In terms of the migration path for folks who were previously on HashiCorp stuff, was that a solved problem now?

It's super trivial. All you do is go into your repository and type “Tofu-upgrade” in it. If it turns out, for whatever reason, you don't want to use that, going back you type “Terraform-upgrade” in it. Going back and forth is trivial.

Did you speak to people at HashiCorp or did anyone as part of the OpenTofu community, was there dialogue with them around this?

I don't think there was any way that there could have been as well because what you heard from HashiCorp was going through a structured press release system like whatever department inside there. I don't think there's any mechanism to have a genuine, transparent conversation with anyone at that company in the midst of this very PR-controlled change.

What about now? Has that changed at all?

Not really, especially since it was announced several months later that IBM is looking to purchase HashiCorp. There's this whole other thing where now you cannot talk transparently and publicly because that might impact that. It's one thing after another for things that could get in the way of having that conversation.

You knew that whatever they said, it was going to go through seven layers of PR speak and it would have all been watered down to nothing anyway.

I don't know if there's anything that could have been said. Part of the license change was the statement that if you need an alternative license, you can talk to our license department and get one. That is something that on the surface sounds like an olive branch, but let's be clear. It's not a good idea to put your business at the whim of somebody else's licensing decision. I don't think there's any meaningful conversation that could have happened in any way at that point in time.

That would have generated any value for either side of this. In terms of OpenTofu now, how are you guys tracking stuff like adoption and scaling? How have you found that? I cannot think of many analogous situations of forks operating at that scale of in-flight stuff and complexity going on.

The proxy that we use, and honestly, I don't have numbers other than I can say they're going up and to the right, is the provider downloads. You can see that going up there, which means as that proxy, people are consuming it quite a bit. A common way people use these tools is they put them in their CICD or something like Terrateam, and we run all that inside of an ephemeral compute. We're redownloading all that stuff every time we run something. That's how peership everyone does it. It ends up being a pretty good proxy. It's going up. We have customers that switched one night and they're like, “I'm over here. I'm happy.”

I guess into the start of the early days, that would have caused you a little probably see a visible bump in your charts that you probably cannot see anymore because of the scale of it.

Just the ease of migration. Because it's a fork, I think that sometimes it seems like it's a new project in people's heads, but no, it's a fork. Up until the last few months, it has all the same code in it. It's not like there's some gaping hole somewhere or something like that.

Options are good. That is what open source is about, and we should want those.

Exploring The Divergence Within Terraform

You mentioned that there are a few things where there is divergence with Terraform itself. Has there been discussion or debate around whether the projects should concern themselves with new verbs for the command line or outside of the provider repository and code base? Has there been a difference of opinion or two groups forming in terms of whether we should be what Terraform was and will always be, or do we want it to do whatever it is a new thing that it can do?

There are different views. Being a community project through the LF or Linux Foundation means that at the end of the day, it's understood that if you want it to diverge in some way, you have to get community support for it. There is this mechanism to slow down. I'm not saying slow down in a negative way but to tamper with any pushes to be radically different because it has to come from what the community wants. The things where it has diverged have all been longstanding features that have been inside the HashiCorp Terraform issues and are finally now being brought over to OpenTofu and implemented by them.

That's super interesting. In terms of the relationship between OpenTofu, all of that work that we've talked about and Terrateam. Has that had any knock-on effect with Terrateam? Do you see that as an opportunity for the business commercially? I don't mean that in a cynical way, but it's like there's not going to be a structural change in this business like this ever again probably.

We didn't look at it from that perspective. Our initial reaction was about how this license change is not great for us, but it's also worse for the community. The way that Terrateam approaches this problem is a way that if you are into it, HashiCorp is not going to solve it that way. You will always be underserved in how that solution works. We are very focused on people who want to solve this problem in a very particular way. If you want another way, there are plenty of great out solutions for you.

It's like every lost sale to us is not a sale you would have had. This also grows the community too. You get more people using it and more feedback on things that don't work or ideas and all that. For us, it was more about the fact that this change sends a bad signal to the community and also restricts their ability to have options within it. That’s what was important for us. Of course, someone can hear what I said and say, “You're a business.” You’re like, “Sure, fine.” There is a reality there that options are good and that's what open source is about and we should want those.

The OpenTofu projects, firstly, are coming into existence, but also maturing as quickly as they did. I guess there's been an explosion of new businesses that are operating in that ecosystem now. Is that fair to say?

Yeah. Even if your underlying business didn't compete in a way where you could have used this, lawyers don't like the gray area. You become reluctant. There's friction there because you're not quite sure. Now you can say, “I have an open source solution here. I can build this business. You don't have to worry about it.” There are other things like asset management and producing. For example, some people are making it so you can make a change through the AWS console, and then they produce the code for you. Those businesses now have an absolute green light where you can continue working on this and expand without worrying about what the future holds for this underlying technology you depend on.

What's Next For Terrateam

Before we finish up, what's next for Terrateam? You mentioned Pulumi support as well, which you haven't talked about. Pulumi has a super interesting relationship with all of that Terraform code base that we talked about in its early days. That's fair to say, right? It ingested it. A lot of the engines that Pulumi has was relying on all of those Terraform providers.

Just to be clear, they have their own engine built from scratch. It's open source, but part of their engine allows them to bridge Terraform providers so they can consume all those. Before, they had to explicitly create a mapping between providers and Pulumi code. Recently, they released something that automatically makes that. Now, all the providers are available.

They depend on that element of the ecosystem additionally because this restriction on the HashiCorp registry can only be called from HashiCorp products. They probably depend on Tofu's registry for that functionality to work as well. It's great for everyone in that regard. Pulumi shares conceptually a lot. It's an IAC tool, Infrastructure As Code. It shares a lot with Terraform. Terraform came first. Let me pick up after that. It's focused more on the developer side of the equation.

The idea is that you can implement your infrastructure in Python, TypeScript, or Go. Terraform uses HCL, which is a bespoke language that is a configuration language effectively. They cater to these different markets. We added support. We had one customer that is interested in it and it was easy to add support, given how modular our system is. I did it on a Friday afternoon. It is very raw. It's in beta, so we want more feedback on how to improve that. I think over time, it's going to get a lot better.

Are there other engines and ideas that you guys are looking at in terms of support for your platform?

In terms of our roadmap, we see expanding the different functionality in as many dimensions as possible to serve as many people as possible. Right now, we're on a big push to expand the VCS vendors like GitHub and GitLab. Right now, we're focused on GitHub. We want to get GitLab support next. The reason those things are coupled is that we do things depending on how you've set up your teams in your provider.

We consume that to understand what teams can do what because we want to have as little duplication as possible. We want to depend on that. There is some integration work there. We have Pulumi and Terraform, and those are the big ones. There are also thoughts on maybe we can expand towards Ansible support or something like that to get all of your things in one spot, but that work is not super concrete.

Being open source means people can open issues, give feedback, and implement things themselves. We're open to those discussions. I didn't hit on this when we talked about it before, but one benefit to it is you get people more willing to open up feature requests with you when you're open source. They're like, “This is cool, but I cannot use it because of this.” Whereas before, they might look at your proprietary and be like, “I got to make an account to make a ticket or something like that.”

I know there's an individual gatekeeper who's going to decide which PRs to delete. For me, that would be like, “What are the chances of this happening?” Probably zero. Malcolm, it's been super interesting talking to you. This is a little bit adjacent to my world. I remember watching all this noise from afar and thinking what an audacious effort it would be to fork something that scope. Also, the importance to those users of Terraform.

I want to thank you for all the work that you've put into it. I congratulate you and everyone else involved in OpenTofu because to do what you've done in that timeframe, I wasn't cynical about it, but I'm glad I didn't buy off that thing that they're now chewing on.

Thank you. All the hard work is being done by people hired specifically to work on OpenTofu. Some appreciation out to them. They're interacting with the community and try to do what the community wants. I'm pretty optimistic about all this. All signs point to this is what people want. At that level of their infrastructure, they want to use what's going to be open and guaranteed to be open. That's what we're providing.

I’m looking at the OpenTofu website. There are some companies there that you rightly list as covering what must be way over seven digits a year in engineering effort to work on the project full time. I see a lot with especially the CNCF projects. Quite often, some of those businesses or large organizations don't get the recognition that they deserve for saying they're going to spend millions of dollars over the next few years committing to that. It's great that you guys have that on the homepage.

This is maybe in this platonic ideal, a lot of open source is developed by people in their free time, but that's not how a lot of things work. This is as close as you can get when, in this situation, you have multiple vendors providing support for the same thing. There are checks and balances there, and that is great for everyone.

‍

Maybe we can catch up in two years and see. We can talk through the history of the flame wars that you've had for the next two years. I'm joking. It's great to see. The best thing about this is that the maturity of open source now is at the point where it’s like what you've talked about. There never seemed to be any contentious decisions in that pathway from the license change with HashiCorp to where you are now. I'm not saying it was easy or it wasn't a lot of work, but the structures, the law, the attitudes, and the opinions of people are like this is a pathway now. Is that fair to say that you haven't had to make any contentious decisions because that road was mapped out in front of you?

Yeah, absolutely. Everyone involved in the project agrees that this is something where the community comes first. Because we all have that agreement, it makes a lot of discussions a lot easier. There hasn't been any situation of strong acrimonious debates or anything like that. This is the structure of the governance we have. We follow that and that is what we all agree is the right thing to do.

Contact Information And Closing Words

That's great to hear. Before we go, where should people go to learn more about or get involved in the community for Terrateam and OpenTofu? Where's the best place to check out?

You can find Terrateam at Terrateam.io and we have a section in there where we'll link out to anything related to OpenTofu. Everything Terrateam is there. Also, you can check out OpenTofu on OpenTofu.org.

There are multiple ways of interacting with both of those communities that you find there.

We have a Slack and OpenTofu has a community Slack as well.

It's part of the CNCF one, I guess.

The OpenTofu one is its own thing currently.

I wish the Discord model was there before it started.

I know.

It's tough having eighteen Slack accounts open, but there we go.

We can come back for a rant episode if you want to talk about that.

Malcolm, thanks again. We wish you all the best for the future.

Thank you very much.

Important Links

• Malcolm Matalka on LinkedIn
• Terrateam
• OpenTofu
• Pulumi
• GitHub
• GitLab
• The Software Paradox

‍