The provider framework has been kept MPL, as have the providers, so we will keep being compatible.
We will see what the longer-term future brings, and we'll react accordingly. We also have a bunch of ideas for improvements to the provider ecosystem and their capabilities, but those will go through the public RFC process once it's in place.
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
Do you have an idea on where you stand on incompatible changes that are strict improvements over TF? As a concrete example, https://github.com/hashicorp/terraform/issues/13022 - My only read on this is that Hashicorp arent doing this as this removes a key selling point of Terraform Cloud.
We're planning to stay 100% backwards compatible, and in the early stages we definitely want for it to be easy for people to migrate back and forth between both tools - even have teams with different engineers using different tools.
DSL changes are honestly the thing we'd like to limit the most, but as long as they're backwards compatible, the RFC process will welcome them, and they will be discussed and considered!
The important thing is for features to be opt-in. You should be able to limit yourself to a feature-set that is Terraform-compatible, if you want. If you want to use additional features on top of that, then that will be an option as well - we definitely want to innovate.
> currently temporary Technical Lead of the OpenTF Project
Assuming you aren't committing under pseudonyms, you've to date made a single contribution to Terraform, which was a fairly trivial change (b49655724d2f96f0e68196fb949a0d625abbd60e).
I pity anyone who underestimates Kuba. OK, most people I've worked with in tech are probably smarter than me, but this guy plays in a different league.
I don’t follow? You don’t think they can set up CI and migrate issues? It seems unlikely that there will be major breaking or architectural changes imminently.
Is Hashicorp were to change Terraform protocols without extremely good justification, the project would be dead immediately. The existence of Terraform in its current state is bringing billions in revenue to vendors like AWS and GCP. There's a lot of money at play. Hashicorp wouldn't risk that.
It would be stupid cat-and-mouse game because it would make all previous versions of legacy Terraform irrelevant, and is unlikely to cause much harm in the long run because the same protocols can be implemented by other tools.
HashiCorp manages a handful (~4 [0]) of the providers, while over 2,000 are managed by the community. I suspect breaking the interface would be further damaging to their reputation. The clouds will also have some influence around their provider.
Right, but lets be honest, I don't care about 1995 of those providers. Nobody is using Terraform to manage spotify playlists [0]. The big ones are what matter, and (and HashiCorp manage the big ones)
In one swoop, we've gone from 2k to 300. I had a look at a handful of them, and they're ranging from 10-100 downloads a week. Our CI pulls the AWS provider more often than that.
There's probably 20(?) from the 300 list that would actually cause enough outcry to be worth talking about, out of 2000 providers.
If they do, they likely have to give plenty of notice due to third party providers, and will still have to maintain the old protocol/a for older versions of all the providers.
The providers will support Terraform and update to the latest framework, which may be incompatible with OpenTF at the time. Are we forking those too?