> But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun.
This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC money. React also deprecates APIs quite often (although they are usually the more obscure parts of the API, the widely used stuff doesn't get deprecated nearly as often).
It gets worse when you add smaller libraries who do come from "volunteers who basically do FOSS for fun" because they often have peerDependencies with the big libraries but don't get updated as the big lib deprecates stuff.
While it's valid to distinguish this from "FOSS volunteers working for fun" in a narrow sense, I hope most here recognize by now that this is a very big red flag in exactly the same way.
A highly ambitious business soliticing VC funds will not be prioritizing the stable, long tail support for the boring little users that most of us represent.
By necessity, in their best times, they'll be chasing rocket launch opportunities that may rapidly pivot strategy, and in their worst times, they'll find themselves hunting for costly efforts to prune.
The prior invites radical rearchitecture with deprecations and breaking changes, and the latter is how things just become dusty and abandoned (or -- if a backing service was involved -- wholly inoperable).
If you want your original code to hold up for 3 and 5 and 10 years with zero/light maintenance so you can focus on emerging opportunities ofyour own, rather than endless maintenance churn, (it's reasonable that you might not need this) these "SaaS businesses with VC money" need to be seen as the pied piper luring you into the dark wood.
Yeah, fair enough, you're right, a lot of the churn is created by companies who do FOSS too.
But I think the original point stands regardless of how popular the library is, or who is backing it. Just because Facebook today cares about React, doesn't mean I'd implicitly trust them to care about it for as long as I want to care about my own project, and I certainly don't trust their use cases to always match mine, and that's OK.
I think what I was trying to get across is that "npm install lib" carries a far bigger cost than most people realize, just because it gets hidden behind "our code" while in reality, as soon as you include a library/framework into your own codebase, you need to see it as "our code" immediately.
I agree with you, but I think the liability of a dependency is FAR higher if it has a peerDependency to another dependency.
For example, react-router has a peerDependency with react, therefor the liability of adding it to your project is much higher because you can have both of these scenarios:
1) Can't update react without updating react-router because react deprecated some API
2) Can't update react-router without updating react because the new version of react-router is using some new API from react
And it drives me insane that people will just add react-random-small-thing from github handle @NotGoingToMaintainThis. These kinds of small dependencies with peerDependencies to core libs are the devil.
I am not opposed to using dependencies, but your project needs to pick a few core dependencies and stick with them...
This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC money. React also deprecates APIs quite often (although they are usually the more obscure parts of the API, the widely used stuff doesn't get deprecated nearly as often).
It gets worse when you add smaller libraries who do come from "volunteers who basically do FOSS for fun" because they often have peerDependencies with the big libraries but don't get updated as the big lib deprecates stuff.