Eric Anderson:
Hi everyone. I wanted to give you a quick update on Contributor. We are now 70 episodes in, we publish almost every two weeks, and we have now a great group of open source founders and some of the fans of those projects, and I need a community manager. If you want to help us out to inspire and organize this group of folks. Look up by our email on Contributor.fyi.

Kuba Martin:
It's much more stable if you see an open source project where contributors from many companies, from many projects, many individual contributors are working on together and together collaborating on RFCs on change requests on issues.

Eric Anderson:
This is Contributor, a podcast telling the stories behind the best open source projects and the communities that make them. I'm Eric Anderson. I am excited to have Kuba here who's going to tell us about OpenTofu. Welcome to the show, Kuba.

Kuba Martin:
Hey, nice to meet you. Thanks for having me.

Eric Anderson:
I think OpenTofu might be new name for some people. Could you tell us briefly what OpenTofu is?

Kuba Martin:
Yeah. Sure. So OpenTofu, which was previously called OpenTF, is a fork of Terraform really. Now, to give you some intro what Terraform itself is and what now of course OpenTofu is, it's basically a system to declaratively manage your infrastructure using code. There is a special DSL where you can basically describe the desired state of your infrastructure, "I'd like one EC2 instance, I'd like one as free bucket, or three as free buckets." You give this kind of to OpenTofu, and OpenTofu will figure out how to make your infrastructure happen, how to create all of this without you clicking around in the UI now. You can then change this code, you can add more S three buckets, add some load balances, remove some stuff. You give it to Tofu, and then Tofu figures out the differences between what's there, what you now want and will give you a plan of how it could achieve this new state of your infrastructure. How it could move this existing state to this new state.
And then once you approve it, actually execute on that. OpenTofu really is also an ecosystem of providers. So providers are actually kind plugins, which some of them are maintained by the core, most of them are community maintained. There's over 2000 providers right now. And providers, you could call them connectors to both cloud providers or SaaS backends, they basically tell Tofu how to communicate with a given backend, what is available in that backend, how to interface with that backend. Right now, to be honest, any new SaaS almost coming out will probably at some point also distribute an OpenTofu provider or Terraform provider because it's just like the lingua franca of defining your cloud infrastructure and you can kind of infrastructures code all the things this way.

Eric Anderson:
Got it. So OpenTofu is a infrastructure as code framework. Maybe you could say it's part of the most popular family of frameworks, the Terraform OpenTofu family. It's Terraform compatible. Fantastic, and how did this come about? I think that's maybe the most interesting part of our discussion Kuba, and tell us first who you are and how you got involved in the project and then maybe how the project came to be.

