4 ms·

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

by thayne 4y ago

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

deleted 4y ago
[deleted]
atoav 4y ago
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.
- vbezhenar 4y ago
  > when was the last commit to some of the GNU utils we use every day? 17 hours ago: https://github.com/coreutils/coreutils/commits/master https://github.com/coreutils/coreutils/commits/master
  - atoav 4y ago
    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?
saghm 4y ago
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.
- ricardobeat 4y ago
  This is already available in reverse: you can mark a repository as unmaintained in GH to let people know you wont touch it anymore.
  - saghm 4y ago
    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".
- vbezhenar 4y ago
  You can update copyright comments once a year.
  - rjmunro 4y ago
    You should only do that if you have changed something. Otherwise you are falsely extending the period before the work enters the public domain.
- johanbcn 4y ago
  Someone will then come up with "Maintaina-bot-bot", so that we don't have to bother clicking that button. Programmers are lazy creatures.
duckmysick 4y ago
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?
- arkh 4y ago
  > What happens if the project is abandoned after you chose to rely on it? Fork it and start maintaining it with other people depending on it.
- thayne 4y ago
  An active project is more likely to stay active than an abandoned project to become less abandoned. See also the Lindy effect.
- alexdowad 4y ago
  > 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.
  - duckmysick 4y ago
    > 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.
gspencley 4y ago
"If the former, I probably don't want to use 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.
- andrepd 4y ago
  > That doesn't mean that everything is perfect and we shouldn't fix things that are broken, Okay, so this is exactly what GP said. There is a difference between "not adding new features" and "not fixing bugs".
  - gspencley 4y ago
    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."

by thayne 4y ago

deleted 4y ago

[deleted]

atoav 4y ago

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.

vbezhenar 4y ago
> when was the last commit to some of the GNU utils we use every day? 17 hours ago: https://github.com/coreutils/coreutils/commits/master https://github.com/coreutils/coreutils/commits/master
- atoav 4y ago
  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?

saghm 4y ago

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.

ricardobeat 4y ago
This is already available in reverse: you can mark a repository as unmaintained in GH to let people know you wont touch it anymore.
- saghm 4y ago
  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".
vbezhenar 4y ago
You can update copyright comments once a year.
- rjmunro 4y ago
  You should only do that if you have changed something. Otherwise you are falsely extending the period before the work enters the public domain.
johanbcn 4y ago
Someone will then come up with "Maintaina-bot-bot", so that we don't have to bother clicking that button. Programmers are lazy creatures.

duckmysick 4y ago

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?

arkh 4y ago
> What happens if the project is abandoned after you chose to rely on it? Fork it and start maintaining it with other people depending on it.
thayne 4y ago
An active project is more likely to stay active than an abandoned project to become less abandoned. See also the Lindy effect.
alexdowad 4y ago
> 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.
- duckmysick 4y ago
  > 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.

gspencley 4y ago

"If the former, I probably don't want to use 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.

andrepd 4y ago
> That doesn't mean that everything is perfect and we shouldn't fix things that are broken, Okay, so this is exactly what GP said. There is a difference between "not adding new features" and "not fixing bugs".
- gspencley 4y ago
  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."