I think it is more that recent updates are used as a proxy for determining if the developer still cares about the project.

The problem is it is hard to distinguish between a project that has been abandoned, and a project that is feature complete and hasn't had any bugs reported in a while.

Although, if you assume that any software is free of bugs, and that at least some users will report bugs, if there is low activity, that suggests that either it isn't well maintained, or there isn't a critical mass of users to find and report those bugs. But then, higher quality software will require a higher number of users to hit that critical mass so it doesn't give you that much information unless you also know how good the software is.

And there is also the state of "it has all the features I need, but I'd be open to adding a new feature if someone else shows a compelling use case for it."

I guess that really depends on what it is.

The older I get, the more change-averse I become. That doesn't mean that everything is perfect and we shouldn't fix things that are broken, but it does mean I start to embrace the philosophy of "don't fix what isn't broken" more and more.

If I have something installed on my desktop / workstation that a) is not network attached and b) is not exploitable from a security point of view (least privileges, no sensitive data) c) has little risk of corrupting data and d) is unlikely to "just stop working" one day because of a systems / dependency update ... then I'm not in any hurry to update it. When I do get around to it it's probably because I'm installing a new version of Linux and so everything is getting an update. But if the old version still works, has no bugs or security risks and there's been no updates for years ... who cares?

I can think of several categories of applications that fall into this category:

- Music / mp3 player

- Classic Shell / Open Shell for Windows

- Office software, like LibreOffice. I'm sure newer versions offer some niceties but things "just work" for me. I don't see the reason to upgrade.

- Almost every game, ever (assuming it's stable and has no major usability bugs that need patching)

- Lots more

Things I do want to upgrade would be my web browser, operating system kernel, anything network attached. Really anything that could affect data integrity or security. Other than that, I'm lazy, comfortable and I don't want to risk the introduction of breaking changes.

Okay, so this is exactly what GP said. There is a difference between "not adding new features" and "not fixing bugs".

Would I be upset if the developer "fixed" these categories of bugs? Of course not. But would I avoid using the software at all if they never did?

...

"I guess that really depends on what it [the software in question] is."

It's a little silly, but I could imagine that if this become a common enough thing, people would start to trust it.

Programmers are lazy creatures.

I use a ton of tools I wrote myself and haven't had to touch in years except for the occasional dependency update.

17 hours ago: https://github.com/coreutils/coreutils/commits/master

Or let's phrase it differently: there will always be a part of the code that you do not have to touch for decades if all goes well. And if that part sits in a seperate repo, is it abandoned or just finished?

If the project already had the features you need, was thoroughly tested and debugged, and was built with almost no dependencies (only relying on a small number of very stable platform APIs), then it might not matter even if it was already abandoned when you started using it.

Case in point: On a recent software project, I took dependencies on two Lua libraries which were already abandoned. Their source code was short and readable enough that I had no problem going through it to understand how they worked. In one case, I added an important feature (support for a different type of PostgreSQL authentication to a Postgres client library). I also packaged both libraries for my Linux distro of choice and submitted them to the official package repositories. If anyone reports bugs against the version which I packaged, I'll fix them, but it seems unlikely that many bugs will ever be found.

As the OP rightly pointed out, the expectation that software libraries should normally need to be constantly updated is ridiculous. Many other things invented by humans stay in use for decades with no alterations. Beethoven's 5th symphony hasn't had any updates in more than 200 years.

I don't understand this argument. Are you saying that some things don't require updates, therefore we shouldn't expect software libraries to be updated as well? But there are also things that do require updates or maintenance. Would that invalidate the argument?

Some examples of things that need updates or maintenance: buildings, infrastructure, tools, machinery. Even immaterial things like books or laws receive updates.

And that includes the 5th Symphony too, which has different editions.

In today's world of software development, many take it as given that every software library should receive periodic updates, and that a library which has not been recently updated is in some sense "dead" and should not be used.

This is logical in cases where the domain is itself constantly changing. For example, software packages which calculate the results of income tax returns must be updated yearly, because the tax laws change. Similarly, packages which perform time zone calculations must be periodically updated, because the time zone rules change.

However, a vast number of software libraries operate in domains which are not inherently subject to change. As an arbitrary example, imagine a hypothetical library which performs symbolic differentiation and integration. Since the rules for how to integrate a function do not change, once thoroughly tested and debugged, there is no reason why such a library could not be used unaltered for decades. Yes, it might not benefit from the development of more efficient algorithms; but if the library was already more than fast enough for a certain application, that might not matter.

While software is different from other things created by humans, the existence of creative works such as books or musical compositions, which often survive for decades or centuries despite not receiving regular updates, provides an illustration of what can and should be possible for software as well. Note, this is an illustration and not an argument.

What a shame it’s been abandoned and no other musician stepped up to take over the work.

Fork it and start maintaining it with other people depending on it.

What does it matter if the developer still cares about the project?

It isn't crashing and no new features are needed. If it did then the project wouldn't be complete.

We're not talking about some early access half broken NPM package here, the blog specifically talks about a completed product.

For you it is.

But for a maintainer, reviewing and accepting a pull request can still be a lot of work, especially if the code has been stable for a long time.

Of course there will be some maintainers who are simply not interesed or unable to offer paid support (e.g. due to their employer being a control freak) but that's ok. As others have pointed out, forking / maintaining out of tree patches (and providing them to others) is not inherently hostile.

Usually I browse the issues / bug reports page and see if there are any breaking bugs that aren't getting much attention. If there are, then that's one more data point that the project might be abandoned.

1) The owners sometimes archive the project or write in the readme: complete, no more features will be accepted.

