The article says Redis is the latest one to pull this shit. Well, today the Linux foundation announced Valkey. If I ran Redis in production I’d go all hands to switch today.
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.
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.
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.
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.
Microsoft released Garnet last week. Which is meant to be a drop in replacement with 10x the performance, written entirely in C# (incredibly accessable vs C++).
MIT licence, like most of the rest of their tools/libs/frameworks.
Nice part here is that they dog food it, since it’s used at scale. So problems tend to get patched quickly by paid devs, while the FOSS community gets to bake in the features they want.
What do you mean by C# is “accessable” vs C++? Do you mean it as readability? Or the software availability (compiler, and the tooling behind the language)?
I disagree, but not to be combative. C++ maybe but C not so much. Even with a good teacher assembly isn’t as accessible as C, neither is machine more than assembly. There is a scale and even with a great teacher C, while an awesome language, is going to take more work. Debatable I guess and nothing wrong with starting with C; quite the opposite, but up-to-speed time will be a bit higher in my view.
Assembly sure, since it will differ from ISA to ISA. But C is still a “high” level language in the sense that you can write once run “anywhere”. Also, more work to do something is expected since C is such a “bare” language to simplify. But again, it doesn’t count as it not being as accessible to get new developers started, but it is and will be more cumbersome to work with (in the context of redis like software).
So yeah, maybe it depends on how you would define accessible is. I think if it is defined as just “how easy it is to get started and understand how it works, and how to work with it”, C and C++ is quite accessible with a good teacher/mentor. The teacher/mentor is important in C and C++ because unlike C# which has Microsoft as its main authoritative source and the big influencer in the language, C and C++ doesn’t have those so the resource on learning it can vary wildly.
I guess the main problem here is using a very imprecise word with arbitrary meaning, “accessible”, that may mean something different to each of us. All I’m saying is there is a continuum of some sort, and along it first is C, then C++, then C++ ++.
I think C is way more accessible than C++. It’s such a simple language that there are only so many footguns. C++, on the other hand, is a behemoth, and there are so many different opinions on “the right way” that it can be quite confusing. And with C++, you get all the baggage of C, and a bunch more.
With C#, you don’t need to worry about memory as much, virtual tables are more sane, templates are more sane, etc. Basically, C# is what happens when someone adds a GC to C++ and cleans house. It’s still complex, but there are far fewer footguns and a vibrant community. The C++ community is large, but I wouldn’t call it “vibrant.”
It’s a high level memory managed language. Usually this by itself means it’s an accessible language.
Combine that with .Net being one of the better if not the best standard libraries/frameworks out there, and it being one of the top five most popular languages in the world, means it’s highly accessible to new and experienced programmers.
Yup, I’ll be bringing it up with our devOPs team so they can start looking into security implications and whatnot. I might even switch our dev env to that, just to test it out.
The article says Redis is the latest one to pull this shit. Well, today the Linux foundation announced Valkey. If I ran Redis in production I’d go all hands to switch today.
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.
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.
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!”
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.
Microsoft released Garnet last week. Which is meant to be a drop in replacement with 10x the performance, written entirely in C# (incredibly accessable vs C++).
MIT licence, like most of the rest of their tools/libs/frameworks.
Nice part here is that they dog food it, since it’s used at scale. So problems tend to get patched quickly by paid devs, while the FOSS community gets to bake in the features they want.
What do you mean by C# is “accessable” vs C++? Do you mean it as readability? Or the software availability (compiler, and the tooling behind the language)?
Accessible to new developers. As in, easy to pick up and code with.
That really depends on the teacher/mentor. C and C++ can be just as accessible. For someone who is learning by themselves however, I agree.
I disagree, but not to be combative. C++ maybe but C not so much. Even with a good teacher assembly isn’t as accessible as C, neither is machine more than assembly. There is a scale and even with a great teacher C, while an awesome language, is going to take more work. Debatable I guess and nothing wrong with starting with C; quite the opposite, but up-to-speed time will be a bit higher in my view.
Assembly sure, since it will differ from ISA to ISA. But C is still a “high” level language in the sense that you can write once run “anywhere”. Also, more work to do something is expected since C is such a “bare” language to simplify. But again, it doesn’t count as it not being as accessible to get new developers started, but it is and will be more cumbersome to work with (in the context of redis like software).
So yeah, maybe it depends on how you would define accessible is. I think if it is defined as just “how easy it is to get started and understand how it works, and how to work with it”, C and C++ is quite accessible with a good teacher/mentor. The teacher/mentor is important in C and C++ because unlike C# which has Microsoft as its main authoritative source and the big influencer in the language, C and C++ doesn’t have those so the resource on learning it can vary wildly.
I guess the main problem here is using a very imprecise word with arbitrary meaning, “accessible”, that may mean something different to each of us. All I’m saying is there is a continuum of some sort, and along it first is C, then C++, then C++ ++.
I think C is way more accessible than C++. It’s such a simple language that there are only so many footguns. C++, on the other hand, is a behemoth, and there are so many different opinions on “the right way” that it can be quite confusing. And with C++, you get all the baggage of C, and a bunch more.
With C#, you don’t need to worry about memory as much, virtual tables are more sane, templates are more sane, etc. Basically, C# is what happens when someone adds a GC to C++ and cleans house. It’s still complex, but there are far fewer footguns and a vibrant community. The C++ community is large, but I wouldn’t call it “vibrant.”
It’s a high level memory managed language. Usually this by itself means it’s an accessible language.
Combine that with .Net being one of the better if not the best standard libraries/frameworks out there, and it being one of the top five most popular languages in the world, means it’s highly accessible to new and experienced programmers.
Yup, I’ll be bringing it up with our devOPs team so they can start looking into security implications and whatnot. I might even switch our dev env to that, just to test it out.