Here's a tough but common situation for open source maintainers:
These three points feel like they're in contention. This article is here to help resolve this contention and potentially spur some thinking about succession for open source projects.
Most rewards that come from contributing to open source are either intrinsic (helping others, learning new skills, interest in a topic, improve the world) or for recognition (better access to jobs, proof of a skill-set, “fame” from a popular project). Most folks don't get paid to work on open source for their first project, so it's unlikely to be their initial motivation.
Recognition is typically what feels “at stake” when removing a previous maintainer from operational roles on an open source project.
Let's split recognition into another two categories: operational and celebratory. Operational recognition is the category of recognition that has security implications like access to sensitive information or publishing rights. Celebratory has no security implications, it's there because we want to thank contributors for the work they've done for the project. Here's some examples of the two categories:
You'll notice that the celebratory recognition might be a good candidate for offsetting the removal of incidental operational recognition (like your account being listed on PyPI).
Ensure the removal of operational recognition is supplanted by deliberate celebratory recognition. Consider thanking the removed individual publicly in a blog post, release notes, or social media for their contributions and accomplishments. If there isn't already a permanent place to celebrate past maintainers consider adding a section to the documentation or README.
Don't take action until you've reached out to the individual. Having your access removed without any acknowledgement feels bad and there's no way around that fact. Even if you don't receive a reply, sending a message and waiting some time should be a bare minimum.
Practice regular deliberate celebratory recognition. Thank folks for their contributions, call them out by name in release notes, list active and historical maintainers in the documentation. This fulfills folks that are motivated by recognition and might inspire them to contribute again.
Think more actively about succession. In one of the many potential positive outcomes for an open source project, you will be succeeded by other maintainers and someone else may one day be in the position that you are in today.
How can you prepare that individual to have a better experience than you are right now? I highly recommend Sumana Harihareswara's writing on this topic. There are tips like:
This work is licensed under