Possibly appointing one or more backup maintainers

[unforgettableid]

Dear @desrod:

The problem

"The reasons for dedicating less time to or even leaving an open source project are many and varied. Maintainers leave their company or lose interest. Changes in their personal lives give them less time to take care of the project, or they stop their activities in the open source scene entirely because of burnout or illness. In the worst case, they have passed away.

"In all these cases, projects are left behind, often with no one but the original author having administration rights or access to the publishing accounts. Of course, you can fork and publish a project under a new name. But, ultimately, that leads to confusion about the state of the project and whether it can and should still be considered a stable piece of software." (Source.)

The solution

"... Each and every open source project of considerable popularity should have a team of co-maintainers to avoid sliding into neglect. Multiple people should have full access to the project and all related services -- like package registries, hosting accounts, and third-party services -- to ensure ongoing maintenance even as maintainers come and go. ...

"Your co-maintainers do not necessarily need to work on the project every day. They might only be an in-case-of-emergency contact, but at least they will be able to be there. This process often means giving new maintainers access when former maintainers want to step down." (Source.)

My suggestion

My biased suggestion would be to invite @juddmon, @parkerlreed, @fw-aaron, @jpschewe, and myself to be co-maintainers of this GitHub repository. If we accept your invitation, perhaps we can help to make sure that the torch gets passed on if someone competent and new expresses interest in helping out.

Each of the five of us has submitted at least one issue, one pull request, and/or one patch.

I suspect that not all five people will accept a co-maintainership invitation. So, you can send out five invitations in the hopes that at least one or two will be accepted.

How to invite new co-maintainers

If you wish to invite new co-maintainers:

• Visit https://github.com/desrod/pilot-link/settings/access.
• Click the big green "Add people" button.
• Enter a prospective co-maintainer's GitHub username.

GitHub can then email the person a co-maintainership invitation. The person can accept or decline.

Conclusion

Dear @desrod:

Are you possibly interested in sending out co-maintainership invitations to the individuals of your choosing?

[parkerlreed]

Thanks for the post. Yeah would be great seeing this software live on.

I already had to include a new config.guess and config.sub on the AUR PKGBUILD because pilot-link predated AArch64 :D

Currently the configure.ac is choking on Arch's default compiler flags

CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions \
        -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security \
        -fstack-clash-protection -fcf-protection"

Specifically -Werror=format-security when parsed at configure.ac line 63

[desrod]

Not interested in co-maintainership at this time. Patches and PRs should continue to work fine without any friction.

The problem with co-maintainers, as has been shown by hundreds of other projects that have opened that door, is it leads to too many opinionated changes taking place, fracturing both the community of users, as well as the project itself, as everyone wants to take their piece of the ball and run with it, causing the dreaded fork, where everyone loses.

I'll test and push these updates as long as existing/prior platforms are not impacted.

[unforgettableid]

@desrod:

I appreciate your reply.

If you're not open to the idea of a co-maintainer, are you at least open to the idea of appointing one or more backup maintainers?

A backup maintainer technically has the same permissions as a full co-maintainer. As long as you remain present, the backup maintainer does not use these permissions. However, if you ever disappear and become unreachable, the backup maintainer can take control of the project. This lets users enjoy a smooth transition, with no fork or confusing project renaming necessary.