For open source code, I think the concern is practical: bit rot is real, and libraries with no recent updates are more likely to have suffered bit rot. It's not that a library can't be finished, but that the world in which it lives never stops moving. It can be a bigger or smaller problem depending on the ecosystem. Old C89 libraries have a good chance of still working, because the ecosystem isn't moving so much any more. Old C# libraries almost definitely don't, because the ecosystem is moving quickly.

Bits don't rot--vendors break things. If my code built with yesterday's SDK and ran on yesterday's OS, and it doesn't for today's, that's not some supernatural phenomenon where digital media rots away--let's clearly blame who's causing it: SDK and OS vendors making changes that break backward compatibility and dump the maintenance burden on developers. The term "bit rot" is an attempt to shift the blame away from those who are causing the rot in the first place.

Whether or not it's good to have a moving ecosystem is another story, but I request we not use the term "bit rot" when we mean "vendors breaking compatibility."

Perhaps the solution is a monthly "NOOP" release?

I would assume a noop is automated, and the library is no longer maintained.

If, however, I saw a statement at the top of the README that said:

"Update as of 2 months ago: We believe this project to be complete. We are not adding new features at this time, but if you see any issues, please open a ticket, as this project is still under active development as needed"

then I would feel very confident.

Thanks, that's a good point.

maybe commit to a log indicating that the test suite has run correctly as of <today's date>?this assumes you have a useful test suite but also at least indicates that you're still paying attention & trying to ensure your library works

quid custos ipsos custodiet still applies. The fact that your test suite ran in Esolang v27.8 successfully doesn't mean what you-the-consumer want it to mean if the last supported version of Esolang is v96.2. It just means someone down-stack of you is committed to backwards compatibility.

That future version won’t be on the supported versions list anyway.

I think this varies by project.

I personally support every version of my projects.

My goal is not to minimize the effort to myself but to facilitate the use of my software.

I meant the new version of Esolang, v96.2, wouldn’t be explicitly supported by your project.

Ah, also a good point.

Great idea!

Agreed but this definitely isn’t in the interest of library maintainers. If they did so it’d mean they are acknowledging all the currently open issues and deciding to do nothing, which would sometimes cause backlash.

I mean most projects just auto close all issues now. Dunno where this desire to have 0 open issues came from. Seems like in the past projects would mark the issue as unconfirmed and ignore it, now they all want to close the thread and not allow further comments. Almost as if someone is going to judge their open source project negatively for having open issues, which if that has ever happened that person is more insane than the devs practicing this.

Other game platforms (game consoles, Windows) seem to have drastically better backward compatibility and API stability.

If you look at the Nintendo DS/3DS (for example), the platform had many hardware revisions (about every other year) and dozens of firmware revisions, yet games from 2004 still worked on a brand new 3DS in 2020.

On the Sony side, PS4 games from 2013 still work fine on a PS5 in 2022 (and probably through 2029.)

