The OpenTF Manifesto

I doubt that’s what would happen if they could afford a license from Hashicorp.

Avoiding proprietary licenses has its place but if you aren’t using terraform to build a product this really shouldn’t impact you much.

  Imagine a future CTO trying to pick the IaC tools for their company. They see Terraform as an option, but then learn there are multiple forks, licensing questions, and a big battle happening in the community. What do they do?

I truly believe that a CTO who sees Terraform as an option and who isn't scared off by the BSL, but then has all of these other concerns, exists only in fantasy.

I don't get this one, you pick OpenTerraform and get on with your life. It's the same with picking OpenSearch over Elastic. I can use the proprietary version that locks me into a single profit-seeking vendor and doesn't have community backing or the one run by a foundation made up of companies that use and are heavily invested in Terraform.

Hopefully it's not down to CTOs to be picking tools for their company but a process within DevOps/Engineering teams etc.

Does anyone else see this as the Nagios Effect all over again, there must be lots to learn from history?

The guys at Pulumi must be having a field day right now. It's exactly how you describe it for us. We're long overdue with an upgrade of our Terraform config from pre v1.0. We have to most likely re-write a big part of our HCL code, so why not try a competitor?

With Vault however that's another story, I've yet to find another secrets management system that has a tight integration with Kubernetes, AWS and supports providers for things like Postgresql to have ephemeral database credentials.

I really appreciate that, and I do think it's right of you to at least make the attempt.

That being said, I don't expect this attempt to work and I fully believe that a fork is going to be inevitable. I also think a fork is an amazing opportunity to standardize the language and prioritize the features developers want.

It isn't just about the license, but the way that Hashicorp has maintained the Terraform project. The github insights show that they don't have nearly as many people working on it as I would expect, and most of them are split into also working on Terraform Cloud. At the same time they don't work with the community that well- there are open issues and pull requests that just get ignored as Hashicorp clearly doesn't see value in open source contributors. This isn't just a Terraform issue either- my company had to move off of nomad due to the lack of development and support (as well as broken features).

I have strong concerns about the future of these projects in general beyond just the licensing. An open foundation that had multiple companies involved would by definition need to find a way for those people to collaborate together, and once they do that it makes it easier for them to invite community collaboration. So while I do appreciate that it is a drastic step, I think it's one that would also be far better for the ecosystem and project as a whole.

That said, maybe this is the wake up call hashicorp needs to fix these problems. If you provide five FTEs that basically doubles the size of their Terraform development team (they have more people working on it than five, but those people are split into other projects), and once they start working with other groups maybe they'll work with the community more as well. I'm not holding my breath though.

Hashicorp isn't going to budge here. The same argument that you've made about Terraform being the underpinnings and needing to be open-sourced can be applied to their other important products like Vault, Consul and Nomad as well. The ecosystem of those three is plainly a direct competitor to Kubernetes which is open-source.

There's really no move for them to make here. It's unfortunate.

Hi Marcin,

I recognize you're in interesting position in Spacelift. Per your recent analyses you may not be impacted and in this case you probably do not want to pissoff Hashicorp folks :)

In reality though force better be responded with force and showing Hashcorp what what was Terraform will be successful as Open Source project with or without them is best way to get them to reconsider.

> it is an equivalent of a civil war.

Why. It is open source. A fork should be no big deal, and definitely not a “civil war”. I think the community should be quicker to fork open source projects that are not serving the needs of the community.

The corporations are trying to have the benefits of open source without the responsibility. Forking is a normal, acceptable part of open source and we should normalize it.

it's not war

hashicorp has decided they don't want to contribute to open source any more

they're totally within their rights to do so, and it doesn't harm anybody; it's not the equivalent of going around blowing up buildings, raping women, and napalming children. at most we can wish they had continued doing the beneficial things they were previously doing

maybe they'll change their minds, as you say, but that's no reason for the community to sit around twiddling its thumbs hoping for such a change. what's important now is that the people who are still willing to cooperate can do so successfully, and that's what opentf is about

that's even more obviously not the equivalent of going around blowing up buildings, raping women, and napalming children. it's very much the opposite, in fact

it's unclear to me which of the parties you intend to accuse of doing the moral equivalent of burning innocent people alive en masse, but either way, maybe you should think about walking back that rhetoric a bit

