The point of this is that you can't treat proprietary software dependencies the same way you treat FOSS. Community FOSS projects just don't have the same development process and governance model that proprietary software does. And so, the assessment of these projects is necessarily different.

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.

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.

Honestly I’m embarrassed at how revelatory this line is.

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.

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.

except that a lot of proprietary software doesn't has anything like that either

there is nothing in common proprietary dev practices which would have e.g. prevented log4j

the main difference is that you can hold someone financially responsible in one case and not in the other (but in turn you can always fix any problem yourself, good luck fixing any proprietary software after it's support runs out).

The federal government has rules regarding the acquisition of software products, and they have various governance and risk management requirements for various scenarios. Many of these were designed with proprietary software in mind.

The point of this bill is to update some of those requirements to make sense with the way OSS works.

The root comment suggested that somehow this was a smear on FOSS, intended to sell more proprietary software. However, this doesn’t hold up, because FOSS components are widely used by all of the big proprietary software vendors in this space too.