Steam has tons of old games that work great on Windows (but the Mac side took a major hit with macOS Catalina's 32-bit apocalypse.)

The 3DS physically included most parts of a DS, that often went unused in "normal" operations.

In my experience old games often work better in proton/wine than in Win 11.

My understanding is that the Steam Runtime also provides a stable base, that (or something close to it) unfortunately wasn't adopted in other ecosystems. Flatpak is great, but not used widely used for binaries yet.

And Playstation is way behind Xbox when it comes to backwards compatibility. Xbox backwards compatibility goes all the way back to the original Xbox released in 2001.

A PHP library I use and used to help maintain had a bit of a fight break out in the Issues on GitHub a couple weeks ago.

They were dropping support for older versions of PHP despite getting nothing from it and using none of the newer features. Just needlessly limiting the audience, and churn for churns sake.

I am reminded of the libressl - 30 days in report. https://youtu.be/oM6S7FEUfkU?t=1073

Removing support for old versions is a simplification of what needs to be considered. It is a reduction of complexity. If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library - even if new features that weren't available in the EOL'ed version haven't been added yet.

> If someone is running a PHP version that has been EOLed, it is perfectly reasonable to discontinue support for it in a library

Its not. Large Linux distributions support those PHP versions for a long time in their LTS releases, and majority of web hosts and infra providers use those distros in their infra.

So what version of PHP are we talking about? https://www.php.net/supported-versions.php and https://www.php.net/eol.php

That some provider is still hosting old EOL'ed and no longer supported versions shouldn't prevent a library author from saying "I'm not going to deal with something that had its last release nearly 4 years ago."

7.4 is supported on focal until 2025 for example. Centos has its own LTS and supported versions and so on.

> That some provider is still hosting old EOL'ed and no longer supported versions shouldn't prevent a library author from saying

Yes it should. Its not 'some' provider. Its providerS. A gigantic part of the web lives on such large hosts. AWS and similar ecosystems constitute a small part of the web. This is not saying that the former is low traffic but large in size compared to AWS et al. There is similar traffic and user activity going on in both ecosystems.

You can easily 'deprecate' something and spend millions of dollars man-hours in upgrading your stack as a larger startup which uses AWS. But millions of small businesses, individuals who rely on Open Source software and such hosting providers won't have the money or time to jump through such upgrade hoops 'just because'. It is 'just because' for the simple fact that a lot of such version hops we do in Open Source software development do not bring much to the end users. And they will not appreciate their businesses getting hampered trying to go through upgrade hoops which they have never asked for.

An alternate approach to this is saying 'f*k you' to those people and doing Open Source for the sake of software development itself, without caring about end users. That would also work - but only for those who develop Open Source and who have the time to keep it updated. The general public would just move on from Open Source and start using reliable private service providers that don't break their businesses every other year.

How much effort should a library maintainer expend to keep 5.x code in place?

Is it worth it for a library maintainer to remove support for 5.x even if they don't replace it with code that makes use of 7.x functionality?

If a site is still running 5.x (stats put it at about 20% of the sites out there are still running these versions https://w3techs.com/technologies/details/pl-php/5 ), are they going to be updating to the latest versions of libraries?

Note that the FOSS approach to "but it doesn't support the old version that I'm running" has been "don't upgrade or fork it and maintain it yourself." It's the flip side of https://boyter.org/posts/the-three-f-s-of-open-source/ ( https://news.ycombinator.com/item?id=32591265 ).

I'm experiencing this myself with Spring Framework 6 targeting Java 17 as a minimum version even though Java 8 LTS continues through at least 2030.

> How much effort should a library maintainer expend to keep 5.x code in place?

Based on the usage of the version and the support for it in large hosting/infra providers.

> Is it worth it for a library maintainer to remove support for 5.x even if they don't replace it with code that makes use of 7.x functionality?

Breaking backwards compatibility is practically always bad. You do it once. You do it twice. By the third time it does not matter because a large part of your users would have moved on to some other stack by the second time.

> If a site is still running 5.x (stats put it at about 20% of the sites out there are still running these versions https://w3techs.com/technologies/details/pl-php/5 ), are they going to be updating to the latest versions of libraries?

These must be seen as ecosystems. The ecosystem would slowly move to a higher version over the span of 2-3 years starting from the point when a version starts nearing its EOL. And the users upgrade slowly on their end.

> https://boyter.org/posts/the-three-f-s-of-open-source/

Using the same language in the article: The users would say one single F word to such a project, without the project maintainers ever hearing about it, and silently move on to some project that is not so self-indulgent and so irreverent towards its users. Nobody has the time to jump through hoops to keep their business running on Open SOurce, less suffer such arrogant sh*t.

Such an attidude is only workable if the project is a hobby one, does not aim to gather ANY kind of community/userbase, does not aim to do any impact.

> I'm experiencing this myself with Spring Framework 6 targeting Java 17 as a minimum version even though Java 8 LTS continues through at least 2030.

I would recommend that you prioritize your users and backwards compatibility in that order. The moment your users start trusting your project that it will not break their software, they will start upgrading easily and adoption and retention will get boosted.

JSON API spec's 'only add, never deprecate' approach is the holy grail to chase:

https://jsonapi.org/format/

> New versions of JSON:API will always be backwards compatible using a never remove, only add strategy. Additions can be proposed in our discussion forum.

I hear you and I get what you're saying. However, to argue the other side, maybe it's a decision based on the possibility of long maintenance going forward. Keeping track of, in your example, PHP and all of its various versions is mentally daunting. What's wrong with a project just saying, "Hey look, we're not saying it won't work for you, but if you're running these older versions, we just don't give you any guarantees that it does. YMMV."

e.g. say a bug comes up in the library, and say that it only affects older versions of PHP. Why can't the project just shrug its shoulders and be truthful that it doesn't have interest in maintenance/support against those old versions? It's better that the project declares this intention now, before the bug comes up, then later having to part ways with the old versions more abruptly.

This is why OSS is great, as you can decide if, at the time said bug is found, that you want to provide legacy support for older PHP versions, maybe through a fork or other means. Have at it, it's your software too.

> feature complete with no bugs

I suppose for simple libraries this might be possible (e.g. left-pad) but how would you know in general that something is bug-free? `units` was introduced in 1979 and is still one of the canonical examples used in automated program repair research to show that new bugs can be found even in extremely well-studied codebases.

I think people might be:

1. Implicitly assuming that all nontrivial code has bugs, and 2. Using recent commits as a signal that means, "If I ran into a bug, there is someone who might fix it (or at least accept a fix PR) to take away my immediate pain.

I've never used or heard of the left-pad library, but I'm willing to bet that I could find an RTL bug in a library with that name.

That reminds me of the overflow bug in the JDK binary search that was present for quite a while.

The Elixir ecosystem is quite good for this. I've found smaller libraries that haven't been update in a long time but still work just fine since Elixir itself hardly ever changes in a breaking way (the recurring phrase in the community being: "There will probably never be a version 2"). It's weird to get used to at first but it's actually quite refreshing.

I used an Erlang library in my Elixir project a while back that hadn't had an update in a decade. If a language's semantics don't change (and they really, really shouldn't change without either A) a very good reason or B) a really, really good backwards compatibility story) then there's really no reason for a library that does a job well to ever update.

About open source lib not being updated :

