In early 2008, Australian brothers Simon Zerner and Toby Zerner started the development of esoTalk. Unfortunately, esoTalk is still in the Alpha stage, and the main developer's older brother, Simon, passed away in mid-2009.
Maintaining and updating esoTalk from Simon is his younger brother Toby. In the README.md file, there is a sentence: "esoTalk was developed by Toby Zerner in memory of his brother Simon." In the end, the two brothers left one developed with PHP+MySQL, which is very simple, fast and modern. Featured open source forum system.
The continuation of esoTalk is so natural.
This leads to a topic, if the author of the open source project dies, who will inherit the code? This is actually two questions. First, who will inherit the copyright; second, who will maintain the code?
Usually, the same person inherits the copyright and maintains the code. After all, not every open source tycoon, like Simon, has a younger brother who can write code.
The copyright issue is actually not that tricky. If the open source software has only one author, then the copyright belongs entirely to him. If there are multiple authors, the author of each code section owns the copyright for that section.
If there is a will, it will be executed according to the will. If there is no will, there are laws such as copyright law and inheritance law. No matter who inherits it, it will not affect users' use of open source software too much. Because open source itself is special, the author of the project has approved the open source license to allow others to use, copy, modify, and distribute the code at will, which already includes most of the rights involved in copyright.
Generally speaking, the author will have signed a contributor license agreement with the legal entities maintained by the project, such as foundations and enterprises, to distribute the copyright before contributing. After signing such an agreement, let alone the author's death, even if he is still alive, he can't do anything he wants to do with the handed over code. (For details, see: Contributor License Agreement (CLA), is it an umbrella or a shackle for open source developers? )
So the problem is focused on, project maintenance. In fact, someone has been asking for answers for a long time.
Hypothesis for a rainy day
" What if Guido was hit by a bus? " In June 1994, a hypothesis was raised on a newsgroup. Guido van Rossum is the inventor of the Python language and a leader in the Python community. And the "bus" here is one of many possible accidental scenarios.
The reason for such a problem is that Python relies too much on Guido. For businesses that want to use Python, there is a risk that has to be considered: if Guido disappears, will Python survive? Commercial products have continued support from vendors based on interest and are therefore less risky, but an academic research project like Python may disappear before long if developers' interests change, or new work is started.
This problem not only worries enterprise users, but also arouses discussion and attention in the Python community. After that, while Guido still played a central role, the community gradually oversaw the future of Python by forming foundations, steering committees, etc.
This discussion has wide-ranging implications. A few years later, someone in the Ruby community asked the same question , "What if founder Matz gets hit by a bus".
Matz said: "Because Ruby is my source of happiness (at least in computing), as long as I live, I will not give up control of Ruby." And he also "nominated" : "If I happen to Whatever, open source is welcome. All the source code is there and I hope Shugo Maeda, Guy Decoux and others will continue to develop this interpreter. I'm sure Dave Thomas will tell the community where to go. He understands the Ruby philosophy as much 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 to stop the project, I call it the bus index. An index ≤ 1 is very bad." Developer Petter Reinholdtsen said that for Debian, ensuring privileged positions have good redundancy Very important.
In addition, Debian advocates decentralization rather than concentration on one leader. For example, the Debian leader can make decisions in a specific area, but it must be handed over to another technical leader; democratic procedures can remove the project leader and overturn any decision of the leader, and so on. (See: Open Source Elder Debian is so tough! ) So when Debian's founder, Ian Murdock, passed away, the community had a smooth transition.
It can be seen that for open source projects with many contributors and escorted by foundations, committees and other organizations, the departure of core personnel will not bring too much blow. No one person can cause unrest in a community without one particular person holding the decision for a long time.
The question was ultimately extended to what should be done to keep the project running if someone in the community has too much privilege before he has an accident.
Given Linus' dictatorship in the Linux community, the question of concern becomes: What if Linus was hit by a bus?
It is difficult for niche projects to survive
Not all projects are as lucky as Python and Ruby. For relatively niche open source projects, it is not easy to continue after the founder's death.
web.py is a lightweight web framework for Python whose founder Aaron Swartz committed suicide in early 2013. For the next three years, the project came to a near standstill. The web.py repository on GitHub has a small number of code commits, but no new versions have been released.
In the next few years, although some developers took over the baton for maintenance, the prospect of web.py could not hide the disappointment. Will the fate of web.py usher in a turning point? Maybe difficult. Whether it's the latest commit record on GitHub or the latest email discussion on the community website, it's all stuck in 2020. Over a year later, they are still quiet.
It's not uncommon for a project like web.py to be stranded due to the death of the lead 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 , haven't recorded a new release for two years. Fortunately, it was finally noticed, and several open source tools developed by Weirich had successors.
There are many more well-known open source projects, lost in the long river of time.
This is actually the same problem faced by the founder who voluntarily abandoned a project: who to give the code to. But there is a big difference. Proactive means that there is time to discuss or plan to find a good home for it.
And unmaintained, which means that if other developers submit bug fixes, security patches, or other improvements, no one will approve the changes, and the project will soon be abandoned by users because the code is outdated, or incompatible with new technology .
One web.py user said that web.py will not be used in new projects because it is not actively maintained. Flask/Werkzeug, Bottle, and Tornado basically fill the same "microframework" niche, and they're noticeably better and more modern.
successor is necessary
Some argue that it should be left to fend for itself, because if an open source project has value, it will naturally be inherited. But things are not so simple.
Abandonment of a project, especially some highly used low-level critical libraries, can result in hundreds of thousands of software applications being affected. Well -known big projects like Linux or the deep learning framework TensorFlow all rely on smaller open source code libraries that in turn depend on other libraries, creating a complex, sprawling web of software dependencies. Analysis by Libraries.io shows that there are more than 2,400 open-source libraries for more than 1,000 other programs, but they receive little attention from the open-source community.
Debian 10 buster server package dependencies
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 developed a will and succession plan for his open source project. Klint Finley, a contributor to WIRED magazine, believes that it would also be a wise choice to transfer copyright to an open source organization, such as the Apache Foundation.
Even if you have the ability and willingness to maintain open source projects, you may encounter a lot of trouble in practice. Klint Finley documented how difficult Searls was in the process. "GitHub refused to let Searls control Rspec-Given because Weirich didn't give him permission. So Searls had to create a new copy of the code and host it elsewhere. He also had to convince Ruby Gems (a code distribution provider) The operator of the "package management system") uses his version of Rspec-Given, rather than Weirich's, so that Searls' changes are accessible to all users. GitHub refuses to discuss policy on transferring control of the project."
Coincidentally, Luacheck's inheritance has been tug-of-war for two or three years due to the transfer of ownership . Luacheck is a tool for linting and static analysis of Lua code, and the repository on GitHub has been in limbo since the death of its creator, Peter Melnichenko. After that, despite the fork created by the community, a Google search for "luacheck", the repo created by Peter was still the first result, and people are still posting issues to the old repo to this day.
A few years ago, Searls suggested that package managers like GitHub and Gems could add something like a "dead switch" to their platforms, which would automatically transfer ownership of a project or account in case the creator hasn't logged in or modified it for a long time. to others.
The "dead switch" is not implemented on GitHub. However, GitHub added a new feature in May 2020: adding account successors . It allows repository owners to invite other users of the same platform as successors without being able to manage. Although successors cannot log in directly to the original account, they can archive and transfer public repositories.
GitLab is also discussing account inheritance. GitLab says this is primarily in response to the death of the account owner. Although the original intention is to solve the possible identity theft or other security-related issues that may occur due to long-term non-use of accounts, it also clarifies the official inheritance process of open source repositories. If a successor could be named in advance, the problems Searls once faced would not arise again.
The "add successor" feature just clears up a few hurdles, but it will make developers or the open source community realize earlier that it is necessary to plan ahead.
Having said that, the hardest part is finding a suitable successor. Don't be discouraged, you might as well turn your attention back to open source. After the code is open source, it has the possibility of infinite life. Over time, developers who have the ability and will will emerge to pick them up and make them their own. As WhiteSource CEO and co-founder Rami Sass put it : "It doesn't belong to anyone, it belongs to everyone."