Kuba Martin:
Sure. So I'm Kuba. Specifically, I'm actually employed at Spacelift as CI/CD provider where I'm a software engineering team lead, but I'm involved with OpenTofu as the interim tech lead of the project. The company I work for is one of multiple companies that are behind the OpenTofu initiative, which is how I got involved in the project. And now, maybe moving over how OpenTofu actually started, and what the history in short was. So in the middle of August you might've noticed the news for those of you that know Terraform, that Terraform changed its license. It was previously under their MPL license. The license along with other HashiCorp projects got changed to the BSL license, which is a source available license, but not an open source license. Which kind of sparked some uncertainty, and we as some companies that were heavily involved into their ecosystem quickly decided that we'd like to fork Terraform into a new project that will continue in this MPL, this open source spirit.
Now, it's worth noting we're very thankful to the work by HashiCorp by setting up this whole community. This ecosystem, we understand that there might be some reasons why they chose to do what they did and now we're basically aiming to continue this in the open spirit. Terraform was before as the MPL version, OpenTofu. Now after this BSL change guard announced, basically a couple founders of these companies involved in this ecosystem got together, they very quickly managed to get an engineering team together that was basically split across these multiple companies. It happened very, very quickly, and we very quickly decided that well, "We'll have to fork this", and started basically doing renaming [inaudible 00:05:30]. Making sure there are no trademark infringements, stuff like that, so that we could publish this fork as soon as possible. It's actually not as simple as just clicking the fork button and saying, "Okay. I'm now a fork of Terraform, I'm now a separate project."
There's actually a lot of trademark stuff you have to make sure works out right before you can do this. Now afterwards, there was also another change where the Terraform registry changed its terms of service. And so the Terraform Registry is the place where all the providers and also reusable modules are hosted. It's mostly a proxy for GitHub, because most of the providers and modules are hosted as GitHub releases, but it's basically the resolving discoverability and documentation layer. So that terms of service change that it can only be used with the HashiCorp Terraform, which was also another thing that we then needed to replace, which is the registry. So this is another thing that is part of OpenTofu will be introducing, which is an official registry. We announced this all of this at the end of August. At the beginning of September, we actually made the fork public.
The community response was absolutely incredible, so we got both a lot of traction, we got a lot of people who wanted to contribute and help in any way they could. So it was a big challenge to even basically get this project up and running and keep up with all of that, what's happening. And then in Bilbao, at the open source summit of the Linux Foundation, at the keynote, we first of all announced our name change to OpenTofu, but also announced that we're joining the Linux Foundation as a Linux Foundation governed project. Right now actually, by the time this is published, we will most likely have our alpha release out, and this alpha release will basically be a first version of OpenTofu that you can actually download, that you can take for a spin locally that has its own registry, that maybe isn't production ready. Don't use it for production yet, but it's good enough to actually get your feet wet.

Eric Anderson:
There's a lot to discuss there, and I'm going to actually kind of earmark most of it and I want to go back to just this idea of forking.

Kuba Martin:
Sure.

Eric Anderson:
We recently had the folks behind Live SQL, which is an emerging fork of SQLite, and so we'll revisit some of the topics there, but Kuba, I feel like in the spirit of open source, we always say, "You can do whatever you want." There's ultimate flexibility, and if you don't like the way a project's headed, the answer is always you can fork it. But then when a fork actually happens, I think there's a lot of angst, where folks are like, "Is this a good thing? Is this a bad thing?" Maybe that angst feels like inappropriate. Given the spirit of open source, you can always fork it.

Kuba Martin:
Totally. It's something big and I understand that it also creates a lot of noise around it. I think there's kind of two kinds of forks. On the one hand, you can be doing small forks, you just add a single feature because you just need one improvement, which is actually a big value of open source that you know. You're using an open source project and you can just take it other feature you're missing just for yourself, and keep up this fork mostly synchronized with the origin to keep your feature in. Because for example, you want end-to-end state encryption for Terraform, that is something we heard people forked it for, implemented it and used it this way for many years, but with such a big fork. I think generally what people can be worried about is that it definitely creates kind of a split in the community in a sense.
You will have to then make decisions, "Do I go with the Hashi Terraform? Do I go with OpenTofu?" Now, until now, as I said previously, Terraform was under the NPL license. Now it isn't. So we feel like we're kind of the continuation of this open spirit, but in practice at the same time, a lot of parts of the ecosystem will hopefully stay compatible. We plan to stay compatible with Terraform. At the same time, provide us when you are a provider creator, those will work with both Terraform and OpenTofu, there won't be a split on that level. This is something that can be very easily used across those. But regarding even forking, like creating a proper almost you could say hard fork, it's not a fully hard fork, because we're planning to stay compatible with a lot of new features that will be introduced in future versions.
But in the sense it is a hard fork in that we are a separate project. We are a completely separate project with a separate roadmap with many more features that we are planning to implement on top of what is there in Terraform. And if you want to do something like that and also market as something like that, have the community use it as something like that, you'll have to make sure that you know, as I said, rename everything. You make sure there's no trademark infringement left.
You have to actually spin up the whole process of developing this, you have to hit the ground running. Because you already have this big community. You don't get to kind of build it very organically. It's like you share a community with this other project and that means you'll get a lot of community interaction right away, so you have to very quickly try to get a good RFC process, change process, working with contributors, getting a place to communicate with this community, getting a workflow to work on pull requests with the community. Handling those pull requests, handling those new issues. I believe those are all big challenges when you are doing actually a proper heart fork of a big project. And as part of that, assuming the community of that project, starting to share it, and getting a lot of it to interact with your project right away.

Eric Anderson:
Yeah. You've mentioned a few things along with the process of forking I want to go into. One is trademarks. I think a lot of people don't recognize the implication of trademarks and open source. Maybe there's an expectation that everything follows the license, but in fact, I was an investor in Chef, and they went through a similar process. And in this case, the parent company often owns the trademarks and even in a neutral governance situation, like an Apache project, the Apache Foundation would own the trademarks. And so any fork of a major project probably involves some trademark compliance efforts. And what does that look like, Kuba?

Kuba Martin:
Totally. So in general, the point is that you don't want people to mistake your project for the original project. You want it to be clear that you're a different project, and that should be visible in user facing text on the website of the project, things like that. This is like the core thing, and since any tool prints a lot of CLI text in this case, there's a lot of ground to cover that you have to go through the whole code base to make sure that generally your tool shows itself as OpenTofu in this case, and not as terraform. So it's clear when you're also using it that, "Well, this is OpenTofu. This is not Terraform."

Eric Anderson:
And then you talked about license just briefly, but that's on some level the biggest change. And I suppose you had a decision, do we stick with the license that was used previously? Or, is this an opportunity to rethink the license altogether? And where did you come out of there?

Kuba Martin:
This is actually a very interesting topic because it kind of senses how open source projects manage their licensing, manage their copyright, and manage how their contributors transfer this. Now, I'm not a lawyer, so there might be some missing pieces in what I'm saying, but in short, when you have an open source project like Terraform, it had the MPL license, which is a weak copy left file-based license. Which means that in general, if you make changes to any of the files in the Terraform project, you have to publish those changes if you're distributing the binary or using the binary. Now, generally if you have a license like that, you can't just take the project and say, "Oh. Actually, now it'll be a different license." You have to at adhere to this original license, you got the code under. Now, all existing code is obviously under that license, which means it's very easy to fork from the last commit with that license.
However, projects also very often have an additional clause you have to sign before contributing to their project. So a common one is a CLA, and generally what Class do is they give a copyright license to the owner of the project. And thanks to this copyright license, for example, HashiCorp in this case can actually change the license from MPL to BSL. This is not something we can do because we have the code under the MPL license. Moreover, there are alternatives to doing the CLA. First of all, obviously you can have no other document to be signed by contributors. And then implicitly, you generally get the contributions under the same license your project is in, like the MPL license. Or, there's also a more lightweight form, which is actually what we use and we have adopted. It's the DCO, the developer certificate of origin. It's a fairly popular one across open source project.
And generally what it means is that they're signing it. You confirm that this is your work, that this is not copyright coded, copied, it's something done by you. You are contributing this, you are giving this away under the NPL license to the owner of the project. Which means that for a project like OpenTofu, all the code we have, we have it under the MPL license. We actually are incapable of changing the license to an arbitrary other one, unless it's compatible with the MPL. But we can just weaken the license, for example, and go to a more liberal license like Apache or MIT.

Eric Anderson:
So presumably you could change the license for all future contributions, but then it kind of muddles the current and future code base, and so it's just simpler to stick with the existing license. And then your comments on a CLA versus a DCO versus nothing are helpful. I imagine a lot of developers have run into contributing to a major project facing a CLA and not quite sure why or what this means. Maybe the last legalese question for you would be governance. So if we've covered trademarks and license, there's this final decision about, "What's the governing body or system in which decisions are made with regard to the project?" And you've already alluded to the fact that you have a plan. Tell us about it.

