I think the real issue here is that the blurb, on its own, is somewhat misleading: it implies that there's no support for remediating any incompatibilities that arise (which is, of course, simply not true).
dependency management problems are a thing irrespective of the license of those dependencies. nobody anywhere is writing assembly code entirely on their own, even then you depend on a compiler. every software project has dependencies. it's a problem solved by version pinning. i can't believe a tech writer wrote this?
here is the article this paragraph is from https://techcrunch.com/2018/02/05/mixpanel-passwords/
it's interesting the author decided to highlight the open source problem and not the fact that mixpanel is in the business of surveillance
that being said, that headline
*slurps your passwords*
@Gargron that's one of the companies that make the Internet a worse place and one the reasons why you need an adblocker these days, and the only thing they talk about is that their product also is buggy? That's like "big problem: the toilets on the death star are not barrier free for people in wheelchairs."
@feld @Gargron I have used it on various production systems for years so that I choose when and how to manage the complexity of upgrading a dependency instead of the dependency authors choosing. It means I can finish out some feature branch before getting into upgrade work. Or, even better, several developers on active feature branches don't all have to figure out a version upgrade just to get the project to build.
@clacke @feld @Gargron Exactly. What we need, and really don't quite have yet (in general) is a way for a person or organization to subscribe to the changelogs of the dependency-tree-assuming-you-were-to-update.
I keep thinking about building this, and what it would require. And first, uh... it would require people to keep changelogs. 😭
@skellat @clacke @feld @Gargron meh. Point taken, but you're going to have that problem no matter what, and there are relatively simple solutions to it. Mirroring the parts of the npm registry you depend on, for example.
npm also changed its policies after that so an incident like that can't happen in the future.
@Gargron that is the most ridiculous thing I've read in a while. As you point out, nobody writes software from first principles nowadays.
Also, just from a purely practical perspective, a library that's used by millions of people every day is a lot less likely to have security problems than the one your inhouse dev team will be rolling while in a crunch to meet a deadline.
@yogthos @Gargron That's insane, but I think it's possibly a misunderstanding of the kind of problem that's been seen with node/npm, where there are too many casually maintained mini-projects used as dependencies for really important things.
There's a huge difference between say using a well-established language like Python, or a framework like Rails, where you know they'll work hard not to break things; and relying on some string filter written by a 15 yo kid who changes the API at random.
@Gargron it's a bit clumsy but in a way it's right. However the real problem is software is big.
React may get security bug yes. But so could a home grown bit of code that carries out the same function.
Also you want to, if possible, have a single version of dependencies across your fleet. Who wants to solve the same problem multiple times or find out you had embedded dependencies and that bug you have patched isn't because someone embedded an ancient version of it in their own stuff