And they live is some delusion that this creaking garbage pile of mummified, unmaintained, full-of-known-vulns old versions they are building on are "stable".
And they live is some delusion that this creaking garbage pile of mummified, unmaintained, full-of-known-vulns old versions they are building on are "stable".
2 - Not everyone who has the bandwidth to write something also has the bandwidth to rewrite very often just to keep using the latest and greatest APIs
A: Hey, let's build this cool graphical UI and add lots of features to our car.
B: And the cost of maintaining that OS, libs, dependencies for the next 15 years will be paid by whom, exactly?
A: Naw, we'll support for one year only. Maybe two.
B: And when there is a software vuln found in a 10 year old version that would allow an attacker to disable the steering and breaks while the car is moving, you wont issue a recall?
A: recall? This is software! Everything is provided without warranty or fitness of use, haven't you read the EULA? It's in ALL CAPS
You're making some big assumptions about the motivations of the upstream developers there.
For example, maybe the upstream developers make a useful library and sell it in some form to downstream developers who find it valuable enough to pay. Clearly your upstream developers have motivation in this case, and that motivation is to provide what the downstream developers actually need and will be willing to pay for.
As another example, maybe the upstream developers provide some platform that is how they make their money, and they offer a useful library that enables downstream developers to write software that runs on the their platform. Again, the upstream developers are motivated to provide what the downstream developers actually need.
If the upstream developers are relying on more social motivations, as in parts of the FOSS community for example, then you have a totally different set of incentives. Relying on libraries maintained by developers with those incentives might not be appropriate for downstream projects that require stability and longevity.
The article is saying pin stuff for as long as possible, like the guy replying here who says the version of the logging tool he integrated one time 10 years ago is all he will ever want.
Paid-for or FOSS, after his initial interaction 10 years ago, he is not going to *pay*, encourage, support, find bugs in or send patches to the upstreams. And that's the vast majority of users, me too when I look at the projects I uses and never contribute to.
> Relying on libraries maintained by developers with those incentives might not be appropriate for downstream projects that require stability and longevity.
That's a particularly sniffy approach to FOSS. You would have walked away from the now-dying Xorg back in the day? Gcc?
If people don't contribute to the things they are dependent on, there is no reason to expect them to still be around when they do want more from them.
From the FOSS project perspective these users do not directly manifest themselves in any useful way at all.
FOSS is great. A lot of people have contributed a lot of value to society through making code they wrote freely available. The world is a better place for it, and I appreciate their efforts when something they've made helps me.
None of that means it's a smart decision to build something important on a foundation that is likely to shift under you later.
If people don't contribute to the things they are dependent on, there is no reason to expect them to still be around when they do want more from them.
If you're relying on something where the developers' incentives are primarily about personal satisfaction and it's only a small team or solo developer then you have little reason to assume they will still be around anyway.
Unless some software has become big enough to be an established community project or someone is developing it professionally, relying on it as a long-term dependency might be unwise. More specifically, either it already does what you need (or you're confident you can patch it to do so yourself), or it might need ongoing development but you have confidence in the support/maintenance model behind it, or you're taking a risk by relying on it.
> I don't care about your issues in the way you care about them, this lib does what my customers need it to and I'm happy about that. When it stops doing what my customers need, then I'll up it (read: probably never).
Its a discord. I don't think either party is wrong or either party is entirely right. They just have competing interests.