As a user and collaborator of TACOS, agreed that it could open up opportunities. Though I echo trade-offs (as in other replies) that it could start a civil war that makes it difficult for end users and collaborators -- reminds me of Python2 -> 3, Presto/Trino, and many other stories. Pledging resources is a great approach.

Hashicorp left the provider frameworks under the original licenses, probably because they don't want to scare provider developers off. So for now both Terraform and a potential fork can continue sharing the same providers without issue.

This is the interesting part of all of this. The meat of Terraform is in its provider ecosystem. Anyone can make a new frontend (or even fork the existing one?), get rid of all the warts, add the missing encryption features gated under enterprise and have a much better tool.

> In economics, a public good (also referred to as a social good or collective good)[1] is a good that is both non-excludable and non-rivalrous. For such goods, users cannot be barred from accessing or using them for failing to pay for them. Also, use by one person neither prevents access of other people nor does it reduce availability to others.

Any free open source product qualifies as a public good. It is free for all to use, and one person using it does not exclude anyone else from using.

They can't retroactively take source code away from people who they already granted access to it under the MPL. The old code is still available under the MPL forever- even if they take down all of their own public copies of it, anyone with the old Terraform code is still free to upload their copy for the creation of a new fork. That's kinda the whole idea with these open-source licenses :)

IMO: HashiCorp is in this situation because they want to grow too big, too fast. A lot of their software is tooling, tooling that doesn't necessarily make sense to sell in a SaaS offering, or if it does: it's going to be commoditized. However, SaaS is where the $ is. They have investors they must please, and they want a big return on investment. It's probably too late to fix this, but IMO if they took the slow and steady route of providing support and professional services HashiCorp could easily be profitable while maintaining all of their products, but perhaps to a lesser degree.

> But, HashiCorp says that, the thing we develop (i.e. Terraform) is used by others and generate revenue for them, this is great, but we can't generate enough revenue from it to keep the company afloat and continue providing TerraForm development, and sell it as a product at the same time.

> What should they do?

Suck it up, open source Terraform under a non profit foundation, find a new source of revenue. Or stop developing Terraform, cut expenditures, and move on with life.

There's no universe where "bait and switch customers who wanted open source into paying us by switching licenses" is a viable option.

> So, just because people adapted it, and HashiCorp cannot survive, should they say, we're closing shop, it's all MIT now, do whatever you want, bye!?

Exactly, you know the answer, you just don't like the implications. People somehow think that a business which started an open source project "deserves" to profit from it. They do not. Open source is a great way to get people to know who you are and build things that are interoperable with your (proprietary, closed source) SaaS offerings. It is not in itself a revenue source.

If the viability of your business is predicated on being the only one able to provide your project as a service and earn that service revenue gravy, just leave it closed source and proprietary. Sure, you won't get adoption at anywhere near the rate, but that's the tradeoff you make.

MPL is a copyleft license, actually, just like EPL and EUPL. What it is not is a viral copyleft license. Anyone making changes to TF code and productionizing it is expected to contribute back but only the direct changes to TF itself, not the extensions around it. That's my reading of EPL/MPL/EUPL. Does that match your reading?

HashiCorp has plenty of revenue and that revenue is growing fast. They are losing money, but that's to be expected during the high-growth phase of their lifecycle. If they are having trouble growing as fast as their investors want it to, changing their licensing is not the way to fix it. This change is unfortunate because it won't bring serious new revenue to the company but it is a major blow to the reputation they had built.

> What should they do? I'd advocate AGPL, but xGPL licenses are avoided like a plague, because Free Software is not "closed forks" friendly, and companies hate to open everything like that.

They can offer it under more than one license if they want. I, for one, would be pretty happy if they offered it under both BuSL and AGPL.

  - business users who are afraid of copyleft could use Terraform under the terms of the BuSL
  - the F/OSS community could distribute it under the terms of the AGPL and freely build on it
  - competitors to Hashicorp would have a choice:
    + open their whole stack and compete in the market based on the quality of their services and support alone (admirable but very tough)
    + negotiate and pay HashiCorp to license Terraform under special, proprietary terms

Probably, many of the same companies who want to fork Terraform now would still want to. But I'd be satisfied and it would likely shift the conversation in a way beneficial to Hashicorp's reputation.

