A currently maintained fork of SSHFS

> The current maintainer continues to apply pull requests and makes regular releases, but unfortunately has no capacity to do any development beyond addressing high-impact issues.

Assuming this is true--and I think it is fair to trust the author of the statement when judging the same author--this doesn't sound like a project that needs a fork, as it apparently in fact does have an active maintainer; if you want to help contribute to sshfs, you thereby can do that without forking it and causing a mess for everyone having to decide which one to use/ship and without the bad blood inherent in resorting to the four-letter F-word of open source project management.

That's the old status before being orphaned. The latest note at the top of the readme in the original repo reads:

> This project is no longer maintained or developed. Github issue tracking and pull requests have therefore been disabled. The mailing list (see below) is still available for use.

> If you would like to take over this project, you are welcome to do so. Please fork it and develop the fork for a while. Once there has been 6 months of reasonable activity, please contact Nikolaus@rath.org and I'll be happy to give you ownership of this repository or replace with a pointer to the fork.

I mostly care if projects don't accept bugfixes. For example "inotify feature longer works with the latest glibc release due to subtle API change" might be an easy 10 line pull request to fix.

But if the maintainer doesn't take the pull request and make a release, then the effort of fixing it is wasted, and every single user has to workaround/suffer from that bug into the future.

There are loads of projects in that state - unmerged PR's from years ago with sensible fixes, no new release, and no forks that are distributed to users.

I'd like software that connects to machine with write privileges, across network boundaries, to have some degree of maintenance, if that's ok.

It may not be just security too, as this integrates FUSE and SSH then there will be bitrot and API drift etc over the years.

I wish github and other code hosters made it easier to "just make a release".

Next to the "Download zip" button on github, they should add a "Download built .deb" and "Download built .exe" - and those buttons should work on any fork, branch, PR, etc. And they should add all the necessary build infrastructure to achieve that.

It turns out that at scale, build infrastructure is pretty cheap to run, since caching is so incredibly effective and there is only a need to rebuild a file once per (human) edit to a file or its dependencies.