2) You can look at the number of open issues. A project with X stars/used-by/forks that hasn't been updated in 8 months and has zero open issues is probably stable.

I imagine that I am not the only one.

"Library/repository activity has little to do with usability, or quality. Some things are more or less finished and correct."

Edit: https://github.com/blaise-io/contribution

For example.. I guess that maybe gaming the system really is required if thats a 'good measure'.

Some software just does what it is supposed to and doesn't need to change, and this is OK, and I have no idea why this fact infuriates some people.

What this means is that for most software an essential part of that software consists of knowledge that needs to be kept alive. The only proof people can have of this is activity surrounding the project. This puts us in the uncomfortable position of having to designate someone as the 'keeper of all knowledge' surrounding a project if it is to be sustained, and failing to do so will result in knowledge being irrevocably lost.

If your whole entire source code is so innovative that you can't immediately understand it, there might be trouble, but so much code is or can be pretty boring.

At most, changing something will make a bug that's not really in the spec but is something everyone wants and relies on, but isn't immediately obvious, then you'll have to fix it.

The trouble is that if knowledge is lost, people will probably not bother to figure it out, and starting fresh might be more appealing.

The bigger issue especially in open source is that if there's no activity, there might not be any in the future. It could be abandoned for 10 years and perfectly fine, until a change is needed, and even if the change is easy and the knowledge is there, it might not happen if nobody cares anymore, and you'll have to fork it yourself, so maybe you choose the actively maintained thing even if it's less complete or more complex or ugly to use.

Sure, you might have the specification that the original developer was given, but every developer brings their own opinions and hard-won experience to a project. Just because the specification says "outgoing messages are sent to a queue" and the program links with ZeroMQ, doesn't tell you whether that's a design goal or a temporary stop-gap proof-of-concept. Maybe the program is structured so it can use an email queue for distributed operation. Maybe the program is designed to be linked into a larger system and just push message structs onto an in-memory vector.

I think if a project was that important, the people who needed something patched would be able to get it together even if the original maintainer went missing.

The original analogy to the challenges of knowledge transfer isn't totally applicable. Knowledge transfer is important to organizations because figuring everything out all over again would be costly, not because it would be impossible.

You certainly care about what it will do tomorrow too (so you can keep up, or avoid having it break stuff for you), but if it goes unmaintained, you don't have to worry about that since it does the job for you.