It ain't like Terraform itself was ever a huge moneymaker. Terraform Cloud (i.e. the fancy-shmancy Terraform backend), maybe, but the actual language, the providers, the modules, etc. are all pretty universally free-as-in-beer. The only way to make money with them is to use them to build something else that then makes money.

Put simply:

> we can't generate enough revenue from it to keep the company afloat and continue providing TerraForm development, and sell it as a product at the same time.

They were never selling it as a product in the first place. It's more of a loss leader if anything; Costco has its $1.50 hot dogs to attract customers to buy memberships, and HashiCorp has Terraform (and its provider/module ecosystems) to attract customers to buy Terraform Cloud (and Vault, and Nomad, and everything else they actually do sell).

It is all about the change. HashiCorp model was open source, and now is not. Salesforce has never been open source.

Would terraform have been as popular it if had never been open source? That we won't know, but we can guess.

  Why would Hashicorp give the slightest worry to losing thousands and thousands of non-paying customers?

Because it goes hand in hand with losing hundreds of unpaid developers, testers, bug-reporters and evangelists.

  If I wrote an open letter decrying Salesforce for not open sourcing their codebase, nobody would take me seriously. But we expect better from Hashicorp for some reason.

Because the community contributed to the codebase. Salesforce was never open source, Terraform was and took community contributions, that's the reason we have different expectations.

  [Docker] can barely muster a viable business

Docker split their development and enterprise offerings into two companies years ago and both are making money.

> They built the most valuable devops tool of the last generation

'They' as in Docker Inc.? They made it accessible for the masses, which counts for a lot, but they built on a lot of pre-existing Linux kernel tech that other people who envisioned containers put in place before Docker came in and seized on the opportunity.

> can barely muster a viable business.

They perused what proved to be the wrong business model until 2019, nowdays they're more than 'barely' viable.

> Why would Hashicorp give the slightest worry to losing thousands and thousands of non-paying customers?

The photoshop effect*. That is to say, devs that are familiar with it will push their workplaces, because it's a pain to pick up yet another tool when you know one that will work.

*A largely hypothesized reason photoshop was so easy to crack back in the day, was that Adobe knew that if kids grew up using photoshop, businesses wouldn't be willing to spend the money re-training their employees, and would just buy a photoshop license.

