There is zero chance of Hashicorp donating Terraform to an open source foundation. If there was they would have never even considered this change in license. Honestly it's not a bad thing, maybe the maintainers of the Terraform fork will actually listen to feedback from the community of people who use it instead of ignoring them.
I did see https://github.com/diggerhq/open-terraform but have no idea if it is related. And I’m sure there are others. What I’ll be interested to see with the forks is how they will practically be maintained. All the bug and security fixes that HashiCorp is writing can’t just be cherry-picked into these forks (I think?), so what exactly are they supposed to do?
Hi! OpenTF is not connected with a single company. This is an united, community-driven effort.
You can check on the manifesto side who is behind. And we welcome all support!
> All the bug and security fixes that HashiCorp is writing can’t just be cherry-picked into these forks (I think?), so what exactly are they supposed to do?
Indeed, any fork will need to implement their own bug fixes.
Ideally they should do this "clean room" and not even look at the BSL'd code, to help defend against any accusations of copyright infringement.
Which is interesting, since Digger (the company that created that fork) is one of the OpenTF Manifesto signatories. Maybe they're recreating it under a different name / without the Hashicorp/Terraform branding all over the place?
Hashi got really good at ignoring PRs if they weren't their own. They even ignored the PRs coming from the dev teams of their own customers (ie users of TF Cloud and Enterprise) which speaks volumes about their willingness to listen to the community...
These people have seriously contributed back to the Terraform community. Terraform doesn't have a test suite- Grunt made Terratest, as well as many other tools. These people have seriously contributed back to the ecosystem, in many ways beyond what Hashicorp has done.
Beyond that, I know some of these companies tried to be contributors to Terraform itself but were ghosted by Hashicorp.
At the same time there's only a handful of regular contributors to Terraform[1]. It would not be hard for these companies to provide more resources to Terraform than Hashicorp is.
Probably not difficult for these competitor organizations to fund an OpenTF team to hire some of these people away from HashiCorp and continue it on as FOSS either. I can't imagine Liam turning down .5M/year to do so.
Marcin here, co-founder at Spacelift. We are open to fund 5 FTEs, feel free to reach out to us via the pledge page if you're interested in OpenTF becoming your full-time job.
Sorry, this may be a miscommunication. Terraform itself has a test suite, yeah, but it doesn't have a testing framework that users of the language can use to test their own code.
To make a python metaphor, if cpython had a testing suite but pytest didn't exist then people wouldn't be able to test their own python code. That's kind of the situation with Terraform right now- you can't test your code using just the Terraform tools, you have to rely on Terratest which was written by Gruntwork. Hashicorp has spent years relying on the open source community to fill those gaps, which Gruntwork has done very nicely.
"Astroturfing"... lol OK. I don't think I've ever made it a secret that I worked for HashiCorp in the early days (leaving in 2017), and have been critical to the point of being banned by the CEO from speaking at HashiConf.
Saying "Terraform doesn't have a test suite" is not miscommunication, it is misinformation, plain and simple - the same as most of the other things I have been correcting this week (not least from the same poster in this thread - someone who's clearly has an axe to grind).
You and the OP are referring to different things. Terraform the codebase has a test suite. Terraform the app does not have a test suite/runner as in a way to run tests against your Terraform files.
It doesn’t have a testing tool built in. No one legitimately understands the phrase “terraform doesn’t have a test suite” to mean anything except “there are no tests”. A runner and a suite are quite different.
I can understand the miscommunication in the first post, but I clarified in a direct comment to you what I meant. I was even comparing it to Terratest, which is not used for testing terraform core. At this point you're just being belligerent for the sake of being belligerent.
It’s actually not a guesstimate about what actions will be taken, it’s a guesstimate of the state that will result from those actions without any reference to ordering or “actions” as a cloud API would understand them - the plan is purely in terms of CRUD on Terraform provider resources and provisioners.
This may seem like a nit, but it fundamentally changes what Terraform is capable of doing in a single pass without external coordination.
This is reality of any successful Open Source ecosystem - folks who contribute the most (code, bug reports, marketing) in the project tend to be those who are making money on the project and these are the same folks who compete with you
Coopetition is name of the game in Open Source and too bad increasing number of the companies want to focus on capturing all economic value from ecosystem they have created with help from so many others
Anyway, the devil’s in the details, of both the license as well as the internal architecture of our system. I can’t share more here, but if you’d like to learn more please reach out via our chat or email. You can also expect more updates on our blog.
We, Terrateam, do not believe we violate the new license but we support Terraform being open due to how important it is to the ecosystem. Unlike Vault or Waypoint, Terraform is closer to a language compiler like Go or Java and benefits from a robust community that can build on top of a stable ecosystem. As such, we have announced our support of the OpenTF Manifest[0]
Massdriver was designed to be infrastructure-as-code agnostic from day 1.
Our goal has been to help companies get great operations, compliance, and security posture from day one.
While Massdriver is not a competitor to HashiCorp, the license language is extremely vague and leaves any infrastructure company running containers for their customers wondering if HashiCorp will consider them a competitor tomorrow.
We are proud to be providing development and community support for this initiative.
Great to see your commitment but I'm also curious why you, unlike some other companies, have chosen not to support with any full time employees? It seems your business is largely based on Terraform and saying pretty much "we'll contribute code" doesn't signal too much commitment.
I realize my comment might sound like an accusation but that's not my intention, I want to hear your reasoning about it!
>Imagine if the creators of Linux [] suddenly switched to a non-open-source license that only permitted non-competitive usage.
Linux cannot even successfully switch from GPL2 to GPL3 because of the sheer number of contributors and the fact that not all of them have transferred their copyright ownership to any given organization. This patchwork of different copyright owners has historically been seen as a potential weakness for Linux, but it seems like perhaps license inflexibility is a strength for open source.
I thought Linus and other believed GPLv2 was fine and the improvements of GPLv3 did not outweigh the potential problems introduced by it. It never came to a point where all authors were asked to agree, or sign away their ownership.
My understanding was that some people in the community believed that GPLv3 was better, and one of Linus's criticisms was that it was essentially impossible to switch even if it were better. I also believe Linus was opposed to the switch, which would make it unlikely anyway, but even if he had approved, I still think it would be practically impossible.
Torvalds considered the anti-TiVo clause to be changing the deal and he didn't want to do that, and there's no way in GPLv3 to opt-out of the clause[0].
This is less "locking down devices is a human right" and more him being angry that the FSF was trying to butt into his project's affairs. He's also similarly angry about "GNU/Linux" as it sounds an awful lot like Stallman just demanding everyone stick "GNU" onto the name of Linus's kernel project.
Anyway all of this is going to seem really quaint in 2027 when Broadcom gets sued under DMCA 1201 by a rogue kernel contributor for evading the Linux linker's license checks[1] and they have to hurriedly rewrite them out of the kernel and relicense anyway.
[0] Granting a blanket exception doesn't work because others can just remove the exception. "No further restrictions" is an ironclad law of copyleft.
[1] The Linux kernel checks the declared license of loaded modules and refuses to link non-GPL-compatible code against any kernel symbol not marked as a user-space equivalent. The reason why this works this way is because Linux ships under GPLv2 plus an exception that says user-space APIs don't trip copyleft, so you can legally load code built to those APIs into the kernel, but anything else might violate GPL.
Since this is enforcing an interpretation of the GPL, this is a DMCA 1201 technical protection measure. You absolutely could make a DMCA 1201 anticircumvention claim in court against a proprietary driver developer that tried to evade the checks. Though Linus usually just bans their modules in the next kernel revision since he's mainly worried about keeping proprietary modules from generating spurious bug reports in Linux. But the lawsuit is still possible, since they're on GPLv2. If they had relicensed to GPLv3, this wouldn't be an issue.
Are you arguing that the GPL check “effectively controls access to a work” or “effectively protects a right of a copyright owner [..] in a work or a portion thereof”? Either way, the bar of how “effective” a measure needs to be to count may be low, but probably not that low.
We changed the license[1] of a project which had 10 contributors, and we got every single one of them to do an Acked-by (by email) which took some weeks. That was on the advice of our lawyers. Can't imagine the impossible hassle of doing the same for something like Linux.
Can't speak for Linux, but got a few projects I've contributed to I've had to sign a CLA which negates that problem (but causes the one in this thread)
And that's assuming that all the contributors are even alive in the first place; unless you've got a Ouija board handy, you're gonna have one hell of a time changing Linux's license.
I think the problem is that if hashicorp thinks you are a competitor you and your clients now have legal/operational issues. Ie you are now a competitor because we are releasing a product just like yours, here is a letter from a lawyer telling you to stop using terraform.
This is precisely the problem with the new BSL license. Whether your usage of Terraform complies with the license isn’t determined by the legal terms, but instead is entirely at the whim of HashiCorp. And they can change their mind at any time. It makes it impossible to build anything on top of Terraform.
I worked at a financial institution that heavily utilized terraform. Their business is banking and they do not offer automation, orchestration or IaC as a service. They're fine.
This seems to affect only those places that attempt to build a business off terraform.
I am not saying those businesses can't be mad at the rug getting pulled out from under them, but it's important to be accurate that this doesn't affect end users of TF directly.
Is the financial institution made up of separate legal entities which bill each other for services, and does one of those entities provide tech infra for the other legal entities?
The messiness of the real-world unfortunately doesn't play well with ambiguity in licences :)
It'll be a headache for every large company which now has to send the licence to their legal teams who have to ask these kind of questions (another interesting one is "can contractors touch our terraform setup?") - in fairness to Hashicorp they've tried to address some of these issues in their FAQ, but the FAQ isn't legally binding so legal teams have to go on what's actually written in the licence.
This covers really well why I think the BSL license is a non-starter for things like TF. I get trying to prevent AWS from competing with you using your own open source code, but it creates this ambiguity where it's not clear whether lots of uses are or are not competing with HashiCorp.
> For example, if you’re an independent software vendor (ISV) or managed service provider (MSP) in the DevOps space, and you use Terraform with your customers (but not necessarily Terraform Cloud/Enterprise), are you a competitor? If your company creates a CI / CD product, is that competitive with Terraform Cloud or Waypoint? If your CI / CD product natively supports running Terraform as part of your CI / CD builds, is that embedding or hosting? If you built a wrapper for Terraform, is that a competitor? Is it embedding only if you include the source code or does using the Terraform CLI count as embedding? What if the CLI is installed by the customer? Is it hosting if the customer runs your product on their own servers?
The answer is at the whim of HashiCorp and subject to change at any point in the future. Even ignoring the attempt to dilute the meaning of "open source", the practical implications of the BSL license are more than enough reason to coalesce around a truly open source fork IMO.
Spacelift co-founder here.
Not going to comment on the legal aspect, but I'm actually curious when it did become acceptable in polite society to say that "we just want to kill the competition".
I appreciate the letter and trying to work with Hashicorp -- I used to have a ton of respect for Hashicorp. But honestly... at this point...
...just fork it into a foundation. Don't wait for Hashicorp's response. I get wanting to have the appearance of working with Hashicorp, but we've been shown again, and again, and again, and a-fucking-gain that private corporations cannot be trusted to maintain public goods. Only community governed non-profit foundations can do that.
Private corporations will put the bottom line first every single time. And in the case of investor funded enterprises, the bottom line is never ending exponential growth or bust.
Imagine a future CTO trying to pick the IaC tools for their company. They see Terraform as an option, but then learn there are multiple forks, licensing questions, and a big battle happening in the community. What do they do? They are now way more likely to pick a different tool that is genuinely open source. The same is true of every dev considering where to build their career, every hobbyist, every open source enthusiast, every vendor, etc. In the end, no matter which fork wins, everyone will be worse off: the community will be smaller and more splintered.
So we opted to ask HashiCorp do the right thing first. If they choose to do the right thing, we can avoid a fork, and avoid splintering the community. We still think that's the best option. But if that doesn't work, then a foundation + fork it is.
Imagine a future CTO trying to pick the IaC tools for their company. They see Terraform as an option, but then learn there are multiple forks, licensing questions, and a big battle happening in the community. What do they do?
I truly believe that a CTO who sees Terraform as an option and who isn't scared off by the BSL, but then has all of these other concerns, exists only in fantasy.
Just went with Elastic cloud after evaluating both Elasticsearch and OpenSearch. It was an easy choice to stick with the incumbent/creator that I was familiar with. No complaints so far.
Pulumi has a few languages other than YAML and Pulumi is declarative[1], and the programs you write are only as complex as you want them to be. This python program declares an S3 bucket and declares ten objects to exist in it.
from pulumi_aws import s3
bucket = s3.Bucket('bucket')
for i in range(10):
s3.BucketObject(
f'object-{i}',
s3.BucketObjectArgs(
bucket=bucket.id,
key=str(i),
)
)
Even so, Pulumi YAML has a "compiler" option, so if you want to write CUE or jsonnet[1], or other[2] languages, it definitely supports that.
Disclaimer: I led the YAML project and added the compiler feature at the request of some folks internally looking for CUE support :)
I'm aware of the SDKs, but we don't want them because they are an imperative interface, no matter how you want to spin it as "declarative". I have access to all the imperative constructs in the underlying language and can create conditional execution without restriction.
Even if I use the Yaml compiler for CUE (which we did) I still have to write `fn::` strings as keys, which is ugly and not the direction our industry should go. Let's stop putting imperative constructs into string, let's use a better language for configuration, something purpose built, not an SDK in an imperative language. These "fn::" strings are just bringing imperative constructs back into what could have been an actual declarative interface. Note, Pulumi is not alone here, there are lots of people hacking Yaml because they don't know what else there is to do. CEL making it's way to k8s is another specific example.
This cannot be the state-of-art in ops, we can do much better, but I get that Pulumi is trying to reach a different set of users than devops and will end up with different choices and tradeoffs
you can have loops and still be declarative, CUE has loops, though they are considered comprehensions more technically, but there is no assignment or stack in CUE
One of the interesting aspects of CUE is that it gives us many of the programming constructs we are used to, but remains Turing incomplete, so no general recursion or user defined functions. There is a scripting layer where you can get more real world stuff done too
The CUE language is super interesting, has a very unique take on things and comes from the same heritage as Go, containers, and Kubernetes
The imperative part of that code appears to be analogous to templating. The actual work done under the covers is not imperative, but is based on the difference between the result of the template execution and the current state of the system. That's what makes it declarative.
It really depends on the interaction between the user's Pulumi script and the Pulumi engine.
If there is more than one back and forth, you become declarative, even if you imperatively generate a "declarative" intermediate representation (not really sure what state file at a point in time could ever be imperative), you then would get back some data from the engine, then make choices about what to send off to the engine in the next request.
It's important to understand that with Pulumi, you can end up in either situation. You have to be careful to not become imperative overall is probably the better way to consider this.
Another way this can break down is if the user writes code to call the same APIs in the middle of a Pulumi script. I meant to try this myself to verify it works, but I would assume that Pulumi is not stopping me from doing something like this.
In general maybe, but in the specific context above, I think calling that loop declarative is accurate, and laughing at that classification is a poor response rooted in a deep misunderstanding.
import pulumi
from pulumi_gcp import storage
bucket = "hof-io--develop-internal"
name = "pulumi/hack/condition.txt"
cond = False
msg = "running"
cnt = 0
while not cond:
cnt += 1
key = storage.get_bucket_object_content(name=name, bucket=bucket)
print(cnt, key.content)
if key.content == "exit":
msg = "hallo!"
break
pulumi.export('msg', msg)
pulumi.export('cnt', cnt)
---
769 exit
770 exit
771 exit
772 exit
773 exit
774 exit
775 exit
Outputs:
cnt: 775
msg: "hallo!"
Resources:
+ 1 to create
info: There are no resources in your stack (other than the stack resource).
Do you want to perform this update? [Use arrows to move, type to filter]
yes
> no
details
----
Of note, all but the last exit had a newline, until I `echo -n` the file I copied up
TF might be susceptible to the same file contents manipulation between plan & apply as well, but then again, you can save a plan to a file and then run it later, so maybe not? Another experiment seems to be in order
I think this is an advantage of Pulumi, here are two use cases:
1. Creating a resource where created is not the same as ready. This is extraordinarily common with compute resources (a virtual machine, a container, an HTTP server, a process) where attempting to create follow-up resources can result in costly retry-back-off loops. Even when creating Kubernetes resources, Pulumi will stand up an internet-connected deployment more quickly than many other tools because you can ensure the image is published before a pod references it, the pod is up before a service references it, and so on. (The Kubernetes provider bakes some of these awaits in by default.)
2. Resources graphs that are dynamic, reflecting external data sources at the moment of creation. Whether you want to write a Kubernetes operator, synchronize an LDAP directory to a SaaS product, or one of my favorite examples. When I set up demos, I often configure the authorized public IPs dynamically:
import * as publicIp from 'public-ip';
new someProvider.Kubernetes.Cluster('cluster',
{
apiServerAccessProfile: {
authorizedIPRanges: [await publicIp.v4()],
enablePrivateCluster: false,
},
}
Of course you think it is an advantage, you work for Pulumi
I'm telling you this is not how a potential user sees the same situation, that it is a disadvantage and was one of the reasons we are not making the switch.
This example above is exactly the kind of code we don't want in ops, it depends on the user environment and physical location at the time they run the command, bad practice. Thanks for an extra talking point though
The claim above is that Pulumi uses an imperative interface and that it is quite easy to slip past the declarative guardrails, so in most cases Pulumi is imperative, not declarative. The fact that Pulumi makes this separation opaque can be discussed, as can the clear separation be shown an alternative with benefits
The claim I keep seeing from Pulumi folks is that Pulumi is declarative, which is is not, as shown in multiple posts by many people. Please stop calling it such, it demonstrates dishonesty towards users
The claim above was that a for loop implied that the code couldn't be declarative.
> Please stop calling it such
I'm not claiming it is always declarative, I'm only claiming that a declarative example above can contain a for loop, and that laughing at that is the wrong response. That's it.
When someone tries to make a sophisticated argument that up is down and white is black, dismissive and shallow is the right response.
> The actual work done under the covers is not imperative
Having a declarative layer somewhere in the stack doesn't make something declarative, if that's not the layer you actually use to work on and reason about the system. See the famous "the C language is purely functional" post.
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 HashiCorp releases/acquires a product that competes with mine, then my license is void.
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 supporting tooling and software so that a user could spin up their own version of the service.
There's an argument to be made that SSPL is de facto "you can't compete with us" since it would be more challenging to make a competitive SaaS offering if your whole stack is source available. I don't disagree. However, as distasteful as SSPL is, at least it doesn't grant licensing to a product conditionally on the unknowable future product offerings of HashiCorp.
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
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.
I don't get this one, you pick OpenTerraform and get on with your life. It's the same with picking OpenSearch over Elastic. I can use the proprietary version that locks me into a single profit-seeking vendor and doesn't have community backing or the one run by a foundation made up of companies that use and are heavily invested in Terraform.
How dare a vendor come up with an idea, pay people to execute on it, give it away for free to the world, acquire users and soak in all the community contributions from people who thought they were using and contributing to a public good, try and fail to indirectly monetize a hosted version because other people were better at it than them, then rug-pull out from under everyone and use copyright/government-stick to kill their competition because they can't compete on even terms.
Then a group of people who are users of idea and actually making money off it with value-adds step up to maintain it as a community project ensuring that it stays open for everyone -- yeah those guys are the assholes. Terraform would have went nowhere if it wasn't OSS and Terraform would be nothing without its outside contributions that make up far more than the code of Terraform core itself. There's a trail of bodies to prove it.
And you should love this, projects that are stewarded by its own users are incentivized to make it the best it can be instead of rejecting contributions because it competes with their cloud offering [1]
I didn't know either, so I did some Googling and found an old announcement[1] from 2009:
> A group of leading Nagios protagonists including members of the Nagios Community Advisory board and creators of multiple Nagios Addons have launched Icinga – a fork of Nagios, the prevalent open source monitoring system. This independent project [is based upon a] broader developer community. [...] Icinga takes all the great features of Nagios and combines it with the feature requests and patches of the user community.
It also looks like in 2014, Nagios centralized and appropriated a domain name and website used for hosting Nagios plugins, away from the community (its plugin developers)[2]:
> In the past, the domain "nagios-plugins.org" pointed to a server maintained by us, the Nagios Plugins Development Team. The domain itself had been transferred to Nagios Enterprises a few years ago, but we had an agreement that the project would continue to be independently run by the actual plugin maintainers.¹ Yesterday, the DNS records were modified to point to web space controlled by Nagios Enterprises instead. This change was done without prior notice.
> To make things worse, large parts of our web site were copied and are now served (with slight modifications²) by <http://nagios-plugins.org/>. Again, this was done without contacting us, and without our permission.
> This means we cannot use the name "Nagios Plugins" any longer.
> [Icinga developer]: "Six months before the fork, there was a bit of unrest among Nagios' extension developers [...] Community patches went unapplied for a long time[.]"
> [...]
> Two years ago, more or less when the split happened, [Nagios author] was having problems resolving [trademark] issues with a company called "Netways".
I'm still not sure what the effect is supposed to be tbh.
Nagios used to be only Open Source then they created the Enterprise version and left the open source core version lagging behind, it was forked a billion times or more :) creating the Nagios Effect. A lot of monitoring software / companies then removed / replaced the core of Nagios from their products.
The guys at Pulumi must be having a field day right now. It's exactly how you describe it for us. We're long overdue with an upgrade of our Terraform config from pre v1.0. We have to most likely re-write a big part of our HCL code, so why not try a competitor?
With Vault however that's another story, I've yet to find another secrets management system that has a tight integration with Kubernetes, AWS and supports providers for things like Postgresql to have ephemeral database credentials.
Even though I strongly believe the OpenTF fork could open up incredible possibilities for the community (I could go on and on about it), it is an equivalent of a civil war. It doesn't serve the community and our only interest is in the continued strength of the community that we continue to build for.
Based on my immense respect for what's been built under Hashi's umbrella I'd rather see a change of mind, and an opportunity to honor our pledge of resources (5 FTEs for 5 years) to the common rather than partisan cause.
I really appreciate that, and I do think it's right of you to at least make the attempt.
That being said, I don't expect this attempt to work and I fully believe that a fork is going to be inevitable. I also think a fork is an amazing opportunity to standardize the language and prioritize the features developers want.
It isn't just about the license, but the way that Hashicorp has maintained the Terraform project. The github insights show that they don't have nearly as many people working on it as I would expect, and most of them are split into also working on Terraform Cloud. At the same time they don't work with the community that well- there are open issues and pull requests that just get ignored as Hashicorp clearly doesn't see value in open source contributors. This isn't just a Terraform issue either- my company had to move off of nomad due to the lack of development and support (as well as broken features).
I have strong concerns about the future of these projects in general beyond just the licensing. An open foundation that had multiple companies involved would by definition need to find a way for those people to collaborate together, and once they do that it makes it easier for them to invite community collaboration. So while I do appreciate that it is a drastic step, I think it's one that would also be far better for the ecosystem and project as a whole.
That said, maybe this is the wake up call hashicorp needs to fix these problems. If you provide five FTEs that basically doubles the size of their Terraform development team (they have more people working on it than five, but those people are split into other projects), and once they start working with other groups maybe they'll work with the community more as well. I'm not holding my breath though.
Smells like the end of Chef. Management doesn't understand how much it takes to maintain the open source project and is just pouring resources into sales and marketing and products that they can charge for, and don't see how that erodes goodwill and the technological foundation of the company.
I also saw that parallel with Chef. I think its the story of all VC funded software that attempts to be "Open Source". For them, Open Source means "You can read the source code, and potentially fix a bug", for us, it means community, transparency, and fixing bugs beyond those your paying customer has.
I looked at github /chef/chef and github /inspec/inspec and its the same as it was shortly after I left. The only changes are from the one person who carried over after the sale to Progress, and the contracting team out of India, with dozens are unanswered queries and pull requests from the community.
What really ruffles my feathers was when they had us define oss-practices (https://github.com/chef/chef-oss-practices), clearly nobody outside our small team read (or understood) those words and goals. It feels like it was work to make us look better in OSS in order to bolster the company sale.
There was a whole lot of community window dressing going on. I still wonder if they weren't trying to ship maintenance of the open source code off onto the community thinking that if all that worked appeared (or thinking that it was actually going on--believing their own bullshit about how involved the community was) that they could just leach that work.
There's probably some manager at Hashi right now trying to argue that they should offload TF maintenance entirely onto the community and they should pivot to hosting services and consulting and making money off of all that free work.
chef said, did and tried some really dumb stuff and lots of it failed for obvious reasons, it's like docker took a chunk of their playbook and their business went the same way.
Hashicorp isn't going to budge here. The same argument that you've made about Terraform being the underpinnings and needing to be open-sourced can be applied to their other important products like Vault, Consul and Nomad as well. The ecosystem of those three is plainly a direct competitor to Kubernetes which is open-source.
There's really no move for them to make here. It's unfortunate.
Tons of organizations run vault and consul as part of their k8s ecosystem so they don't directly compete. The vault CSI driver might be the single most installed CSI driver across all the orgs I've worked for
If you are running Nomad as your orchestrator, because of the tight integrations you are almost certainly running vault for secrets and consul for service discovery/service mesh. The ecosystem of the three is the competitor to K8s.
While the Nomad stack is a direct competitor to k8s, Consul and Vault are both heavily used alongside k8s. In fact, Consul had features that were only for k8s the last time I checked
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.
It's far more likely to be Vault as a base, actually. The MPL would allow someone like Amazon to use Vault's source as a base, and so long as the core source wasn't modified Amazon would be under no obligation to make their modifications public.
The MPL is a lot more "business" friendly than the GPL.
The very fact that HashiCorp is changing their license and restricting use clearly indicates they see this threat as reality. Amazon/Microsoft/Google/Whoever using HashiCorp's work/effort but keeping all the money to themselves.
There's a lot more reasons to run Vault than those.
Having a standardized way to "do secrets" for any team, any service, any app within the organization is very nice. Becoming cloud-agnostic for your secrets (connecting your local Vault with the cloud provider's vault) is another great benefit. Automatic secret rotation is also another great benefit. Secret versioning and auditing... etc.
It's not just "can't have this secret in VCS or viewable via kubectl".
> It's not just "can't have this secret in VCS or viewable via kubectl".
That is exactly what it is.
You seem to misunderstand (and thus downvote?) the statement I made. I'm not saying "haha vault bad", I'm answering "what other product" (from ghshephard) with the reality of today.
This has nothing to do with what Vault is or isn't, but just with the concept of storing secrets in a uniform way in clouds for use with cloud workloads what is being used right now.
I did not downvote you, no. Downvoting because we disagree isn't how that's supposed to work, even though some use it that way.
Regardless, the use of Vault is not exclusive to cloud environments.
All of the listed features of Vault have benefits within larger organizations even if they don't use the "cloud" and deploy monolithic applications.
Most frameworks have built in ways to fetch secrets/config from Vault, making it an easy standardized way to do things across all of your applications/teams.
It doesn't mean you need to use it, of course, but it has a lot of perks for many different situations.
I totally agree that Vault is more than a glorified password manager (because that's what most Clouds have in their implementation of a secrets store), but the thing is, everywhere I go, I don't see people use Vault, I see them use whatever AWS/Google/Azure happens to have (and often badly).
I'm not sure if that's even what ghshephard meant when he was curious for 'products', since technically all those cloud-integrated services aren't really stand-alone products for that matter.
In AWS for example, with or without EKS (and then something like External Secrets Operator in the EKS case), it's all just AWS Secrets Manager and sometimes Parameter Store. In a few cases people do manual encryption (using KMS), but in no case was HashiCorp Vault used.
Often, it's even worse: no secrets management at all. Stuff just gets pumped into environment variables (more often than not they get committed as .env files to Git), and there's just no drive to change that, even when a business policy is in place. Some even 'work around' this by storing secrets in password managers like 1Password and LastPass so they can check the compliance box without actually protecting the secrets (since they also live in plain text in VCS and at runtime in the environment).
In terms of 'products', I'd say Vault and the cloud ones don't really compare, but reality is depressing and secrets are often not as secret as the name implies. From a developer perspective, they might compare them because they desire the secrets to be injected into the environment either way, and as such the source doesn't matter much. I'm not sure if we should see that as a feature or a bug.
We use vault as a framework that associates authentication with secret engines via a policy framework. The Secret Engines could be AWS, PostGres Database, PKI, SSH Certificate Signer, Key value stores, etc... and the Authentication Framework might be LDAP, OKTA, or plain tokens. The Policy framework is pretty dynamic and has many thousands of possible policies mapping various authenticated entities to various authority (read, list, write, etc...) to various secret engines. Combine that with the syntactic niceties of template-rendering integration with the chosen secret-store, and maybe some clever stuff around single-use token wrapping - and I think of all of those features as belonging to a single product.
I'm relatively new to this field - and see tons of Vault at colleagues companies, and have friends who run/support Conjur (Enterprise more than cloud). Those are the only two secret-management framework/products I'd hear of - so was interesting in knowing what else had mindshare.
I wonder if some of this also depends on how the secrets are consumed (and created), I'd imagine that if you store things like an API key and secret for a third party API, someone needs to 'enter' that data at some point in time and then set an ACL to allow a person or system to then consume it.
But if you have two programs what exchange secrets between multiple instances of each other, (one can do CRUD, the other only Read), you'd have much more interaction. Same as with a system creating secrets and a human reading it.
As for where it would make no sense at all: automated workload identities where you get time-limited temporary credentials that represent a role; most public clouds have some sort of link-local API, an injection method or mount method to provide ever-rotating secrets which gets picked up by the client SDK automatically. If you are using something like AWS, you'd be able to consume hundreds of services without ever persisting a secret anywhere.
This is also where my 'cloud' (and K8s) remarks are based on; when your workload and your resources speak the same authn/authz with a centrally coordinated policy system, there really isn't much value in adding something in the middle of that, and as such you don't see a lot of Vault and Vault-like implementations.
That said, as soon as you add something disconnected like local virtual machines, on-prem stuff etc. where authentication has historically been extremely bad and unless you brought a proper Kerberos setup you're screwed beyond mitigation. That's where Vault (when it came out) delivered a lot of value. It's probably also why we see AWS, IBM, GCP, Azure, in the same list with Vault and CyberArk. I'm surprised VMware doesn't have anything yet, but perhaps they recognise they lost this one already.
I recognize you're in interesting position in Spacelift. Per your recent analyses you may not be impacted and in this case you probably do not want to pissoff Hashicorp folks :)
In reality though force better be responded with force and showing Hashcorp what what was Terraform will be successful as Open Source project with or without them is best way to get them to reconsider.
Why. It is open source. A fork should be no big deal, and definitely not a “civil war”. I think the community should be quicker to fork open source projects that are not serving the needs of the community.
The corporations are trying to have the benefits of open source without the responsibility. Forking is a normal, acceptable part of open source and we should normalize it.
What would it mean to “normalise” forking? The costs of maintaining a fork are significant, and if one group of programmers are being funded to work on the project then it can be very difficult to fork a project in any meaningful way without significant resources behind it.
Also IIUC most of the parties in this conversation are corporations. They’re all trying to enjoy the benefits of open source development for a variety of reasons.
Currently forks are painful, because they aren't normalized i.e. our tools and workflows don't expect them. I'm saying rather than discouraging forks we should adapt our tools and workflows to expect them.
But the real work is all the hard work that goes into a fork. I've watched open forks die all the time--all it takes is no one to step up and do/pay for the work, which is basically the default, because it is in everyone's interest if someone else is the one to do that.
I think that's really the crux of the problem--there are plenty of folks willing to maintain software for money, and a whole lot of people who'd rather it not cost money and if it does, not their money.
If the tooling is better, who is going to maintain this?
hashicorp has decided they don't want to contribute to open source any more
they're totally within their rights to do so, and it doesn't harm anybody; it's not the equivalent of going around blowing up buildings, raping women, and napalming children. at most we can wish they had continued doing the beneficial things they were previously doing
maybe they'll change their minds, as you say, but that's no reason for the community to sit around twiddling its thumbs hoping for such a change. what's important now is that the people who are still willing to cooperate can do so successfully, and that's what opentf is about
that's even more obviously not the equivalent of going around blowing up buildings, raping women, and napalming children. it's very much the opposite, in fact
it's unclear to me which of the parties you intend to accuse of doing the moral equivalent of burning innocent people alive en masse, but either way, maybe you should think about walking back that rhetoric a bit
it's not a possible schism. hashicorp has clearly and unmistakably abandoned the open source community. conceivably they'll change their minds, but their communication doesn't have any ambiguity in it
i have no idea what you could possibly mean by 'focus on the "civil"'. it's good that people are being civil to one another, isn't it? then why are you criticizing them?
You're missing the point- the OpenTF group wants to mend the schism if possible, by getting Hashicorp to change their licensing back. If they immediately fork then that's not likely to happen, so they're attempting this first.
I don't think it will work, but I think it's good of them to try.
mending the schism would be great, but we probably can't do that by pretending it doesn't exist like https://news.ycombinator.com/item?id=37139929, or analogizing it to blowing thousands of children's extremities off, or analogizing acknowledging its existence to blowing thousands of children's extremities off
I'm still not sure which of the latter two was the intent of the comment I was responding to
my objection is not that mass graves, piles of mangled bodies, your close friends unexpectedly disappearing into pink mist, and terrible stenches are too sacred to be used as a metaphor for something else
my objection is that warfare involves people intentionally harming each other, and that doesn't seem to be what's going on here. it's not that war is a more extreme version of the situation; it's that it's directionally different
rather, hashicorp is struggling to not go bankrupt, so they've decided to switch to making a proprietary product instead of an open-source products; and terraform users, naturally enough, are reluctant to make their infrastructure vulnerable to a proprietary software license. hashicorp is not intentionally harming terraform users, and terraform users are not intentionally harming hashicorp
they're just not continuing their previous cooperation
Not sacred enough for you to invoke the Holocaust in a discussion about data protection legislation and the "right to be forgotten" within mere hours of this statement, however...
Such hypocrisy, attacking others for "rhetoric" that needs to be "dialled back a bit" when you're every bit as guilty of the exact. same. thing.
please note that the comment you are replying to says the opposite of what you are implying it does; it says 'my objection is not that mass graves, (...) are too sacred'
the comment you are referring to, for anyone who is interested, concerns the question of whether or not there is a higher standard of morality to which legislation can be held, or whether legislation itself is the ultimate moral authority, or whether there is in fact no objective standard of morality at all. anyone who is interested in that kind of thing can read it at https://news.ycombinator.com/item?id=37147305
Don't you think you should check yourself before attacking others?
> "it's unclear to me which of the parties you intend to accuse of doing the moral equivalent of burning innocent people alive en masse, but either way, maybe you should think about walking back that rhetoric a bit"
... but only earlier today were you equating a data protection law with the Holocaust... seems you could do with a bit less projection and rhetoric yourself, Kraggy.
this is careless reasoning; rather than equating a so-called 'data protection law' with the holocaust, i said the justification others were using for that law was incorrect, because if it were correct, it would also justify the holocaust
this is not an extremely advanced form of logic, but i understand that it is not within everyone's grasp
my objection to the war rhetoric in this case is that it casts people as opponents who are not, in fact, opponents, just different parties pursuing largely independent interests. in that context playing 'let's you and him fight' seems unlikely to improve the situation
Why use so-called? It's literally a law concerning data protection. Unless you feel that the empirical truth somehow shouldn't be used to describe the GDPR and colloquial "right to be forgotten" aspects it entails, you're just trolling for trolling's sake -- either that, or you don't even know that you're using "so-called" improperly.
Once again you jump to mansplaining and condescension, followed by failing to even get a username correct when it's literally on your screen.
Your repeated attempts to tell people what they think, what they do or do not know, and where they live, show that every observation of you being arrogant, condescending, and disingenuous, is patently correct.
Unsure if you need a shovel to get out of that hole you've put yourself in, but you're sure backpedaling quickly, yikes.
As a user and collaborator of TACOS, agreed that it could open up opportunities. Though I echo trade-offs (as in other replies) that it could start a civil war that makes it difficult for end users and collaborators -- reminds me of Python2 -> 3, Presto/Trino, and many other stories. Pledging resources is a great approach.
Speaking of nuclear options, need to get the providers to pledge/follow the fork, maybe via some kind of API incompatibility. Terraform is useless if the providers don't work with it and only the fork. Focus on disrupting the ecosystem.
Hashicorp left the provider frameworks under the original licenses, probably because they don't want to scare provider developers off. So for now both Terraform and a potential fork can continue sharing the same providers without issue.
This is the interesting part of all of this. The meat of Terraform is in its provider ecosystem. Anyone can make a new frontend (or even fork the existing one?), get rid of all the warts, add the missing encryption features gated under enterprise and have a much better tool.
I totally agree. I do not think pleading with Hashicorp to reconsider will result in changing back the license
Doing the Fork and showing it IS sustainable and has broad community support can encourage Hashicorp to make concessions.
After taking this unilateral hostile step I do not think Hashicorp deserves the community trust and what industry needs is "Foundation Governed" Terraform like solution, whatever name this solution will have.
You can see example in Confluenct which builds proprietary solutions around Kafka, where Kafka itself is Apache project.
> In economics, a public good (also referred to as a social good or collective good)[1] is a good that is both non-excludable and non-rivalrous. For such goods, users cannot be barred from accessing or using them for failing to pay for them. Also, use by one person neither prevents access of other people nor does it reduce availability to others.
Any free open source product qualifies as a public good. It is free for all to use, and one person using it does not exclude anyone else from using.
They can't retroactively take source code away from people who they already granted access to it under the MPL. The old code is still available under the MPL forever- even if they take down all of their own public copies of it, anyone with the old Terraform code is still free to upload their copy for the creation of a new fork. That's kinda the whole idea with these open-source licenses :)
I've heard some people discuss that the contribution agreement that Hashicorp makes people sign gives them the right to change the license for existing contributions, but I'm not a lawyer so I really couldn't say for certain either way.
HashiCorp makes its external contributors sign a CLA to basically hand over the copyright.
However the MPL and licensing in general is irrevocable. They have irrevocably licensed Terraform 1.5.5 under the MPL and an enterprise license (dual license). Anyone can use, modify and distribute version 1.5.5 under the terms of the MPL.
Since HashiCorp retains full copyright they can release the next version under the BSL.
Note that many free software projects (like Linux) don't have a CLA which makes relicensing impractical since every contributor would have to agree to it.
Why not get it under the umbrella of either the Linux Foundation or CNCF? Things like this and Ansible should be really kept under neutral companies and not companies like Red Hat and HashiCorp that have shown that all they care about open source is the free work they get from contributors.
We just moved the signatures to a table format, so you individuals can now add themselves to the table: just set the "type" column to "Individual." Thank you!
Turns out the proliferation of open source was never because of "collaboration" or "community", it was actually just a result of zero interest rates and "growth".
That's a possibility, but a collection of companies trying to drive FOSS even after the original company stops is a great argument that it is in fact a collaborative thing
How exactly do the companies involved plan to fund a fork? It would require at minimum 3-4 full time engineers, and no one is going to do that work for free.
It’s also telling that this manifesto blithely suggests TF could become Apache 2, which is wholly untrue.
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.
As I see it Hashicorp has failed to create a viable business model in an environment where there isn't unlimited perpetual VC money. Now they're at the stage of giving up and simply trying to shake down those who have managed to make better business models.
It's usually not a good idea to be near a company flailing like this since who knows what their next rent seeking approach will be. A company with nothing to lose is a dangerous partner to have.
The worst part is they did create a viable business model. They were profitable when they had their IPO. They then pretended that the IPO was just another Series X investment, blew all the money, and went negative on their cashflow.
Hashicorps problem isn't that their business model doesn't work, it's that they are really bad at their jobs. They ignore customer feedback, laid off support people, and then jacked their prices up. It's a self inflicted wound, and instead of trying to fix it they just keep making it worse.
Definitely, the fact they're rent seeking against similar small companies clearly shows that. Sad that rather than looking inward to improve themselves they've decided to just attack others.
I've worked for three companies now that went to hashicorp to buy TFE and left with a quote equal to a quarter or more of revenue and the sales rep acting like they are the second coming and obviously we are stupid for not thinking they bring that much value to our org. No org invests 1/4 of their revenue on a single tool. So we used atlantis or spacelift or hand rolled GHA scripts and saved a fortune.
We are trying to pay them and they are being so unreasonable with pricing that we can't give them our money
It’s been that way for years with them. It’ll be interesting to see if they go the road if a private equity buyout, or they’re acquired by a technology company for the copyright/trademark.
He doesn't work at Hashicorp anymore, and even quit the board. Since the company is public he could have just completely cashed out at this point (and I wouldn't blame him for it).
Only Hashicorp employees are allowed to comment here? How about the person that actually built it? Maybe he has interesting things to say. Also, he's been silent on HN as a whole, not just Hashicorp-related threads.
Maybe he signed a gag order and cashed out. We may never know.
We say OpenTF is (or will be) a fork, and forks are bad, nuclear option, etc, but really, Hashicorp are the ones who made a breaking change, and the "fork" merely maintains that which already was, but for reasons, are not allowed to continue using their own name.
We need for the shortest sound-bite 3-word sentence to the non-technical to somehow use terminology that says that the entity that caused the problem is the one who did some action.
OpenTF did not (or is not prepareing to) fork this project, Hashicorp did.
If it was me and I wasn't legally prevented by something actually binding in writing with signatures, I'd even keep using the original name and duke that out.
It can be rebranded, that's pretty straightforward for something that's such an industry standard. "Oh yeah? Earthworks? That's the open source fork of Terraform" pretty simple. If it were a lesser known technology it would be an issue but most of the (modern) internet runs on it, whatever they name the fork will be well known pretty much instantly
One thing I particularly hate about license change is lack of notice - If you operate in good faith you probably would want to give time to community to make arrangement, whenever it is negotiating agreement with you or looking for alternatives. Lack of notice this means everyone who embedded Terraform put their customers at risk immediately as in case any discovered CVEs they will not be able to ship security fixes to their customers.
Having recently picked up Rust (yes, sorry for mentioning it, I promise it's relevant), I picked up Terraform the other day. I was shocked by how weak its language-level developer experience story is.
I am working in VSCode, which by and large tends to be the editor supported best, with the most mindshare. Terraform has static and mostly strong typing, yet some testing revealed I was able to pass an argument of the wrong type to some variable I declared. This is type safety 101: variable declared `str` shouldn't accept `int`, ever. Yet `tf validate` was silent, so was all IDE-integrated tooling (whatever the VSCode TF extension does).
Jumping to/from symbol definitions/usages was also flaky (but not entirely absent).
Really disappointing! My excitement of diving into TF went poof. Maybe I'm overly sensitive, but I was so excited to escape YAML hell (Ansible).
Now I'm even firmer in the boat of just using a regular old language, like Pulumi with Python (with full typing).
Did I do something wrong or can anyone confirm my findings?
You can, for most of the cases. You just need a way to tag resources as belonging to the tool. This can be done via prefixed (or suffixed) names, tags, etc.
That… is state, just stored elsewhere. It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.
Terraform having state wasn’t some easy button decision, it was absolutely required and carefully considered.
The state is stored in the resources themselves, to be precise.
> It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.
As someone who worked on tagging inside AWS, I don't believe that there are any major AWS services left that don't support tagging. These days, tagging-on-creation also guarantees that you won't have untagged resources if your provider happens to die between "CreateResource" and the "TagResource" operations.
You can also sometimes use prefixed names to signal that a resource belongs to the infrastructure-as-code.
API limits for "describe" calls are also pretty lax. And you need to use them anyway to check if the current state of the world matches with the saved state.
State will be needed for some integrations that don't support tagging/naming (Okta, I'm looking at YOU!), but at least for AWS it's not needed.
There may be no services at large that don’t support tagging (certainly was historically not the case though), but there a hundreds of resources that don’t.
Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).
Finally, how would you manage tags as an actual resource themselves in this model?
For resources that don't support tagging or user-defined naming, you'll need state.
> Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).
You can fix your IAM. Cost allocation tags are treated specially.
> Finally, how would you manage tags as an actual resource themselves in this model?
Ask Roblox employees how they feel about Hashicorp products. Terraform is probably the most solid product they have seconded by vault, but after hearing the consul and nomad horror stories, I don't think I could take their products seriously ever, not when kubernetes is setting right there.
TL;DR The outage was caused by (a) they enabled a new streaming feature in Consul under unusualy high read-and-write load, (b) the load conditions triggered a pathological issue in the third-party BoltDB system upon which Consul relies and (c) all of that was exacerbated by having one consul cluster supporting multiple workloads.
I'd use quotes to catalog this as a "horror" story, because this was clearly a very specific issue triggered by a specific and complex set of circumstances.
The blogpost also mentions that Roblox worked closely with Hashicorp engineers to mitigate the issue, and work towards structural solutions; the post also affirms their choice to manage their infra themselves rather then moving into a public cloud solution.
Sure, Kubernetes covers loads of territory. But there definitely are niches where products like Consul & Nomad do add value.
Hashicorp enterprise support is rock solid for Nomad, Consul, Vault. If there is a P0 problem, they will root cause, and usually have a fix identified in < 48 hours. All three of those products are taken very seriously - running 10,000+ servers in a single cluster.
Enjoy spending the rest of your life trying to get etcd to cooperate. If you think operating Kubernetes at scale is a cakewalk, you don't have the scale problems you think you do.
I'll take consul over etcd ten million times out of ten.
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 this scale of operation, be running Nomad and optionally Consul and optionally dealing with the intricacies of Consul than running Kubernetes and being _forced_ to deal with what a miserable pain in the ass etcd is.
I was saying that running Kubernetes is _not_ the obvious choice -- at least once you're at 10^5+ systems.
Until you have 3 days of downtime and end up on a special build of consul that nobody else has while nearly decimating your companies stock price, reputation, and employee morale, the alternatives start looking better. The point I'm making is that it doesn't handle their scale today and that projects with larger communities, support, and usage exist today. No one said k8s was a silver bullet, it's just an alternative to an already failing infrastructure.
If you truly read and understood the Roblox post-mortem you would understand that the problems that they had with Consul were partly and unintentionally self-inflicted and partly due to BoltDB. The "special build" was just early access to Hashi's already-ongoing work to replace boltdb with bbolt, which has long-since shipped.
The hyperbole applied to the description of the harm done to Roblox here I'm just going to ignore. Roblox is still popular. The company still has the reputation of a rock-solid engineering department. Roblox's stock isn't doing much differently than the rest of technology companies on the market and the "damage" you mention is vastly overstated anyway. In fact, Roblox's stock literally had a huge rally after and PEAKED within two weeks after the outage.
391 comments
[ 2.8 ms ] story [ 306 ms ] threadHope so too, we're a fractured community splits resources and forces every organization to have a discussion on what to use. That affects all of us.
[1] https://github.com/hashicorp/terraform/pull/28603
Update: and in the past hour this repo is gone.
The fork you mentioned is no longer existing.
Indeed, any fork will need to implement their own bug fixes.
Ideally they should do this "clean room" and not even look at the BSL'd code, to help defend against any accusations of copyright infringement.
Which is interesting, since Digger (the company that created that fork) is one of the OpenTF Manifesto signatories. Maybe they're recreating it under a different name / without the Hashicorp/Terraform branding all over the place?
Please consider helping us by: - starring the Manifesto - spreading the word - pledging your organization if you can
Beyond that, I know some of these companies tried to be contributors to Terraform itself but were ghosted by Hashicorp.
At the same time there's only a handful of regular contributors to Terraform[1]. It would not be hard for these companies to provide more resources to Terraform than Hashicorp is.
https://github.com/hashicorp/terraform/pulse/monthly
Patently false. Terraform has had an excellent test suite since 2014.
To make a python metaphor, if cpython had a testing suite but pytest didn't exist then people wouldn't be able to test their own python code. That's kind of the situation with Terraform right now- you can't test your code using just the Terraform tools, you have to rely on Terratest which was written by Gruntwork. Hashicorp has spent years relying on the open source community to fill those gaps, which Gruntwork has done very nicely.
Hashicorp even recommends Terratest for testing: https://www.hashicorp.com/blog/testing-hashicorp-terraform
Saying "Terraform doesn't have a test suite" is not miscommunication, it is misinformation, plain and simple - the same as most of the other things I have been correcting this week (not least from the same poster in this thread - someone who's clearly has an axe to grind).
https://developer.hashicorp.com/terraform/cli/commands/plan
It’s actually not a guesstimate about what actions will be taken, it’s a guesstimate of the state that will result from those actions without any reference to ordering or “actions” as a cloud API would understand them - the plan is purely in terms of CRUD on Terraform provider resources and provisioners.
This may seem like a nit, but it fundamentally changes what Terraform is capable of doing in a single pass without external coordination.
They have experimental support: https://developer.hashicorp.com/terraform/language/modules/t...
Coopetition is name of the game in Open Source and too bad increasing number of the companies want to focus on capturing all economic value from ecosystem they have created with help from so many others
We nevertheless support this initiative, though, as written in the article itself.
[0]: https://spacelift.io/blog/spacelift-latest-statement-on-hash...
Disclaimer: Work at Spacelift
Not sure what specifically you mean with this.
Anyway, the devil’s in the details, of both the license as well as the internal architecture of our system. I can’t share more here, but if you’d like to learn more please reach out via our chat or email. You can also expect more updates on our blog.
[0] https://terrateam.io/blog/opentf-pledge
Our statement: https://medium.com/@DiggerHQ/diggers-statement-on-the-hashic...
Here is how your post looks like: https://postimg.cc/Pvwdw8D3
courtesy of: https://news.ycombinator.com/item?id=28838053
(But yes, I agree that this is annoying, and this kind of sign-up-nagging is what prevents me from having any interest in using Medium or Substack.)
Our goal has been to help companies get great operations, compliance, and security posture from day one.
While Massdriver is not a competitor to HashiCorp, the license language is extremely vague and leaves any infrastructure company running containers for their customers wondering if HashiCorp will consider them a competitor tomorrow.
We are proud to be providing development and community support for this initiative.
Read our statement here: https://blog.massdriver.cloud/posts/2023-08-14-opentf-commit...
If you want to help us keep Terraform open source, please show your support at https://opentf.org/!
I realize my comment might sound like an accusation but that's not my intention, I want to hear your reasoning about it!
Linux cannot even successfully switch from GPL2 to GPL3 because of the sheer number of contributors and the fact that not all of them have transferred their copyright ownership to any given organization. This patchwork of different copyright owners has historically been seen as a potential weakness for Linux, but it seems like perhaps license inflexibility is a strength for open source.
This is less "locking down devices is a human right" and more him being angry that the FSF was trying to butt into his project's affairs. He's also similarly angry about "GNU/Linux" as it sounds an awful lot like Stallman just demanding everyone stick "GNU" onto the name of Linus's kernel project.
Anyway all of this is going to seem really quaint in 2027 when Broadcom gets sued under DMCA 1201 by a rogue kernel contributor for evading the Linux linker's license checks[1] and they have to hurriedly rewrite them out of the kernel and relicense anyway.
[0] Granting a blanket exception doesn't work because others can just remove the exception. "No further restrictions" is an ironclad law of copyleft.
[1] The Linux kernel checks the declared license of loaded modules and refuses to link non-GPL-compatible code against any kernel symbol not marked as a user-space equivalent. The reason why this works this way is because Linux ships under GPLv2 plus an exception that says user-space APIs don't trip copyleft, so you can legally load code built to those APIs into the kernel, but anything else might violate GPL.
Since this is enforcing an interpretation of the GPL, this is a DMCA 1201 technical protection measure. You absolutely could make a DMCA 1201 anticircumvention claim in court against a proprietary driver developer that tried to evade the checks. Though Linus usually just bans their modules in the next kernel revision since he's mainly worried about keeping proprietary modules from generating spurious bug reports in Linux. But the lawsuit is still possible, since they're on GPLv2. If they had relicensed to GPLv3, this wouldn't be an issue.
And even if you could, you're basically just left with the GPLv2.
[1] https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...
This is precisely the problem with the new BSL license. Whether your usage of Terraform complies with the license isn’t determined by the legal terms, but instead is entirely at the whim of HashiCorp. And they can change their mind at any time. It makes it impossible to build anything on top of Terraform.
I talk about that more here: https://blog.gruntwork.io/the-future-of-terraform-must-be-op...
This seems to affect only those places that attempt to build a business off terraform.
I am not saying those businesses can't be mad at the rug getting pulled out from under them, but it's important to be accurate that this doesn't affect end users of TF directly.
It'll be a headache for every large company which now has to send the licence to their legal teams who have to ask these kind of questions (another interesting one is "can contractors touch our terraform setup?") - in fairness to Hashicorp they've tried to address some of these issues in their FAQ, but the FAQ isn't legally binding so legal teams have to go on what's actually written in the licence.
> For example, if you’re an independent software vendor (ISV) or managed service provider (MSP) in the DevOps space, and you use Terraform with your customers (but not necessarily Terraform Cloud/Enterprise), are you a competitor? If your company creates a CI / CD product, is that competitive with Terraform Cloud or Waypoint? If your CI / CD product natively supports running Terraform as part of your CI / CD builds, is that embedding or hosting? If you built a wrapper for Terraform, is that a competitor? Is it embedding only if you include the source code or does using the Terraform CLI count as embedding? What if the CLI is installed by the customer? Is it hosting if the customer runs your product on their own servers?
The answer is at the whim of HashiCorp and subject to change at any point in the future. Even ignoring the attempt to dilute the meaning of "open source", the practical implications of the BSL license are more than enough reason to coalesce around a truly open source fork IMO.
The rest of the agreement is still valid, just the completion part is nullified
...just fork it into a foundation. Don't wait for Hashicorp's response. I get wanting to have the appearance of working with Hashicorp, but we've been shown again, and again, and again, and a-fucking-gain that private corporations cannot be trusted to maintain public goods. Only community governed non-profit foundations can do that.
Private corporations will put the bottom line first every single time. And in the case of investor funded enterprises, the bottom line is never ending exponential growth or bust.
Imagine a future CTO trying to pick the IaC tools for their company. They see Terraform as an option, but then learn there are multiple forks, licensing questions, and a big battle happening in the community. What do they do? They are now way more likely to pick a different tool that is genuinely open source. The same is true of every dev considering where to build their career, every hobbyist, every open source enthusiast, every vendor, etc. In the end, no matter which fork wins, everyone will be worse off: the community will be smaller and more splintered.
So we opted to ask HashiCorp do the right thing first. If they choose to do the right thing, we can avoid a fork, and avoid splintering the community. We still think that's the best option. But if that doesn't work, then a foundation + fork it is.
Avoiding proprietary licenses has its place but if you aren’t using terraform to build a product this really shouldn’t impact you much.
What's different about this one?
We are working on wrapping TF in CUE since you can CUE->JSON->TF
https://github.com/hofstadter-io/cuelm
Many more CUE experiments are going on in the devops space
Disclaimer: I led the YAML project and added the compiler feature at the request of some folks internally looking for CUE support :)
[1] https://www.pulumi.com/blog/pulumi-is-imperative-declarative...
[2] https://www.pulumi.com/blog/extending-pulumi-languages-with-...
[3] https://leebriggs.co.uk/blog/2022/05/04/deploying-kubernetes...
Even if I use the Yaml compiler for CUE (which we did) I still have to write `fn::` strings as keys, which is ugly and not the direction our industry should go. Let's stop putting imperative constructs into string, let's use a better language for configuration, something purpose built, not an SDK in an imperative language. These "fn::" strings are just bringing imperative constructs back into what could have been an actual declarative interface. Note, Pulumi is not alone here, there are lots of people hacking Yaml because they don't know what else there is to do. CEL making it's way to k8s is another specific example.
This cannot be the state-of-art in ops, we can do much better, but I get that Pulumi is trying to reach a different set of users than devops and will end up with different choices and tradeoffs
(I maintain https://cuetorials.com and am very active in the CUE community)
One of the interesting aspects of CUE is that it gives us many of the programming constructs we are used to, but remains Turing incomplete, so no general recursion or user defined functions. There is a scripting layer where you can get more real world stuff done too
The CUE language is super interesting, has a very unique take on things and comes from the same heritage as Go, containers, and Kubernetes
https://cuelang.org | https://cuetorials.com
The imperative part of that code appears to be analogous to templating. The actual work done under the covers is not imperative, but is based on the difference between the result of the template execution and the current state of the system. That's what makes it declarative.
If there is more than one back and forth, you become declarative, even if you imperatively generate a "declarative" intermediate representation (not really sure what state file at a point in time could ever be imperative), you then would get back some data from the engine, then make choices about what to send off to the engine in the next request.
It's important to understand that with Pulumi, you can end up in either situation. You have to be careful to not become imperative overall is probably the better way to consider this.
https://www.pulumi.com/docs/languages-sdks/javascript/#entry...
Another way this can break down is if the user writes code to call the same APIs in the middle of a Pulumi script. I meant to try this myself to verify it works, but I would assume that Pulumi is not stopping me from doing something like this.
https://www.pulumi.com/registry/packages/gcp/api-docs/storag...
Of note, all but the last exit had a newline, until I `echo -n` the file I copied up
---
ooo...
---I uploaded a different file while waiting to be asked to continue, and then proceeded to get different outputs
Note, while I can get the contents of a bucket in TF, I cannot build a loop around it as I have above
https://registry.terraform.io/providers/hashicorp/aws/latest...
TF might be susceptible to the same file contents manipulation between plan & apply as well, but then again, you can save a plan to a file and then run it later, so maybe not? Another experiment seems to be in order
1. Creating a resource where created is not the same as ready. This is extraordinarily common with compute resources (a virtual machine, a container, an HTTP server, a process) where attempting to create follow-up resources can result in costly retry-back-off loops. Even when creating Kubernetes resources, Pulumi will stand up an internet-connected deployment more quickly than many other tools because you can ensure the image is published before a pod references it, the pod is up before a service references it, and so on. (The Kubernetes provider bakes some of these awaits in by default.)
2. Resources graphs that are dynamic, reflecting external data sources at the moment of creation. Whether you want to write a Kubernetes operator, synchronize an LDAP directory to a SaaS product, or one of my favorite examples. When I set up demos, I often configure the authorized public IPs dynamically:
I'm telling you this is not how a potential user sees the same situation, that it is a disadvantage and was one of the reasons we are not making the switch.
This example above is exactly the kind of code we don't want in ops, it depends on the user environment and physical location at the time they run the command, bad practice. Thanks for an extra talking point though
The claim I keep seeing from Pulumi folks is that Pulumi is declarative, which is is not, as shown in multiple posts by many people. Please stop calling it such, it demonstrates dishonesty towards users
> Please stop calling it such
I'm not claiming it is always declarative, I'm only claiming that a declarative example above can contain a for loop, and that laughing at that is the wrong response. That's it.
That was more me yelling into the void or larger thread than at anything specific you said, sorry :]
When someone tries to make a sophisticated argument that up is down and white is black, dismissive and shallow is the right response.
> The actual work done under the covers is not imperative
Having a declarative layer somewhere in the stack doesn't make something declarative, if that's not the layer you actually use to work on and reason about the system. See the famous "the C language is purely functional" post.
http://conal.net/blog/posts/the-c-language-is-purely-functio...
This is where the deep misunderstanding is coming from.
On the other hand, if I build a product with HashiCorp-owned BSL'd code, then HashiCorp releases/acquires a product that competes with mine, then my license is void.
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 supporting tooling and software so that a user could spin up their own version of the service.
There's an argument to be made that SSPL is de facto "you can't compete with us" since it would be more challenging to make a competitive SaaS offering if your whole stack is source available. I don't disagree. However, as distasteful as SSPL is, at least it doesn't grant licensing to a product conditionally on the unknowable future product offerings of HashiCorp.
We are certainly in interesting times around the monetization / financial sustainability of open source
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.
Then a group of people who are users of idea and actually making money off it with value-adds step up to maintain it as a community project ensuring that it stays open for everyone -- yeah those guys are the assholes. Terraform would have went nowhere if it wasn't OSS and Terraform would be nothing without its outside contributions that make up far more than the code of Terraform core itself. There's a trail of bodies to prove it.
And you should love this, projects that are stewarded by its own users are incentivized to make it the best it can be instead of rejecting contributions because it competes with their cloud offering [1]
[1] https://github.com/hashicorp/terraform/issues/9556
Does anyone else see this as the Nagios Effect all over again, there must be lots to learn from history?
> A group of leading Nagios protagonists including members of the Nagios Community Advisory board and creators of multiple Nagios Addons have launched Icinga – a fork of Nagios, the prevalent open source monitoring system. This independent project [is based upon a] broader developer community. [...] Icinga takes all the great features of Nagios and combines it with the feature requests and patches of the user community.
It also looks like in 2014, Nagios centralized and appropriated a domain name and website used for hosting Nagios plugins, away from the community (its plugin developers)[2]:
> In the past, the domain "nagios-plugins.org" pointed to a server maintained by us, the Nagios Plugins Development Team. The domain itself had been transferred to Nagios Enterprises a few years ago, but we had an agreement that the project would continue to be independently run by the actual plugin maintainers.¹ Yesterday, the DNS records were modified to point to web space controlled by Nagios Enterprises instead. This change was done without prior notice.
> To make things worse, large parts of our web site were copied and are now served (with slight modifications²) by <http://nagios-plugins.org/>. Again, this was done without contacting us, and without our permission.
> This means we cannot use the name "Nagios Plugins" any longer.
There's some previous discussion of those controversies on HN here: https://news.ycombinator.com/item?id=9452013
From that article[3]:
> [Icinga developer]: "Six months before the fork, there was a bit of unrest among Nagios' extension developers [...] Community patches went unapplied for a long time[.]"
> [...]
> Two years ago, more or less when the split happened, [Nagios author] was having problems resolving [trademark] issues with a company called "Netways".
I'm still not sure what the effect is supposed to be tbh.
--
1: https://icinga.com/blog/2009/05/06/announcing-icinga/
2: https://www.monitoring-plugins.org/archive/devel/2014-Januar...
3: https://web.archive.org/web/20160314090137/http://www.freeso...
With Vault however that's another story, I've yet to find another secrets management system that has a tight integration with Kubernetes, AWS and supports providers for things like Postgresql to have ephemeral database credentials.
Even though I strongly believe the OpenTF fork could open up incredible possibilities for the community (I could go on and on about it), it is an equivalent of a civil war. It doesn't serve the community and our only interest is in the continued strength of the community that we continue to build for.
Based on my immense respect for what's been built under Hashi's umbrella I'd rather see a change of mind, and an opportunity to honor our pledge of resources (5 FTEs for 5 years) to the common rather than partisan cause.
That being said, I don't expect this attempt to work and I fully believe that a fork is going to be inevitable. I also think a fork is an amazing opportunity to standardize the language and prioritize the features developers want.
It isn't just about the license, but the way that Hashicorp has maintained the Terraform project. The github insights show that they don't have nearly as many people working on it as I would expect, and most of them are split into also working on Terraform Cloud. At the same time they don't work with the community that well- there are open issues and pull requests that just get ignored as Hashicorp clearly doesn't see value in open source contributors. This isn't just a Terraform issue either- my company had to move off of nomad due to the lack of development and support (as well as broken features).
I have strong concerns about the future of these projects in general beyond just the licensing. An open foundation that had multiple companies involved would by definition need to find a way for those people to collaborate together, and once they do that it makes it easier for them to invite community collaboration. So while I do appreciate that it is a drastic step, I think it's one that would also be far better for the ecosystem and project as a whole.
That said, maybe this is the wake up call hashicorp needs to fix these problems. If you provide five FTEs that basically doubles the size of their Terraform development team (they have more people working on it than five, but those people are split into other projects), and once they start working with other groups maybe they'll work with the community more as well. I'm not holding my breath though.
I looked at github /chef/chef and github /inspec/inspec and its the same as it was shortly after I left. The only changes are from the one person who carried over after the sale to Progress, and the contracting team out of India, with dozens are unanswered queries and pull requests from the community.
What really ruffles my feathers was when they had us define oss-practices (https://github.com/chef/chef-oss-practices), clearly nobody outside our small team read (or understood) those words and goals. It feels like it was work to make us look better in OSS in order to bolster the company sale.
There's probably some manager at Hashi right now trying to argue that they should offload TF maintenance entirely onto the community and they should pivot to hosting services and consulting and making money off of all that free work.
It's all good and "fun" on the IPO up.
(in x months we will rewrite the whole universe).
There's really no move for them to make here. It's unfortunate.
If you are running Nomad as your orchestrator, because of the tight integrations you are almost certainly running vault for secrets and consul for service discovery/service mesh. The ecosystem of the three is the competitor to K8s.
s/ someone who runs both ecosystems at scale.
All their other products are at best small x% share of a crowded market or dominated by another product.
The MPL is a lot more "business" friendly than the GPL.
The very fact that HashiCorp is changing their license and restricting use clearly indicates they see this threat as reality. Amazon/Microsoft/Google/Whoever using HashiCorp's work/effort but keeping all the money to themselves.
Having a standardized way to "do secrets" for any team, any service, any app within the organization is very nice. Becoming cloud-agnostic for your secrets (connecting your local Vault with the cloud provider's vault) is another great benefit. Automatic secret rotation is also another great benefit. Secret versioning and auditing... etc.
It's not just "can't have this secret in VCS or viewable via kubectl".
That is exactly what it is.
You seem to misunderstand (and thus downvote?) the statement I made. I'm not saying "haha vault bad", I'm answering "what other product" (from ghshephard) with the reality of today.
This has nothing to do with what Vault is or isn't, but just with the concept of storing secrets in a uniform way in clouds for use with cloud workloads what is being used right now.
Regardless, the use of Vault is not exclusive to cloud environments.
All of the listed features of Vault have benefits within larger organizations even if they don't use the "cloud" and deploy monolithic applications.
Most frameworks have built in ways to fetch secrets/config from Vault, making it an easy standardized way to do things across all of your applications/teams.
It doesn't mean you need to use it, of course, but it has a lot of perks for many different situations.
I'm not sure if that's even what ghshephard meant when he was curious for 'products', since technically all those cloud-integrated services aren't really stand-alone products for that matter.
In AWS for example, with or without EKS (and then something like External Secrets Operator in the EKS case), it's all just AWS Secrets Manager and sometimes Parameter Store. In a few cases people do manual encryption (using KMS), but in no case was HashiCorp Vault used.
Often, it's even worse: no secrets management at all. Stuff just gets pumped into environment variables (more often than not they get committed as .env files to Git), and there's just no drive to change that, even when a business policy is in place. Some even 'work around' this by storing secrets in password managers like 1Password and LastPass so they can check the compliance box without actually protecting the secrets (since they also live in plain text in VCS and at runtime in the environment).
In terms of 'products', I'd say Vault and the cloud ones don't really compare, but reality is depressing and secrets are often not as secret as the name implies. From a developer perspective, they might compare them because they desire the secrets to be injected into the environment either way, and as such the source doesn't matter much. I'm not sure if we should see that as a feature or a bug.
I'm relatively new to this field - and see tons of Vault at colleagues companies, and have friends who run/support Conjur (Enterprise more than cloud). Those are the only two secret-management framework/products I'd hear of - so was interesting in knowing what else had mindshare.
But if you have two programs what exchange secrets between multiple instances of each other, (one can do CRUD, the other only Read), you'd have much more interaction. Same as with a system creating secrets and a human reading it.
As for where it would make no sense at all: automated workload identities where you get time-limited temporary credentials that represent a role; most public clouds have some sort of link-local API, an injection method or mount method to provide ever-rotating secrets which gets picked up by the client SDK automatically. If you are using something like AWS, you'd be able to consume hundreds of services without ever persisting a secret anywhere.
This is also where my 'cloud' (and K8s) remarks are based on; when your workload and your resources speak the same authn/authz with a centrally coordinated policy system, there really isn't much value in adding something in the middle of that, and as such you don't see a lot of Vault and Vault-like implementations.
That said, as soon as you add something disconnected like local virtual machines, on-prem stuff etc. where authentication has historically been extremely bad and unless you brought a proper Kerberos setup you're screwed beyond mitigation. That's where Vault (when it came out) delivered a lot of value. It's probably also why we see AWS, IBM, GCP, Azure, in the same list with Vault and CyberArk. I'm surprised VMware doesn't have anything yet, but perhaps they recognise they lost this one already.
AWS Secrets Manager
AWS Systems Manager Parameter Store
AWS KMS
Google Cloud KMS - Cloud Key Management System
Azure Key Vault
confidant - https://lyft.github.io/confidant
keywhiz - https://github.com/square/keywhiz
knox - https://github.com/pinterest/knox
strongboxsafe - https://strongboxsafe.com
conjur - https://www.conjur.org
+ many more
Ansible Vault - probably not competing directly
I am pretty sure companies like netflix, facebook, uber, tesla and others are probably using their own in house creations.
I recognize you're in interesting position in Spacelift. Per your recent analyses you may not be impacted and in this case you probably do not want to pissoff Hashicorp folks :)
In reality though force better be responded with force and showing Hashcorp what what was Terraform will be successful as Open Source project with or without them is best way to get them to reconsider.
Why. It is open source. A fork should be no big deal, and definitely not a “civil war”. I think the community should be quicker to fork open source projects that are not serving the needs of the community.
The corporations are trying to have the benefits of open source without the responsibility. Forking is a normal, acceptable part of open source and we should normalize it.
Also IIUC most of the parties in this conversation are corporations. They’re all trying to enjoy the benefits of open source development for a variety of reasons.
Why? If we have tooling or workflows that assume forks don't happen, maybe we can fix those. Forking should be cheap, easy and frequent.
"The truth is that a fork hurts everyone."
So, which is it?
But the real work is all the hard work that goes into a fork. I've watched open forks die all the time--all it takes is no one to step up and do/pay for the work, which is basically the default, because it is in everyone's interest if someone else is the one to do that.
I think that's really the crux of the problem--there are plenty of folks willing to maintain software for money, and a whole lot of people who'd rather it not cost money and if it does, not their money.
If the tooling is better, who is going to maintain this?
hashicorp has decided they don't want to contribute to open source any more
they're totally within their rights to do so, and it doesn't harm anybody; it's not the equivalent of going around blowing up buildings, raping women, and napalming children. at most we can wish they had continued doing the beneficial things they were previously doing
maybe they'll change their minds, as you say, but that's no reason for the community to sit around twiddling its thumbs hoping for such a change. what's important now is that the people who are still willing to cooperate can do so successfully, and that's what opentf is about
that's even more obviously not the equivalent of going around blowing up buildings, raping women, and napalming children. it's very much the opposite, in fact
it's unclear to me which of the parties you intend to accuse of doing the moral equivalent of burning innocent people alive en masse, but either way, maybe you should think about walking back that rhetoric a bit
I mainly wanted to focus on the "civil" than "war" aspect of the possible schism.
i have no idea what you could possibly mean by 'focus on the "civil"'. it's good that people are being civil to one another, isn't it? then why are you criticizing them?
I don't think it will work, but I think it's good of them to try.
I'm still not sure which of the latter two was the intent of the comment I was responding to
my objection is that warfare involves people intentionally harming each other, and that doesn't seem to be what's going on here. it's not that war is a more extreme version of the situation; it's that it's directionally different
rather, hashicorp is struggling to not go bankrupt, so they've decided to switch to making a proprietary product instead of an open-source products; and terraform users, naturally enough, are reluctant to make their infrastructure vulnerable to a proprietary software license. hashicorp is not intentionally harming terraform users, and terraform users are not intentionally harming hashicorp
they're just not continuing their previous cooperation
Such hypocrisy, attacking others for "rhetoric" that needs to be "dialled back a bit" when you're every bit as guilty of the exact. same. thing.
the comment you are referring to, for anyone who is interested, concerns the question of whether or not there is a higher standard of morality to which legislation can be held, or whether legislation itself is the ultimate moral authority, or whether there is in fact no objective standard of morality at all. anyone who is interested in that kind of thing can read it at https://news.ycombinator.com/item?id=37147305
> "it's unclear to me which of the parties you intend to accuse of doing the moral equivalent of burning innocent people alive en masse, but either way, maybe you should think about walking back that rhetoric a bit"
... but only earlier today were you equating a data protection law with the Holocaust... seems you could do with a bit less projection and rhetoric yourself, Kraggy.
this is not an extremely advanced form of logic, but i understand that it is not within everyone's grasp
the comment in question is https://news.ycombinator.com/item?id=37147305
octavia's other, rather astounding comment in https://news.ycombinator.com/item?id=37149528 is probably also useful context
my objection to the war rhetoric in this case is that it casts people as opponents who are not, in fact, opponents, just different parties pursuing largely independent interests. in that context playing 'let's you and him fight' seems unlikely to improve the situation
Once again you jump to mansplaining and condescension, followed by failing to even get a username correct when it's literally on your screen.
Your repeated attempts to tell people what they think, what they do or do not know, and where they live, show that every observation of you being arrogant, condescending, and disingenuous, is patently correct.
Unsure if you need a shovel to get out of that hole you've put yourself in, but you're sure backpedaling quickly, yikes.
Doing the Fork and showing it IS sustainable and has broad community support can encourage Hashicorp to make concessions.
After taking this unilateral hostile step I do not think Hashicorp deserves the community trust and what industry needs is "Foundation Governed" Terraform like solution, whatever name this solution will have.
You can see example in Confluenct which builds proprietary solutions around Kafka, where Kafka itself is Apache project.
Any free open source product qualifies as a public good. It is free for all to use, and one person using it does not exclude anyone else from using.
However the MPL and licensing in general is irrevocable. They have irrevocably licensed Terraform 1.5.5 under the MPL and an enterprise license (dual license). Anyone can use, modify and distribute version 1.5.5 under the terms of the MPL.
Since HashiCorp retains full copyright they can release the next version under the BSL.
Note that many free software projects (like Linux) don't have a CLA which makes relicensing impractical since every contributor would have to agree to it.
https://opentf.org/
It’s also telling that this manifesto blithely suggests TF could become Apache 2, which is wholly untrue.
Why is it untrue? If Hashicorp has the ability to relicense to BSL, what would prevent them relicensing to anything else?
They could only make my contributions to Terraform Apache 2 with permission, so at best it could be MPLv2 with Apache 2 files interspersed.
It's usually not a good idea to be near a company flailing like this since who knows what their next rent seeking approach will be. A company with nothing to lose is a dangerous partner to have.
Hashicorps problem isn't that their business model doesn't work, it's that they are really bad at their jobs. They ignore customer feedback, laid off support people, and then jacked their prices up. It's a self inflicted wound, and instead of trying to fix it they just keep making it worse.
We are trying to pay them and they are being so unreasonable with pricing that we can't give them our money
His GitHub activity seem to indicate he is now focused on the Zig programming language.
Maybe he signed a gag order and cashed out. We may never know.
Regardless, this is likely a painful moment for him. Maybe he just doesn't want to talk about it, and won't for some time.
We say OpenTF is (or will be) a fork, and forks are bad, nuclear option, etc, but really, Hashicorp are the ones who made a breaking change, and the "fork" merely maintains that which already was, but for reasons, are not allowed to continue using their own name.
We need for the shortest sound-bite 3-word sentence to the non-technical to somehow use terminology that says that the entity that caused the problem is the one who did some action.
OpenTF did not (or is not prepareing to) fork this project, Hashicorp did.
If it was me and I wasn't legally prevented by something actually binding in writing with signatures, I'd even keep using the original name and duke that out.
Name is identity, and thus the canonical representation of "Terraform" is now BSL.
However, if you don't have an identifier such as the trademarked name and you look at the project itself then I think you're right.
The whole point of this thread is the premise that it's not a fork.
Hashicorp's copy is the fork, and it's backwards that the fork gets to keep the name and the original must rename itself.
Disclaimer: Work at Spacelift
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.
Imagine if that language covered more of the stack then just one tool too!
I am working in VSCode, which by and large tends to be the editor supported best, with the most mindshare. Terraform has static and mostly strong typing, yet some testing revealed I was able to pass an argument of the wrong type to some variable I declared. This is type safety 101: variable declared `str` shouldn't accept `int`, ever. Yet `tf validate` was silent, so was all IDE-integrated tooling (whatever the VSCode TF extension does).
Jumping to/from symbol definitions/usages was also flaky (but not entirely absent).
Really disappointing! My excitement of diving into TF went poof. Maybe I'm overly sensitive, but I was so excited to escape YAML hell (Ansible).
Now I'm even firmer in the boat of just using a regular old language, like Pulumi with Python (with full typing).
Did I do something wrong or can anyone confirm my findings?
Yes, can confirm the terraform language server is kinda unreliable. We could both be doing something wrong, but it seems like that's a common outcome.
FWIW, the Rust support is also better in CLion than VS Code.
They still need the state (boo!), but otherwise they're great.
Terraform having state wasn’t some easy button decision, it was absolutely required and carefully considered.
The state is stored in the resources themselves, to be precise.
> It’s also not usable for lots of important parts of AWS, which does not have consistent tagging support and would leave you running very much foul of API rate limits.
As someone who worked on tagging inside AWS, I don't believe that there are any major AWS services left that don't support tagging. These days, tagging-on-creation also guarantees that you won't have untagged resources if your provider happens to die between "CreateResource" and the "TagResource" operations.
You can also sometimes use prefixed names to signal that a resource belongs to the infrastructure-as-code.
API limits for "describe" calls are also pretty lax. And you need to use them anyway to check if the current state of the world matches with the saved state.
State will be needed for some integrations that don't support tagging/naming (Okta, I'm looking at YOU!), but at least for AWS it's not needed.
Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).
Finally, how would you manage tags as an actual resource themselves in this model?
> Furthermore, tagging is restrictable by IAM, is often co-opted by finance for cost allocation, and is subject to often-bizarre limits about what the content can be (even more so across providers).
You can fix your IAM. Cost allocation tags are treated specially.
> Finally, how would you manage tags as an actual resource themselves in this model?
Why would you do that?
https://blog.roblox.com/2022/01/roblox-return-to-service-10-...
TL;DR The outage was caused by (a) they enabled a new streaming feature in Consul under unusualy high read-and-write load, (b) the load conditions triggered a pathological issue in the third-party BoltDB system upon which Consul relies and (c) all of that was exacerbated by having one consul cluster supporting multiple workloads.
I'd use quotes to catalog this as a "horror" story, because this was clearly a very specific issue triggered by a specific and complex set of circumstances.
The blogpost also mentions that Roblox worked closely with Hashicorp engineers to mitigate the issue, and work towards structural solutions; the post also affirms their choice to manage their infra themselves rather then moving into a public cloud solution.
Sure, Kubernetes covers loads of territory. But there definitely are niches where products like Consul & Nomad do add value.
Enjoy spending the rest of your life trying to get etcd to cooperate. If you think operating Kubernetes at scale is a cakewalk, you don't have the scale problems you think you do.
I'll take consul over etcd ten million times out of ten.
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
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 this scale of operation, be running Nomad and optionally Consul and optionally dealing with the intricacies of Consul than running Kubernetes and being _forced_ to deal with what a miserable pain in the ass etcd is.
I was saying that running Kubernetes is _not_ the obvious choice -- at least once you're at 10^5+ systems.
The hyperbole applied to the description of the harm done to Roblox here I'm just going to ignore. Roblox is still popular. The company still has the reputation of a rock-solid engineering department. Roblox's stock isn't doing much differently than the rest of technology companies on the market and the "damage" you mention is vastly overstated anyway. In fact, Roblox's stock literally had a huge rally after and PEAKED within two weeks after the outage.