OTOH, I've been on projects where a dependency was chosen on the promise of what they will do in the future. That future never materialized, so we were left with a bunch of unfinished dependency code, maintained a bunch of components ourselves etc — it was a mess, in short. So I never rely on promises, only on what's there today.

Whatever it was originally meant to do is probably either obsolete, or well known to all users, if it's been so long the original devs left.

If it's got ZeroMQ, and has for 5 years, one can probably assume someone will be upset if it suddenly does not have ZeroMQ.

Regardless of intent, for practical purposes, if people are using it, they probably want that to stay around until you do an orderly transition to some other thing.

Reverse-engineering all that can be an utter nightmare even with tests. I suggest that people who disagree consider, for example, the word "reverse-engineer" as in how they might reverse-engineer a car.

Usually you have this kind of problem when it's NOT producing desired results and the problem is how to make it do something that's needed without affecting some set of usecases that you don't understand yet.

gn

We solve problems with code, or by finding ways to avoid writing code.

We translate vague requirements into things a computer can handle, or we translate between computer languages, because any spec that was complete would just be the program. That's why they keep us. The computers can do pure logic on their own.

Opinion is very much a part of it because pure logic is just a useless pile of text unless it has something to do with the real world, which is full of opinions.

Even inside the program itself, we aren't dealing with logic. Languages are designed for human minds, and compilers are meant to catch mistakes people make. Libraries are often chosen for all kinds of perfectly good nontechnical reasons, like "That one is actually maintained" or "Everyone already knows this" or "People seem to like this" or "That seems like it won't be a thing in 3 years".

At my company we had a real scramble to upgrade log4j when the CVE for that came out. A lot of software was many versions behind. Luckily for us, no breaking changes had been made, and it was simply a matter of bumping the version to the latest one.

That was a lucky break, because if that had been a library like Jersey or Spring it would have been an entirely different ballgame.

If you don't keep your builds up to date, you open yourself up to risks like that, which are unknown and to some extent unknowable.

Dependecies and external APIs change so software breaks.

An example from a project of a customer today: Ruby had a Queue class up to 3.0.2. For some reason they moved it to Thread::Queue since 3.1.0. It's only a name change but it's still one release to do.

I'm not sure what flags you are referring to, but that might be because I went from 8 to 11 and skipped 9 and 10.

> the changes of which only broke code using non-public API surface

The APIs weren't non-public. They were publicly documented. They did say they were internal and you should avoid them, but they were still used in libraries and referenced in tutorials and stack overflow answers. And if you happened to transitively use a library that used one of those APIs, it would cause a fair amount of pain when you upgraded.

Ultimately, the break seems to have been intentional, but did receive appropriate consideration. Mark’s comments about moving forward do address these points.

I do think as a general heuristic no updates for 3 months means it’s been at least 2 months since anyone paid attention to outstanding bugs, especially the npm ecosystem.

I'm not saying that because of the leftpad fiasco, I mean that any library that small should simply be pasted into your codebase because the risk of managing the dependency outweighs the benefits.

If I see a library which is supposed to solve a simple problem but it requires a large number of dependencies to do it, that's a big red flag which indicates to me that the developer who wrote it is not good enough to have their code included in my project - I don't care how popular that library is.

Node libraries are a bit odd in that respect because package JSON files have an "engines" property that informs users about the minimum and maximum Node version the library works with. The author of leftpad could check its compatibility with each new version of Node that's released, and update the engines value version accordingly. That would be quite helpful because abandoned libraries that aren't known to be working with newer Node versions don't get updated, and users can user that information to look for something else.

What that means is that any Node library that isn't being updated as often as Node itself is probably not actively maintained, or the author isn't making full use of Node's feature set.

Really? This sounds feasible at all for you for all the millions libraries in npm not to be labelled as "obsolete"? Checking if string concatenation still works on every major node release and tagging it as such?

