5 ms·

> Community-driven - so that the community governs the project for the community, where pull requests are regularly reviewed and accepted on their merit and cha

by pxc 3y ago

> Community-driven - so that the community governs the project for the community, where pull requests are regularly reviewed and accepted on their merit and changes are proposed through a public RFC process IMO if OpenTF wants to quickly pull ahead, they'd do well to quickly revive popular but neglected PRs from Terraform, inviting those authors to rebase on top of OpenTF and quickly getting them merged. The RFC process will slow them down here, at least for features, but presumably there are still old bug fixes that died on the vine, too.

fishnchips 3y ago
Yup. This is very much what we intend to do.
- pxc 3y ago
  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. :)
  - kskkkkkkk 3y ago
    Well, CloudFormation is as proprietary as it comes so I'd say you chose correctly with TF.
    - pxc 3y ago
      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.
      - benterix 3y ago
        Out of curiosity, is it troposphere?
        pxc 3y ago
        Yep! The folks using it seem pretty happy with it.
  - nickjj 3y ago
    > 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.
  - TheGRS 3y ago
    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.
- kskkkkkkk 3y ago
  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.
- benterix 3y ago
  How do you plan to deal with changes that will break compatibility with TF?
- ricardbejarano 3y ago
  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/ https://www.bejarano.io/terraform-stateless/
Coryodaniel 3y ago
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/choose https://github.com/opentffoundation/roadmap/issues/new/choos...
- mcfedr 3y ago
  Excellent. I've made and supported sevreral PRs in the past and they all seem to just drift around for so long
jeffchao 3y ago
+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.

by pxc 3y ago

fishnchips 3y ago

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

pxc 3y ago
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. :)
- kskkkkkkk 3y ago
  Well, CloudFormation is as proprietary as it comes so I'd say you chose correctly with TF.
  - pxc 3y ago
    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.
    - benterix 3y ago
      Out of curiosity, is it troposphere?
      - pxc 3y ago
        Yep! The folks using it seem pretty happy with it.
- nickjj 3y ago
  > 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.
- TheGRS 3y ago
  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.
kskkkkkkk 3y ago
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.
benterix 3y ago
How do you plan to deal with changes that will break compatibility with TF?
ricardbejarano 3y ago
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/ https://www.bejarano.io/terraform-stateless/

Coryodaniel 3y ago

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/choose https://github.com/opentffoundation/roadmap/issues/new/choos...

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

jeffchao 3y ago

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