As a side note, we've recently released OpenTofu 1.7 with end-to-end state encryption, enhanced provider-defined functions, and a bunch more[0].
If you've been holding out with the migration, now is the perfect moment to take another look, and join the many companies that have already migrated!
[0]: https://github.com/opentofu/opentofu/releases/tag/v1.7.0
Note: Tech Lead of the OpenTofu project, always happy to answer any questions
For example:
# current method
module "foo" {
count = var.enable_foo ? 1 : 0
}
# better?
module "bar" {
enabled = var.enable_bar
}
I'd also really like to be able to say in an output block, "this value doesn't have to exist, only display it if its parent module is enabled", again without the "count" attribute.
There's a bunch of nontrivial technical complexity though, because of how OpenTofu currently works.
I understand why people were upset about licensing changes but I was not one of them who were particularly bothered. Why should I switch?
OpenTofu is indeed a hard fork. When doing similar features (like provider-defined functions) we try to stay compatible where it makes sense, but there's often some differences (like our more extended capabilities of provider-defined functions[0]) and also new features in Terraform that we're not introducing - and vice versa.
You can check for known incompatibilities in our migration guides[1], based on your Terraform version. In practice, the longer you wait, the more the projects will diverge, so if you still want to "wait and see" I would suggest settling on your current Terraform version for now - otherwise, the migration will just be more work for you later.
Regarding the reasons for switching, I'd say features and community-first process. We're striving to be very community driven in what work we're prioritizing[2] and have received a lot of positive feedback over that from our users.
Some companies we've spoken to see adopting the open-source community-driven project as a way to reduce risk long-term. It's also a way to keep your options open if you're in the market for commercial Terraform/OpenTofu management systems.
[0]: https://github.com/opentofu/terraform-provider-go
Hm, with that logic they could dump MySQL in favor of MariaDB as well
1) Oh, I prefer open source alternative for ideological reason.
2) This software is not really worth that much.
3) Hectoring developers every single time in providing why their software should be preferred over unpaid alternatives.
4) Blaming companies that they are bigger users so they should pay not me.
If these entitled developers who deserve all the money but no one deserve their money just shut the fuck up every once in a while it will be a good thing.
Hey, what if they do - what we do to other companies ... to us ...
presses a red button
Oracle bought MySQL which was forked into MariaDB. MariaDB created the Business Source License (BSL). Hashicorp switches Terraform to BSL which then leads to Terraform being forked into OpenTofu. OpenTofu seems to be getting adopted by Oracle.
Too often it's a failure. Too often it has some upsides, but also is a LOT of work that is discovered over time. Too often it's seen as good BUT now some incompatible new version or alternative requires the whole debacle start again.
I only want to learn technologies that will be relevant until the day I retire, otherwise I'm not advancing, it's all just a treadmill.
Yes, I too wish I could make a living programming in 65C02 assembly on my Apple //e like I did in 1986.
I also don’t see any reason I have to learn about S3 instead of storing all of my files on an on prem CDRW jukebox
S3 will also certainly be around in 20 years.
I think of terraform as a form of insurance. It's "Oops manual change" insurance. In the event that somebody breaks something in the console and you need to undo it, it's exponentially faster-easier. However you have to pay premiums to get this insurance as well as a setup cost.
So is the insurance worth it? It depends on the org. But I've seen small places where it's a small team that communicates well and nobody screws around in the console with stuff they don't understand (and if they break it they can own it). So there absolutely are places where the amount of time terraform costs you (in learning, setup, and extra PR time, waiting for atlantis to finish, locks) is higher cost than the time saved when you need.
That is nonsense.
You just said, equivalently, "Terraform is all things to all people".
We'll inevitably see others large companies follow suite - it was one thing when hashicorp was independent tech company but it's very different when it's owned by a direct competitor.
Which is ironic given that OEL is a direct rip-off of RHEL which IBM also now owns.
IBM employees then initiated the fork of vault which is called openbao. Later IBM buys Hashicorp. The fork might have just been an attempt at leverage in the negotiations but it remains to be seen if it will live on.
One of the things that has always really frustrated me about terraform is that it seems to go out of its way to make you do things in a very annoying, inconsistent way. Part of this is necessary due to the nature of the provider ecosystem, you can't guarantee consistency across providers - and I won't burden this post with my gripes about inconsistencies and annoyances within providers, such as the AWS provider.
Really though the interface has always been terrible (IMO). Stuff like iterating through a nested map using a for loop, which is trivial in most languages, is annoying and obtuse to the point of comedy. God help you if this map contains mixed types. Novices have trouble picking it up in general. It's very easy to start a project that sprawls completely out of control, and there doesn't seem to be a standard at all as to how to organize projects/code, so each terraform project I inherit is wildly different and has its own seemingly unique pain points.
A lot of this has gotten better over the years with QoL improvements within terraform itself - but really, as a developer, I've gotten more than a little tired about the hubris that Hashicorp shows with some of the stuff around the terraform ecosystem. Features that people beg for routinely get told by maintainers that they will not be doing that because reasons or because "it's not possible" (such as dynamic provider blocks). OpenTofu is already tackling many of the gripes and feature requests I've had over the years and are doing so eagerly and have some heavy hitters behind it.
Terraform is good, but it was always going to be vulnerable to competition - It's basically just a state-based wrapper around cloud API's. A great idea, but easy to duplicate. I don't know what they were thinking trying to put this behind a walled garden when they could have used it to get people into the hashicorp ecosystem and sell their other enterprise products.
I've been using terranix, which uses nix to generate a tf.json file, and oh my god is the experience night and day. I can make functions! I can refactor! And if it's a pure refactor, there is nothing to apply.
my process is roughly:
comment out the resource in the module, run a plan -> get output like:
"module.foo1.aws_resource.bar will be deleted"
Then copy my resource in source to module.foo2.aws_resource.bar, the command becomes:
terraform state mv module.foo1.aws_resource.bar module.foo2.aws_resource.bar
I guess this might be harder if you're using upstream "official" modules, but I avoid those like the plague.
Second that. One of my colleagues is working on adding proper tracing to the OpenTofu codebase, to help understand the exact cause of failures.
https://opensource.oracle.com/ (almost endless list)
But then they have take FLOSS projects and abandoned them, see OOo for instance:
https://en.wikipedia.org/wiki/Apache_OpenOffice#/media/File:...
It would be hubris if they tried to then take the moral high ground.
So to move forward with upgrading the Terraform support in their tool, Oracle had two choices: pay HashiCorp (soon IBM) a hefty license fee to resell Terraform, or use OpenTofu which is free and has now proven to be well-run enough to issue a new release with both Terraform compatibility and OpenTofu-specific enhancements, while dodging lazy accusations of code theft from HashiCorp.
This is a no-brainer for Oracle, and it’s great news for the future of OpenTofu.
Good info on our experience here: https://masterpoint.io/updates/opentofu-early-adopters/
Oracle wins a big competitive talking point versus IBM, as well as crushing the value of IBM's acquisition of Hashicorp, and completely eliminating IBM's Terraform inroad into a large group of Oracle's enterprise customers.
If you're an enterprise customer, do you want your enterprise deployments on a company that knowingly does two near-identical implementations, and can't seem to decide on which one to favor?
It's largely because a lot of Oracle DB products where performance mattered (eg. Exadata) needed some sort of a base OS that Oracle could manage and optimize as needed.
https://github.com/VirtuslabRnD/pulumi-kotlin
For Pulumi. When I see the pulumi-kotlin example code I much prefer it over my Terraform scripts. (We picked TF before Pulumi was an option, and waaaaay before it had reasonably typesafe lang support)
This lets you use Pulumi w/Gradle multi-project builds in Kotlin script.
There's also a first-party Pulumi SDK for F#: https://www.pulumi.com/docs/languages-sdks/dotnet/
If you're into Nix, you might enjoy using this to generate Terraform JSON. The language is inspired by Nix, so it feels familiar to Nixers, but it has a better type system that recently includes ADTs, at least on its master branch: https://github.com/tweag/tf-ncl
Even self hosting your state management in a bucket is simpler with Pulumi since it uses lock files on S3 versus a separate DyanamoDB + S3 combo.
I have been using it in production for 4-5 years and used Terraform for several years before that.
This is disturbing because S3 does not give you guarantees required to implement real locking.
(Of course, companies do go out of business, and products stop to be maintained, and the example here is a bit extreme, but the point is that company will do what makes the most business sense)
Oh so you never heard of “suppliers”?
It makes perfect sense for them to push their customers to move to the more permissive licensing to avoid any legal issues.
>
> OpenTofu is a Terraform fork, created as an initiative of Gruntwork, Spacelift, Harness, Env0, Scalr, and others, in response to HashiCorp’s switch from an open-source license to the BUSL. The initiative has many supporters, all of whom are listed here.
I still have no idea what I am looking at. I know that probably means this product isn't for me, but it peeves me when products do this. "What is X? X is like Y!"
It's like using AWS CloudFormation or GCP Deployment Manager, but supports quite a few cloud vendors with the same tools.
I don't know much about Oracle's services so can't figure if this is a huge number of users, of a small subset of their clients.
* Oracle Products (e.g. DB, Fusion, E-Business Suite)
* Oracle Cloud (OCI)
What's telling is that Oracle Cloud's Terraform-as-a-Service (Resource Manager) is still Terraform:
https://docs.oracle.com/en-us/iaas/Content/ResourceManager/C...
Clearly, Oracle must think there is some legal distinction between telling Terraform-as-a-service, and selling+distributing a product _containing_ Terraform that end users then use as Terraform-as-a-service.
Version support here: https://docs.oracle.com/en-us/iaas/Content/ResourceManager/R...
Why Oracle Cloud isn't using Terraform version 1.5.7 which is still open source in Resource Manager is anyone's guess. Perhaps the tool isn't getting much attention recently?
* Oracle legal
Sun and MySQL precede them.
One theory of mine is that we can measure the risk that a project will be relicensed by looking at things like diversity of contributors, trademark ownership, contributor agreements, and license terms. Low risk projects include the Linux kernel (GPL, DCO) [1]. High risk projects include Kubernetes (Apache, CLA) [2].
If this trend continues developers will need to get a better understanding of how relicencing works and may decide to avoid contributing to projects with elevated risk.
[1] https://alexsci.com/relicensing-monitor/projects/linux/
[2] https://alexsci.com/relicensing-monitor/projects/kubernetes/
To me, the obvious questions are who owns the IP, and what are their incentives to maintain the current licensing.
I think "contributor agreements" are the biggest red flag. Though I like them for potentially upgrading a license (say from GPLv2 to v3), not that this always is a good thing.
Yes, in my experience it is.
Permissive licenses like Apache, MIT, and BSD are easiest for the corporate lawyers to approve but also easy for the project owner to relicense. Relicencing Monitor isn't measuring how easy it is for companies to use the software; risk is solely measuring how easy it is to relicense the software.
Copyleft licenses are lower risk than permissive licenses in this specific context as they are viral. A CLA or a very small number of contributors can negate that, as happened with Emby [1].
SourceGraph is probably the best example here (I need to add them still). They switched off Apache 2 and prompted this [2] helpful blog post.
[1] https://alexsci.com/relicensing-monitor/projects/emby/
[2] https://drewdevault.com/2023/07/04/Dont-sign-a-CLA-2.html
Mostly things like copyright ownership transfer is not a thing with OSS communities because it strongly discourages third parties from contributing. Copyright transfers are only needed with some licenses (GPL style licenses that insist everything else is licensed the same way) and cannot prevent a retroactive fork even if you have them. Other licenses allow distributing mixed licensed code and you can just create a commercial source distribution for those because the license explicitly allows that. Either way, anyone with the pre-license change version of the code can fork. That's why Elastic, which used the Apache license and had copyright transfers, got forked.
The more widely used an OSS project is, the more likely it is that somebody will fork it if it is re-licensed. Because that usually means lots of external contributors and plenty of interest from wealthy companies that depend on it. Meaning there are skills and money needed to fund the fork. Copyright transfers don't stop this from happening. Unless you specifically want to fire most of your user base, this just doesn't make any sense from a business point of view.
A failure to fork basically indicates the project didn't have a strong developer community and big companies simply didn't care about the project.
I consult some clients on Elasticsearch and Opensearch. Most of my recent clients now default to Opensearch. Because it's the OSS option. They are clearly spending money to get support (from me and others) but Elastic isn't getting any. As far as I can see, Opensearch now represents the vast majority of new users and is becoming a significant source of money for hosting, training, and consulting. But Elastic is getting none of that.
My guess is that the industry will learn from the repeated re-licensing and forking and subsequent community split that has been happening. Elastic, Redis, OpenTofu, Centos, etc. The pattern is the same every time: 1) project gets relicensed 2) a few weeks later a consortium of companies pools resources together and forks 3) most users stick with open source and the company cuts themselves off from those users.
Long term, I would not be surprised to see some of those companies offering support for their OSS forks (in addition to their commercial offerings) or even reverting the license change. This would make a lot of sense for e.g. Elastic as there's a lot of duplicated effort between them and Amazon. And Amazon gets a lot for free from outside contributors.
I also had the same thought to create some sort of risk metric that could be applied to projects, but I do think your initial metric is lacking some criteria. Foundations like the CNCF and ASF have to be among the lowest risk, and CLAs can be more or less harmful depending on their specific content. I think a big red flag has to be if they’ve taken any VC or PE funding.
However I think the principle of taking this risk more seriously is good and important.
