Well, does that mean "i will never touch this again" or "I won't add any new features, but I will fix bugs"? If the former, I probably don't want to use it. If the latter, I might consider it, depending on what it does, and if it has the features I need, but then, again, how do I know if they are still watching it since they posted that.
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."
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.
Not to get into a semantic argument about specific words and their meanings, but my broader point is that there are certain categories of bugs where I wouldn't care if they ever got fixed or not. Maybe this is nit-picking and maybe it's my cynical brain coming out of 25 years of software development where people can't even seem to agree on what constitutes a "bug" vs a "change request" half the time, or how we prioritize the severity of bugs etc. but my point is that sometimes "it's not broken" means "it's good enough."
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."
Maybe a bot that once every three months (or whatever time period you prefer) does a commit to the changelog that says "I am [not] still maintaining this project" and it sends you an email a week before to hit a toggle to remove the "not". Then in the readme you can put a paragraph saying "I use Maintaina-bot (tm), and I commit to clicking the button every three months as long as I'm maintaining this project".
It's a little silly, but I could imagine that if this become a common enough thing, people would start to trust it.
My thinking is that someone forgetting about a project, not caring about it, or for some reason being unable to update it (e.g. losing access to an account or even being physically unable due to injury or death) might not update the project to indicate this; I think a lot of the wariness of older projects that haven't been recently touched is because it's hard to tell the difference between "no changes need to be made so I'm leaving it untouched but monitoring" and "no one is even looking at this and if a change needs to be made, no one knows".
The laziness (which I have no issues admitting I also have!) is exactly why I think having to explicitly act each time to indicate ownership is important; otherwise, it would be impossible to tell the difference between software that's maintained but hasn't needed updates from something that no one is maintaining anymore, which is the issue we have now.
I mean it depends on the kind of project right? What would be catastrophic for a web framework could be totally normal for a command line tool. I mean when was the last commit to some of the GNU utils we use every day? If your module provides math functions or implements some protocoll chances are those underlying things are not going to change etc.
I use a ton of tools I wrote myself and haven't had to touch in years except for the occasional dependency update.
Sure, because the repo contains a ton of tools. Yet another advantage of the monorepo: if everything is in one repo nobody will notice that you haven't touched that one part of the code since you wrote it.
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?
All abandoned projects were active at some point in the past. A project being active now is not a guarantee it will stay so. What happens if the project is abandoned after you chose to rely on it?
> What happens if the project is abandoned after you chose to rely on it?
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.
> 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.
Re-reading the comment as a whole might help to correct this "strawman" interpretation, but anyways, here is some clarification:
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.
