But I'm going to offer a really spicy take: I like the idea both as a way to keep costs down for users and to keep the open source ecosystem healthy.
Given a generous warning (which the original plan did include) I think it's a good idea to encourage devs to offer a proof-of-life every once in a while.
How often do you look at a project that's been inactive for, say, three years and wonder what it's deal is and if it's safe to use? Sure, there are some happy, finished, does-what-it-says-on-the-label projects that just don't need a lot of maintenance, but more often, it's stuff that's just sitting there with unpatched dependencies, and even if it works today it will almost certainly break with the next breaking change to the language or framework and not offer an upgrade path. (I plead guilty.)
So you skip over it because you know you can't take on that kind of risk and you don't want to take on the technical debt of maintaining your own fork.
With this change (or something like it--colder storage might be a good compromise) devs who actually do still care about their happy finished projects get occasional reminders to let their users know they're still alive and doing things.
Putting up the occasional comment costs devs almost no time or effort and is a great service to the open source community. I do agree with the backtrack because deletion probably is too extreme, but I don't think this idea is without merit.
(At any rate, paging @ben to encourage him to update the title following the backtrack.)
I don't really think you did - you said they exist but you attitude amounted to "if the maintainer can't be bothered to say hi the package/project doesn't matter". I think this is far off the mark because of the volume of those packages in dependency chains.
Importantly, they've backtracked already
But I'm going to offer a really spicy take: I like the idea both as a way to keep costs down for users and to keep the open source ecosystem healthy.
Given a generous warning (which the original plan did include) I think it's a good idea to encourage devs to offer a proof-of-life every once in a while.
How often do you look at a project that's been inactive for, say, three years and wonder what it's deal is and if it's safe to use? Sure, there are some happy, finished, does-what-it-says-on-the-label projects that just don't need a lot of maintenance, but more often, it's stuff that's just sitting there with unpatched dependencies, and even if it works today it will almost certainly break with the next breaking change to the language or framework and not offer an upgrade path. (I plead guilty.)
So you skip over it because you know you can't take on that kind of risk and you don't want to take on the technical debt of maintaining your own fork.
With this change (or something like it--colder storage might be a good compromise) devs who actually do still care about their happy finished projects get occasional reminders to let their users know they're still alive and doing things.
Putting up the occasional comment costs devs almost no time or effort and is a great service to the open source community. I do agree with the backtrack because deletion probably is too extreme, but I don't think this idea is without merit.
(At any rate, paging @ben to encourage him to update the title following the backtrack.)
Have you tried looking through the dependencies of any of your projects and seeing when they were last updated?
It's ridiculously common for packages that everyone depends on to go years without updates. Often that's just called "maturity".
Yes, I acknowledged that in my earlier comment so I'm not sure why you're pointing it out to me again.
I don't really think you did - you said they exist but you attitude amounted to "if the maintainer can't be bothered to say hi the package/project doesn't matter". I think this is far off the mark because of the volume of those packages in dependency chains.
That's not what I said at all.
Yes, some finished projects have lots of projects that depend on them.
And of course lots of abandoned projects also have projects that depend on them. So it's not clear what your point is.