Only Terraform?

[lazzurs]

Giving this is going to be forking Terraform is this also going to fork the other Hashicorp tools or just Terraform?

I would rather see a foundation take over all of the Hashicorp tooling chain and not just Terraform.

[EamonKeane]

Probably only going to happen for Terraform, see e.g.:

Terraform is more like Linux and Kubernetes.

https://twitter.com/monadic/status/1691154424708657152

[SeanKnight]

Perhaps CNCF would be a good home for the forks.

[eadderley]

Given that the earliest signers are companies that make their money off of Terraform in some way or another, I don't think that's likely. It's kind of weird/to be expected because the means by which you could make money off of much of the rest of Hashicorp's stack is already heavily controlled by HC's Enterprise licenses prohibiting that.

[ZIJ]

This initiative's scope is only Terraform for now for 2 reasons:

1 - Terraform ecosystem alone is large enough to warrant a dedicated effort

2 - Terraform differs from Vault and Hashicorp in one fundamental way. It is not a piece of backend that someone could host and charge management fee for (Unlike Vault or Consul or say Elastic or Mongo). It's a language, with a CLI. Much broader ecosystem; much less reasonable move by Hashi. It is sad but understandable for Hashicorp to prevent commercial distribution of Vault for example. To make use of Vault you need a Vault server. Fair enough. But Terraform is different. The server part (Terraform Cloud) which Hashicorp tries to bucket together under Terraform name is not required; and that server part was never open-source in the first place! So unlike with Vault, Hashicorp isn't trying to limit commercial of open-source code. They are trying to force everyone who builds on Terraform the language to only use their closed-source server for running it.

[bilalq]

How broad is "ecosystem" defined here. What about CDKTF?

[jnicholls]

I want to parrot @bilalq's question. I see CDKTF as intimately a part of TF, in the same way that HCL is intimately a part of TF: they are both higher-level authoring languages that render down to TF JSON, fully understanding that HCL is much tighter to the raw JSON config structure than CDKTF is. I'd love to seek clarification of the following:

1. Does the foundation seek to also maintain a fork of CDKTF?
2. If not, can the foundation shed clarity on whether or not it aims for CDKTF's output to be executable by OpenTF in the same way it is with TF? Is the way that CDKTF is layered on top of TF well-enough understood by OpenTF to even make this judgement?

Thanks in advance!

[chester89]

I'd like Vault and Consul included as well. But as @eadderley mentioned, that's very unlikely.
I haven't heard of any companies that host them and/or provide operational support, except Hashicorp with their HCP offering

[JM2K69]

I think packer need to be fork like terraform.

[orbang]

Without CDKTF, terraform is pretty much useless for a lot of companies. If OpenTofu doesn't maintain compatibility with tools like CDKTF (which is also a language, not a server product), I don't think it will be viable for a lot of users

[castrillo-clorian]

As @JM2K69 said, there is any manifesto where we can review if you guys (opentofu) are gonna to fork any other TF products, like packer. I'm sorry maybe I'm not good to find forum/channel, etc where it has been discusting those kind of topics already; I'm been working with TF since 3 years and Packer it's the second tools I offert in my solutions, it would be great to know any other/similar solution

[RyanBijkerk]

+1