I agree. It has only been a few months since the split. I have noticed more and more uptake of OpenTofu amongst colleagues, and I've personally switched. The thing that makes the difference is what is running on people's laptops, because that's what people will eventually put into prod.

> The thing that makes the difference is what is running on people's laptops, because that's what people will eventually put into prod.

"It works on my machine!"

"Then we'll ship your machine"

Docker: https://miro.medium.com/v2/resize:fit:720/format:webp/1*Ibnw...

Lol plain old VMs have been shipping your machine since well before Docker was around.

And in some cases, unfortunate git commands will ship your machine too!

That works while OpenTofu and Terraform files are compatible - but once they no longer are, presumably you'd have to standardise on one or the other.

The point is that once they are no longer compatible, people would standardize on the one that they're familiar with which is most likely the one that's running on their machine.

There are enough pretty annoying and long standing terraform issues that if opentofu started picking them off I'd consider switching.

You can kinda see this with vim and neovim where both are continuing to exist and benefit each other.

Encrypted state files are either done or coming soon. That's going to be a big one, since Hashicorp used that as a selling point for Terraform Cloud.

But currently, people are equally comfortable with both; the CLI commands are exactly identical between the two, save for the name of the binary itself. In any org where both are in use, if people are forced to choose at some point, they will have to balance many other factors besides familiarity, such as features and confidence in the platform.

> The thing that makes the difference is what is running on people's laptops, because that's what people will eventually put into prod.

I disagree—I think support of deployment tooling (like Atlantis) is the bigger proof. If you are running terraform on your local machine it is likely a very small company.

There is no incentive for users of tf to move, consumers are not impacted by the licensing changes.

Opentofu hasn't shipped a 1.7 stable with removed blocks yet, whilst terraform is already on 1.8 with provider functions

Hey, tech lead of the project here!

Just to clarify, provider-defined functions are coming in OpenTofu 1.7, along with e2e state encryption. Generally, I recommend not comparing version numbers of Terraform and OpenTofu post-1.6.

Implementing the e2e state encryption was non-trivial, and we wanted to make sure we get it right, so that's why the release took us a while. We also got a slight additional delay due to needing to handle the C&D letter OpenTofu got from HashiCorp[0], but that's all sorted now.

The beta for 1.7 however is coming out this week, with the stable release planned in the next ~3 weeks.

[0]: https://opentofu.org/blog/our-response-to-hashicorps-cease-a...

I'm definitely in the camp that has moved my tiny company infra to opentofu. Thanks for all your hard work.

That’s awesome! Appreciate the kind words :)

In the very early days of Terraform, when it was 2 months or so old I helped a little. How many people did (so much more than me) with all these projects to be later betrayed by relicensing.

    > git log --pretty=format:"%h %an %ad %s" --date=short | grep "Luke Chadwick"
    dcd6449245 Luke Chadwick 2014-07-30 Add documentation for elb health_check
    0eed0908df Luke Chadwick 2014-07-30 Add health_check to aws_elb resource
    96c05c881a Luke Chadwick 2014-07-30 Update documentation to include the new   user_data attribute on aws_launch_configuration
    15bdf8b5f9 Luke Chadwick 2014-07-30 Add user_data to aws_launch_configuration
    8d2e232602 Luke Chadwick 2014-07-29 Update documentation to reflect the addition of associate_public_ip_address to the aws_instance resource
    974074fee9 Luke Chadwick 2014-07-29 Add associate_public_ip_address as an attribute of the aws_instance resource

> How many people did (so much more than me) with all these projects to be later betrayed by relicensing.

Were you betrayed? They did a thing you licensed them to do. That’s the whole point of non-copyleft free software licenses, after all! It’s kind of odd to specifically choose a license which allows others to use one’s code in proprietary software, then be upset when others use one’s code in proprietary software.

If one wishes one’s software and its users to remain free, the answer is to use a copyleft license.

Just to be clear: MPLv2 is a copyleft license.

Doh! You’re right.

They can and did use it in commercial software before relicensing. I don't have a problem with that. It's a betrayal to get a huge community together under one expectation and then decide you don't like that expectation any more. Had they used, even something like AGPL from the start it would not have been successful in the same way, would not have gotten the same levels of outside contributions, so yes it's a betrayal.

It's a limited betrayal, because that license also allows for OpenTofu to exist and fork, but the need to do that is just annoying.

Don't use your project (nor Terraform) but great project name!

Anecdotally, I know several teams likely to adopt OpenTofu when state encryption ships https://terrateam.io/blog/opentofu-feature-preview-state-enc...

IIRC, Gitlab runners gives you a big warning with tf telling you to use opentf, so that provides some incentive.

There's also not any incentive to use the original terraform.