Thinking about your open-source legacy
As maintainers, we spend hours working on software that we like to build - Ranging from planning to coding & testing, to writing docs and supporting end-users.
Regardless of how successful your open-source projects are, people are using it to solve the problem that you are helping them with! If you are lucky, they decide to contribute back or support you in some other way.
Being a maintainer comes with a commitment until the day it is marked as deprecated and end-users become aware of it.
But what happens if you get hit by a bus? Have you ever thought about your open-source legacy and what would/should happen to your project(s)? Most probably not, but you should.
One day we will no longer be around, and it’s time to think about your afterlife.
Avoiding the bus-factor
The best way to prepare is to make yourself redundant and avoid the so-called “bus-factor”. The easiest way to achieve this is to have multiple maintainers on your project.
As an example, I am a maintainer of KEDA, but I am not the only one - I’m lucky enough to closely work with Zbynek Roubalik, Jeff Hollan & Ahmed ElSayed who help share the workload.
Another interesting aspect is that our voting process only allows maintainers from the same company to share a single vote. This is not only to avoid having one company mandate everything, but if I would pass away then Zbynek would have an equal voice compared to Jeff & Ahmed. This was an excellent tip from Liz Rice during our CNCF Incubation process.
Make sure that every maintainer has the same permissions, access to all systems, and share passwords.
Open-Source Foundations
Being part of a foundation is wonderful because they help you with a variety of things (depending on foundation) such as legal services, networking, PR, and more.
KEDA, for example, is a CNCF project and has been helping us a lot. One of the ways is through the free tools that are available to us. We heavily rely on 1Password to share sensitive information amongst maintainers so that everybody can access them in a secure manner, but you can use any other password manager.
Another way is through their support - They are very kind people and I am not aware if this is an “official benefit” but I am sure that they will help in case one of us pass away.
They also allow the community to share memories in their memoriam to honor a person and grief as a community about a loss.
Maintaining ownership continuity
In some cases, you might be the sole maintainer of an open-source project. While this is not ideal, it often happens, and for me, that is the case for Promitor & Kubernetes Event Grid Bridge.
That means that when I pass, there is nobody else who can take over and the projects will fully rely on its community. While this is great, this means that nobody can manage my Azure Pipeline builds, container images, documentation publishing, or even post a notice of my passing.
Luckily, GitHub allows you to maintain ownership continuity through GitHub Successor. It allows you to ask another GitHub user to become your successor so that when you pass, they can request access to your repos and take the required actions that you want or they see fit.
Be careful though and think carefully if you are sure you can trust the person whom you have assigned because he will be the owner of all your hard work.
So, what happens if you did not assign a successor? As per the GitHub Deceased User policy, your next of kin, collaborators, and/or business partners can request to get access to your account through GitHub support.
Assigning a designated successor
The process to assign a successor is very straightforward.
In this example, @billbracket wants @tomkerkhove to become his successor:
- @billbracket navigates to his Account settings, and notices a “Successor settings” section:
- @billbracket adds @tomkerkhove as a successor (you can only have one) after which it is listed as pending:
- @tomkerkhove will receive an email that @billbracket is inviting him to be his successor:
- @tomkerkhove has the option to accept or decline @billbracket his request
And that’s it!
Trademarks, Licenses & Wills
I am by far an expert on trademarks & licenses, but make sure you think about this and have a written statement of what your expectations are. If you are not sure, ask for legal help or even write a will.
This is another reason why an open-source foundation can be useful here because it will help you sort out things.
In my case, I have created a digital testament on GitHub that declares what I’d like to happen. Although I’m not sure if this is solid from a legal perspective, it at least explains my wishes, proves I have written it before I have passed, and helps my successor.
However, I’m not the only one doing this - Earlier this year, Troy Hunt shared that he has included somebody in his will who will take over Have I Been Pwned when he passes so that the server can continue to evolve.
For my projects, I do not have passwords that have to be shared with my successor, but if I would have it then I would document how to access them in my testament as well.
This should be a last resort, though, because you should never ever ever store secrets in source control but this feels like a special case. Oh and don’t forget to make the repo private!
How can GitHub help more as a platform?
Improving the Successor experience
The easiest way for GitHub to start is showing GitHub users to whom they have agreed to become their successor, or allowing them to change their mind and no longer be their successor.
The latter part is equally important as setting it up because you commit to taking care of somebody’s hard work when he/she passes. But what if you are no longer in touch and don’t feel comfortable with it anymore? Then it’s best to let that person know, instead of ignoring your commitment at all.
Making the digital testament concept part of the platform
I would love to see a “digital testament” being integrated with GitHub Successors so that this is the first thing my successor sees when he takes ownership of my projects. This would make successors aware that there is a testament so they know where to start.
This could be as simple as having a tomkerkhove/.testament repo, similar to how profile READMEs work.
Managing sponsorship funds
Last but not least - GitHub Sponsors. Things always get tricky when money gets involved and in some scenarios, you’d trust a person to be your successor, but you want your sponsorship to be handled by another person, cancel all sponsors automatically or automatically donate all your income to a charity of your choice.
Because of that, I would love to see some more advanced controls for GitHub Sponsors and GitHub Successor. In a best-case scenario, I can fully configure in GitHub Sponsors what I’d like to do.
The sweet spot
Let’s use an example - My GitHub Sponsors is linked to Stripe where I receive a payout every month thanks to all my sponsors.
When my successor starts the procedure when I have passed, I’d love to automatically:
- Change my Stripe account with a charity fund that I have pre-defined so that the funds can be used for medical research, saving the environment, helping people who need it, etc
- Send out an update to all my sponsors telling them that I have passed and all funds are now being sent to a charity, based on a pre-defined text that I have written
By doing that, people become aware that I am no longer around and they know my contributions will stop as well as they can stop sponsoring me if they want to.
Wrapping Up
While this is not a light topic you read when you want to relax, but it is something we need to think about and be prepared for.
While my projects are not widely adopted, I still have assigned a successor for my account and have created a digital testament. I’m not naive thinking a lot of people would be impacted when I pass, but there still are people waiting for those fixes so it is best to be honest and let them know.
I hope I gave you some measures that you can easily put in place to help - GitHub Successor is one of them!
Have you thought about this before and taken measures? I’m happy to learn from you, so don’t hesitate to reach out to me!
Thanks for reading,
Tom.
Photo by Timothy Eberly on Unsplash