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.
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).
I think both are true, it really depends on the business, and the mentality of the exec. It is extremely difficult to get software approved in my environment if it doesn’t come with some kind of vendor support.
Basically they want assurance that if something breaks, they can get someone to fix it if necessary.
Personally, I don’t think this is the best approach. Vendor support is often underwhelming, and it is not forever. The longer you want it, the more it will cost you to keep it. By the time they cash out, you’re so invested the cost to change is prohibitive.
My biggest gripe with closed source software, is the pissweak amount of peer review it gets, and it shows repeatedly. It’s disturbing that we use things as important as operating systems and security products that only get scrutinised by a small number of people. People who probably all have similar methodologies and tools at their disposal. So, you forever see CVEs because they miss simple things. We’ve actually had a vendor (who we spend millions on yearly) tell us they wouldn’t fix a 9.9 because they were planning to discontinue the product, and sign a nda.
I would love to convince my org to refit to oss, but it would be an enormous investment just to transition, and honestly… With the stuff we’re seeing on the horizon of tech, I’m expecting some wild shifts in the way we do things in a similar 10 year timeline. It’s been nice working with x86 since 8086, but it’s time.
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.
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!”
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.
Sure they can, but I think they would not be viewed equally, at least to me. I would expect more from the developers of the tool for which I seek support than from third parties. But to each their own.
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.
So… not gonna read the response where I point out it has less to do with “profit” and more to do with the people who actually do the work for a company?
Well I agree with that part, when I’m saying using open source vs proprietary, I’m not proposing companies use alpha software in production. I was thinking more along the lines of avoiding MS Exchange in favor of of Postfix/Dovecot/CalDAV even though Exchange is arguably superior at managing one’s emails and appointments.
For as much as we all hate MS Teams with a passion: It is not arguable. It is superior. And Exchange and Outlook couples well with MS Teams which gives you a corporate chat client, teleconferencing, document sharing, etc.
That hodge podge of tools? It is someone’s job to maintain that. Likely someone who is maintaining significant parts of corporate infrastructure and doesn’t have time to work through what the 55 year old waste of space refuses to even try to understand but will instantly get blamed in meetings with the c-suite if that idiot can’t figure out how to write an e-mail.
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’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).
I think both are true, it really depends on the business, and the mentality of the exec. It is extremely difficult to get software approved in my environment if it doesn’t come with some kind of vendor support.
Basically they want assurance that if something breaks, they can get someone to fix it if necessary.
Personally, I don’t think this is the best approach. Vendor support is often underwhelming, and it is not forever. The longer you want it, the more it will cost you to keep it. By the time they cash out, you’re so invested the cost to change is prohibitive.
My biggest gripe with closed source software, is the pissweak amount of peer review it gets, and it shows repeatedly. It’s disturbing that we use things as important as operating systems and security products that only get scrutinised by a small number of people. People who probably all have similar methodologies and tools at their disposal. So, you forever see CVEs because they miss simple things. We’ve actually had a vendor (who we spend millions on yearly) tell us they wouldn’t fix a 9.9 because they were planning to discontinue the product, and sign a nda.
I would love to convince my org to refit to oss, but it would be an enormous investment just to transition, and honestly… With the stuff we’re seeing on the horizon of tech, I’m expecting some wild shifts in the way we do things in a similar 10 year timeline. It’s been nice working with x86 since 8086, but it’s time.
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.
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!”
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.
Sure they can, but I think they would not be viewed equally, at least to me. I would expect more from the developers of the tool for which I seek support than from third parties. But to each their own.
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.
So… not gonna read the response where I point out it has less to do with “profit” and more to do with the people who actually do the work for a company?
Good chat.
Well I agree with that part, when I’m saying using open source vs proprietary, I’m not proposing companies use alpha software in production. I was thinking more along the lines of avoiding MS Exchange in favor of of Postfix/Dovecot/CalDAV even though Exchange is arguably superior at managing one’s emails and appointments.
For as much as we all hate MS Teams with a passion: It is not arguable. It is superior. And Exchange and Outlook couples well with MS Teams which gives you a corporate chat client, teleconferencing, document sharing, etc.
That hodge podge of tools? It is someone’s job to maintain that. Likely someone who is maintaining significant parts of corporate infrastructure and doesn’t have time to work through what the 55 year old waste of space refuses to even try to understand but will instantly get blamed in meetings with the c-suite if that idiot can’t figure out how to write an e-mail.