What? Docker is still completely open source apart from the desktop GUI. The engine and (I'm pretty sure) all components are completely free and if anything, they have pushed for the standardization of the container runtime. Buildkit is free, compose is free, no feature is paywalled apart from Mirantis-centric stuff (not part of docker inc)

You can absolutely bet that they would get dropped like a rock if they moved to changing the engine's license. Even the docker desktop code wasn't ever open to begin with anyways.

Nginx is FreeBSD License, The Docker Engine is licensed under the Apache License 2.0

Far easier said than done.

> The fantastic cost of running TF in the cloud is painful.

Citation needed. I don't think it costs very much at all.

Yes, I believe I saw a video of Linus stating exactly this

My understanding was that some people in the community believed that GPLv3 was better, and one of Linus's criticisms was that it was essentially impossible to switch even if it were better. I also believe Linus was opposed to the switch, which would make it unlikely anyway, but even if he had approved, I still think it would be practically impossible.

Torvalds considered the anti-TiVo clause to be changing the deal and he didn't want to do that, and there's no way in GPLv3 to opt-out of the clause[0].

This is less "locking down devices is a human right" and more him being angry that the FSF was trying to butt into his project's affairs. He's also similarly angry about "GNU/Linux" as it sounds an awful lot like Stallman just demanding everyone stick "GNU" onto the name of Linus's kernel project.

Anyway all of this is going to seem really quaint in 2027 when Broadcom gets sued under DMCA 1201 by a rogue kernel contributor for evading the Linux linker's license checks[1] and they have to hurriedly rewrite them out of the kernel and relicense anyway.

[0] Granting a blanket exception doesn't work because others can just remove the exception. "No further restrictions" is an ironclad law of copyleft.

[1] The Linux kernel checks the declared license of loaded modules and refuses to link non-GPL-compatible code against any kernel symbol not marked as a user-space equivalent. The reason why this works this way is because Linux ships under GPLv2 plus an exception that says user-space APIs don't trip copyleft, so you can legally load code built to those APIs into the kernel, but anything else might violate GPL.

Since this is enforcing an interpretation of the GPL, this is a DMCA 1201 technical protection measure. You absolutely could make a DMCA 1201 anticircumvention claim in court against a proprietary driver developer that tried to evade the checks. Though Linus usually just bans their modules in the next kernel revision since he's mainly worried about keeping proprietary modules from generating spurious bug reports in Linux. But the lawsuit is still possible, since they're on GPLv2. If they had relicensed to GPLv3, this wouldn't be an issue.

We changed the license[1] of a project which had 10 contributors, and we got every single one of them to do an Acked-by (by email) which took some weeks. That was on the advice of our lawyers. Can't imagine the impossible hassle of doing the same for something like Linux.

[1] https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...

The ecosystem outside of providers is far less important than people like to claim. Open source modules are almost all poorly scoped, often just wrapping a single resource completely unnecessarily - simultaneously over- and under-abstracted. It's also a huge security risk to pull them in.

Giving away most of your product for free and selling commercial services on top when it's very easy to compete with you on that front is.... well it's not a sustainable business model.

It would be troublesome if any of the vendors at $work past or present went bankrupt, this is the nature of having external vendors. I am not particularly concerned.

I was not the biggest fan of Terraform in the first place, I don't like some of the language choices, but it works better than anything else that exists out there.

Definitely, the fact they're rent seeking against similar small companies clearly shows that. Sad that rather than looking inward to improve themselves they've decided to just attack others.

Have you actually read the financial statements? None of what you just wrote is remotely true.

I've worked for three companies now that went to hashicorp to buy TFE and left with a quote equal to a quarter or more of revenue and the sales rep acting like they are the second coming and obviously we are stupid for not thinking they bring that much value to our org. No org invests 1/4 of their revenue on a single tool. So we used atlantis or spacelift or hand rolled GHA scripts and saved a fortune.

We are trying to pay them and they are being so unreasonable with pricing that we can't give them our money

Blew all that money? They still had about $1B in the bank at the last earnings, and they only raised $1.2B in the IPO iirc

Yep, I wonder the same

Do not mix source code license with Trademark. Trademark use is focused by Trademark policy which is here for Hashicorp https://www.hashicorp.com/trademark-policy

It can be rebranded, that's pretty straightforward for something that's such an industry standard. "Oh yeah? Earthworks? That's the open source fork of Terraform" pretty simple. If it were a lesser known technology it would be an issue but most of the (modern) internet runs on it, whatever they name the fork will be well known pretty much instantly

That would be what I meant by legally prevented.

Hi! OpenTF is not connected with a single company. This is an united, community-driven effort. You can check on the manifesto side who is behind. And we welcome all support!

The fork you mentioned is no longer existing.

> All the bug and security fixes that HashiCorp is writing can’t just be cherry-picked into these forks (I think?), so what exactly are they supposed to do?

Indeed, any fork will need to implement their own bug fixes.

Ideally they should do this "clean room" and not even look at the BSL'd code, to help defend against any accusations of copyright infringement.

> Update: and in the past hour this repo is gone.

Which is interesting, since Digger (the company that created that fork) is one of the OpenTF Manifesto signatories. Maybe they're recreating it under a different name / without the Hashicorp/Terraform branding all over the place?

Probably not difficult for these competitor organizations to fund an OpenTF team to hire some of these people away from HashiCorp and continue it on as FOSS either. I can't imagine Liam turning down .5M/year to do so.

Gruntwork is the only one of these companies that I genuinely cannot understand Hashicorp having any beef with.

> Terraform doesn't have a test suite

Patently false. Terraform has had an excellent test suite since 2014.

> Terraform doesn't have a test suite- Grunt made Terratest

They have experimental support: https://developer.hashicorp.com/terraform/language/modules/t...

We use Terragrunt to manage thousands of Terraform configurations. If it and Terraform drift apart, we will have to go one way or the other eventually. Separately, a new license for Terraform means its gotta go back through legal and compliance so we will be paused for months anyway.

Let me introduce you to my go-to for that bullshit: https://scribe.rip/@DiggerHQ/diggers-statement-on-the-hashic...

courtesy of: https://news.ycombinator.com/item?id=28838053

You can click the X on that modal to close it.

(But yes, I agree that this is annoying, and this kind of sign-up-nagging is what prevents me from having any interest in using Medium or Substack.)

> cloud-based TF instances

Not sure what specifically you mean with this.

Anyway, the devil’s in the details, of both the license as well as the internal architecture of our system. I can’t share more here, but if you’d like to learn more please reach out via our chat or email. You can also expect more updates on our blog.

Ah, this is great when. MongoDB did not do it in their switch to SSPL

No need to be sorry about mentioning Rust :)

