Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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


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.

But if OpenTF really flourishes, this could end up being better for us than if the license change had never happened. I wish you guys the best in making OpenTF a clear winner! The sooner that happens, the less of a shakeup this will be for the whole userbase and the more teams will stay invested and stick with terraform-the-technology (if not the trademark). I'm optimistic. :)


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.


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/


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?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: