Because of that bucket of problems people end up using these tools to manage terraform runs (also known as TACOs). Terraform Cloud is one of them; there's also Spacelift, Atlantis and a bunch of others covering various aspects of what terraform the language doesn't handle natively (ci/cd, state, tfvars management, dependencies, etc).
At the core though, this seems to boil down to a multi-graph comprised of states with some extra stateful pieces on top, like TFVars, inputs/outputs etc. All that's needed is a reliable service that manages these stateful bits in a manner that supports security and compliance needs (secrets stored safely, audit trail, etc). Currently all that is either not there at all, or part of a large "package offering" like Terraform Cloud or Spacelift.
The case I'm making is that this "logical core" needs to exist in a way that's not coupled to a do-it-all cloud-based solution. It probably should not be part of the language itself; but also shouldn't be an all-or-nothing proposition. Hence the VM / runtime parallel
Another parallel to express a similar concept could be "instrumentation for terraform" - it'd be odd if all the observability tooling for a particular language (say Java) were coupled to a cloud-based offering by the company that created said language (Oracle) right? There's a bunch of stuff outside of Java that most Java applications need nevertheless - like application server (eg Tomcat) and so on. Okay that's not exactly instrumentation; but then logging tools, monitoring tools, etc.
I took the definition from Lightspeed's OSS GTM workshop that was held in May this year. Upon further googling, it appears that a broadly accepted meaning of "fauxpen source" is indeed different. Thank you!
We are beyond excited to be part of this great initiative. We did of course expect a fork to be of significant interest to people; what we did not expect is this crazy level of support for it. 2k+ stars, 100+ companies and 400+ individuals pledged, and there is already more full-time engineering positions committed to it by pledging companies than the whole Terraform Core team at Hashicorp (source: terraform commit history)
An earlier version of the manifesto contained pledged resources from each company (you can still find it in commit history). It totalled to ~10 full-time engineers just from founding orgs. It was removed to simplify adding their entries for new pledgees
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
I am a co-founder of Terrateam and we have made a pledge for OpenTF. I understand where you are coming from, but right now it is difficult to know what exactly to pledge as we want a dialogue with HashiCorp on what they need as well, if they want to donate to a foundation.
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.
We are in some sense a competitor too, alongside Spacelift, Env0, Scalr and a few others. Our product is built differently though, Digger is orchestrating terraform jobs in your existing CI instead of taking over the whole CI stack and effectively duplicating it just to run terraform. We built it this way almost by accident; our original product was very different (think "heroku-like UI for AWS" that generated and ran terraform on the server) and this is how we arrived at what Digger is now. Luckily we don't seem to be affected by the licensing change as we neither embed nor distribute any of hashicorp's code (it's on the user to set up the right version of it in say GH Actions).
Anyways, fully agree that if you have a great product, you don't need to make such moves. We designed our product the way we did purely out of technical considerations - it didn't seem to make any sense to duplicate the CI stack. But it looks like this whole idea behind Terraform Cloud of having an "infra-specific CI" was driven exclusively by commercial interest. You can charge per minute! You can charge even more per resource! Now it's catching up with Hashi; so they have to make such defensive moves. If the product made sense technically, if it was designed the way someone would design it with no commercial considerations whatsoever, they wouldn't have to make such moves.
> Funny enough, our own product (Digger, an open-source CI runner for Terraform) is not using Terraform (or any other Hashicorp's code) under the hood.
What a smackdown! You guys had me thinking you'd written a custom executor engine or something of that nature.
I've spent a fair amount of time digging around the terraform codebase and hacking on providers. I'm not too worried about the license change tbh, almost all the important IP is locked up in the provider codebases and no matter what direction hashicorp goes those providers will remain open.
The question will be, how are those providers executed? Most likely an open terraform fork will fill that role for the foreseeable future. But long-term I think hashicorp just handed IaC to crossplane and pulumi.
I think ACK from AWS and k8s-config-connector
from GCP probably represent the future of IaC. Crossplane is neat and all and pioneered the architecture but using the cloud provider native operators directly will always be a better experience. The question will be what the next generation of TACOS frontend tools look like.
Rewriting a provider into a kubernetes reconciler isn't an impossible undertaking and the tools for doing so are improving at a rapid rate. I recently finished up on a major project writing a kubernetes controller for a private cloud platform.
if Hashi chooses to enforce it to such extent that even calling a terraform binary (which is open source itself for now) constitues "embedding"... then good luck Hashi staying an "open source company". The days of proprietary programming languages are long gone. They appear to be confusing the languages / frameworks space with self-hostables. BSL makes total sense for Mongo / Elastic (as well as Vault or Consul). Not so much for a CLI / compiler thingie which Terraform is.
with Vault and Consul that makes a ton of sense; they're centralised backend services that are inherently SaaS-like. But expanding the "on top of terraform" definition to a CLI / language? That's insane. It's like making a programming language or framework proprietary and saying you can't sell anything written in the language without the language creator's permission. I guess such languages did exist in the early days of the industry but those days are long gone
that's the most puzzling bit. Do they not want to anyone offering anything that could compete with any of Hashi's products to be able to use terraform binary at all?
if so, that's similar to proprietary programming languages. Not a thing. The community can just agree on a similar but open alternative and the original company is left behind. That's why all languages and frameworks are open-source with permissive licenses.
and if not, if it's just about the hosted / managed parts - then what exactly is it that I can use wrongly? Terraform Cloud / Enterprise was never open source. There's nothing I can self-host and charge users for...
> Do they not want to anyone offering anything that could compete with any of Hashi's products to be able to use terraform binary at all?
I think they want to make it difficult for SaaS products that embed terraform (or an altered version of terraform I would assume where they have built APIs) in their product. That said, customers can install terraform so you can still hypothetically have an "integration" with Terraform where you call the raw binary (like Atlantis). So basically, they want terraform cloud to have a "privileged" user experience is my guess.
Because of that bucket of problems people end up using these tools to manage terraform runs (also known as TACOs). Terraform Cloud is one of them; there's also Spacelift, Atlantis and a bunch of others covering various aspects of what terraform the language doesn't handle natively (ci/cd, state, tfvars management, dependencies, etc).
At the core though, this seems to boil down to a multi-graph comprised of states with some extra stateful pieces on top, like TFVars, inputs/outputs etc. All that's needed is a reliable service that manages these stateful bits in a manner that supports security and compliance needs (secrets stored safely, audit trail, etc). Currently all that is either not there at all, or part of a large "package offering" like Terraform Cloud or Spacelift.
The case I'm making is that this "logical core" needs to exist in a way that's not coupled to a do-it-all cloud-based solution. It probably should not be part of the language itself; but also shouldn't be an all-or-nothing proposition. Hence the VM / runtime parallel
Another parallel to express a similar concept could be "instrumentation for terraform" - it'd be odd if all the observability tooling for a particular language (say Java) were coupled to a cloud-based offering by the company that created said language (Oracle) right? There's a bunch of stuff outside of Java that most Java applications need nevertheless - like application server (eg Tomcat) and so on. Okay that's not exactly instrumentation; but then logging tools, monitoring tools, etc.