I’m not sure why you say this. Maybe I don’t understand what you mean.
I have Delta Dental through my employer’s benefits and it covers all the types of operations that I’d expect: preventive, endodontic, periodontic, orthodontic, prosthodontic, etc.
If I need a root canal, it’s covered by Delta Dental (up to a point, given the deductible). If I chip a tooth, and get an inlay or onlay, that is covered. Is this not insurance? Why not?
Where I live, Delta offers a plan that essentially provides a set price list for various procedures as long as you are in network. Perhaps the person you're replying to has run into that plan and didn't realize that they also have more conventional plans.
- A rice cooker frees up a burner on the stove, which is useful for those with small apartments or other situations where there are few or no burners available.
- Rice cookers are very consistent and virtually foolproof, even the cheap ones. Add water and rice, set it, and forget it. I can say I’ve over or under cooked rice on the stove at least a few times, but not once in a rice cooker.
- Decent rice cookers make far better rice than I’ve personally ever made on the stove (and I have cooked rice on the stove plenty).
- More expensive models keep rice hot (at a food-safe temperature) for hours, so you can prep well in advance of a meal. I put rice on to cook and can leave the house for hours without worrying about it, and have rice for the whole day in one batch, if needed.
- Rice cookers also cook other things and some handle different kinds of rice. Brown rice needs to be cooked significantly differently than white rice, for example.
Yeah, of all the appliances in my own home, the microwave is the one I never complain about. I press the +30s button a few times, and the food is hot after a minute or two.
Yes, there are ten other buttons I never use. Yes, they could conceivably be “better” in small ways. Yes, modern ones can break like every other appliance does, but the ones from the 80s and 90s broke, too.
Agree. The better your team members, the less need there is for code review.
However, the approach of few/no code reviews doesn’t work for large open source projects that accept external contributions (the author of the post is mitchellh who is a founder of HashiCorp, which has/had several large open source projects).
Except it’s more if I have text following a variable.
Try this:
STR.”x=\{x} y=\{y} z=\{z}.”
Compared to:
“x=“ + x + “ y=“ + y + “ z=“ + z + “.”
A string template incurs an overhead of 3 characters per variable (“\“, “{“, and “}”) plus the leading “STR.”, which is 4 characters. Concatenation incurs an overhead of 4 non-whitespace characters per variable (`”+` and `+”`), and that’s ignoring whitespace. If you have more than 3-4 variables, string templates are shorter.
The concatenation example is less readable as well. Have I included whitespace to exactly match the string template example? It’s a little hard to tell at a glance because I have to distinguish what is code whitespace and what’s included in the string.
It's also ironic that most of the companies supporting OpenTF have closed-source products, yet they demand that HashiCorp keep their products open source.
env0 founder here, and core member in the OpenTF initiative. Thank you for your note. I wanted to mention that indeed env0 enjoyed Terraform being free, but also contributed back to the Terraform ecosystem, with github.com/env0/terratag OSS and TheIaCPodcast.com for education. Also important to mention another and probably a more important key member in the OpenTF initiative - Gruntwork, creators of Terragrunt and Terratest. I believe we all contributed nicely to the community, especially compared to our size / being small compared to Hashi. Just my 2 cents, in order to add a bit more context to "companies supporting OpenTF have closed-source products".
The core of every HashiCorp product is/was OSS. None of Spacelift is OSS, for example.
I’m not claiming it’s not the same monetization model, but with endless talk from these companies about the commitment to OSS and the virtues of OSS and the benefits HashiCorp has and would continue to receive by keeping their code OSS - it’s just ironic to see most of these companies have no open source code and aren’t actually willing to commit to an OSS model.
I can't say I'm familiar with the other companies/their tools but I assume they're all somewhat nebulous to terraform - did they not try to contribute back to hashicorp terraform?
In the TF scenario specifically it seems like it would have been smarter for hashicorp to open the core oss project to some outside contributors more directly (potentially moving to a different "ownership" on GH).
Maybe they'll relent and throw support behind the new project. Who knows.
At this time (4h after posting) they've responded to almost every other question/comment except this one, so they've seen this question and chosen not to respond, which means the answer is bad - no tests.
I like the idea of a Vault alternative, but I won't use a security product in production that is not automatically tested for vulnerabilities and regressions.
I'm very curious about this. I imagine HashiCorp has lawyers that are quite confident in the license change. IANAL, but I'd guess that the BSL is chosen in particular because it is somehow compatible with MPL in a legal sense? Or because, after 4 years, the license "degrades" into the MPL which gives them a loophole or such? I'm very interested if someone knows.
> TF providers are just wrappers around other APIs
If it's so simple, Pulumi could have done this themselves. Why didn't they? Would Pulumi have been as successful without leveraging the vast ecosystem of existing Terraform providers? Now they are a growing Terraform competitor.
> If it's so simple, Pulumi could have done this themselves. Why didn't they?
Because that would be a waste of time unless there's some specific case where an existing provider is insufficient.
> Would Pulumi have been as successful without leveraging the vast ecosystem of existing Terraform providers? Now they are a growing Terraform competitor.
Pulumi itself is free software, just like Terraform was (and hopefully still is). There is literally nothing stopping Hashicorp from doing the exact same thing in the opposite direction.
Are you pretending they aren't a competitor profiting off that work though?
Pulumi is free, except you pay for the features that aren't free: https://www.pulumi.com/pricing/. So, Pulumi has grown their directly competing product partially on top of the Terraform ecosystem - and I'd argue they'd be half as successful without reusing Terraform providers - and make money off of that product. It's at least understandable to me that Hashicorp doesn't like this.
Most TF providers are not maintained by Hashicorp, but by the company whose product the provider integrates into. Development of the provider is an investment the company makes to lower CAC.
Sure, but the providers for some of the biggest platforms are maintained by HashiCorp[1] - like the AWS, Azure, GCP, and Kubernetes providers[2], and it appears the Pulumi AWS provider (for example) _does_ use the Terraform AWS provider, even to this day[3].
3. https://github.com/pulumi/pulumi-aws/tree/008c4360bc9fc24303... - Just prove it to myself, I can see the `upstream` git submodule, which embeds pulumi/terraform-provider-aws, which is a fork of hashicorp/terraform-provider-aws, although the repo was not created as a fork in Github, so it is not marked as a "fork" and so I have to compare commit histories to tell that it is a fork.
The Pulumi Kubernetes provider is a native provider. It does not take a TF provider as a dependency. Instead, it works directly based off the k8s API spec.
The Google TF provider is actually maintained by Google via Magic Modules, a single source for both TF and Ansible . The generated TF provider does reside in HashiCorp’s GH org tho.
I've always seen open source as more of a spectrum. On one extreme, you have gpl3 stuff coming from the church of GNU itself. Moving up the spectrum you have stuff like the Linux kernel or certain CNCF projects, which can be used in proprietary distributions etc. Above that you'll have company specific licenses like the Amazon software license or whatever hashicorp+elastic are doing these days. At some point you're with RHEL where you need to sign a license to get their source, and above that you're signing ndas, and above that its closed source, and above that they're cryptographically obfuscating their source code with anti reverse engineering licensing.
I appreciate open source in all it's forms, as it's so much easier to 1. Read the code in case of a bug or just to understand your dependencies better, 2. Many of the semi closed licenses still allow you to learn things like syntax for GitHub actions or do analytics or whatever, which is still more value than an entirely closed system, and 3. It allows me to reproduce binaries and independently audit security.
That said, I'm worried about a tragedy of the commons situation. I'm not a fan of capitalism, but at the end of the day I can't pay for housing or taxes in clout or goodwill, and the only way I see likely to both attract talent and survive is one which works within the system while sacrificing their principles as little as possible. These wonderful engineers at elastic and hashicorp and pulumi and every other company mentioned in this thread need to eat.
I'm not saying I have an answer, but I am saying that I respect and understand why companies like elastic and hashicorp are resorting to drastic measures. If the choice is between either of those companies going under or having their source code come with a little bit more restrictions, I'd chose the latter. I'd much rather them have a noncompete clause in their license than have them just shut the window into their source code altogether.
That's being disingenuous. The link you cite is the pricing of Pulumi Cloud. Of course hosting infra can cost money. The second non-heading line in your link shows a way to host Pulumi on your own infra and that is fully free: https://www.pulumi.com/docs/concepts/state#using-a-self-mana...
However, Pulumi Cloud is only as valuable as Pulumi itself. If Pulumi didn't support deploying to AWS, for example, then it is useless to my organization which uses AWS and I'm obviously not going to consider Pulumi Cloud. So Pulumi does gain a lot of value even from just the Terraform AWS provider that it uses under the hood (and which it can continue to use because it seems Terraform provider licenses are not changing, which is nice).
> The paid features have nothing to do with the providers;
They absolutely do. If I use AWS and Pulumi could not deploy to AWS, well I'm certainly not going to buy Pulumi Cloud, am I? If I use multiple cloud providers and Pulumi doesn't support all of them, I'm unlikely to invest further in Pulumi Cloud, right?
The providers determine whether I can even use the tool to do what I want in the first place. The providers are 99% of the value!
The fact that Pulumi leverages the Terraform AWS provider under the hood adds huge value for them, and I absolutely believe they indirectly profit off of that.
No, they absolutely do not. Pulumi - as in the actual tool, not its developers' equivalent to Terraform Cloud - would still exist and would have used those providers regardless of whether or not there's some Pulumi equivalent to Terraform Cloud. Pulumi also would've existed (and resulted in indirect profits via Pulumi Cloud) had that provider ecosystem not yet existed; it just would've been Pulumi starting it instead of Hashicorp/Terraform.
> The providers determine whether I can even use the tool to do what I want in the first place. The providers are 99% of the value!
And you can use 100% of that value without paying a fraction of a penny to Pulumi, just as you can without paying a fraction of a penny to Hashicorp. It's a completely different offering from their respective paid products altogether.
> I absolutely believe they indirectly profit off of that.
You say this as if it's a one-way street, but it ain't. Pulumi and Hashicorp profit from there being an ecosystem of providers compatible with both and therefore useful to both sets of customers. That's one of the main sales pitches for open source, after all: to collaborate on something that benefits everyone instead of wasting a bunch of effort on independent silos.
That is: Hashicorp indirectly profits off Pulumi's own contributions to that same ecosystem. They could profit even more by making Terraform compatible with Pulumi's provider interface (even still! I'm pretty sure Apache 2.0 code can be included in non-FOSS codebases, BUSL included).
Like, the relationship between Hashicorp and Pulumi is not just to the letter but to the spirit of free and open source software. If Pulumi's existence and success (despite being nowhere near that of Terraform, and despite also being open source - even more permissively so, in fact) is indeed what motivated Hashicorp to switch Terraform from MPL 2.0 to BUSL, then that's toxic as all hell and completely nullifies any of Hashicorp's lip service to "open source".
> You say this as if it's a one-way street, but it ain't. Pulumi and Hashicorp profit from there being an ecosystem of providers compatible with both and therefore useful to both sets of customers.
This is idealism.
The reality is Pulumi's providers have no value for Terraform, which already built and curated its own ecosystem after years of time and effort. Then, Pulumi can spin up a directly competing product in a fraction of the time by reusing all of that work. So I understand the motivation for the license change.
Circling back to your original comment which spawned this thread:
> Like, has anyone of any significance used a Hashicorp product to meaningfully compete with Hashicorp?
The answer is unequivocally "yes". Pulumi has. And Pulumi can continue to do so, apparently. Terraform providers continue to be MPL-licensed.
With IBM Cloud® Secrets Manager, you can create secrets dynamically and lease them to applications while you control access from a single location. Built on open source HashiCorp Vault, Secrets Manager helps you get the data isolation of a dedicated environment with the benefits of a public cloud.
No, it's realism. The only one to blame for Hashicorp not adequately capitalizing on the two-way street that is multiple FOSS (well, formerly, in one case) IaC systems being compatible with one another... is Hashicorp. Instead of recognizing a case where "open source" is mutually beneficial, they'd rather take their ball and go home - and that's their right, but it ain't beyond criticism.
> The reality is Pulumi's providers have no value for Terraform, which already built and curated its own ecosystem after years of time and effort
The reality is that Hashicorp adopted Pulumi's strategy of autogenerating provider resources from API catalogs rather than maintaining handwritten bindings (i.e. what differentiates Pulumi's "native" v. "classic" providers). So yes, Pulumi's providers clearly have value. Hell, they can continue to have value even after Hashicorp's BUSL shenanigans thanks to Apache 2.0 being permissive.
> The answer is unequivocally "yes". Pulumi has.
The answer is hardly "unequivocal", per above and per the previous comments. Calling a collection of third-party-developed API shims a "product" is itself a massive stretch of the word, and calling bidirectional / mutually beneficial contribution to that collection "competition" is itself a massive stretch of the word.
IBM Cloud Secrets Manager is much better evidence in support of an unequivocal "yes" (though like most non-mainframe IBM-branded products these days I'd question whether or not it counts as "of any significance").
Would terraform have been successful without the ecosystem of providers provided by third parties, and many, many external contributions to providers they do manage?
Out of curiosity, I setup two directories where the second has a new file, a modified file, and a removed file compared to the first:
Then `git diff --name-status dir1 dir2` outputs the following, showing the changes by file name. This also doesn't require running `git init` on the two directories either, so it's immediately usable out of the box.