This isn't so much an open source issue as one of blind trust. People blindly trust packages and libraries without even bothering to look at the source code for them, often for things they are unqualified to improve, maintain, or to even do on their own without the library, framework, or whatever other crutches they are using.
When's the last time you included something from NPM and actually looked at the source code? Ever reject something because what NPM sent you was already minified or obscured, something that should only ever be done on your deployment? How often have you used a library to do something you are unqualified to even do directly? How often have you assumed the approach some lib or framework is doing is the best or even only way? How often have you verified the claims of a library in terms of its alleged quality with a code audit? Have you ever bothered to check that the code sent to you is the same as the one presented by the author on places like Github? (big warning flag if there's a mismatch!)
There are people who make claims they investigate the code they use, and I really have to call bullcookies on that. It's just another lame excuse to not put in the "Work" when long term it almost always ends up costing more in time, effort, and money. It's another of these cases of false simplicity where the "credit mentality" of "now, now, now" results in bloated expensive codebases that screws over everyone from the developers, to the product/site/program owners, to the end user. The entire attitude of "pay more later for something we can't afford now" is rampant across the entire industry, and is a piss poor approach to running any business. As Henry Kissinger joked 40 years ago, "America has gone from a nation of savers to a nation of debtors".
As I said in my own recent post on the topic:
hashnode.com/post/npm-and-blindly-including-libra…
It's the same broken mentality of blind trust that gave us the problems of running client-side code with too many privileges like Java, Flash, and ActiveX -- often in many cases to bypass protections being built into the browser for being things you should NEVER have been allowed access to in the first place... such as the lovely ability to quite often extract people's passwords from their clipboard.
You also -- as I said there -- we keep hearing people bragging about how this stuff "lowers the bar of entry for beginners" -- sometimes that bar is there for a reason. At least in terms of business coding we need a "you need to be this tall to ride" bar so we don't end up asked to "squeal like a pig" by ignorance and bad practices like a second rate Ned Beatty on a trip down the Cahulawassee river.
Unfortunately when it comes to ignorance and bad practices, so many of these "frameworks", "libraries", "includes", "modules", whatever name is hot and trendy for them this week, reek of them so bad, it often seems the people making them are not in fact qualified to write a single line of whatever the underlying language is.
Mind you it's nowhere near as bad on the back-end as it is on the front-end where such blindly included libraries rooted in ignorance -- such as bootstrap, jQuery, angular, react, vue, etc -- are the antithesis of good practices or competent process... but it's still there nonetheless.
Just look at the "function that broke the Internet" -- it wasn't even very well written; but endless people blindly included it and look at the havoc it wrought when its creator got into a spat with NPM and removed it. What if people had simply copied into their own code instead of blindly including it from a 'repository'?
How often does that blindly including not make allowances for sticking with the version that works for you, and instead just 'grabs the latest'? Whist sure there are mechanisms in place for when new versions change functionality in a breaking manner, how many people actually USE them? Sight few from what I've dealt with in cleaning up other people's messes.
Again, lessons many learned early on in client side are being ignored or forgotten both client and server-side. Don't blindly trust other people's codebases, don't create dependency hell, don't assume future versions will be compatible with what you've written forever, don't go to a library or framework for anything you cannot implement yourself without them.
But no, the "I want it now" screaming like a petulant five-year-old rules the industry, and nobody should be surprised when taking the sleazy shortcuts, failing to put in the work, mated to unrealtistic expectations and insanely short timelines whips around and starts biting people.
There's a reason it's called "Work" and not "Happy Happy Fun Time". As is oft attributed to Patton:
A pint of sweat will save a gallon of blood.
Every time you take one of these alleged shortcuts, you're rolling the dice. That's not development, that's gambling. More so when the effort to verify if what you're blindy including is any good is often more than just writing it from scratch.
Aka "the ultimate heresy". How dare anyone suggest writing something new specific to your task from scratch, when an off the shelf answer for a completely different question can have ten times the work and effort thrown at it to get a half-assed result that almost gets the job done.