Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The OpenTF Manifesto

opentf.org

Post reply on HN
Print view View original

231–240 of 392 posts

Re: The OpenTF Manifesto

#231

Post by jen20 »

AtNightWeCode wrote: post #197
bloopernova wrote: post #125

If any Hashicorp people are reading, can you please tell your middle and senior management that this decision has deeply soured my entire DevOps cohort on continuing to use Terraform in the future. We're already exploring alternatives. Future client projects may not use Terraform at all. Languages and frameworks must remain open or they will wither and die.

The fantastic cost of running TF in the cloud is painful. Several years ago it was very clear that it would be difficult for HC to survive once they became a company registered at stock markets.

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

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

Re: The OpenTF Manifesto

#232

Post by verdverm »

i_am_jl wrote: post #230
verdverm wrote: post #195

Earlier quoted context omitted.

My understanding is that the aforementioned companies' licenses are to the same effect, so what is the difference?

Redis is 3-clause BSD, BSD does not have a "your license is void if you sell a product that competes with us" clause. Redis does have enterprise products that are licensed in a manner similar to BSL, but Redis itself is not. MongoDB and Elastic are SSPL. SSPL approaches the problem like the AGPL; it compels licensees who sell a service derived from the software to make available under the SSPL the source of all suppo…

thanks for the explanation, my understanding is that they are all after limiting competition in various ways, while still trying to maintain the mantle of open source

We are certainly in interesting times around the monetization / financial sustainability of open source

Re: The OpenTF Manifesto

#233

Post by bit_flipper »

verdverm wrote: post #195
i_am_jl wrote: post #139

Earlier quoted context omitted.

You may make production use of the Licensed Work, provided such use does not include offering the Licensed Work to third parties on a hosted or embedded basis which is competitive with HashiCorp's products. Read benevolently it's a prohibition from spinning up a service based on HashiCorp's code and undercutting HashiCorp's pricing. On the other hand, if I build a product with HashiCorp-owned BSL'd code, then HashiCo…

My understanding is that the aforementioned companies' licenses are to the same effect, so what is the difference?

SSPL has no provision even close to the reach of the "anti-competition" clause Hashicorp is using. While SSPL is not considered open source, it isn't that far off from the AGPL. The difference between SSPL and AGPL is that SSPL (1) is in effect regardless of modification of the service and (2) extends copy left virality to all programs which support running the service, including those that interact with the software over a network.

MongoDB, Elastic, etc. cannot stop you from running a competitor based on the terms of their licenses, they just ask that you publish the source code for whatever service you're running in its entirety (I acknowledge there are disagreements about how far "entirety" extends). The clause in Hashicorp's license actually revokes the right to use their software at all if you're a direct competitor.

OK, no one is going to build an open source competitor to Elastic or MongoDB because then you have no moat and your business will probably fail, I get it, but it's still possible to do without repercussion. It's not like the AGPL is that far off in terms of limitation, either, which is why you don't see many copyleft services run by large corporations unless they've been dual-licensed.

Re: The OpenTF Manifesto

#234

Post by jen20 »

nikolay wrote: post #219
new23d wrote: post #175

As an end-user, not competing with HashiCorp, this change doesn't worry me. According to their FAQ [1]: 10. What are the usage limitations for HashiCorp’s products under BSL? All non-production uses are permitted. All production uses are allowed other than hosting or embedding the software in an offering competitive with HashiCorp commercial products, hosted or self-managed. 24. Can I host the HashiCorp products as a…

It should worry you - it hurts the ecosystem. Terraform is just a tool. The providers, modules, not supported by HashiCorp, is what makes Terraform useful. Ige the ecosystem dies, Terraform becomes useless.

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.

Re: The OpenTF Manifesto

#235

Post by mkl95 »

> This is similar to how Linux and Kubernetes are managed by foundations (the Linux Foundation and the Cloud Native Computing Foundation, respectively), which are run by multiple companies, ensuring the tool stays truly open source and neutral, and not at the whim of any one company.

> We strongly prefer joining an existing reputable foundation over creating a new one. Stay tuned for additional details in the coming week.

Joining an existing foundation sounds like the right move to me. Many organizations need this fork to take off very quickly, since they are facing legal uncertainty. Make sure it is clear how to support the project, and those organizations will be happy to do so.

Re: The OpenTF Manifesto

#236

Post by jen20 »

cyberax wrote: post #76

Terraform core is kinda crappy. The language is awful, and the module infrastructure sucks. I would support (with my own money) a fork that would re-use the Terraform providers, and reimplement the language as something not so insane.

Well, if that's something you _actually_ want, take a look at Pulumi, which does precisely what you ask.

Re: The OpenTF Manifesto

#237

Post by jen20 »

yevpats wrote: post #165
0xbadcafebee wrote: post #142

Actually, can we just kill Terraform? Please? Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at al…

I think it's not only the issue with terraform but also the underlying infrastructure. AWS should've never have imperative APIs in the first place. Or at least it's time for AWS V2 APIs

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

Re: The OpenTF Manifesto

#238

Post by pcthrowaway »

busterarm wrote: post #169
pcthrowaway wrote: post #129

Earlier quoted context omitted.

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

the OP was suggesting that it's just obvious to use Kubernetes instead of Nomad. I was saying that anyone who operates large scale Kubernetes knows that you will forever be dealing with tuning etcd and fighting to keep etcd alive. It's an underpinning service of Kubernetes. Roblox's outage was related to the intricacies of running consul and mistakes that they made. The point I was making was that I would rather, at…

I was interested in Nomad in the past, but Kubernetes is open source, so it has that going for it

Re: The OpenTF Manifesto

#239

Post by ghshephard »

hdaz0017 wrote: post #183
busterarm wrote: post #121

Earlier quoted context omitted.

[flagged]

There is a big difference though Terraform is the out and out winner in its market. All their other products are at best small x% share of a crowded market or dominated by another product.

Genuinely curious - other than Vault - what other product is there for secret management in the cloud infrastructure space. I get that CyberArk Conjur is big in the enterprise space, but I thought cloud users, even with k8s, mostly went with vault.

Re: The OpenTF Manifesto

#240

Post by flanked-evergl »

scrum-treats wrote: post #225
mardifoufs wrote: post #184

Earlier quoted context omitted.

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…

Didn't Docker actually try it earlier this year, e.g., https://blog.alexellis.io/docker-is-deleting-open-source-ima... ?

Not sure what "it" refers to here, but what Docker did is in no way similar to what HashiCorp did.
Post reply on HN