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.
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.