Yes. I mean, they could just leave the max version of the engines property blank because it should always work if it's something as trivial as leftpad, but in a well-run package repository the work of checking library compatibility should be getting done. The fact that NPM is full of old libraries that haven't been tested in new versions of Node is a bad thing, and those libraries should be flagged as untested.

I think there’s a useful lesson there.

I check for things like over-engineering and I check out the author (check their other libraries if there are any).

"Do one thing and do it well" - the unix philosophy, and why I still use cd, ls (dir on windows) today.

If a project exceeds two functions its probably doomed to become either redundant or broken.

If a project does one thing well, even if something else uses it, you can always decompose to it (your software is always useful, even when somebody writes the fancy bells and whistles version).

SQLite seems to hit a good balance. There's always something new but nothing particularly breaking (from my light usage POV), so it looks live.

The author chimes in, says he’ll take a look next evening, then two years whoosh by.

There is an ambitious todo and nothing moves.

The code is in alpha for years, considered unstable, huge exclamation points in the readme that it should not be used, and yet somehow there are hundreds of reverse dependencies and it’s like this for years (usually should mean “RUN!!!”). Sometimes sneaky as it’s not a direct dependency for you, but for those two or three libraries used by like 80% of the ecosystem.

We do announce when there is a user-visible and significant issue or update, but that's quite rare, maybe once every 6 months or more.

It’s not a common use-case, I guess, but I had some old projects that I abandoned and wanted to try working on them again and found it almost impossible. The worst cases had dependencies which weren’t available unless I used an x86 laptop with an older version of Mac, because the packages were never built for arm laptops.

In regards to the second case, bet that's Python with the wheels situation, where it doesn't fallback to building from source by default for some reason (instead throwing a super obtuse error), at least with Poetry.

Also, not many people (especially me included) are able to write something that's perfect first time. In an ideal world, other developers would be testing and challenging what's been written; which would meant the product or library needs updating.

I think it's (perhaps ideally) likely, that at least one of these factors is relevant.

I don't know if this is a good suggestion or not but I wonder if some form of "keepalive commit" might help here. I can imagine a few ways they might work, some simple, some more elaborate.

This expectation that things need to be committed to or updated every month has to stop, we're just wasting time and energy on stuff that is already fixed (unless there are security issues, of course).

Maybe GitHub needs to automatically include an UPDATES.md into each page, I dunno.

You might not care too much, and it clearly depends on the application, but for me updating a software that doesn't use anymore a library for getting user input that leads to a buffer overflow if you insert a certain character, or similar things (like remote code execution, etc.), can be quite important. Finally, apps are most of the time connected to the Internet, which makes them inherently vulnerable.

After searching "android software libraries CVEs" I found this in the first results' page: https://github.com/dotanuki-labs/android-oss-cves-research

It might be outdated, but the principle still applies.

It's very unlikely that your application is self-sufficient and doesn't need updates.

EDIT: I read the message from Apple as a "hopeful" attempt to say "come on, man at least update the dependencies".

What security ? "Google security" where everyone except the user has access to his data ? Why does a note taking app needs internet to function ? Why does my phone app need access to internet ?

> The expectation that software libraries or frameworks should break every few months is disturbing.

As a library user, it's hard to find a good balance between fully trusting a system to stay alive for a while without maintenance, while being super paranoid about every aspect I rely on. Mentally it's easier to expect it to break every now and then, than to keep thinking "it's probably fine, but I still need to be defensive about stuff that never happen".

I think the issue on a library being "alive" or not is best mitigated by the users being comfortable to fix it if it broke under their use case. There's libraries I thought were completely dead but were a good shortcut to where we wanted to go, and we expected to extend it here and there anyway. That can't work for everything (thinking of security libs in particular, I wouldn't want to touch them) but it's to me the ideal situation, with no undue stress on the lib maintainer as well.

According to the OP, it is also due to companies controlling mobile OS such as Apple.

One of the things I like about non-corporate open source OS like NetBSD is I can run old userland utilities with new kernels without any problems.

What do you mean by this?