5 ms·

Shares were going down for some time, env0 (Terraform Cloud competitor) just raised 35m from VC for a what seems to be a good product... Hashicorp did it's move

Shares were going down for some time, env0 (Terraform Cloud competitor) just raised 35m from VC for a what seems to be a good product... Hashicorp did it's move. If there's a community behind, the fork will live and, who knows, maybe many will start using it instead of the original one. It's all up to the community and substantial sponsors, at this point. I still think that the best way to compete is by having a more appealing product, thought, rather than changing licence. And I mean this for Hashicorp, Elastic, etc. If you need to do this move is because you don't really succeed at having a better product, else you would just benefit from FOSS rather than it being a liability.

igorzij 3y ago
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.
ckdarby 3y ago
The writing has been on the wall. They're burning $50M loss last quarter which is mind blowing considering they had a monopoly originally. Michael raised too much money and let everything go to his head and his leadership. The internal chatter I hear is pure technical folks know this is a terrible choice, but "leadership" is so pressured and desperate given the economic headwinds they're trying to cut out any competitors building on top of their success. They refuse to believe their paid offers are just not good enough. Hashicorp had lost nearly all it's value in the space. Terraform, terra..what? Pulumi is starting to gain momentum as the long term winner in the space. Nomad, K8s is mostly destroyed their future outside of some very specific cases around smaller deployments and frequent disconnects with the control plane. Vagrant, docker RIP. Consul, coredns and the main reason to use it for service discovery is gone with any of the cloud providers versions like ECS or K8s. Vault, Pulumi chipping away at the main reason why people buy it which is dealing with TFs lack of encrypting each value in the state file. There are still spots where Vault wins (but open source is all that is needed) such as issuing out temp credentials off of a "root credential". Packer, lack of overall community adoption even though in automation with hardware it is incredibly needed. Piss poor documentation and experience when getting started with it. Rest of the services I've never looked at because there hasn't been a gap with a lack of a winner already. License change just means company is dead in my future choices anyways.
- pachico 3y ago
  > They refuse to believe their paid offers are just not good enough This is the most important sentence, as I see it.
- jen20 3y ago
  > cases around smaller deployments The size of a usable nomad cluster can absolutely dwarf the (pathetic) scaling capabilities of Kubernetes, largely thanks to the poor etcd API which simply cannot be fixed.
  - xref 3y ago
    I’m curious what companies would run into that theoretical scaling limit, seeing as Google itself built and uses k8s/borg

igorzij 3y ago

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.

ckdarby 3y ago

The writing has been on the wall. They're burning $50M loss last quarter which is mind blowing considering they had a monopoly originally. Michael raised too much money and let everything go to his head and his leadership. The internal chatter I hear is pure technical folks know this is a terrible choice, but "leadership" is so pressured and desperate given the economic headwinds they're trying to cut out any competitors building on top of their success. They refuse to believe their paid offers are just not good enough. Hashicorp had lost nearly all it's value in the space. Terraform, terra..what? Pulumi is starting to gain momentum as the long term winner in the space. Nomad, K8s is mostly destroyed their future outside of some very specific cases around smaller deployments and frequent disconnects with the control plane. Vagrant, docker RIP. Consul, coredns and the main reason to use it for service discovery is gone with any of the cloud providers versions like ECS or K8s. Vault, Pulumi chipping away at the main reason why people buy it which is dealing with TFs lack of encrypting each value in the state file. There are still spots where Vault wins (but open source is all that is needed) such as issuing out temp credentials off of a "root credential". Packer, lack of overall community adoption even though in automation with hardware it is incredibly needed. Piss poor documentation and experience when getting started with it. Rest of the services I've never looked at because there hasn't been a gap with a lack of a winner already. License change just means company is dead in my future choices anyways.

pachico 3y ago
> They refuse to believe their paid offers are just not good enough This is the most important sentence, as I see it.
jen20 3y ago
> cases around smaller deployments The size of a usable nomad cluster can absolutely dwarf the (pathetic) scaling capabilities of Kubernetes, largely thanks to the poor etcd API which simply cannot be fixed.
- xref 3y ago
  I’m curious what companies would run into that theoretical scaling limit, seeing as Google itself built and uses k8s/borg