Yup. This is very much what we intend to do.

[delayed]

Well, CloudFormation is as proprietary as it comes so I'd say you chose correctly with TF.

Technically we mostly use an open-source library for generating CloudFormation, but yeah it still ends up being a bit more deeply vendor-specific than TF.

Out of curiosity, is it troposphere?

Yep! The folks using it seem pretty happy with it.

> Recently I (new to it myself) introduced Terraform on my team at work (my department historically mostly uses CloudFormation), and this whole license rug pull left me wondering if I'd made a mistake.

Personally I wouldn't sweat it.

TF as a tool (not original vs fork) has hit what I think is critical mass, it can't fail. If folks agree the fork is better from a licensing / management level then everyone will use the fork in the end. If not, the original will win. If both tools remain backwards compatible then most end users won't notice the difference.

I think this is a really interesting time. We're getting to witness in real-time how much individuals and businesses value licenses, or specifically what happens when a mature project changes its license.

NOTE: I don't have any tools or services that compete with TF. I'm coming at this as an end user. I contributed once but it was mainly around documentation.

No you’re fine, timing just happened to be at an odd moment, but TF generally has become the new standard and IMO has greatly improved our ability to deliver. I also worked with cloud formation in the past using a custom Python framework. Making changes was MUCH more involved and keeping track of breaking changes was very difficult. TF solves a lot of problems with tracking state and adding new components.

Thanks, that's really appreciated.

One thing that is always unclear with company-owned projects is what is exactly going against their business plans so you don't waste time preparing a PR only to get half-baked excuses about why it can't be accepted.

Point in case, the numerous PR's and issues to disable warning coalescing in Terraform that are always met with a dismissal but nobody understands why.

How do you plan to deal with changes that will break compatibility with TF?

May I suggest a working group on stateless Terraform? [1] or at least some debate around the possibility of supporting it?

[1] https://www.bejarano.io/terraform-stateless/

Our first two issue templates on github are for exactly this! Please add any that are particularly important to you or your team!

https://github.com/opentffoundation/roadmap/issues/new/choos...

Excellent. I've made and supported sevreral PRs in the past and they all seem to just drift around for so long

+1. Stale PRs, also communicate and welcome feature requests or bug fixes that may exist across SO and other channels -- TF-scoped, but perhaps even HCL (if possible) or HCL-adjacent libraries.