X works perfectly for me, and there is nothing I would want it to do that it doesn't do now. Why should it change?
I have many programs I wrote years ago that I don't change and I use every day. Constant changes are not a measure of utility.
But again and again, you'll find users looking at repositories and deciding that something is "dead" because there isn't any recent commit, often blaming developers for not doing more free work for them. This is a toxic attitude. When we have a software that works well and solves our problems, we should celebrate it, not complain it doesn't find new problems to solve.
> X works perfectly for me, and there is nothing I would want it to do that it doesn't do now. Why should it change?
I'm not sure whether a program that works for you is a good indication that it no longer needs to change.
> When we have a software that works well and solves our problems, we should celebrate it, not complain it doesn't find new problems to solve.
I think anyone can agree that, at the very least, screen tearing and proper support for mixed DPI setups are problems that fall squarely in the responsibilities of X and yet it still didn't manage to solve them after so many years.
So it's hardly the case that X is just so good that users nowadays have to try really hard to find new problems for it to solve.
We do need some form of signal that indicates a project has a maintainer though. It doesn’t matter that he has been inactive for 4 years (on that project), but if I submit a PR, it’s nice if there’s someone at the end of the line.
Repos could really have exactly that. A dead man's switch that asks you every, I don't know, three.to six months - via email even - "you good for this repo still?". You answer with a click "yup" and that's it - a signal on a repo on github or whatever that says "still alive". Otherwise "uh oh - we need help" and then a mechanism there to immediately offer alternative forks with a good enough signal "strength". It's like a pinky promise instead of actual repo activity.
You wouldn’t even necessarily need git/github to implement a new system! Agree on a standard file name like .githeartbeat containing a timestamp. Every few months (or w/e), active maintainers could push a commit to update the timestamp.
It sounds like a good idea, but I'm afraid it may be a nightmare for packagers (like the ones providing packages on GNU/linux distros), as they see updates to upstream only to realize they are just pings and don't need to be repackaged.
It wouldn't be that often, though. And maybe they would actually love to have such heartbeat. I would love to hear a packager on that.
Personally I'm a fan of zero touch where I as a developer submit my code repo to app store like play store, apple app store, flathub or something and they just build it using a standard definition that the store defines and make it available on the store. Kind of feels like a lot of effort for every distro to look at every change in every application...
Repos could also have a notice like "It's been X days since last interaction" which would track the last commit, merge or even just comment in the issue tracker made by the maintainers.
On github? I can't do that. Process has to be as frictionless as possible - hence not in a repo in files itself. A simple email with a button, not to bother maintainers too much / at all.
If somebody discovers a security bug, what are the chances that somebody can cut a high-quality release with the fix in it, if it hasn't been done for two years?
While not wrong, ignores that this isn't the norm.
I think we could use the terms releasing and maintaining. Constant releases is not the same as constant maintenance. And it is hard to agree that our industry sees that.
By way of analogy, we seem to think we can improve the roads by building new bridges every year.
X works perfectly for me, and there is nothing I would want it to do that it doesn't do now. Why should it change?
I have many programs I wrote years ago that I don't change and I use every day. Constant changes are not a measure of utility.
But again and again, you'll find users looking at repositories and deciding that something is "dead" because there isn't any recent commit, often blaming developers for not doing more free work for them. This is a toxic attitude. When we have a software that works well and solves our problems, we should celebrate it, not complain it doesn't find new problems to solve.