The fate of the open source project after the death of the programmer

You have probably never heard of the recently deceased Jim Weirich or his programs. But you almost certainly used applications built on the basis of his work.

Weirich helped create several key tools for Ruby, a popular programming language that has been written for sites like Hulu, Kickstarter, Twitter, and a huge number of others. The source code of its code was open, which means that everyone could use and modify them. "He was a prolific member of the Western Ruby community," said Justin Searls, a Ruby developer and co-founder of the software development company, Test Double.
')
When Weirich died in 2014, Searls noticed that no one supported one of Wyrich's tools for checking software. This meant that no one would approve the changes if other developers sent bug fixes, security patches or other improvements to the draft. Any tests based on this tool will fail as a result, since the code will become obsolete and will become incompatible with new technologies.

This case reflects a growing concern in the open source community. What happens to the code after the programmer's death? Already written many articles about what will happen in social networks with social accounts after the death of the user. But for programmers, this problem was not so acute. Partly because most companies and governments rely on commercial software that is supported by teams of people. But today, more programs rely on such little-known, but critically important software, which did Weirich.

Some open source projects are well known - Linux OS or Google TensorFlow artificial intelligence platform. But each such project depends on smaller open source libraries. And these libraries depend on others. The result is a complex, mostly hidden network of software dependencies.

This can lead to big problems, as happened in 2014 with a security vulnerability called Heartbleed, discovered in OpenSSL - a program with source code that is used by almost all web sites that process payments from bank cards. This software comes with most versions of Linux, but it was supported by a small team of volunteers who did not have the time or resources for a comprehensive security audit. Soon after such a fiasco, a security problem was discovered in another frequently used open source program, Bash, which caused countless web servers and other devices to be vulnerable to attack.

Surely there are even more unsolved vulnerabilities. A group of people analyzing the links between software projects, Libraries.io, found more than 2,400 open source libraries used by at least 1,000 other programs and were not receiving adequate attention from the open-source community.

And security flaws are only part of the problem. If the software libraries are not updated, they may stop working with new programs. This means that an application that depends on an outdated library may stop working after updating other software. When a developer dies or abandons a project, anyone dependent on the software may suffer. Last year, when Azer Koçulu programmer [Azer Koçulu] deleted the tiny Leftpad library from the Internet [not Leftpad, but left-pad, and not from the Internet, but from the package storage system npm / approx. trans.], which led to a diverging effect, added headache support for Facebook, Netflix and other projects.

Bus factor

The smaller the number of people owning a part of the code, the greater the risk that it will be left without an owner. Developers even have a dismal term for such cases - the bus factor , meaning the number of people the bus must knock down before there is no one to support the project. Libraries.io identified about 3,000 open source libraries used in many other programs that have very few programmers.

Orphaned projects are a risk of using open source software, although commercial software vendors may leave the user in the same position, no longer supporting or updating old programs. In some cases, responsible programmers adopt orphaned open source projects.

This was done by Sears with one of the Wyrich projects. His most popular projects at the time of his death were managed by him together with someone else. But Searls found one project, an Rspec-Given testing tool that no one got, and wanted to take responsibility for updating it. But he faced some difficulties.

Rspec-Given lived on a popular site for collaboration and posting GitHub code, where about 67 million projects are located. Wyrich's Rspec-Given page on GitHub was the main place for other people to report bugs or offer help with code improvements. But GitHub did not want to give the page control to Surse, since Weirich did not transfer such rights to him before his death. Therefore, Searles had to create a new copy of the code and place it in another place. He also had to persuade operators of Ruby Gems, a package management system that distributes code, to use his version of Rspec-Given instead of Weinrich’s version so that all users have access to the changes made by the Searls. GitHub declined to comment on its rules for transferring project management.

This solved the potential problems with Rspec-Given, but opened the eyes of how many things could go wrong. “It's easy to treat open source projects as a purely technical phenomenon,” said Searls. “But as soon as something takes off, if the work of hundreds of other people depends on it, it also becomes a social phenomenon.”

The support groups of most package management systems have at least one process of transferring control over the library, but it usually depends on someone noticing that the project is orphaned, and then volunteered to support it. "We have no official rules on this matter, since such problems do not often arise," says Ivan Phoenix from the Ruby Gems project. "We have an expert council that solves such questions individually."

Some package management systems track libraries and mark widely used projects that have not been updated for a long time. Neil Bowers, who helps maintain the Perl programming language package system , says he sometimes seeks volunteers to support orphaned projects.

Dead man's trigger

Taking control of Rspec-Given inspired Searls, who at the time was only 30 years old, to write his will and plan to transfer his open source projects. Developers can take other actions to secure the future of their projects. For example, transfer rights to some foundation, like the Apache Foundation. But many open source projects often start as a hobby, so programmers may not think about transferring rights until it's too late.

Sears suggests that GitHub and package management systems such as Gems add a “dead man trigger” to themselves, allowing programmers to automatically transfer control of a project or account to someone else, if this creator has not logged in or made changes to the project during a certain period. of time.

But the transfer plan is not just opening up access to the code to other people. Michael Drotbom, who took over the development of the popular Matplotlib Mathematical Library after the death of its creator John Hunter in 2012, indicates that the successors also need to understand the code. “Sometimes there are parts in the code that only one person can understand,” he says. “Knowledge exists only in the mind of one person.”

This means that people need to be involved in the project at an early stage, ideally, immediately after it is started to be used by other people besides the developer. Sears says that this approach has another advantage - the distribution of work on supporting the project, which helps to avoid developer “burnout”.