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

Packagers should generally only be looking at tagged releases in the upstream repository, though -- not every commit.

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

That's what distros do. That's what they are - a collection of vetted software packages tweaked to work together.

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.

But someone has to volunteer to implement this process. Do you have time for that?

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?

The fix can be submitted on the previous release branch. If that branch doesn't exist, it can be cut off of the old commit the release was made from.

If your objective is to improve security, this is better than getting a version with myriad changes that may introduce new bugs.

Having an active maintainer fixing security bugs as they arise isn’t “finding new problems to solve.”

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.