I often observe that people that started a small open source project seem to abandon it sooner or later. I'm guilty of this myself in numerous cases. Reasons there are many probably, from new obligations in life to shifts in interest and whatnot.
At some point somebody comes by with an issue, or a merge request even, but the maintainer does not take care of it. Usually this ends up in forks, often though forks undergo the same fate. Apart from the immediate forks-jungle, stuff like software stores or other things might be hardlinked to the original repo, which means places like these end up with dead originals and a number of forks with varying degree of being maintained as well.
To me its just a sad situation overall. And yet I cannot find the time or motivation to maintain some stuff, because circumstances just changed. And I also do not think one is obliged to do so, just because they where nice enough to share their code when the project mattered to them.
Is there a better way? Usually these are very nieche projects, and there is not a circle of regularly active developers that could share administration of a repo, but rather a quiet one-man-show with a short timespan of incredible activity. Some kind of sensible failover mechanism once the original maintainer vanishes would probably be cool. Or any other way that introduces some redundancy in keeping a repository alive. You know how package maintainers in Linux distributions open their package(s) for adoption by somebody else if they run out of capacity? I think that is nice.
I will publish a small project soon I think, but somewhere in the future I fear to leave one or the other person frustrated again when I have moved on to other things...
Some suggestions;
license it in GPL or another copyleft license so that future contributors will contribute back to the source and not just take what they want and leave. A lot of issues with open source projects not being maintained is because people will spin up an MIT or BSD license and then people, corporate employees, etc. just grab what they want and never contribute back.
document all of your code ad nauseum so whoever wants to take over can understand everything easily. That way minimizes NIH syndrome or feeling like it's easier just to restart.
before you turn off the lights, leave a roadmap.
I like your second point, and already started polishing the thing more than I would have for just my own purposes. It's a good way to make it easier for somebody to take it on in the future. And it's also a measure that the original creator more likely has the will to implement while focusing on building the thing, i.e. before they moved on to other things. Also for my current project I try to keep it simple. It may not be the prettiest, most configurable or universal tool. But it has a short code and minimal dependencies. Thank you for your comment, that made me think about how traits like this can become very valuable for others.
Your first point I do anyways, and the third I'm not sure about yet. Maybe documenting such things as issues preserves them decently.