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