In early 2008, Australian brothers Simon Zerner and Toby Zerner started the development of esoTalk. Unfortunately, esoTalk was still in Alpha phase when the lead developer brother Simon passed away in mid-2009.
It was his brother Toby who replaced Simon in maintaining and updating esoTalk.
In the README.md file, it says: “esoTalk was developed by Toby Zerner in memory of his brother Simon.” In the end, the two brothers left behind an open source forum system developed with PHP+MySQL, with very simple, fast and modern features.
The continuation of esoTalk is so natural.
This brings up the topic of who inherits the code if the author of an open source project dies. This is really a question of two things. One is, who inherits the copyright, and the other is, who maintains the code?
Usually, it is not the same person who inherits the copyright and maintains the code. After all, not every open source author has a brother who can write code, like Simon.
The copyright issue is not really that tricky. If there is only one author of the open source software, then the copyright belongs entirely to him. If there are multiple authors, then the author of each code part, owns the copyright of that part.
If there is a will, the will is enforced. If there is no will, there are laws like copyright law and inheritance law to govern. No matter who inherits, it will not affect the user too much to use open source software. Because open source itself is special, the author of the project has licensed others to use, copy, modify, and distribute the code at will through the open source license, which already includes most of the rights involved in copyright.
Generally speaking, the author will have already signed a contributor license agreement with the legal entity that maintains the project, such as a foundation or corporation, to assign the copyright out before contributing. After signing such an agreement, the author, not to mention the author’s death, is still alive and cannot do anything with the handed over code if he wants to.
So the problem is focused on, project maintenance. Actually, someone wanted an answer a long time ago.
Prepare for trouble
“What if Guido had been hit by a bus?” was a hypothesis posed in a newsgroup in June 1994. Guido van Rossum is the Guido van Rossum is the inventor of the Python language and the leader of the Python community. The “bus” in this case is one of many possible accident scenarios.
The reason there is such a problem is that Python is too dependent on Guido. For companies that want to use Python, they have to consider the risk that if Guido goes away, will Python survive? Commercial products have vendors who continue to support them based on interest, so the risk is low, but with an academic research project like Python, if the developer’s interests change or new work is started, it may not be long before the project disappears.
This issue not only worried enterprise users, but also generated discussion and attention in the Python community. Since then, while Guido has continued to play a central role, the community has taken steps to oversee the future of Python through the creation of foundations, steering committees, and more.
The discussion was wide-ranging. A few years later, someone in the Ruby community asked the same question, “What if Matz, the founder, had been hit by a bus “.
Matz said, “Because Ruby is my source of joy (at least in computing), I will not relinquish control of Ruby as long as I live.” And he also made a “nomination”: “If something happens to me, open source is welcome. All the source code is there, and I hope that Shugo Maeda, Guy Decoux and others will continue to develop the interpreter. I trust that Dave Thomas will tell the community where to go. He understands the Ruby philosophy as well as I do.”
The Debian community recognized in 2005 that there should be at least two active people in any key position. “How many people get hit by a bus before the project stops is what I call the bus index. An index ≤ 1 is very bad.” Developer Petter Reinholdtsen stated that it is very important for Debian to make sure there is good redundancy in privileged positions.
In addition, Debian advocates decentralizing authority rather than concentrating it in a single leader. For example, the Debian leader could make decisions in specific areas, but had to delegate them to another technical leader; a democratic process could remove the project leader and overturn any decision made by the leader, etc. So when Ian Murdock, the founder of Debian, died, the community had a smooth transition.
As you can see, for open source projects with a large number of contributors, and with foundations, committees, and other organizations to protect them, the loss of a core person is not a big blow. Without a specific person to hold the decision for a long time, no one can cause turmoil in the community.
The question is ultimately extended to what should be done to keep the project running if one person in the community has too much privilege before something happens to him.
Given the dictatorial rule of Linus in the Linux community, the question of concern became: What if Linus got hit by a bus?
It is difficult to renew the life of niche projects
Not all projects are as lucky as Python and Ruby. For more niche open source projects, it’s not easy to survive the death of the founder.
web.py is a lightweight web framework for Python, and in early 2013, its founder Aaron Swartz committed suicide. For the next three years, the project came to a near standstill. web.py’s GitHub repository had a small number of code commits, but no new versions were released.
In the years since, web.py has been maintained by a succession of developers, but the future of web.py has been bleak. will the fate of web.py ever turn around? Probably not. The latest commits on GitHub and the latest email discussions on the community site are all stuck in 2020. More than a year later, they’re still quiet.
It’s not uncommon for projects like web.py to be put on hold due to the death of a major developer. Even after the death of Jim Weirich, a well-known contributor to the Ruby community, two of the most popular projects he created, Rake and Builder, had no new releases in two years. No new releases were recorded for two years. But the good news is that it was finally noticed, and several of the open source tools Weirich developed have successors.
There are more or less well-known open source projects that have been lost in time.
This is actually the same problem as the founder abandoning a project voluntarily: who to give the code to. But there is a big difference, active means there is time to discuss or plan to find a good next home for it.
And without someone to maintain it, that means that if other developers submit bug fixes, security patches, or other improvements, there will be no one to approve the changes, and the project will soon be abandoned by users because the code is outdated, or incompatible with new technologies.
One web.py user said will not use web.py in new projects because it is not actively maintained. Flask/Werkzeug, Bottle, and Tornado basically fill the same “microframework” niche, and they are significantly better and more modern.
Successor is necessary
Some people think that it should be left to its own devices, because if an open source project has value, then it will naturally be inherited by someone. But it’s not that simple.
The abandonment of a project, especially of some highly used underlying key libraries, can result in hundreds of thousands of software applications being affected. Big, well-known projects like Linux or the deep learning framework TensorFlow depend on smaller open-source libraries that in turn depend on other libraries, creating a complex, large network of software dependencies. Analysis by Libraries.io shows that there are up to 2400 open source libraries used for over 1000 other programs More than 2,400 open-source libraries are available for over 1,000 other programs, but they receive little attention from the open-source community.
Therefore, it is necessary to find successors for open source projects that have been abandoned due to sudden changes in developers. After taking over Weirich’s legacy Rspec-Given project, Justin Searls created a will and succession plan for his open source project. Klint Finley, a contributor to WIRED magazine, believes that transferring the rights to an open source organization, such as the Apache Foundation, is also a wise choice.
Even with the ability and desire to maintain open source projects, there can be a lot of trouble in practice. Klint Finley documented Searls on how difficult this process can be. “GitHub refused to let Searls take control of Rspec-Given because Weirich didn’t provide him with access. So Searls had to create a new copy of the code and host it elsewhere. He also had to convince the operator of Ruby Gems, a “package management system” for distributing code, to use his version of Rspec-Given instead of Weirich’s so that all users could access Searls’ changes. GitHub declined to discuss its policy on transferring control of projects.”
It’s no coincidence that the Luacheck inheritance was also a tug-of-war for two or three years over ownership transfer. The repository on GitHub has been in limbo since the death of Melnichenko. Then, despite the community creating a branch, a Google search for “luacheck” still shows Peter’s repository as the first result, and to this day, people are still issue to the old repository.
A few years ago, Searls suggested that package managers like GitHub and Gems could add something like a “deceased switch” to their platforms that would automatically transfer ownership of a project or account to someone else in case the creator hadn’t logged in or modified it in a long time.
The “deceased switch” is not implemented on GitHub. However, GitHub added a feature in May 2020: Adding a successor to an account. It allows the repository owner to invite other users from the same platform as successors in case they are unmanageable. While successors cannot log in directly to the original account, they can archive as well as transfer public repositories.
GitLab also is discussing account inheritance as a matter of course. GitLab has said that this is primarily in response to the death of an account owner. While the original intent was to address identity theft or other security-related issues that might arise due to accounts not being used for a long period of time, it also clarifies the process for official inheritance of open source repositories, though. If a successor can be appointed in advance, the problems Searls once faced will no longer be present.
The “add successor” feature only clears a few hurdles, but it will make developers or the open source community realize earlier that it is necessary to be proactive.
That said, the hardest thing is to find the right successor. There is no need to be discouraged, it is worthwhile to pull more attention back to the open source thing. After the code is open source, it has the possibility of unlimited renewal. In time, there will be developers with the ability and will to pick them up and make them their own. As WhiteSource’s CEO and co-founder Rami Sass says: " It doesn’t belong to anyone, it belongs to everyone.”