3 ms·

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 terra

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). https://github.com/diggerhq/digger https://github.com/diggerhq/digger 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.

Iammadeofpizza 3y ago
To copy the comment from Reddit https://old.reddit.com/r/Terraform/comments/15o9mzt/openterraform_an_mpl_fork_of_terraform_after/jvqio3o/ https://old.reddit.com/r/Terraform/comments/15o9mzt/openterr... > 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. Oh yes you are: https://github.com/diggerhq/digger/blob/develop/pkg/core/terraform/tf.go#L161 https://github.com/diggerhq/digger/blob/develop/pkg/core/ter... You're on thin ice if you want to argue whether forking a terraform process constitutes "hosting" or "embedding" terraform.
- igorzij 3y ago
  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.
  - pachico 3y ago
    I think it's quite clear they don't care about being called an open source company, which is fine, as I see it. This will shake the sandbox. I personally hope that the community will step up with a fork.
- dpeckett 3y ago
  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.

Iammadeofpizza 3y ago

To copy the comment from Reddit https://old.reddit.com/r/Terraform/comments/15o9mzt/openterraform_an_mpl_fork_of_terraform_after/jvqio3o/ https://old.reddit.com/r/Terraform/comments/15o9mzt/openterr... > 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. Oh yes you are: https://github.com/diggerhq/digger/blob/develop/pkg/core/terraform/tf.go#L161 https://github.com/diggerhq/digger/blob/develop/pkg/core/ter... You're on thin ice if you want to argue whether forking a terraform process constitutes "hosting" or "embedding" terraform.

igorzij 3y ago
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.
- pachico 3y ago
  I think it's quite clear they don't care about being called an open source company, which is fine, as I see it. This will shake the sandbox. I personally hope that the community will step up with a fork.
dpeckett 3y ago
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.