Kuba Martin:
Sure. So as OpenTofu, we have a technical steering committee that's basically comprised of various projects and companies backing the initiative. Other than that, we're under the Linux Foundation's governance. Now, the technical steering committee right now, basically five companies have a seat, Gruntwork, Harness, Spacelift, envzero, Scalr. But we have a few seats left. So for example, if HashiCorp would ever like to join the OpenTofu community, presumably they'd get a seat at the technical steering committee. Or, if any other project or company want to pledge their support in a big way like contributing engineers or things like that, then this is something that generally is a way to get on the technical steering committee. Now, regarding day-to-Day feature development, and also proposing changes to the project, how to make changes in the project, the way we think about it is that all major changes have to go through an RFC process.
So request for comments document. This is basically a process that a lot of open source projects like Rust, Kubernetes, Go, they follow a very similar process where you publish what you'd like to change with some reasoning, and publicly try to get comments from as many people as possible, and then iterate on that RFC. And this is a way also to understand what the community thinks about this RFC, get the community to respond, get the community to express whether this is interesting to them or not. So generally you have this RFC, which each major change even proposed by the technical committee goes through.
Then you have a community discussion fully in the open where anybody can participate, and then once an RFC is deemed having enough interest, it basically goes to the technical steering committee, which makes the final call. The very nice thing about the steering committee is that as it is right now, it's a bunch of competitors having to fight it out in a sense, which makes sure that no change will actually be for the benefit of a single company. So with OpenTofu, you can be sure that there's actually multiple companies who have to come to some compromise, come to some consensus to actually implement those changes and accept those changes.

Eric Anderson:
Awesome. Setting aside the kind of governance and legal aspects, you went through quite an adventure here. I imagine getting to this point, and I'm kind of curious, it would be fun to hear about some of the milestones, like the decision to fork. There was a blog post or some kind of publication written that kind of announced the intention, and I can imagine writing that you might feel like you're going out on a limb. Is anyone going to follow us? Tell us what that experience is like and the response.

Kuba Martin:
Sure. So very shortly after the license change was published, we published a manifesto, as this bunch of companies and projects behind the initiative. We published a manifesto very quickly as the OpenTF Manifesto, which basically described the situation that it's very important in our opinion for Terraform to stay open source because it is, we believe the reason why Terraform is so popular is the ecosystem of providers really. And the ecosystem of providers is there, because everybody felt that this is the tool they'll be able to use for always in whatever way they need. So this is the place I can trust to build providers for. So we published this manifesto, and it actually garnered enormous interest. So we got a lot of interest on 8Chan, on Reddit, and social media. Basically we got a lot of following. We had hundreds of individuals and companies pledge in the manifesto, where they could sign that they support the cause.
We had some companies also join with actually meaningful contributions. All contributions are meaningful, of course, but with some concrete also pledges. And then after this manifesto, like two weeks later, we basically published our intent to fork. So the manifesto was really a call for reversing this license change. We did already start working on a fork, anticipating that we're not sure, obviously if the license will be changed back and it would better start now, but be delayed by those two weeks. But then we at some point announced our intent to fork, which again, garnered enormous interest.
Basically all these posts right away when they were posted were getting an enormous amount of interest right away. So it was like the second milestone in a sense. We've heard a lot of voices that, "All right. You're doing a lot of writing, but where's the code? Give me the code." And well, we tried our best to also get the code out as soon as possible. The moment we had all the trademark issues ironed out, which was again a week or two later after us announcing the intent to fork, we actually made the code base public, which will again, garnered a bunch of public interest.

Eric Anderson:
Kuba, you mentioned earlier this point that not only do you have to fork the project, but there's some other elements of the community that need to be recreated, and one of those is the registry. And maybe that's kind of unique in this situation around creating a community fork, so tell us about the registry and then we'll go into more of the roadmap that you're working on.

