Description
Governments have a chains of succession, companies have succession plans, and individuals may have a legal will each of which defines how affairs are to be handled should an individual die or become incapacitated, but FOSS projects tend not to have anything similar.
Succession can be looked at two ways: product and community. On the product side, it can be unclear which other package or dependency could be used should this one fall behind. On the community side, smaller projects may not have chosen a key contributor to recommend following, and large projects may not have designated a successor lead-maintainer or a set of people who should be trusted to find and elect a new lead maintainer.
One key reason this is a problem for FOSS is because there're more uncertainty than there needs to be in the open source ecosystem and that uncertainty causes stress for maintainers, users, and developers.
Proposed solution:
A protocol could address the product side by directing dependents to a new repo or package that can satisfy most of the same needs for which people chose this one. Interchangeability could be increased by making test suites that work across competing packages.
On the community side, a protocol would tell smaller projects without a large community what's the best way forward. For larger communities, it would be more about who could take over as lead maintainer or which community members would be empowered to find and elect a new maintainer.
Issues in this repo are not proclamations but open for discussion as to their accuracy and value. You can help by providing evidence and lines of investigation supporting or refuting the proposed problems.
Questions that should apply to all issues in this tracker: Is this problem accurate? Is there a deeper issue? Is it valuable? Can it safely be ignored? Please discuss.