4 ms·

Downstream projects that only consume old versions of upstreams projects are deadweights to the upstream. They don't encourage, support, find bugs in, or send

Downstream projects that only consume old versions of upstreams projects are deadweights to the upstream. They don't encourage, support, find bugs in, or send patches to the upstreams. 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".

jimbob45 6y ago
We use a decade+ old version of log4net. It suits us just fine and I’m not even sure “vulns” are something we would need to care about in debug logging software.
- cmckn 6y ago
  I think “vulnerabilities” are always worth thinking through like this. If a YAML library you only use to read in a config file at startup has some buffer overflow bug...who cares? It’s usually painless to just bump the version, but just because a bug was fixed doesn’t mean you’re now insecure.
- bryanrasmussen 6y ago
  It certainly doesn't look like there are a lot of problems https://www.cvedetails.com/product/7281/Apache-Log4net.html?vendor_id=45 https://www.cvedetails.com/product/7281/Apache-Log4net.html?...
steelbrain 6y ago
1 - Never versions are not always more secure or more 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
Quarrelsome 6y ago
so says the library publisher. The product publisher says in counter: > 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.
cmckn 6y ago
I think the point is that the build is “stable” not that the dependency is. The last thing I want when I’m implementing a feature is to have to deal with some unwanted, unrelated API change because a dependency was updated.
rsj_hn 6y ago
It's always an issue of externalizing costs. Everyone wants to do what benefits them in the short term, and have the environment maintained and supported by someone else. 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
Silhouette 6y ago
Downstream projects that only consume old versions of upstreams projects are deadweights to the upstream. They don't encourage, support, find bugs in, or send patches to the upstreams. 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.
- outsomnia 6y ago
  > 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. 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.
  - 6y ago

Downstream projects that only consume old versions of upstreams projects are deadweights to the upstream. They don't encourage, support, find bugs in, or send patches to the upstreams. 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".

jimbob45 6y ago

We use a decade+ old version of log4net. It suits us just fine and I’m not even sure “vulns” are something we would need to care about in debug logging software.

cmckn 6y ago
I think “vulnerabilities” are always worth thinking through like this. If a YAML library you only use to read in a config file at startup has some buffer overflow bug...who cares? It’s usually painless to just bump the version, but just because a bug was fixed doesn’t mean you’re now insecure.
bryanrasmussen 6y ago
It certainly doesn't look like there are a lot of problems https://www.cvedetails.com/product/7281/Apache-Log4net.html?vendor_id=45 https://www.cvedetails.com/product/7281/Apache-Log4net.html?...

steelbrain 6y ago

1 - Never versions are not always more secure or more 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

Quarrelsome 6y ago

so says the library publisher. The product publisher says in counter: > 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.

cmckn 6y ago

I think the point is that the build is “stable” not that the dependency is. The last thing I want when I’m implementing a feature is to have to deal with some unwanted, unrelated API change because a dependency was updated.

rsj_hn 6y ago

It's always an issue of externalizing costs. Everyone wants to do what benefits them in the short term, and have the environment maintained and supported by someone else. 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

Silhouette 6y ago

Downstream projects that only consume old versions of upstreams projects are deadweights to the upstream. They don't encourage, support, find bugs in, or send patches to the upstreams. 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.

outsomnia 6y ago
> 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. 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.
- 6y ago