Yes, can confirm the terraform language server is kinda unreliable. We could both be doing something wrong, but it seems like that's a common outcome.

The IntelliJ support for Terraform is far more complete.

FWIW, the Rust support is also better in CLion than VS Code.

Pulumi looks great. Why aren't they more popular?!?

They still need the state (boo!), but otherwise they're great.

What's preventing Pulumi from making a license change in the future?

They are EVEN MORE crappy than TF.

I worked at a financial institution that heavily utilized terraform. Their business is banking and they do not offer automation, orchestration or IaC as a service. They're fine.

This seems to affect only those places that attempt to build a business off terraform.

I am not saying those businesses can't be mad at the rug getting pulled out from under them, but it's important to be accurate that this doesn't affect end users of TF directly.

This covers really well why I think the BSL license is a non-starter for things like TF. I get trying to prevent AWS from competing with you using your own open source code, but it creates this ambiguity where it's not clear whether lots of uses are or are not competing with HashiCorp.

> For example, if you’re an independent software vendor (ISV) or managed service provider (MSP) in the DevOps space, and you use Terraform with your customers (but not necessarily Terraform Cloud/Enterprise), are you a competitor? If your company creates a CI / CD product, is that competitive with Terraform Cloud or Waypoint? If your CI / CD product natively supports running Terraform as part of your CI / CD builds, is that embedding or hosting? If you built a wrapper for Terraform, is that a competitor? Is it embedding only if you include the source code or does using the Terraform CLI count as embedding? What if the CLI is installed by the customer? Is it hosting if the customer runs your product on their own servers?

The answer is at the whim of HashiCorp and subject to change at any point in the future. Even ignoring the attempt to dilute the meaning of "open source", the practical implications of the BSL license are more than enough reason to coalesce around a truly open source fork IMO.

> have contender products they can choose to vigorously fund tomorrow.

Then why didn’t they “choose” to fund hashicorp yesterday and avoid this?

As usual in OSS-goes-private events these all just sound like “keep building our critical infrastructure tool for free or we will go elsewhere”.

What is hashicorp or any other company in their position to do?

This is not sustainable.

Hosting the statefile in a secure way, state-locking, injecting the secrets so you're not keeping the secrets locally or in env var, and pre-built integration with other Hashicorp suite.

I see the use case for it if you don't want to use a 3rd party or open source tool (Atlantis) but the pricing seems prohibitive.

AWS has had a Terraform competitor for a long time; CloudFormation. I'm not sure how much they contribute to Terraform, some I think, but most of the AWS provider for Terraform to my knowledge is developed and owned by Hashicorp. If AWS just stopped contributing to Terraform development, I think it would have effectively zero difference.

> These tools are not going to be able to be used with users using new Terraform versions

As discussed in the other thread, we believe that we are not in violation of the new license, you can find more details in our today's announcement[0].

Disclaimer: Work at Spacelift.

[0]: https://spacelift.io/blog/spacelift-latest-statement-on-hash...

Correct. That, or "negotiate" with HashiCorp for a commercial license.

> > There is no contract.

> There are social contracts

> > Try to enforce it.

Omitting commitment details may simplify pledges, but it also makes pledges almost meaningless. I'd take pledges much more seriously if they still had details

Do the founding orgs have public disclosure of their finances? It seems the vast majority of them are VC backed companies that probably don't even have two years worth of runway, let alone be in a position to meaningfully commit to funding engineers for five years.

They can make their own contributions going forwards BSL licensed. They can also make their own contributions Apache 2 _going forward_.

They could only make my contributions to Terraform Apache 2 with permission, so at best it could be MPLv2 with Apache 2 files interspersed.

