...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.
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.
There's really no move for them to make here. It's unfortunate.
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.
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.
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
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?
Does anyone else see this as the Nagios Effect all over again, there must be lots to learn from history?
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.
Avoiding proprietary licenses has its place but if you aren’t using terraform to build a product this really shouldn’t impact you much.
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.
At Oxide, our vision has been that on-premises infrastructure is deserving of a system consisting of both hardware and software, at once integrated and open. Ensuring Terraform users can easily deploy to Oxide has been essential for realizing this vision: we want customers of an Oxide rack to be able to use the tools that they know and love! And while HashiCorp's move to the BSL does not immediately affect Oxide (our Terraform provider is and remains MPLv2), we recognize that the ambiguity in both the license and HashCorp's language has created widespread concern that gives customers pause. We support the OpenTF efforts to assure an open source Terraform. It is our preference to see an MPLv2 Terraform as led by HashiCorp, and we join the call from the OpenTF signatories for HashiCorp to renew its social contract with the community by reverting the change of Terraform to the BSL. That said, we also agree with OpenTF's fallback position: a BSL-licensed Terraform is not in fact tenable; if Terraform must be forked into a foundation to assure its future, we will support these efforts. Open source comprises the foundation of the modern Internet, and is bigger than one company: it is the power of us all together to determine our fate. But we cannot take that foundation for granted -- and we must be willing to work to exercise that power to assure an open source future.
Thank you to the consortium here that is coming together to guide Hashi to see the wisdom in an open source Terraform!
It would be ironic though if Hubris ever gets relicensed
We're already exploring alternatives. Future client projects may not use Terraform at all.
Languages and frameworks must remain open or they will wither and die.
- MPL is a weak-copyleft license, which allows companies to grab and run Terraform codebase, provide it as-is (as Terraform), or as white-labeled Terraform compatible feature/layer. This is alright (because license allows this).
- These people also contribute their own fixes upstream, which is great, and maintain their own patches if Hashicorp decides to reject them (which is fine, too, this is how ecosystem works).
But, HashiCorp says that, the thing we develop (i.e. Terraform) is used by others and generate revenue for them, this is great, but we can't generate enough revenue from it to keep the company afloat and continue providing TerraForm development, and sell it as a product at the same time.
What should they do? I'd advocate AGPL, but xGPL licenses are avoided like a plague, because Free Software is not "closed forks" friendly, and companies hate to open everything like that.
BSL is neither Free nor Open, which we all hate, but it allows HashiCorp to survive to a degree (this is not a fact, this is what HashiCorp is thinking).
So, just because people adapted it, and HashiCorp cannot survive, should they say, we're closing shop, it's all MIT now, do whatever you want, bye!?
Weak copyleft licenses are not designed for software that big. Or they assume that the developing party is untouchable. Strong copyleft solves this, but companies hate it because its unrelenting transparency.
What should we do?
P.S.: I neither endorse, nor support BSL, or HashiCorp's decision (or any company treads the same path).
Edit: I mistyped MPL as permissive instead of weak-copyleft. Corrected, sorry.
> What should they do?
Suck it up, open source Terraform under a non profit foundation, find a new source of revenue. Or stop developing Terraform, cut expenditures, and move on with life.
There's no universe where "bait and switch customers who wanted open source into paying us by switching licenses" is a viable option.
> So, just because people adapted it, and HashiCorp cannot survive, should they say, we're closing shop, it's all MIT now, do whatever you want, bye!?
Exactly, you know the answer, you just don't like the implications. People somehow think that a business which started an open source project "deserves" to profit from it. They do not. Open source is a great way to get people to know who you are and build things that are interoperable with your (proprietary, closed source) SaaS offerings. It is not in itself a revenue source.
If the viability of your business is predicated on being the only one able to provide your project as a service and earn that service revenue gravy, just leave it closed source and proprietary. Sure, you won't get adoption at anywhere near the rate, but that's the tradeoff you make.
They can offer it under more than one license if they want. I, for one, would be pretty happy if they offered it under both BuSL and AGPL.
- business users who are afraid of copyleft could use Terraform under the terms of the BuSL
- the F/OSS community could distribute it under the terms of the AGPL and freely build on it
- competitors to Hashicorp would have a choice:
+ open their whole stack and compete in the market based on the quality of their services and support alone (admirable but very tough)
+ negotiate and pay HashiCorp to license Terraform under special, proprietary terms
Put simply:
> we can't generate enough revenue from it to keep the company afloat and continue providing TerraForm development, and sell it as a product at the same time.
They were never selling it as a product in the first place. It's more of a loss leader if anything; Costco has its $1.50 hot dogs to attract customers to buy memberships, and HashiCorp has Terraform (and its provider/module ecosystems) to attract customers to buy Terraform Cloud (and Vault, and Nomad, and everything else they actually do sell).
It is harsh, but they’re a public company now, not Mitchell.
Why would Hashicorp give the slightest worry to losing thousands and thousands of non-paying customers?
If I wrote an open letter decrying Salesforce for not open sourcing their codebase, nobody would take me seriously. But we expect better from Hashicorp for some reason.
[Docker] can barely muster a viable business
'They' as in Docker Inc.? They made it accessible for the masses, which counts for a lot, but they built on a lot of pre-existing Linux kernel tech that other people who envisioned containers put in place before Docker came in and seized on the opportunity.
> can barely muster a viable business.
They perused what proved to be the wrong business model until 2019, nowdays they're more than 'barely' viable.
Would terraform have been as popular it if had never been open source? That we won't know, but we can guess.
The photoshop effect*. That is to say, devs that are familiar with it will push their workplaces, because it's a pain to pick up yet another tool when you know one that will work.
*A largely hypothesized reason photoshop was so easy to crack back in the day, was that Adobe knew that if kids grew up using photoshop, businesses wouldn't be willing to spend the money re-training their employees, and would just buy a photoshop license.
I'd wait and see what happens with OpenTerraform. If the fork gains some good momentum, it would be the easier choice. Usually, you should be okay with using the latest FLOSS version for a few weeks/months until things settle anyway.
Citation needed. I don't think it costs very much at all.
Terraform is neither a language nor a framework, and I certainly don't think it will wither and die if they transition to BSL. Case in point, docker's revenue grew by 12x once they started taking control of their code and stopped caring about community. Same with postman or nginx or many other companies.
You can absolutely bet that they would get dropped like a rock if they moved to changing the engine's license. Even the docker desktop code wasn't ever open to begin with anyways.
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.
[1] https://gitlab.com/nbdkit/nbdkit/-/commit/952ffe0fc7685ea775...
10. What are the usage limitations for HashiCorp’s products under BSL?
All non-production uses are permitted. All production uses are allowed other than hosting or embedding the software in an offering competitive with HashiCorp commercial products, hosted or self-managed.
24. Can I host the HashiCorp products as a service internal to my organization?
Yes. The terms of the BSL allow for all non-production and production usage, except for providing competitive offerings to third parties that embed or host our software. Hosting the products for your internal use of your organization is permitted.
Here's the kicker though... before the change to BSL, the future of Hashicorp didn't really matter as much, since somebody could fork their projects and keep them going. But with this licensing change, if Hashicorp shuts down one day, nobody could create a fork for several years.
So to me, whether or not I can use the software as currently licensed isn't the biggest issue. I want the ability to have an "escape hatch" should Hashicorp continue its downward trajectory or shut down completely.
It would be troublesome if any of the vendors at $work past or present went bankrupt, this is the nature of having external vendors. I am not particularly concerned.
I was not the biggest fan of Terraform in the first place, I don't like some of the language choices, but it works better than anything else that exists out there.
I could also see someome like Amazon eventually launching a CloudFormation like tool that works natively with Terraform, but now that's off the table and I think a net negative.
It also sounds like projects like Atlantis also would be against the BSL, including self-managed installations of the tool.
That's not meant to be a redundant or snarky question. The key issue with the BSL and that FAQ is that the wording is intentionally vague. What does "competing" mean? What does "hosting or embedding" mean? Who decides?
In order to really know if you're a competitor, you have to reach out to HashiCorp (as the FAQ tells you to do). So whether your usage is valid is not controlled by the license terms, but is instead entirely at the whim of HashiCorp. So they switched from a permissive open source license to a HashiCorp decides license: they get to decide on a case by case basis now—and they can change their mind at any time.
That is very shaky footing on which to build anything.
See https://blog.gruntwork.io/the-future-of-terraform-must-be-op... for more info.
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
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!
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.
Update: and in the past hour this repo is gone.
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.
The fork you mentioned is no longer existing.
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?
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.
They have experimental support: https://developer.hashicorp.com/terraform/language/modules/t...
Patently false. Terraform has had an excellent test suite since 2014.
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
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.)
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.
Even though this really doesn't affect my use case it does feel like kind of a dirty bait and switch. I do hope for a future where there's a version (and Terraform provider module versions) that are actively maintained under a true open source license. I'll favor using those over the official BSL version as much as possible.
I guess it's the CLA that all of the contributors signed that allows this to happen? I wonder if there's a way for open source licenses to address this, and disallow the use of CLAs, or require some CLA clause that doesn't allow sudden switches to non-permissive licenses?
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.
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.
Imagine if that language covered more of the stack then just one tool too!
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...
> 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.
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.
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...
Devops people need to find a viable way to reward the developers of the tools they make a living from operating. Failing that they will wake up finding no one is willing to make them or that those that do have an ulterior motive.
These tools are not going to be able to be used with users using new Terraform versions (though they can always use the current or any previous versions, or can use their fork these companies are jointly supporting).
Then there are open source tools that don't directly compete with Hashicorp that are in a bit of a gray area, but I've seen Atlantis, Pulumi, OTF, and other tools all claim that this does not affect them. I would presume this could also apply to things like Terratest, Terragrunt, etc. but I don't know. I am not a lawyer.
And if none of these company/product names are familiar to you, then you shouldn't have any noticeable difference :)
As discussed in the other thread, we believe that we are not in violation of the new license, you can find more details in our today's announcement[0].
Disclaimer: Work at Spacelift.
[0]: https://spacelift.io/blog/spacelift-latest-statement-on-hash...
That's because the BSL license is intentionally vague. What does "competing" mean? What does "hosting or embedding" mean? Who decides?
In order to really know if you're a competitor, you have to reach out to HashiCorp (as the FAQ tells you to do). So whether your usage is valid is not controlled by the license terms, but is instead entirely at the whim of HashiCorp. So they switched from a permissive open source license to a HashiCorp decides license: they get to decide on a case by case basis now—and they can change their mind at any time.
That is very shaky footing on which to build anything.
And the legal team at every company you work for will have to take that into account before deciding you can or can't use Terraform.
See https://blog.gruntwork.io/the-future-of-terraform-must-be-op... for more info.
Like it or not, cohorts of engineering organizations like the above (cloud providers) have a very outsized weight and already have contender products they can choose to vigorously fund tomorrow.
From the article:
The license does not allow you to use Terraform if you meet both of the following conditions: You are building a product that is competitive with HashiCorp. You embed or host Terraform in your product.
My $0.02: the management of hashicorp is following a stupid trend and should have thought about their customers more.
It will come out to what lawyers think, I guess. Lawyers usually say no to things with poorly established precedent.
Then why didn’t they “choose” to fund hashicorp yesterday and avoid this?
As usual in OSS-goes-private events these all just sound like “keep building our critical infrastructure tool for free or we will go elsewhere”.
What is hashicorp or any other company in their position to do?
This is not sustainable.
I see the use case for it if you don't want to use a 3rd party or open source tool (Atlantis) but the pricing seems prohibitive.
Long term? Possibly less adoption (teams may elect to go with Pulumi or some other alternatives), less 3rd party tooling available (what if Hashicorp decides your tool is their competitor?), etc.
It seems very similar to the spat that community had with Red Hat with how 3rd party captures too much value from their own internal offering and leadership responds by changing the license model and makes things less open-source-y. Perhaps this will become the new normal for OSS/former OSS? IDK.
There is no contract. Try to enforce it. Even non-binding expectations differ widely among projects.
> We believe that HashiCorp should earn a return by leveraging its unique position in the Terraform ecosystem to build a better product, not by outright preventing others from competing in the first place.
Nobody at Hashi cares how their competitors think they should make money. As for competition, Hashi just blew the whistle for an all-comers product pace-race against its formerly free-riding rivals. The old code remains MPLv2-licesed. That's the starting line. Their new BSL automatically releases new code under MPLv2 four years after it's published. That's Hashi committing to a minimum pace. They clearly foresaw a fork.
They are betting their maintenance commitment, expertise, new development pace, and existing book of business will make their new, less than four-year-old versions the versions users want, despite the license. Hashi's announcement and FAQs try to minimize perceived cost of the license change by emphasizing they intend no change for users, customers, and contributors, as distinct from product-service competitors. This new fork announcement tries to maximize uncertainty about the license and throw shade on future development prospects. It's all in the game.
Customers can watch the runners run. Eat popcorn.
I think it's highly unlikely Hashi's rivals will make enough marketing pain on this to force them to reverse the change. The database companies made far bigger moves, with more complexity and fewer marketing lessons learned. They held out. So the war's on the product dev and product marketing fronts.
The real test will come in January, after Hashi says it will stop backporting fixes to the current MPL release. At that point, the rivals are under their own power only. Will any MPL-today-licensed fork be so competitive with Hashi's version at that point that customers bet on it over Hashi's long-term? It will have to bear its own development and maintenance costs for whatever differentiates it.
I'm familiar with the products, but not an active user. My main question is whether there's substantial new development still to be done on the most popular projects, or whether it's really a maintenance war. I'd be looking for whether Hashi's new versions break compat, either tactically or as a consequence of new development.
There are social contracts
> There are social contracts
> > Try to enforce it.
Please consider helping us by: - starring the Manifesto - spreading the word - pledging your organization if you can
Hope 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.
> We strongly prefer joining an existing reputable foundation over creating a new one. Stay tuned for additional details in the coming week.
Joining an existing foundation sounds like the right move to me. Many organizations need this fork to take off very quickly, since they are facing legal uncertainty. Make sure it is clear how to support the project, and those organizations will be happy to do so.
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.
With Vault they’ve just recently launched their new cloud secrets service. Most of their revenue comes from Vault. Nearly all of their future revenue growth is vault. Any competitor could relatively easily provide the same service with vault FOSS today. Vault is feature complete. The only moat they have is their license.
Best for the ecosystem if both Vault and Terraform are maintained by a foundation. Not best for Hashicorp, but best for the industry for sure.
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.
After thinking about it for a few days, I think Hashicorp's move is actually net great for everyone. The products that matter will be forked and maintained in the open. Hashicorp would choose wisely to merge mature forks back into their product, if they can, and now you have a pretty standard model of up selling enterprise features on an open product that's developed in the actual open. It frees Hashicorp up to focus on the enterprise, which they have already been doing, but they've been neglecting their OSS, like Terraform (what the actual fuck is going on with the development of Terraform over the last two years?)
This is great. I'm really looking forward to using freed forks that pop up in the months ahead.
This is Hashicorp's sink or swim moment.
If you asked me when they announced the license change, I'd say bet the horse on Pulumi and move on. But now I actually think this could really rejuvenate the TF ecosystem.
Obviously there would be tradeoffs involved. But if we can cover the 80% situation, that would be a good start.
I think Gruntwork's blog explains this the best - https://blog.gruntwork.io/the-future-of-terraform-must-be-op...
Obviously, there's the argument that Hashicorp might sue you even for that, but it feels like the reductio ad absurdum that any company can sue you for anything, and not remotely plausible.
VMS are a concept of older times and should be replaced by containers. YES; there is still use for VM's but everyone and their mother migration to k8s will mean wonders for portability of applications and more.
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
Long living forks and fragmentation sucks, but now HashiCorp has to react to this and provide compelling benefits if they don't want to loose the whole project alltogether.
The rest of the agreement is still valid, just the completion part is nullified
Perhaps if they went down the certification strategy it would've been a safer gamble. Certified Hashicorp Terraform Practioner. 650 a cert, probably would've saved their arse.
Isn't "Terraform" a copyrighted / owned word by Hashicorp? Is it somehow itself part of the MPL - the name itself?
Would then whatever opentf.org would become need a new "tf" name?
Just don't know the ins and outs on that.
There was definitely room for improvement around using Terraform to do actual deployments. From better UX around doing PR's -- showing not only the commit diff but the output of a "tf plan" as well to see what it might actually do -- to actually running the deployments on isolated build machines that could hold the sensitive cloud API keys and provide a deployment audit trail, these were all features that teams absolutely needed to use Terraform sanely. As a solo developer you don't really need those features, but if you're on a team you definitely did, and were almost certainly willing to pay for it. Hashicorp recognized that need and created the cloud/enterprise offerings to provide that.
At some point the thought even crossed my mind of creating some open-source tool that could provide a nice enough web interface for dealing with Terraform for teams, building on what we had and providing the features I listed above, but the main reason I didn't was because it would be biting the hand that feeds. Such a tool would take away people's incentives from using Hashicorp's paid offerings and ultimately reduce their investment in Terraform and their other fantastic tools, and in my opinion, be disrespecting the tremendous work Hashicorp had done up to that point. I've been a user of their stuff since they only had Vagrant, and of course have loved them seeing them succeed.
It seems others, however, had different opinions and saw a business opportunity thanks to the permissive licensing and the high costs of Hashicorp's paid offerings. Plenty of money to be made from making it easy to use TF in teams, especially when you're not obligated to contribute back or maintain the underlying software [1]. Any time I saw a "Launch/Show HN" post from a company that was offering such TF wrapper web interfaces, I kept being surprised that Hashicorp hadn't yet clamped down on preventing lower-cost offerings of their paid services. It was only a matter of time.
[1]: I realize this reads as overly harsh to some of these companies, especially as some of them are in here replying and pledging to give back, so let me try to explain my reasoning here. When I use a product, I like it when the source is available from me to learn from and understand how it works [2] and to contribute back to for needed features or bugfixes [3].
When a company makes a product open-source, that's great! But if that product is the core of that company's business model [4], and another company starts competing with that company using the same open-source product, then I see a problem down the line. While you can make the argument that the competition is good and motivates the two companies to compete on the value they bring to their customers, which is a net-benefit to the open-source ecosystem as a whole as the open-source product is improved, it eventually turns into a race to the bottom. Pricing will be used as a core differentiator, reducing the overall R&D spending on the open-source product because ultimately the two companies have to maintain non-R&D staff like sales, finance, and support. If the Total Addressable Market is fixed (obviously not, but work with me), then that's two or more companies with the same fixed non-R&D costs diverting revenue that could be spent instead on improving the open-source product. Sure, the reality is that a lot of that revenue isn't going back to the open-source product, as a lot of people are complaining about in the comments, but that diversion is probably going to happen anyway whether there's 1 company or 20, so I'd accept it as a cost of doing business.
If instead the competition were on providing a better but different open-source product in the same space (e.g. Pulumi), rather than working off the same base, that would be a different story. But if developers keep seeing businesses take open-source projects and directly compete with their creators, then I think we're going to see a net harm to the open-source community as it creates a sort of chilling effect as it'll demotivate them from going the open-source route so that they can find a viable way to sustain their efforts. I think licenses such as the BSL and SSPL are valid enough compromises, considering that even mentioning the AGPL inside of a lot of companies seems to be like someone saying Voldemort's name. We can't rely on large corporations sponsoring open-source projects, either with money or developer time, if we want them to succeed.
We grant inventors 20 years of exclusive-use on an invention, provided they explain how to reproduce it through the publishing of a patent. What's the difference between that and the BSL? I see a lot of complaints about bait-and-switches, but I don't really see the issue. If you contributed to the project under the old license, it's still available under the old license! You just don't get any of the new changes starting from the license change. If you decided to use Terraform in a non-competing way [5] solely because of the old license, and are concerned about the new one, then you have to recognize that Hashicorp is now another addition to a long-line of "open-core" companies trying to deal with the reality that companies will make money any way they legally can. This is where the industry is currently headed, and whatever replacement you find will probably be next.
If you believe different, then make an open-source offering, and don't just make a public statement saying it'll be open-source forever. Public statements are great and all, up until there's doubts about meeting payroll. Find a way to make the statement legally binding and then we're talking. Which is I guess why there's so much consternation, since the way to do it is through the license, but the OSI doesn't recognize any of these other licenses as "open-source" and the AGPL is a non-starter at most companies.
[2]: Reading the source code for libraries I use has been incredibly valuable in my understanding of how to use the libraries properly, much better than any documentation could. And of course, makes me a better programmer in the process.
[3]: At one point, Terraform was missing a feature that I badly needed. With the source available, I could easily get a new version of it running locally with that feature to unblock me, and then everyone benefited when I contributed it back to the project. It's also been invaluable having these locally modifiable builds to understand the quirks of products from cloud vendors, and to work around them. Ever had multiple deployment pipelines fail because Azure decided to one day change the format of the timestamps they returned in API calls, without publishing a new API version? I have.
[4]: As opposed to supplementing their business model. Google open-sourcing K8s was great for them because it drove adoption of their cloud VMs. Their cloud business makes money off the VMs, not GKE, so sponsoring K8s is essentially a marketing expense. But for Hashicorp, their core business model is paid offerings of their products.
[5]: Yes, I get that the license currently is un-clear, for all their products. But let's simply say that you're not trying to directly sell a wrapper around running Terraform.
Terraform has a bad design. It's a configuration management tool, first and foremost, and configuration management tools need to do one thing well: fix things. Not just "change state", but functionally, actually fix some software to make it work again. Terraform is really bad at this. It's difficult to configure, difficult to operate, and it likes to find any reason at all to just blow up and force you to figure out how to make the software work again.
Configuration management tools should make your life easier, not harder. You shouldn't have to hire a "Terraform Admin with 3 yrs experience" just to learn all the bizarre quirks of this one tool just to get your S3 bucket to have the correct policy again. You shouldn't have to write Go tests just to change said policy. It's like it was invented to be a jobs program for sysadmins.
I have a laundry list of all the stupid design decisions that went into the damn thing. And because the entire god damn industry is stuck on this one tool, no other tool will ever replace it. Its providers are so large and there are so many modules created that it would take years of constant development to replace it. So it doesn't get changed or improved, and it can never be replaced. It is the incumbent that blocks progress. A technological quagmire we can't extricate ourselves from.
The essential purpose of this tool is really to be a general interface to random APIs, track dependencies in a DAG, pass values into resources when it has them, attempt to submit a request to the API, and then die if it doesn't get a 200 back. We can accomplish this in a simpler way that is less proprietary and more useful. And we can ramp up on specific functionality to give the solution actual intelligence, like default behaviors for specific resources in specific providers, hints on how to name a resource, more examples, canned modules that are easier to discover or publish, ability to use different languages or executables, etc. But we need to put forward those alternatives now, or we won't get the chance again for a long time.
When terraform fails, it's typically because of a an API error or a configuration issue that is beyond its control?
Not handling state rollback is a design decision that, having dealt with the fun of CloudFormation, I'm pretty happy that they made.
This describes almost every tool in my toolchain that's over a decade old, this is just what happens. If you want to kill terraform and replace it with something better the usual bar is that it must be 10x better. If that's something you think you could do I'd be (genuinely) excited to see it :)
Hierarchical state and provider management. The difficulty of hooking a kubernetes provider to a EKS or GKE provider in a one-shot-apply is pretty terrible. Trying to nest the helm provider under kubernetes isn't quite as painful but still not great and there isn't a way to get the necessary CRD manifests in place for dependencies or resources before they need to be created.
Diffs as a first-class citizen throughout the layers of providers as opposed to situations like helm_release where helm diffs are completely opaque to terraform and especially to tools like Atlantis.
Slightly more of real programming language concepts (pure functions at least), or else insanely good configuration flexibility. Same defaults with simple overrides should be the default for all providers and modules in a standard way. I think deep merge with reasonable conflict resolution is all terraform needs (plus a rewrite of how configuration works in a lot of places), but I want to be able to define a template configuration for e.g. a cluster and be able to instantiate a new cluster with just:
k8s_config = { region = "us-west1" node_config = { machine_type = \ cloud_native_machine_type( \ cpu = "amd", ram = "256G", cores = "16") spot_instance = true } }
And have deep merging successfully override the default configuration with those values, plus that kind of generic function capacity to turn verbose/complex configuration blocks into a simple definition.
Yes, it can be awkward, and yes the S3 bucket resource change was pretty bad, but overall its operating model (resources that move between states) is extremely powerful. The vast majority of "terraform" issues I've had have actually been issues with how something in AWS works or an attempt to use it for something that doesn't map well to resources with state. If an engineer at AWS makes a bone-headed decision about how something works then there isn't much the terraform folks can do to correct it.
I've actually been pretty frustrated trying to talk about terraform with people who don't "get it". They complain about the statefile without understanding how powerful it is. They complain about how it isn't truly cross-platform because you can't use the same code to launch an app in aws and gcp. They complain about the lack of first-party (aws) support. They complain about how hard it is to use without having tried to manually do what it does. Maybe you do "get it", and have a different idea of what terraform should do. Could you give a specific example (besides the s3 resource change) where it fails?
It's a complicated tool because the problem it's trying to solve is complicated. Maybe another tool can replace it, and maybe someone should make that tool because of this license change, but terraform does the thing it intends to do pretty well.
I haven’t shared your experience, but I read OPs book on Terraform cover-to-cover before and trying to work with the system.
Everything from Kubernetes to various Colocation technology leverage it because it codifies the ability to deploy a tech stack.
but it could just be a yml file. In essence, the requirements section says "here are the builders it needs & their versions" which identifies types of jobs. each entry is a job with a job type, a unique name, and some config info. Each builder is just a series of CRUD operations.
Like you said, it builds a directed acyclic graph, queues up the ready jobs, and executes them. updating the infrastructure's "state" with info from the completed jobs & adding new jobs when their dependencies are finished. the state files are just a dump of that structure as json.
Its not thathard. I think of myself of a junior level dev and I built something for me in my side time in a month with a full test suite and its 3/4 of the way there. CLI, builder dependency injection, type checking, relationship dependencies, it took me a few weekends
I think a senior engineer could build out an enterprise grade functional core product in a few weeks. building & maintaining the CRUD APIs is the real headache, but I think vendors would take care of that themselves if there was a popular enough OS solution.
1. IaC description should be format agnostic and transformable (eg definable in yaml, json, whatever).
2. Something about provider interfaces here, but it's already super messy and not sure if it's an improvement or just a shift
3. State files were wild west last time I checked. And there should be a default database interface provider at minimum. Maybe there is now?
4. Forcing the apply->statefile cycle as the default requires all of compute, interface, and a human. This should have been an abstraction on a raw interface for automated use.