You would find your car keyed pretty fast.
Start up the discussions on migration, yes. Do not switch just because something is open source. Production is about using the best tool for the job at a reasonable price. Open source tools are nice but you also need to factor in what level of support you have with a company and so forth.
Yeah you’re right.
I was righteously angry and hyperbolic. That said, sure, you’ll want to look at support if you want to externalise responsibility as a legitimate business strategy. That doesn’t always mean you want to go that way though. I’ve been in situations where support for commercial firewall appliances was like pulling teeth and a simpler open source solution that a few people can grok would’ve been the better option.
YMMV I guess, but this type of commercially backed FOSS rug pull should definitely factor into the decision and right now it usually doesn’t.
I think you are very much over-valuing how much companies care about FOSS in production. Unless the intent is to be able to fork and support it in house (which is almost always a bad idea), it isn’t really a concern. What matters is the license. And… spend enough time having to all but physically smack people on the nose for even thinking about the (corporate) cancer that is LGPL and you get different thoughts about the importance of FOSS in Production.
I would definitely be wary of a license change. I have personally not checked what the new Redis license is. But if it is still favorable but also looks like something they can profit off of? I would probably put it in their favor. Because that suggests they are done being obnoxious. Contrast that with something like Hashicorp’s bullshit where a LOT of companies don’t even bother to pretend to be diplomatic when discussing how much chaos they caused.
I think you are very much over-valuing how much companies care about FOSS in production.
I’m not. I specifically mentioned externalising responsibility is a legitimate business strategy. I corrected the statement I made in anger and the thrust of the follow up’s point is that if you decide to go with commercially backed FOSS the possibility of a rug pull should factor into the financial prospects of whatever you’re doing in the long term.
I develop the infrastructure part of a product for a living and the product as a whole is expected to be supported by us for up to 10 years. If a vendor decides to switch up licensing half way through that lifecycle I’d be weary to continue business. VMware is a great example, they switched from perpetual to subscription after the Broadcom sale went through. We are looking at alternatives.
edit: Also, using FOSS as part of your solution doesn’t necessarily imply you have to take up it’s development. Depending on a community is also an option (although ethically I’d say it’d be nice to push improvements back).
They don’t care much for the license per-se, but they would if it affect their business.
On one of my projects, we had to be stuck with an older version of MongoDB due to the Mongo cloud service not having server in certain regions.
Since the project deals with sensitive information, that cloud service not an option. The only option that we have is to use local cloud providers. The only problem is the latest version (that we’re using on most our stuff) was priced exorbitantly.
We ended up using the ones with the last version with AGPL. Had to change a bunch of our code to accomodate the downgrade.
It’s easy to judge from ivory tower, but the reality in the industry is that we can’t be idealists on everything.
No clue about this instance but I’m pleased to see in general the business model where the code is all open source and support can be paid for. That would be a pretty fair business model for me as a (company) customer, assuming the product meets my needs. One example of this is XCP-ng, a virtualization OS, competing against VMware, but all open source and with paid support. Great for homelabbers too
The problem is that other companies can offer support as well, and they can do it for cheaper because they don’t have to finance development with that.
Start up the discussions on migration, yes. Do not switch just because something is open source.
If it’s a fork of literally the same software, just rebranded, why not? Plenty of people switched from CentOS to AlmaLinux right away by executing a small shell script.
And how is that working out with Suy vs Yuzu? I mean, it is the exact same code so you might as well just use it, right?
The reality is that you have no idea if the new maintainers are trustworthy or even competent. In this specific case the “maintainers” are the Linux Foundation which is one of the more trustworthy sources. But there is still no guarantee they will emphasize performance or user support versus stability.
Which is why you have conversations rather than just “FOSS good!”
Production is about using the best tool for the job
I find this attitude kinda simplistic and problematic. This attitude applied elsewhere can be used as justification for all sorts of terrible things, I don’t know why it should get a pass in tech. Sometimes the best tool for the job is produced by an evil company you want to boycott. Sometimes the best tool causes lots of collateral damage or harm, or has potential to lock you into an ecosystem. Maybe you want to support the growth of other tools and are willing to sacrifice some performance.
Even if only profit is considered, I think it’s reasonable for a company to conclude that open source software is inherently better due to reasons that go beyond immediate utility and profit making potential by thinking longer term.
Obviously you do what you can to avoid supporting bad/“bad” companies
But… me and my engineers aren’t getting paid more to make a support tool for what we are paying or to help a project out with their teething issues. So picking a solution with poor support/poor capabilities just means we are putting in a lot more hours for work that we won’t get paid for.
Versus having a budget to buy tools other people developed and possibly even support. Which means we have more cycles to dedicate to what our actual job is.
And our customers aren’t going to say “Hey, good for you. Thanks for supporting this project”. They will say "We have downtime. We either want to be compensated or will change to a different solution.
We’re all free to make the calculation that makes sense for us. Not everyone wants to sacrifice everything for profit, and this is a viable tactic.
