OpenTF announces fork of Terraform
opentf.org
opentf.org
In the long run few will care about this licencing change (as much as they should!) – business users will accept it, individuals won't take any notice, and competitors would get mired in issues as expected. Basically a win for Hashicorp.
But winning on positive changes beats licencing issues. Business users will go where the centre of gravity in the ecosystem is, individuals will too, and will prefer free (in both senses) solutions, and competitors will push this hard to all their customers. It'll be interesting to see Hashicorp needing to build OpenTF support into their products to remain compatible.
> So far, four companies pledged the equivalent of 14 full-time engineers (FTEs) to the OpenTF initiative. We expect this number to at least double in the following few weeks. To give you some perspective, Terraform was effectively maintained by about 5 FTEs from HashiCorp in the last 2 years. If you don’t believe us, look at their repository.
Wow. Even if most of this doesn't actually play out in the long run, that's some good support.
They literally do:
"HashiCorp even had all contributors sign a CLA which explicitly said (link to the CLA in the Internet Archive as HashiCorp has of course removed this wording): [...]
The move to BUSL—which is not a free and open source license—broke the implicit contract. That was the brash action!
Terraform would've never gotten the adoption it did, or all the contributions from the community had it not been open source. Most of us would've never agreed to the CLA to contribute to the project if it was BUSL licensed. Taking all those contributions and all that community trust, and then changing to the BUSL license is a bait and switch." [1]
I agree with the overall sentiment, but they could've left out all the judging side comments.
[1] Source: https://opentf.org/#why-fork
In the announcement literally the only mention of this is:
> The manifesto outlined the intent of the OpenTF initiative in two steps — the first was to appeal to HashiCorp to return Terraform to the community and revert the license change they were making for this project. The second, in case the license was not reverted, was to fork the Terraform project as OpenTF.
> Since no reversal has been done, and no intent to do one has been communicated, we’re proud to announce that we have created a fork of Terraform called OpenTF.
What you’ve quoted and linked to is the manifesto before this announcement.
They could have played the announcement much differently to how they did, but they chose not to, and chose to focus on the positives instead.
It’s not even in the announcement faq.
> they could've left out all the judging side comments.
That is literally what they did.
I imagine the manifesto will disappear now that it is, obviously, superseded.
Just give it a tiny bit of time, yeah? Come on, what they’re doing seems like good work, well played and without nastiness.
We do not fault HashiCorp for trying to build a thriving business and we respect their amazing achievements and contributions. However, on this one issue of the Terraform license, we do not agree with their position and believe strongly in the need for a truly open source, community-driven Terraform.
Of course, this is untrue. They may have had all contributors after some specific date sign one, but it is simply untrue that all contributors have signed one at all.
I wish it were not the case. It should be more like contributors get paid like employees retroactively in a situation like this but no idea how something could be structured like this.
So you can just license all future contributions under AGPL and use the MIT licensed code, effectively making the combined work AGPL. But the MIT part remains MIT, anyone could fork your project, remove all AGPL code and return to MIT. It’s wise to clearly mark which code is which, especially since MIT requires that the copyright notice must be retained:
> The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
It makes sense they'd do this, but we need to stop loving people who appear to give us things. They're just making reasonable business decisions.
If Hashicorp didn’t have a business plan that made money off terraform being OSS then the time for that was years ago.
If you release as OSS then your competitors will use it to. This is predictable and all plans should account for it.
This competition didn’t hurt Hashicorps chances of profitability, they were factored in from the beginning.
They weren't, actually.
From a Hashicorp FAQ article (which is a transcript of a video interview which has since been delisted from YouTube) titled 'Why is HashiCorp committed to open source?':
> Mitchell: [I]t's always sort of been a default for me. [...] When we were starting the first projects, we both didn't intend to ever start a company around them. There was no monetization goal at all, and so I think open source was an obvious default then.
https://www.hashicorp.com/resources/why-is-hashicorp-committ...
Reading through these comments, I'm reminded of a pop psychology book that I read that essentially said "never try to take someone away, no matter how small, it is perceived as a much larger loss than it is".
If Hashicorp had started with this new license in the first place, do we really think they wouldn't have had the business success that they've had? We'll never know, but my guess is that a license that says "competitors can't copy us" would seem totally reasonable to folks contributing, and irrelevant to customers that have a problem to solve. Someone correct me if I'm wrong here, I want to understand this obviously passionate response.
(Since I've commented a couple times on this let me also say I'm not a hashicorp employee nor know anyone there)
I don't see OP talking about 'loving people'. Just stating that a very good approach was taken. Wrt 'give us things', it is not about giving either (that's like free beer), but about freedom. If OpenTF indeed ends up under Linux Foundation / CNCF it doesn't matter how many competitors are involved, but that freedoms are assured.
My comment was about a previous commenter thinking it was amazing that other companies put FTEs in place for a few years to work on OpenTF. It's not amazing; their businesses were built on Hashicorp licencing Terraform as OSS. They've been given far, far more than a few FTEs' worth of effort, and their continued existence depends on OpenTF being actively developed. It's not a noble thing (unlike the original open sourcing); it's just business as usual.
Where was this support when they built a business on this free work?
1. Open-source software is a gift to the world. You make it, release it, and people can do whatever they want with it, including not contribute back. There is no exploitation here. You can build a trillion dollar business on top of Linux, without paying Linux anything. This is how open source is meant to work. This is the known contract when you release something as open source. To imply that by following the spirit of open source, somehow HashiCorp, a 5 or 6 billion dollar company is being exploited doesn't quite jive, IMO.
2. HCP has been clear that they will not put forth resources to review pull requests. They let many good pull requests languish until they die. If HCP were better stewards of the Terraform community and prioritized contributions, would things be different? I don't know. But I think if one is going to say the competitors should have contributed to Terraform, one also has to acknowledge that HCP has explicitly stated they are not going to prioritize reviewing your contribution. If you're looking for the best way to spend your engineering time, the best business decision for you is probably not to spend a lot of time on a piece of work that may die in the vine.
3. But it's not even just to say none of these folks have contributed back. They may not have many commits in the repository, but Gruntwork has created Terragrunt, which is free and open source. This has impacted the community considerably. The founders have written a book on Terraform.
4. Where is HCPs acknowledgment of all of the people that saw Terraform as stable open source foundation to build providers for, to build tooling for, to contribute pull requests to? Terraform itself is pretty simple, the hard work is in the providers. HCP makes some of the important providers, yes, but so many providers are made because Terraform is popular. HCP wants to make this all about them. They want you to think they put all the work into making Terraform what it is today. They did put a lot of work in, but the community did too!
"Culture eats strategy for breakfast." -- Peter Drucker
env0 a small Company is providing 5 FTE, the web claims their revenue is <5m (1.4m)
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
Imho the best possible choice, and one that was easy to see coming when they announced they were joining "an existing foundation".
[0] https://oxide-and-friends.transistor.fm/episodes/fork-in-the...
I think they have a stronger sense of community building, and more more intentionally make space for individuals to take leadership roles that are truly independent from their employer (member company) affiliations.
As someone who has been involved in many open source foundations over the years, they all have their pros/cons. If you are looking for the most customized approach, the Linux Foundation (LF) is probably the most customizable as they have build hundreds of entities that many people may not think of being part of the LF... CNCF... GraphQL Foundation... R Consortium... OpenJS Foundation... Overture Maps Foundation... LF is really "foundation as a service" and they are best at ecosystem building from my biased perspective.
There are other foundations out there with their own advantages... ASF is very lightweight and pretty much accepts anything open source as long as you adhere to their fairly simple rules... EF is great if you have a need for a European base etc
Will HashiCorp remain relevant throughout this? Seeing a lot of parallels with Red Hat's recent mistake...
[0] https://www.jeffgeerling.com/blog/2023/im-done-red-hat-enter...
Hashicorp doesn't have RH's moat at all.
For them to get accepted into the CNCF would require relicensing a large amount of MPL work. What's always been confusing to me about Hashicorp's change and any subsequent relicense of OpenTF is that I know for a fact not everyone who contributed code to Terraform signed the CLA and allowed permission to relicense.
I suspect if OpenTF tries to relicense to a more permissive license like Apache 2 (rather than less in the case of BSL) license we might see some fireworks.
- https://github.com/cncf/foundation/tree/main/license-excepti...
- https://github.com/cncf/foundation/blob/main/license-excepti...
This is correct, but I believe MPL has never been approved as a main project license for a CNCF project before, as opposed to a license of a third party dependency (the default rule is that such projects must be under the Apache License 2.0). FWIW I would not hesitate to support such a request for a policy exception.
Moving OpenTF to CNCF is a great approach. It will be helpful to be able to share this news.
IMO if OpenTF wants to quickly pull ahead, they'd do well to quickly revive popular but neglected PRs from Terraform, inviting those authors to rebase on top of OpenTF and quickly getting them merged.
The RFC process will slow them down here, at least for features, but presumably there are still old bug fixes that died on the vine, too.
But if OpenTF really flourishes, this could end up being better for us than if the license change had never happened. I wish you guys the best in making OpenTF a clear winner! The sooner that happens, the less of a shakeup this will be for the whole userbase and the more teams will stay invested and stick with terraform-the-technology (if not the trademark). I'm optimistic. :)
Personally I wouldn't sweat it.
TF as a tool (not original vs fork) has hit what I think is critical mass, it can't fail. If folks agree the fork is better from a licensing / management level then everyone will use the fork in the end. If not, the original will win. If both tools remain backwards compatible then most end users won't notice the difference.
I think this is a really interesting time. We're getting to witness in real-time how much individuals and businesses value licenses, or specifically what happens when a mature project changes its license.
NOTE: I don't have any tools or services that compete with TF. I'm coming at this as an end user. I contributed once but it was mainly around documentation.
One thing that is always unclear with company-owned projects is what is exactly going against their business plans so you don't waste time preparing a PR only to get half-baked excuses about why it can't be accepted.
Point in case, the numerous PR's and issues to disable warning coalescing in Terraform that are always met with a dismissal but nobody understands why.
https://github.com/opentffoundation/roadmap/issues/new/choos...
In every case I can remember, the community-centric forks outpaced or altogether outlived them. Hudson is dead. OpenOffice is basically irrelevant. Oracle ZFS sees little interest and is not what anyone thinks of when they hear 'ZFS'. But Jenkins, LibreOffice, and OpenZFS are all going strong many years later.
This could end up being a really good thing for Terraform users, would-be contributors, and Terraform itself as a technology. I wonder if any Terraform maintainers from HashiCorp itself will jump ship to work on it full time as OpenTF. A similar phenomenon ended up being a decisive factor with the post-Oracle forks of Sun software IIRC.
[0] https://www.youtube.com/watch?v=-zRN7XLCRhc
[1] https://www.youtube.com/watch?v=Zpnncakrelk
[2] http://dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-...
My point with that observation about licensing was just that in many cases, it didn't even take something as drastic as a license change to get a project superseded by a community fork. Just changing the release process or removing some community maintainers' commit bits or whatever could be enough.
Maybe some of that was because seeing what was done to OpenSolaris made everyone else ready to jump right away as soon as they saw any shift at all in other projects, though.
You have a blog too! Hurrah! I celebrate your entire catalog. If you start another podcast, please be sure to mention it on oxide and friends. It was crickets over there in the "On the Metal" podcast, but when you guys made that last episode I had 2 years of oxide & friends, so perhaps that was ok.
Terraform is the gateway to Hashicorp and it feels like they're going to lose it.
I didn't really know what or how to think about the mismanagement aspect of it, but I was already a F/OSS enthusiast by that time. I ran Linux at home and used free software everywhere I could. I even eschewed Times New Roman in favor of Linux Libertine (then the font of the W in the Wikipedia logo!) for my school essays because I didn't want to support the hegemony of a proprietary typeface.
What I did understand about Sun was that they had been the caretakers (and sometimes creators) of some of the most important and beloved technology I'd ever used. I didn't know anything about Solaris, Hudson, ZFS or SPARC, but I knew Sun for VirtualBox, OpenOffice, the MySQL database system that seemed to be everywhere in the open-source world, and the Java programming language I was writing in for school.
I remember a sense that something precious had died with that buyout, even though I didn't understand what led up to it. I worried a lot about OpenOffice, which I relied on and advocated to friends, and I practically cheered when I read about the formation of The Document Foundation and LibreOffice.
But the biggest mistakes Sun made were made in 2002-2004, and they never recovered:
- the Solaris on x86 "cancellation" (it
was more putting it on hold, maybe, but
the market took it as a cancellation)
- not making a deal with Google for Google
to use Solaris in their data centers
- killing off Sun PS (professions services)
Making a deal with Google would have reinvigorated Solaris' mind-share at a critical time.
IBM did the opposite of killing off its professional services division. IBM killed off their x86 systems division and beefed up its PS, and IBM went on to make a killing on PS.
The vendor lock-in issues totally compounded these terrible decisions.
After 2002 Sun was always on the back foot.
Wow i had no idea that had almost happened!
Anyone care to elaborate further on that?
I wonder what could have been, if later solaris was open sourced and google could push their improvements… maybe we’d all be running containers based on solaris zones, and would have solaris on our smartphones? Who knows!
I understand people's dislike of the license change, but Hashicorp isn't Oracle.
The future of Terraform is open-source
We are beyond excited to be part of this great initiative. We did of course expect a fork to be of significant interest to people; what we did not expect is this crazy level of support for it. 2k+ stars, 100+ companies and 400+ individuals pledged, and there is already more full-time engineering positions committed to it by pledging companies than the whole Terraform Core team at Hashicorp (source: terraform commit history)
https://oxide-and-friends.transistor.fm/episodes/fork-in-the...
- https://www.scalr.com/ - https://github.com/Scalr
- https://gruntwork.io/ - https://github.com/gruntwork-io
- https://www.massdriver.cloud/ - https://github.com/massdriver-cloud
- https://spacelift.io/ - https://github.com/spacelift-io
- https://digger.dev/ - https://github.com/diggerhq
All those companies have very decent experience with Terraform. Even if some didn't contribute to the core, they all built decent software on top of or around Terraform.
In addition, we at Terramate also plan to contribute as much as possible. We have worked exhaustively with Terraform and related libraries such as HCL and are very well aware of the limitations and shortcomings we need to resolve with OpenTF.
I'd love to emphasize that many of us tried to contribute to Terraform in the past, but HashiCorp became somewhat hesitant to review and accept PRs which massively slowed down innovation for Terraform.
While I see the reasoning behind HashiCorps decision to switch licenses I strongly believe that closing up the ecosystem further won't do any good to Terraform and other of HashiCorps products, hence our strong buy-in for OpenTF.
I'd love to emphasize that many of us tried to contribute to Terraform in the past, but HashiCorp became somewhat hesitant to review and accept PRs which massively slowed down innovation for Terraform.
I also encourage you to take a look at the Sponsor badge on our (Spacelift's) profile. Whenever a possibility exists, we give back to the projects we use. We tried the same with Hashi, too.
Re: trusting us over Hashi. DON'T. If there are any lessons learned from the great Hashi bait-and-switch trick it's that for-profit companies should not be trusted as the guardians of open source.
Trust the foundation that takes over the project. Trust the cash we'll endow it with.
we support our employees working on open source during their Friday projects
If we are to accept that the OpenTF foundation is going to be a better maintainer of terraform we need something better than "Hack on opensource if you want to!"
Spacelift doesn't have a good track record of contributing to opensource so the current model isn't working.
Also, Jacob started OctoSQL before ever joining Spacelift so its pretty odd to use that as an example of spacelift doing OSS well. Especially since his activity on his has tanked since joining you.
The employes can do open-source on Friday but no part of Spacelift is actually open-source?
Trust the foundation that takes over the project
My concern is spacelift and some of the other companies have no track record of being GOOD at opensource. Not as part of the terraform community or opensourcing things they've built in-house.
This group of people has taken a leap of faith. They aren't asking us to leap with them, they're asking us to pay attention to where they land, and come along if it looks like the water is fine.
I applaud their approach.
OpenTF is the same MPL license under a different name.
Companies that use terraform to manage their infrastructure are not practically impacted in any way, except by this OpenTF effort (which I don't personally oppose either!) which will create a schism and leave us with competing tools that are not quite interoperable over time (thinking about ZFS/OpenZFS, MySQL/MariaDB, etc.).
https://www.hashicorp.com/license-faq#usage-limitations
It isn't the AGPL, but I am just sort of stunned at the uproar around this. Is Hashicorp supposed to just shrug and clap while a competitor takes (primarily) their work and competes with them using it? That's what the MPL allows, and they don't want to do that anymore, so they... changed the license to protect their interests. What do you expect them to do?
Thought the same. I think the uproar is partly manufactured by competitors and freeloaders who are affected by this license change, eg. Spacelift.
Two sources (mariadb and fossa.com) claim that by BSL any production use requires a different (commercial) licence, while HashiCorp's explanation [0] indeed tells that there is no change except for those providing competitive offerings (I'll take their word for it). Which seems... more than fair? Not sure what the uproar is about either, if anything, I understand (and support) HashiCorp. Too bad about the split though.
I'll preface this with I don't know anything about Terraform, OpenTF, HashiCorp, etc. I couldn't even guess what Terraform is. I'm in mobile dev. However, I work on open source a lot and think about sustainability and revenue streams quite a bit.
I read the manifesto. I saw the "revert the license or we'll fork". What I didn't see is any form of trying to work with HashiCorp on their goals. It seems like very considerable resources have been pulled together to fork, but I didn't see the part where anything remotely like that level of effort and resources was on offer to HashiCorp to rethink the plan and come up with a better answer.
As I understand it (which is based off of some comments. See above about not knowing anything about this), a good chunk of the resources are actually from competitors. If true, it takes a lot of the sting out of the "HashiCorp are jerks" argument. I mean, I'm not saying they're not, but it's more like, "HashiCorp changed the license so they could push back on competition, so the competition forked the code". I don't really expect "right and wrong" from companies, or open source for that matter. But the spin and vibe feel a little misdirected.
I mean, don't get me wrong. Building up a community who contributes, then doing a rug pull, sucks. However, the "company does a risky thing and builds this awesome tool, then a bunch of others fast follow and exploit it" has become very common, and it is going to be a bad thing in the long run. You can say "We believe that the essential building blocks of the modern Internet, such as Linux, Kubernetes, and Terraform need to be truly open source", but to be fair, Terraform was not an essential building block until somebody built it.
As much as license rug-pulls damage user/community investment, fast-follow competition and the threat of forking will ensure far less investment in the very kind of open source everybody wants.
There is a financial sustainability problem involved in "big open source", and we are seeing the changes. In many ways, it simply has to happen. Going forward, I do hope new products like this start with a license that works rather than changing, as that is obviously not appreciated, but many devs reflexively avoid that kind of arrangement, even if it costs nothing to use.
Anyway, just thinking out loud. Hashicorp might be run psychopaths. I have no idea. In a general sense, though, the whole industry is going to need some new models. If it's just "fully open source or nothing!", there's a whole class of tools that won't exist. Building things is risky and expensive. I don't want to go back to when everything was closed source and needed a license, but open source without a reasonably protectable revenue model will definitely limit what gets built and why. And as we like to say, "if you're not the customer, maybe you're the product", or something like that :)
It’s being forked only now because there is big money at stake.
I’m gonna wear my cynical hat and say: it never was about collaboration.
Seriously: people are falling for the collaboration meme. Isn’t anybody wondering “why now?”
Why not a year ago, why not a year in the future?
Hear, hear. We would love to see them join forces with OpenTF.
Happy to answer any questions you might have!
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
Hashicorp engineers were incentivized to work on features related to Hashicorp paid services, and Hashicorp competitors who would similarly benefit from a stronger Terraform codebase were disincentivized from potentially helping Hashicorp.
Isn't this always going to be the case?
Honestly, are you signing up to maintain the feature long-term? Fix bugs? Update documentation? Review PRs with small changes to the feature?
The cost of accepting a PR can be much higher than the cost of creating the PR.
Even if you promise to maintain it! What if you don't? What recourse does the maintainers have? They can't just remove your feature, since customers started using it and you don't want to announce breaking changes and scare everybody.
If you're building an open source product with lots of users, where compatibility is important. Then accepting a PR is a huge liability, you'll always want to be extremely conservative about it.
A PR is not always a gift, regardless of innocent it looks.
I'm wondering how OpenTF will handle the plugins. Will it pull from HashiCorps servers, or will it spin up its own plugin registry? If the latter, will the existing plugins be mirrored?
(Marcin, co-founder of Spacelift, and one of the members of the OpenTF initiative)
At a glance, three of the top four contributors to the AWS provider are from outside of Hashicorp, and two of those three are AWS employees.
Thanks for the insight. I think it wouldn't hurt to have an open registry at some point, but we will need to figure out the governance model for that as part of the foundation.
Stringing together resources to pull from a secrets manager and still having the secrets stored plainly in state is enormously frustrating. We aren’t all living in a nirvana of fast rotating out of band secrets.
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
> This is actually a feature I'd love OpenTF to have and am quite passionate about, personally
You're probably already aware, but SOPS¹ kinda fits the bill for integration here perfectly.
It supports local secrets as well as encryption via keys stored with all the big cloud providers, and it's already battle-tested as it is used heavily at Mozilla (it comes from there).
Additionally, like OpenTF, SOPS is maintained independently of any single corporation, written in Go, and distributed under the MPL-2.0 license. On its face, it seems like a match made in heaven.
SOPS is a great tool and could be a pretty killer starting point for this stuff!
--
Also interesting to mention that they haven't said a single word about CLAs. If this project would require a CLA (and copyright assignment) to contribute, then it doesn't matter that it's a foundation, they could also re-licence it easily, which is exactly what they are fighting against.
Relicensing is a completely separate conversation, and there are plenty of open source CLAs which don't have that provision.
So, you've never heard of a Developer Certificate of Origin? If it's good enough for Linux, it's good enough for me.
So in other words, a CLA.
What's the point of open source if you have to reveal you real identity?
I don’t know what happens to the Linux Foundation when we’re all in the nursing home, but them relicensing everything is not currently plausible. It is a merely theoretical possibility.
According to the link below:
> Anyone who is contributing any code to any CNCF project must have the CLA signed.
https://contribute.cncf.io/resources/glossary/#:~:text=Contr...
what is the reason those require CLA? Why underlying license is not enough?
A CLA is required when the repo owner wants the ability to change the license down the road without contacting N contributors.
(Marcin here, co-founder of Spacelift, one of the members of the OpenTF initiative)
We provided a dedicated team on a temporary basis. Once the project is in the foundation, we will make a financial contribution, with which dedicated developers will be funded. At that point our devs will gradually hand over to the new, fully independent team. The other members of the initiative so far follow the same pattern but I can't speak on their behalf re: exact commitments.
Oracle tried to constrain Hudson, but Jenkins won.
while digging up that link, I also saw one named replication: https://github.com/hashicorp/vault/blob/v1.14.1/website/cont...
Gah, this is frustrating! I am learning Python but TF and tf-ls are written in Go. I need to figure out how best to contribute.
This repo [0] seems to still be licensed under MPL, so there is no need for an immediate action, but if there is a willingness in the community to take it over and improve, I see no reason why we wouldn't do it.
Tools, frameworks, etc all have to be written by people, and I'm sure you're already keenly aware that poor programmer tooling can be the death of a project.
This is definitely selfish on my part since I write a lot of Terraform and lean on the language server a lot, but I hope that terraform-ls can have a couple of people dedicated to it eventually.
Unfortunately (of course!!) my own pet issues are pretty niche, since I expect there aren't many people using a lot of private registry modules like the client I work for. Hence my desire to fix it myself :)
I 100% agree with your perspective on tooling, and hope the OpenTF team will take terraform-ls (and hcl-lang) under their org, too, because I will never contribute one more character to any repo in the hashicorp org.
Adopting hcl-lang is very low risk, but not zero, and it would be a spiteful move for Hashicorp to introduce some BuSL-only change to hcl for the purpose of hard-forking the language
On the weekend I try to get through a couple of Exercism items, and rest. I really wish I had 10x the energy to contribute to so many worthy open source projects :(
Maybe call it OpenVLT and OpenCNSL. Then we can wrap it in a larger OpenHC or OpenMoto umbrella of projects.
Especially with the integration points between Terraform, Vault, and Consul, those can be maintained better.
Hell, I would do it myself, it I had the connections and time to do it. I might still try if no one else does. I would model it after OpenTF
I dunno if you're trying to play on "hashimoto" but https://github.com/getmoto/moto#readme would be a prime name collision for any such "OpenMoto" name
But yes, please, to adopting Vault. I don't have a horse in the race about Consul but my suspicion is such an effort would only be worthwhile if trying to adopt Nomad, too, which I gravely doubt
I think this license change will hamper adoption and contribution when teams compare a foundation supported k8s vs a source available Nomad. I haven’t heard of anyone taking this on, but I’d love to keep my eyes on it if/when it happens.
Disclaimer: early supporter of opentf, cofounder of massdriver
Consul is just a nice distributed KV store and Consul Templates integrate well with vault secrets.
It can also be used as a storage engine for Vault of needed.
https://github.com/leg100/otf https://news.ycombinator.com/item?id=34536663
Wondering about nomad and it's future. It didn't have as much user base though and if only containers matter, nothing can beat the simplicity of docker swarm.
No sure about Vault. I found it over engineered and complicated to graspe.
I have been trying to help https://github.com/vaagrunt/vagrunt but there are 4400 forks so it's hard to know if one of the other ones is getting "community buy in" - I just saw that one in another HN thread and tried to help out (it's always bugged me that there was no $(make dist) for Vagrant so hopefully here's my ability to fix that bug since Hashicorp was for damn sure never going to accept any such PR)
Disclaimer: I'm one of the founders.
My personal use cases are PG and SSH CA leases (err, back when I used SSH :-D but I'm guessing that's still a non-zero audience)
I'll definitely be using OpenTF for any future projects and if I find myself a part of or leading a DevOps team again, will work to migrate that team over.
The providers will support Terraform and update to the latest framework, which may be incompatible with OpenTF at the time. Are we forking those too?
The provider framework has been kept MPL, as have the providers, so we will keep being compatible.
We will see what the longer-term future brings, and we'll react accordingly. We also have a bunch of ideas for improvements to the provider ecosystem and their capabilities, but those will go through the public RFC process once it's in place.
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
DSL changes are honestly the thing we'd like to limit the most, but as long as they're backwards compatible, the RFC process will welcome them, and they will be discussed and considered!
The important thing is for features to be opt-in. You should be able to limit yourself to a feature-set that is Terraform-compatible, if you want. If you want to use additional features on top of that, then that will be an option as well - we definitely want to innovate.
Assuming you aren't committing under pseudonyms, you've to date made a single contribution to Terraform, which was a fairly trivial change (b49655724d2f96f0e68196fb949a0d625abbd60e).
[0]: https://developer.hashicorp.com/terraform/plugin/framework/m...
[0]: https://registry.terraform.io/browse/providers?tier=official
[0] https://registry.terraform.io/providers/conradludgate/spotif...
So they can always do it again...
As a long-term HashiCorp fanboy, and a true fan of the work of Mitchell this would be my dream come true, on a very personal level. It would also be a great day for the entire community.
Managing a cloud deployment in 2023 feels a lot like managing a Sharepoint server in 2010. You really want it all to be scriptable, but the tooling isn’t quite there yet.
I understand that on day one the tests may not yet be green or some links in documents might not be updated, but I would feel a lot better if there was a public github repo that had a README.md with a big note at the top saying "Work is underway, don't use this yet".
Without such a repo, it feels very much like opensourceness and community involvement is an afterthought.
Really, there's a few things, like getting rid of trademark infringement and setting up some basic community guardrails, that we need to finish prior to publishing.
We're doing our best to get this out and public as soon as possible.
You can take a look at the new public roadmap repo[0] to track progress towards milestones such as publishing the repo.
[0]: https://github.com/opentffoundation/roadmap
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
> So far, four companies pledged the equivalent of 14 full-time engineers (FTEs) to the OpenTF initiative. We expect this number to at least double in the following few weeks. To give you some perspective, Terraform was effectively maintained by about 5 FTEs from HashiCorp in the last 2 years. If you don’t believe us, look at their repository.
That actually sounds promising.
This matters a lot; am I the only one skeptical about this move just being about cloud competitors trying to preserve margin?
I fear that sooner or later the APIs will become non-compatible so the only "good move" would be to jump to OpenTF as soon as possible to avoid complication. But for entreprise it will be a tough jump: updating all tooling, scripts, deployment flows, CI, compliance check, etc.
[Marcin, co-founder of Spacelift, one of the members of the OpenTF initiative]
(even though I wish there was some breaking changes to be able to fix some of nasty bugs that have been there for years ahah)
I also don't have a good grasp of what the situation is for the in-flight PRs for Hashicorp's repo: are those changes still MPL until they land in "main" and get BuSL-ed? IOW, is the PR author responsible for resubmitting or could any such patches be pulled in safely (err, DCO and CLA nonsense aside)?
Even better would to leave a note rescinding permission for Hashicorp to include that work, though I'm not sure whether that is a viable strategy.
At the very least, these steps will create more work for Hashicorp and send a clear signal that the community thinks that they have made a mistake.
I don't see how that would work. If a valid offer has already been made under a license agreement, it's then entirely up to Hashicorp whether to merge it or not.
https://news.ycombinator.com/item?id=37264675
We’d love to know what issues / PRs are important to your team to help us prioritize
A) This could easily be a another reddit moment, where corps and actual bill payers will forget about it in two weeks since it simply -does not concern them-. The supporting list mostly consists of actual competitors.
B) If they can manage all these resources, why can we just simply not do something new along the way? Terraform has its flaws and everyone that seriously had to worked with it can name many.
For instance: Did you know that you cant easily shut down a server when deleting a terraform resource? At least not without hacks or workarounds?
Its time for a "cloud-init native" solution to all these problems and while appreciating the effort i think this fork will actually hinder future development by having things remain the same.
- Cluster Api all the way -
Marcin here, one of the member of the OpenTF.
99% of the value of Terraform is its ecosystem - providers, modules, tutorials, courses etc., and millions of lines of battle-tested production code already written in that language. 1% of the value is in the tool itself, with the tool serving as the gatekeeper to all these riches. One of the things that I personally want to see is opening up the codebase to allow building new things on top of it, which then don't need to reinvent the wheel.
You dislike HCL? Fine, have something else give the tool an AST and we'll take it from here. You don't need/want to go through the CLI? Not a problem, embed some of these libraries directly in your app.
Personally I think Terraform hit on a really good pattern for IaC, and while there are lots of rough edges that could be polished, the overall approach is by far the best fit yet invented for the problem it's aiming to solve.
1. Create new certificate
2. Update the certificate attached to the load balancer
3. Delete old certificate
But it isn't actually possible to do that in that order with terraform because of how dependencies work.
By default what terraform will try to do is:
1. Delete old certificate. this will either fail, because the certificate is in use (as is the case in AWS) or destroy a resource that is still in use and cause the load balancer to enter a bad state
2. Create new certificate
3. Update the load balancer
The only ways I have found to work around this is with targeted applies (which are discouraged), or splitting the change up into multiple code changes, with separate applies for each change.
> Will I be able to use OpenTF as a drop-in replacement for legacy Terraform?
> Yes
> Will OpenTF be compatible with future Terraform releases?
> OpenTF will be 100% interoperable with future Terraform releases until the community wishes otherwise.
I dunno if "auto import" will ever be a thing, but I will be first in line to change its model to actually contact the provider during `plan`, which neither TF nor Pulumi do right now and it's a cause of endless wasted hours and borked deploys
CDKTF looks promising. How will OpenTF interplay with it?
Anyone know why this was done in this order? Why not apply for CNCF right from the get-go?
(Marcin here, one of the OpenTF folks)
opentffoundation
open-tf-foundationAs an added benefit, shorter names add a sense of legitimacy to new projects.
> So far, four companies pledged the equivalent of 14 full-time engineers (FTEs) to the OpenTF initiative. We expect this number to at least double in the following few weeks. To give you some perspective, Terraform was effectively maintained by about 5 FTEs from HashiCorp in the last 2 years. If you don’t believe us, look at their repository.
#opentf
We are super excited to be supporting this initiative. The community around Terraform has been pushed aside for too long.
Terraform is the most widely adopted tool for managing cloud infrastructure. Putting it in the hands of a foundation that can ensure it remains open-source, community-driven, and impartial is crucial to so many infrastructure and operations teams around the globe.
Depending on when you start, the first release mag already be out!
Also I know Hashicorp has a good moat (how good we don't know yet). Some very big companies pay Hashicorp and there's no way they're going to leave for opentf anytime soon. The support alone is plenty valuable enough to keep them there.
What vendors is the post referring to?
- Spacelift
- env0
- Digger
Pulumi is not targeted, since the licenses of the providers are not changed.
How about "Genesis" or "Reliant"?
Why not now?
There's unfortunately a bunch of these things we have to do before we can publish. We created a public roadmap repo if you'd like to track the progress[0]. We're doing our best to make it public as soon as possible.
[0]: https://github.com/opentffoundation/roadmap/milestones
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
- New startup, cool idea, not much budget to hire engineers
- Make it open source, piggy back on the free exposure that will get you, no marketing is needed because everyone loves open source!
- Your project gets to have top tier programmers as maintainers, make all the nifty features, fix all bugs etc. for free or at minimum cost
- Few months later, change license and/or close source it.
- Rinse and repeat!
Sometimes you get the community to fork it and maintain it by themselves, unfortunately, that’s not always the case.
Not to defend HashiCorp too much but in this case "a few months" was actually nine years.
Also, none of the companies that pledge FTE support to OpenTF are open-source.
In most case in these companies it's maintained and created at the expense of the company. I would expect that 90-99%% of the code, product development (talk to users, understand needs, etc), even devrel (marketing) (be on every conference to convince people to use it, that codification is good)- it's a lot of money, resources, and effort.
> New startup, cool idea, not much budget to hire engineers
In this case a few folks build it from the ground initially (most likely founders) I think. Please, let's not forget about this.
The important thing here is to discuss why did they do this (I meant relicensing it). Most likely- trying t create a moat from a lot of other VC-funded companies that play in this space? Not sure. It would be great to know their exact concern.
It is also very interesting to see how this will play out specifically for Vault vs Infisical. So far, Infisical has been growing incredibly, especially after the license switch.
It's their product -- they can do as they wish.
Simimlarly, I wish the OpenTF Foundation all of the luck in the world in their efforts to persuade Hashicorp to keep Terraform Open Source.
I am not affiliated with either group; I wish both groups well in their respective positions; I am not affected in any way by Terraform going closed source, or forking, or whatever.
One of the paradigms that I think in is that of Software Engineer, and that of first principles.
The basic "problem" that TerraForm is attempting to solve is that of "cloud provisioning".
"Cloud Provisioning" is a fancy name for "Infrastructure Provisioning" which is a fancy name for both "Server Provisioning" and "provisioning other services related to servers" remotely.
Which in turn are fancy names for "create and configure a remote computer or VM" (VM's are effectively remote computers) or some piece of software or infrastructure related to one.
Which are in turn fancy names for "spin up a remote server and/or something related to one or more of them..."
Pretty simple, pretty straightforward, once we drill down through all of the layers of linguistic sediment...
Problem is, in general, no two cloud computing providers -- use the same API.
That is, AWS's API is in general, different from Azure, which is different from GCP, which is different from other providers, etc., etc.
Here, have a look at some of them (there are quite a few!):
https://registry.terraform.io/browse/providers
The net effect is or should be, that Terraform creates its own abstraction layer, its own API -- over all of these other disparate and ununified API's, sort of like "The One API to bind them" (Compare to how Microsoft Windows in the early days created a unified API across disparate PC hardware components created by multiple vendors).
With this unified API (or secondary abstraction layer if you prefer, API of API's), now code can be ran to programmatically automatically ad hoc add/modify/delete cloud infrastructure components (which remember, is a fancy way to say "servers and things related to remote servers") as needed.
Thinking in this way then, it wouldn't be necessary to fork Terraform and/or keep it Open Source.
If one were a Software Engineer, and one were inclined to, they could start building a rival Open Source product which would match the above functionality, completely from scratch with no dependencies on Hashicorp's code or licensing.
Already there seem to be more than a few Open Source projects in this space; and while many may lack the depth and breadth of Hashicorp's product, it will only be a matter of time before one or more becomes dominant.
The key word to search for in this space, on GitHub, is "cloud management"
What follows is a list of early Open Source contenders in this space:
https://github.com/topics/cloud-management
To recap, I wish both Hashicorp and the OpenTF Foundation well in their respective quests.
I expect to see many (and many other) non-affiliated Open Source cloud management tools and API's in the coming years... it's an interesting space...
_Layered and modular - with a programmer-friendly project structure to encourage building on top, enabling a new vibrant ecosystem of tools and integrations_
Now sales are tough. Pricing is terrible. We've been using their services for years while being offered enterprise services without much incentive.
Why the license change? Lock out competitors or perhaps a charitable assumption, secure future service offerings without being exploited by cloud offerings that use their code while competing.
The decision was a business decision. The amount they spend on sales to sell what I think is an amazing product, just over priced, is their doom. Why lock an enterprise into a three year contract tied to usage?