5 ms·
Respectfully, you have a too-reasonable hunch of how decisions are made at the executive level, and because of that, you're reaching an incorrect conclusion. T
by peteforde 4y ago
Respectfully, you have a too-reasonable hunch of how decisions are made at the executive level, and because of that, you're reaching an incorrect conclusion.
The primary factor driving the decision making process is not cost but risk.
Many fail to remember the lengths to which companies like Microsoft, Oracle, Sun and others went to create FUD around the adoption of OSS in the public sector. It involved lobbyists, marketing campaigns and a whole certifications industry.
When a CIO selects a technology, they aren't just weighing its merits and price tag; they are actively looking to leave a glowing legacy while actively doing everything they can to avoid being humiliated if the technology fails. See, the CIO knows that, as far as their board of directors is concerns, it's not the software that failed but the executive.
That's why enterprise support packages exist; it's an insurance policy and a promise that if something goes terribly wrong at 2am, someone is going to pick up the phone when you call.
Companies with expensive tools have an obvious interest in convincing their best customers that the competition in inherently risky.
- deleted 4y ago[deleted]
- Forgeties79 4y ago>Companies with expensive tools have an obvious interest in convincing their best customers that the competition is inherently risky Honestly I’m embarrassed at how revelatory this line is.
- kube-system 4y agoGovernment contractors expensive tools are already heavily using open source tools. The whole log4j scandal that this bill is in response to is perfect evidence of exactly that. It is not in the interest of 'proprietary' software vendors to fearmonger about OSS libraries. They too use OSS libraries just like everyone else does today. It isn't 1995 anymore where a proprietary piece of software can run on a full stack of code written by the people who work locked away in a single building at one company. Everyone is using open source dependencies. There is nobody left that would benefit by demonizing open source libraries.
- leaflets2 4y agoIt's not OSS libraries they'd be worried about, as competitors, but OSS applications, I d think.
- kube-system 4y agoThis bill is in response to a recent issue with an OSS library: log4j.
- leaflets2 4y agoMaybe. At least that's what they want you to think
- origin_path 4y ago"Companies with expensive tools have an obvious interest in convincing their best customers that the competition in inherently risky." The problem is that they don't need to do this. In the open source community we're doing a great job all by ourselves. I've written open source libraries and platforms, I've also written proprietary software that uses open source. Log4j, Heartbleed, half of NPM etc weren't the work of Oracle lobbyists, they were avoidable fuckups caused by everyone relying on critical infrastructure that wasn't really maintained. I'd actually go further and say you overestimate the power of lobbying and underestimate the possibility of lobbyist's having a point. The primary argument these firms made against relying on OSS was that it's often just a bunch of random people with no incentive to do the un-fun work like security audits or patch backports. There's nobody who takes responsibility for things. That's true and is pretty much the core of Red Hat's business model so it's not like anyone can really dispute this. The software industry does need new approaches to how we use open source stuff, IMO. Sandboxing of libraries would go a long way. But we can't just pretend there's no problem here and it's all the work of shadowy corporations, it's naive ideological stuff.
- mistrial9 4y ago> they were avoidable fuckups caused by everyone relying on critical infrastructure that wasn't really maintained uhh rewriting history much? the reason the entire world uses openssl is because it operates correctly. The judgement here is diluted by exaggerating the worst moments of an otherwise profoundly performant ecosystem. btw- I turned my outward facing servers off for three days for Heartbleed, so .. how to balance a serious development, with the growth of billions of devices working correctly each day for years to get here. In a previous life I did work on internal proprietary C/C++ code bases and yes, there were ridiculous technical debts, bugs, and missed opportunities right along with correct code, insights reduced to code, and solving hard problems well.