Live data from Hacker News

The OpenTF Manifesto

opentf.org

91–100 of 392 posts

Re: The OpenTF Manifesto

#91
post #79

We need a new word for this. 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 t…

afaik you can't use terraform in the name, it's trademarked by Hashicorp

That would be what I meant by legally prevented.

Re: The OpenTF Manifesto

#92
post #6

I love it. The list of "pledged companies" is literally just a list of all the offenders that Hashicorp are trying to shake off.

This is reality of any successful Open Source ecosystem - folks who contribute the most (code, bug reports, marketing) in the project tend to be those who are making money on the project and these are the same folks who compete with you

Coopetition is name of the game in Open Source and too bad increasing number of the companies want to focus on capturing all economic value from ecosystem they have created with help from so many others

Re: The OpenTF Manifesto

#93
post #37
post #17

>Imagine if the creators of Linux [] suddenly switched to a non-open-source license that only permitted non-competitive usage. Linux cannot even successfully switch from GPL2 to GPL3 because of the sheer number of contributors and the fact that not all of them have transferred their copyright ownership to any given organization. This patchwork of different copyright owners has historically been seen as a potential we…

I thought Linus and other believed GPLv2 was fine and the improvements of GPLv3 did not outweigh the potential problems introduced by it. It never came to a point where all authors were asked to agree, or sign away their ownership.

Torvalds considered the anti-TiVo clause to be changing the deal and he didn't want to do that, and there's no way in GPLv3 to opt-out of the clause[0].

This is less "locking down devices is a human right" and more him being angry that the FSF was trying to butt into his project's affairs. He's also similarly angry about "GNU/Linux" as it sounds an awful lot like Stallman just demanding everyone stick "GNU" onto the name of Linus's kernel project.

Anyway all of this is going to seem really quaint in 2027 when Broadcom gets sued under DMCA 1201 by a rogue kernel contributor for evading the Linux linker's license checks[1] and they have to hurriedly rewrite them out of the kernel and relicense anyway.

[0] Granting a blanket exception doesn't work because others can just remove the exception. "No further restrictions" is an ironclad law of copyleft.

[1] The Linux kernel checks the declared license of loaded modules and refuses to link non-GPL-compatible code against any kernel symbol not marked as a user-space equivalent. The reason why this works this way is because Linux ships under GPLv2 plus an exception that says user-space APIs don't trip copyleft, so you can legally load code built to those APIs into the kernel, but anything else might violate GPL.

Since this is enforcing an interpretation of the GPL, this is a DMCA 1201 technical protection measure. You absolutely could make a DMCA 1201 anticircumvention claim in court against a proprietary driver developer that tried to evade the checks. Though Linus usually just bans their modules in the next kernel revision since he's mainly worried about keeping proprietary modules from generating spurious bug reports in Linux. But the lawsuit is still possible, since they're on GPLv2. If they had relicensed to GPLv3, this wouldn't be an issue.

Re: The OpenTF Manifesto

#94
> When any company releases their tool as open source, the contract with the community is always the same...

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.

Re: The OpenTF Manifesto

#95
Long time YC reader here. Created an account just to make this comment: maybe this idea of a fork is a good thing. We maybe able to potentially explore developing HCL further. Develop further abstractions that are provider agnostic. At least for most common resources like instances, security groups etc.

Obviously there would be tradeoffs involved. But if we can cover the 80% situation, that would be a good start.

Re: The OpenTF Manifesto

#96
post #7

Also, update from Spacelift, we believe that we are not in violation of the new license, you can find more details in our today's announcement[0]. 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

You guys effectively sell cloud-based TF instances though, don't you? Pretty sure that's a no-no...?

Re: The OpenTF Manifesto

#97

Ask Roblox employees how they feel about Hashicorp products. Terraform is probably the most solid product they have seconded by vault, but after hearing the consul and nomad horror stories, I don't think I could take their products seriously ever, not when kubernetes is setting right there.

Well, here's the link to the post-mortem of said "horror" story on the Roblox blog:

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.

Re: The OpenTF Manifesto

#98

We at Oxide were honored to be asked to add our name to OpenTF Manifesto. Our statement: 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 kn…

As a huge Oxide fan, thank you for the support!

Re: The OpenTF Manifesto

#99
post #35

Earlier quoted context omitted.

I really appreciate that, and I do think it's right of you to at least make the attempt. That being said, I don't expect this attempt to work and I fully believe that a fork is going to be inevitable. I also think a fork is an amazing opportunity to standardize the language and prioritize the features developers want. It isn't just about the license, but the way that Hashicorp has maintained the Terraform project. Th…

Smells like the end of Chef. Management doesn't understand how much it takes to maintain the open source project and is just pouring resources into sales and marketing and products that they can charge for, and don't see how that erodes goodwill and the technological foundation of the company.

I also saw that parallel with Chef. I think its the story of all VC funded software that attempts to be "Open Source". For them, Open Source means "You can read the source code, and potentially fix a bug", for us, it means community, transparency, and fixing bugs beyond those your paying customer has.

I looked at github /chef/chef and github /inspec/inspec and its the same as it was shortly after I left. The only changes are from the one person who carried over after the sale to Progress, and the contracting team out of India, with dozens are unanswered queries and pull requests from the community.

What really ruffles my feathers was when they had us define oss-practices (https://github.com/chef/chef-oss-practices), clearly nobody outside our small team read (or understood) those words and goals. It feels like it was work to make us look better in OSS in order to bolster the company sale.

Re: The OpenTF Manifesto

#100

Ask Roblox employees how they feel about Hashicorp products. Terraform is probably the most solid product they have seconded by vault, but after hearing the consul and nomad horror stories, I don't think I could take their products seriously ever, not when kubernetes is setting right there.

Hashicorp enterprise support is rock solid for Nomad, Consul, Vault. If there is a P0 problem, they will root cause, and usually have a fix identified in < 48 hours. All three of those products are taken very seriously - running 10,000+ servers in a single cluster.
Post reply on HN