Kuba Martin:
Sure. So with the registry, the registry is the place that basically hosts all the providers and modules, or rather it's the place where Terraform calls out to find those providers and modules. Because actually, what the registry does, it tells Terraform, "So hey. If you want to download this version of this provider, here's the URL you can download it at." And for most providers and most modules, this'll actually be a link to GitHub. It'll either be a link to a GitHub turbo, so a repository turbo at a certain revision for modules or for providers, it'll be a release artifact. This is not the case for all providers. For example, the official HashiCorp providers are hosted directly on the registry, but for most providers, this is the case. So in a sense, what is really cool here is that we can basically take a very similar approach, because all of this is in GitHub really exposed and published by the community, we can kind of build our registry around a similar architecture of just being a redirector and a proxy in a sense to GitHub, to GitHub releases to stuff that people host on GitHub.
This includes some caveats like us needing to keep up mirrors of the HashiCorp providers, like the AWS provider, Google Cloud provider. But other than that, it's fairly straightforward in that design. Though right now as we're nearing the alpha release, we have a registry version that's mostly an MVP, just get it working so people can get their hands on OpenTofu. But for the stable release, we'll actually have a big RFC process for this. We'll have a public discussion around the possible approaches we can take, and then discuss them as RFCs, and actually find out which approach to take and which we choose. Because whatever we choose for the stable release is here to stay.
So we kind of have to take our time here to make sure that whatever design we choose for the stable release will be easy to maintain for the core team, will be usable for everybody, and will also be, and this is really, really important, a drop-in replacement for existing Terraform users. So you know, have some Terraform code base, you want to just use OpenTofu with it. You don't want to be changing providers, modules, addresses, et cetera. You don't want to be rewriting stuff. The ideal case for us would be for engineers in a single team to be able to use both Tofu and Terraform across different engineers and be able to work together on the single code base. That's kind of the target we set for ourselves for the initial stable release.

Eric Anderson:
And this registry is a service. So now the kind of OpenTofu group is kind of managing a service in addition to a project, right?

Kuba Martin:
Yeah. Exactly. So this is why it's hard, and this is why we have to think about it hard, because you then have a foundation that needs to host a service that actually costs a bunch of money to maintain. Fortunately, there are companies who are willing to pledge and donate the services. Like Fastly, who basically said they're happy to burn the bandwidth requirements that will have with the provider serving, for example. Those are things that really help, and those are things that really also help in open source projects, that actually such companies are very happy to support, to sponsor such things to make it easier for such projects to host such services.

Eric Anderson:
Great. And where does the project go from here in terms of roadmap and are there places for listeners who kind of are excited by this conversation to get involved?