The thing is, even if the lib is "feature complete", it's pretty rare to not have to update anything, since the ecosystem in which this lib evolves will undoubtely have changed. Programming language, hardware, OS, etc. everything evolves all the time.

This is only true if the ecosystem doesn’t care about compatibility, so this is just a symptom of a deeper issue. Say what you will about Wintel, but the long-term compatibility of x86 and Windows still lets me run a lot of win32 applications written two decades ago without issues.

I bet that if I moved back to Windows, KatMouse would work just as well as ever—and it was already nearly a decade out-of-date when I stopped being a daily Windows user.

Theres a good chance the documentation could say things in a better way…

Security threats also evolve all the time. A library that hasn't been updated in months is very likely an insecure library.

I use an ancient library to perform some math. It's been working just fine for more than 10 years without any need for update. Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation.

I think what you are saying is simply FUD when taken as a blanket statement.

> I use an ancient library to perform some math.

Anyone can cherry-pick examples to try to disprove a security principle. A pure, functional math library isn't representative of the vast, vast majority of libraries that are imported every day.

The most-used libraries across languages are for things like database access, logging, package management, HTTP, and (de)serialization. All of those things need to be kept updated for security.

> Can someone explain why is it insecure and what updates are needed to complex algos to make them so? When looking at the code it is pure computation.

You didn't specify the language or library.

Most libraries that people import are going to be JS, just because of the number of JS users and the minimal standard library in that language. Many are also going to operate on user input, which means they can have vulnerabilities.

The mathjs package in NPM, for example, has had tons of vulnerabilities[1].

1. https://security.snyk.io/package/npm/mathjs

C++ Library, forgot the name, need to look.

NPM system is security abomination I agree. But I am not using it. I look at things from my own perspective. If 90% of the world programmers are bound to NPM ecosystem (doubt it) it is their problem. Not mine. I do not "import" half of the Internet for my "hello worlds".

Are you passing user input into it? Does it interact with anything on the system? Poorly sanitized inputs present a very serious risk for RCE vulnerabilities.

As already said it is pure computational lib. It does not interact with anything and I use it from my code. There are tons of libraries like this. They work just fine, do not pose a security risk and have no need for update.

But thanks for trying anyways.

Updates may be a security threat too… didn’t log4j become a security treat _because_ it had been updated?

Imagine TeX becoming unavailable because Knuth didn’t update it for three years.

From the Tex Tuneup of 2021: "The TEX family of programs seems to be nice and healthy as it continues to approach perfection. Chances are nil that any documents produced by previous versions of TEX or METAFONT will be affected by the changes in the new versions"

This is how the Gods do programming :)

I mean a heartbeat is needed sometimes to make sure something is still alive and can address critical issues if they do happen. But I do agree that libraries and apps don't need to "update" to show that.

Maybe some other way like "Hey, we're still here just the thing we're working on doesn't need an update" would suffice for most things.

By "the world" I think you mean a specific subset of people: investors/execs/the business side. I don't particularly believe that average end users or competent engineers feel that way...

In fact, average end users infamously don't voluntarily update things that aren't visibly broken.

I would love to see this theoretical world in which libraries have no bugs.

Thing is, even if there are no known bugs, having rare updates means if I do find a new bug it’s less likely to get addressed quickly.

I'm not sure I follow your logic. If you find a bug, wouldn't that provide a reason for updating your code? What is the utility of issuing superfluous updates when you don't have any new known bugs to fix? How does doing that shift your likelihood of fixing bugs when they are found, in any direction?

I like that so many unix command tools (like cat, ls...) is rarely updated. Often comes with a man page written in 30 years ago. Same with a lot of C libraries.

If a library is not updated in some capacity "recently" (coming from the Java land, "recent" is a different timescale than Javascript), then I have little confidence that a security issue can be resolved if discovered. Even if a library is complete, it may depend on libraries downstream that do have security issues that are no longer supported, which means it needs to swap to newer versions, etc.

One word: security updates. Ok that was two. Most software had dependencies, those tend to surface vulnerabilities over time.

Everything you use continuously improves. What do you use that has seen improved versions since you bought it?

Our knowledge, our abilities, our raw materials continuously improve, and everything is expected to advantage of this. Things that don't improve, are soon outdated and fall behind.

Everything continuously improves: cars, bicycles, windows, houses, refridgerators, tv, etc, etc.

s/improves/churns/g

We reached the peak of software usability a long time ago, probably around the turn of the century. Now it's all about trendchasing, change for the sake of change, dark patterns to squeeze the $$$ out of you, etc.

I think there's still room for real improvement: once we have afforable displays that cover your entire wall, imagine what something like miro could bring you. Visual collaboration, pen drawings that turn into organizated information, architecture diagrams that can be turned into low-code models and running software, all whilst collaborating with others all over the world in front of their digital display walls.

Last 2 years, the thing i miss most about working in the office, is the ability to collaborate with co-workers in front of a huge whiteboard. The brainstorming, ideation. Miro is nice, but it deserves a huge screen, it needs more interaction with your co-workers, and it needs to help you take your drawings into real value (running software, designs that can be fed into 3d printers, cnc machines, etc).