Only Hashicorp employees are allowed to comment here? How about the person that actually built it? Maybe he has interesting things to say. Also, he's been silent on HN as a whole, not just Hashicorp-related threads.

Maybe he signed a gag order and cashed out. We may never know.

Realistically you're either deploying consul on top of 1-N kubernetes clusters, or Nomad.

If deploying on kubernetes, you now have all the problems that come with kubernetes, plus additional problems of trying to get consul working.

I spent a week just trying to stand up a federated multi-datacenter deployment of consul on EKS before my company decided it was too much hassle

Do you consider cloudformation as imperative APIs?

This is clearly a poor idea. Declarative infrastructure management is ultimately a dead end, because order of operations actually matters.

I agree. Cloud infrastructure should be versioned and immutable. If I have an S3 bucket and make 4 changes to it, there should be V0 (making the bucket) and V1-V3 (each subsequent change). I should be able to tell the bucket API to restore the bucket to V2. Terraform is a hack to fill that gap. The AWS bucket service itself should be doing it, not Terraform. Several classes of software that we all maintain ourselves would go away if cloud infra were versioned & immutable.

Oh god I would be writing for hours. Short version, this is not nearly everything:

  - Bad UX
    - Tool does not have interactive mode to provide suggestions or simple solutions to common problems
    - Lack of options or commands for commonly-used tasks, like refactoring resources, modules, sub-modules, etc. (Using 'state mv' and 'state rm', etc is left as an exercise for the user to figure out and takes forever)
    - Complains about "extra variables" found in tfvars files, making it annoying to re-use configuration, even though having "extra variables" poses no risk to operation
    - (NEW) Shows you what has changed in the plan output, followed by what will *actually be changed* if applied, though both look the same, so you get confused and think the first part matters, but actually it's irrelevant.
  
  - Bad internal design
    - HCL has a wealth of functions yet is too restrictive in how you can use them. You will spend an entire day (or two) tying your brain into knots trying to figure out how to construct the logic needed to append to an array in a map element in an array in a for_each for a module (which was impossible a few years ago).
    - Providers are inconsistent and often not written well, such as not providing useful error messages or context.
    - Common lifecycle policy conventions per-resource-type have to be discovered by trial-and-error (rather than being the default or hinted) or you will end up bricking your gear after it's already deployed.
    - The tool depends on both local state and optionally remote state. Local state litters module directories even though nearly everyone who uses it at scale uses modules as libraries/applications, not the location they execute the tool from. Several different wrappers were invented and default to changing this behavior because it has been a problem for years.
  - Default actions and best practices (such as requiring a plan file before apply or destroy, automatically running init before get before validate, etc) are left to the user to figure out rather than done for them (again, wrappers had to solve this).
  - Some actively dangerous things are the default, like overwriting backup state files (if they're created by default).
  - Version management of state is left up to the user (or remote backend provider)
  - Not designed for DRY code or configuration; multiple wrappers had to implement this
  - You can't specify backend configuration via the -var-files option, and backend configuration can't be JSON ... why? They just felt like making it annoying. Some "philosophical" development choice that users hate and makes the tool harder to use.
  - Workspaces are an anti-pattern; you end up not using them at scale.
  - You can't use count or for_each for provider sections, so if you wanted a configurable number of providers (say with different credentials each), tough luck. ("We're Opinionated!")
  - Can't use variables in a backend block. ("We're Opinionated!")
  - Can't have more than one backend per module. ("We're Opinionated!")
  - Lots of persistent bad behavior has been fixed in recent releases, like not pushing state changes as resources are applied, others I can't remember.
  - Global lock on state, because again, ya can't have more than one backend block per module.
  - All secrets are stored as plaintext in the state file, so either you don't manage secrets *at all* with Terraform, or you admit that your Terraform state is highly sensitive and needs to be segregated from everyone/everything and nobody can be given access to it.
  - No automatic detection of, or import of, existing resources. It knows they're there, because it fails to create them (and doesn't get a permission error back from the API), but it refuses to then give you the option of importing them. The *terraformer* project had to be invented just to get a semblance of auto-import, when they could have just added 100 lines of code to Terraform and saved everyone years of work.
  - Not letting people write modules, logic, providers, etc in an arbitrary executable. Other tools do this so you can ramp up on new solutions quickly and make turn-key solutions to common needs, but Terraform doesn't allow this; write it in Go or HCL or get bent.
  - You have to explicitly pass variable inputs to module blocks, so you can't just implicitly detect a variable that has already been passed to the tool. But this isn't the case if you're applying a module; only if you create a sub-module block. This just makes initial development and refactoring take more time without giving the user an added benefit.
  - You have to explicitly define variables, rather than just inherit them as passed to the tool at runtime. Mind you, you don't have to actually include the variable type; you just have to declare *the name* of the variable. So again, it wastes the user's time when trying to develop or refactor, for absolutely no benefit at all.
  - You have to bootstrap the initial remote backend state resources *outside* of Terraform, or, do it with local state, and then migrate the state after adding new resources or using a separate identical module that has a backend configuration. Does that sound complicated? It is, and annoying, and unnecessary.
  - You have to be careful not to make your module too big, because modules that manage too many resources take too long to plan and apply and risk dying before completing. (If you're managing resources in China, make the module even smaller, because timeouts over the great firewall are so common that it's nearly impossible to finish applying in a reasonable time)
  - Tests. In Go.
  - Schema for your tfvars files? Nope; write some really complicated logic in a variable to validate each variable in a different way.
  - Providers don't document the restrictions on things like naming convention for required parameters, so you have to apply to the API and then get back a weird error and go try to dig up some docs that hopefully tell you the naming convention so you can fix it and try again.
  - Terraform *plan* will give you 'known after apply' for values it very easily could tell you *before* the apply, but for whatever reason doesn't. You never really know what it's going to do until you do it and it blows up production.
  - It's very difficult (sometimes near impossible) to just absorb the current state of the infrastructure into TF (as in, "it's working right now, please just keep it the way it is"). Import only works if you've already written the HCL for the resources, and then look up how the provider wants to you to import that resource.
  - Version pinning is handled like 5 different ways, but is still impossible to pin and use different sets of versions when applying different state files for the same HCL module code and values.