Kuba Martin:
Sure. So basically regarding the roadmap, I won't tell you anything concrete for the roadmap, because kind of the core tenet of OpenTofu is to be more open, to be more community driven, to use this RFC process. So we generally first have to go through the RFC process for some features to actually be able to confirm, "Yes. This is something we're doing." Now, we have some ideas that is important. Those ideas are also going through the RFC process or will go through the RFC process. One idea is end-to-end state file encryption I previously mentioned that is a very commonly requested feature from Terraform is that state files, which is where Terraform stores the current state of your infrastructure, and plan files, which kind of contain a plan that you can later confirm, very often contain sensitive information. They contain secrets, database passwords, stuff like that.
And you generally store the state files or plan files as free buckets, or other backends, state backends. So you have to trust your state backend to store the sensitive information. Now in effect, this state backend is just a blob storage, and blobs can be encrypted end-to-end very easily. So one of the features we are kind of keen to work on is end-to-end encryption for these end-to-end encryption. That would be integrated with either key you provide or secret management service like KMS, to transparently encrypt all those state files and decrypt them so that you don't have to store those sensitive values. You don't have to trust your state backend to store those sensitive values. The beautiful thing is also that a person who previously tried to get this change into Terraform is now working on an RFC to OpenTofu, and worked on the POC of this, which is really great to see.
Another one is we've talked a lot about registries. Registries are fun topic here. Right now, the Terraform registry is kind of a custom protocol, and it's a simple protocol. It's not hard to write registry for it, but it's a completely custom service. You have to have a specialized service for terraform providers, for terraform modules. Now, we already have a lot of artifact registries in the ecosystem. A very commonly used is OCI registries, open container image registries. They are used well for container images mostly, but more and more projects are using those for arbitrary artifact storage. Because what OCI Registries gives you is actually arbitrary blob and metadata storage, which is literally what providers and modules are, they are a blob with some metadata. So in effect you can actually very easily, and we did a POC of that basically integrate OpenTofu with OCI registries to very easily store providers and modules on OCI registries.
Just to give a few examples, Docker Up, GitHub Container Registry, AWS container, ECR. Those are basically container registries, so that you can use those in place without hosting a custom service to just host your private providers, your private modules much, much more easily. So that's another one, and those are the main points of the roadmap.
Now, for people who'd like to be up-to-date, first of all, we have a Slack community that you can find in the Read me of the project. This is a place where you can come with discussions with the announcements. At the same time, everything OpenTofu, all RFCs, all enhancement proposals, they're going through GitHub issues, so you can try keeping up with the GitHub issues. Though there's quite a lot of them, we're getting a lot of contributions here as far as issues go. So there is also one more much easier way to keep updated is that in the repository, there's actually a weekly updates file where you can get weekly updates around what the current status of OpenTofu is, what we're currently looking at, what are the main RFCs or issues being discussed right now where we specifically invite you to come join us in discussing, give your input.
Those are the most important things right now. How you can currently best contribute, because this is also not trivial when a project just starts. There's not so many low hanging fruits that you can just pick up from the issue tracker. It's also something that needs to develop, needs to mature a bit for this to be available. So really, there are various ways to contribute. They're not always the most obvious ones, and this is basically the place you can find it. It's mostly submitting issues, taking it for a test drive, actually joining the discussion, giving your opinion as an expert in DevOps and Terraform. Those are all really, really valuable things.

Eric Anderson:
Maybe as we wrap up Kuba, I wonder if you would care to offer some advice to anybody who's ever felt frustrated with a project, seen an opportunity for a fork, maybe there was a similar event that occurred in a project's lifecycle and they're like, "I think we need to fork here." Now that you've been through it, what would you suggest they do, or how would they should approach that situation?

Kuba Martin:
I tell them to first really try to come to an understanding with the current owners of the project, because doing an actual fork is a lot of work. So if they want to fork, I believe the first one is actually trying really to talk with the current owners, with the current maintainers if maybe there's a way to come to a common solution. But if that is not the case of course, and I believe the first most important thing to do is that if you want your fork to really be seen as the new community standard, or if you want this to happen, you have to have multiple entities behind it. Because if you tell people, "Okay. So here was this original project, here's my fork", but both were a single company that is like how will your project not devolve to the same situation?
That's kind of the potential problem. So at the same time, it's also you will have to keep up with the original project. There will be a lot of work involved. You'll need a lot of manpower, very possibly. So it's a very good idea to get multiple companies involved to actually have a very healthy community driven, like open source approach to this, where multiple entities are contributing to this, where multiple entities are working on this together. Because this also shows a lot of maturity and stability for the project. It's much more stable. If you see an open source project where contributors from many companies, from many projects, many individual contributors are working on together and together collaborating on RFCs, on change requests, on issues. This I believe is a very big value in possible forks and very important in possible forks, to get the community behind you to actually benefit this group for it.

Eric Anderson:
Super. Kuba. Really appreciate the conversation today. Anything you want to say as we wrap up?

Kuba Martin:
No. Thanks for having me. This has been great. This has been very fun. I'm happy to have been able to talk about OpenTofu a bit, and tell you more about it.

Eric Anderson:
You can subscribe to the podcast and check out our community Slack and newsletter at Contributor.fyi. If you like the show, please leave a rating and review on Apple Podcasts, Spotify, or wherever you get your podcasts. Until next time, I'm Eric Anderson, and this has been Contributor.