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.
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.