That's off the top of my head, there's much more.

There’s a lot of inertia in ops tooling. Switching costs are very high for an existing project, and once you learn the quirks of one tool or another, it takes a lot to justify something else for a new project even if it’s better, since you know the new tool will have its quirks too.

The cost-benefit analysis of new stuff is also different for ops compared to pure development. You tend to care more about stability and predictability than productivity and elegant design. Problems in pure dev land cause bugs that mostly aren’t super urgent; problems with ops tools bring down whole systems and wake everyone up at 2am. For these reasons, ops is always going to have a more conservative mindset that shuns the shiny new thing to some extent.

Honest question, what do you consider config vs infra? What is infra if not configuring a system to run?

You can definitely use Ansible to provision infra as well. Whether that’s the right tool for the job is a matter of taste.

> I have a hard time thinking of how terraform as a piece of software can do to much more than it already does to fix things?

Oh, that one's easy: have the "plan" phase actually consult the underlying provider in order to know the straight face errors that are going to fail 60% of the way through your "apply" phase. I thought about including an example, but I don't care to try and lobby unless the community fork takes off, because Hashicorp gonna Hashicorp _their_ baby

Look, I know the TF community is allllllllllll about that Omniscient .tfstate file but (related to the sibling comments about the tool _being helpful_) the real world is filled with randos in an organization doing shit to underlying infra or humans fat-fingering something and it is not a good use of anyone's life having to re-run plan and apply due to some patently stupid but foreseeable bug

I'm no Terraform expert but it's been in my resume and toolbox since ~2016.

Up until these changes, I would always pick Terraform for managing AWS. I have my gripes with it but it has been the best choice (as the saying goes, anybody that uses a tool long enough should have complaints about its limitations).

Now, however, I'm finally thinking of going with the CDK to insulate myself from more seismic shifts in the "OSS ecosystem" of devops tools.

Right now there is pulumi as a alternative that supports different clouds. Otherwise AWS CDK or Azure Bicep come to mind.

If i could to a do-over I'd want the solution to look and feel like AWS CDK but without the cloudformation in the background, and support for GCP and Azure.

I've worked with CDK for 2 years now and being able to define your code in Typescript is quite handy and drastically reduces the effort it takes for new people to learn how our deployment work. It's also quite nice to be able to directly bundle and deploy the application together with the infrascructure with very little effort.