What Happens to Open Source Code After The Developer’s Death?

//What Happens to Open Source Code After The Developer’s Death?

While for a long time there has been a battle between open source software and proprietary software, it must be recognized that for several years now, these two worlds have not been seen as opposed, but somewhat complementary.

One of the advantages of these open source software, beyond the ability to easily contribute to open source projects, is that open source code can be used and modified as desired in both open source and commercial software.

Jim Weirich is a developer who has had several open sources tools like Rake, Builder, RubyGems, Ruby KoanS and more. He was also a significant contributor to the Ruby community of the western world. In 2014, Weirich died leaving behind a panoply of tools used by a large number of people. But to ensure the durability of these tools that were sometimes developed by Weirich only, we must resume his projects.

Justin Searls, the developer at Ruby and co-founder of the software company Test Double, noted that after the death of Weirich in 2014, one of the tools left by the developer was not maintained. This means that if there were security patches and other bugs that were submitted by the contributors, there would be no one to approve these changes. Over time, the code of the tool would become obsolete, because incompatible with new technologies.

Through this case, Searls points out that the death of Weirich highlights a growing concern in the open source software community. In other words, what happens to open source code after the disappearance of developers?

Although some people might find a simple answer by saying that we need to turn to other open source tools that are maintained, the same problem would arise again if the tool is maintained by a person or a small community of volunteers and that these are unavailable or dead.

When companies developed their software without resorting to dependencies in the open source community, the problem involved only a handful of people and was therefore imperceptible. But with the integration of open source code in many commercial software, the importance of maintaining open source code at all times resurfaces.

The case of the Heartbleed flaw detected in OpenSSL is an edifying example. OpenSSL is an encryption toolkit consisting of two libraries (TLS and SSL). It is used by the majority of companies on the web to ensure the security of their communication for their commercial and non-commercial services. In 2014, a fault called Heartbleed was detected in these tools and allowed an attacker to recover the contents of the server memory without leaving any digital trace. According to the information reported, this tool would be developed by a small team of volunteers who did not have the time or resources to carry out comprehensive security audits.

Beyond the security issues caused by the abandonment of an open source project, Searls reports that compatibility issues can arise in many software when a developer dies and abandons a project that is integrated with many software.

To better demonstrate the scale of the problems generated by open source open source projects, Libraries.io, a group that examines connections between software projects, has identified more than 2400 open source libraries that are used in at least 1000 other programs. But have received little attention from the open source community.

As an example, last year, when developer Azer Koçulu removed a small library called Leftpad on the Internet, it created a domino effect that would have caused headaches to Facebook, Netflix, and other sites as well.

To avoid abandoning Weirich’s open source Rspec-Given test tool, Searls turned to Github, which hosted the project code. But the platform refused to give him control of the page because the owner did not designate him as the new project manager after his death.

To avoid abandoning Weirich’s open source Rspec-Given test tool, Searls turned to Github, which hosted the project code. But the platform refused to give him control of the page because the owner did not designate him as the new project manager after his death.

Given the difficulties that could arise in the management of an open source project after the death of its owner, what solutions can you recommend to avoid these problems?

By |2017-12-21T08:30:36+00:00December 21st, 2017|Skill Development|2 Comments


  1. Estephanía Sandoval December 29, 2017 at 9:28 pm - Reply

    This is an interesting post that make us to think how bad can this problem be. The main advantage in this model is given by the ability to generate a scenario of collaboration with the software provider or the integrator, focusing on the development of a company focused on the business. In general, this type of tool has a “counter cyclic” behavior, which makes it attractive in scenarios of uncertainty or economic contraction. Losing this tool would mean a big problem for the development of the digital technology. Good article!

  2. Daniel Ogeto O. December 31, 2017 at 2:07 pm - Reply

    Thanks for this very informative and eye-opening article. With the widespread use of Digital technology, much has been written about what happens to social-media accounts after users die. But it’s been less of an issue among programmers. In part, that’s because most companies and governments relied on commercial software maintained by teams of people. But today, more programs rely on obscure but crucial software like Weirich’s. Some open-source projects are well known, such as the Linux operating system or Google’s artificial-intelligence framework TensorFlow. But each of these projects depend on smaller libraries of open-source code. And those libraries depend on other libraries. The result is a complex, but largely hidden, web of software dependencies. When a developer dies or abandons a project, everyone who depends on that software can be affected. The fewer people with ownership of a piece of software, the greater the risk that it could be orphaned. Developers even have a morbid name for this: the bus factor, meaning the number of people who would have to be hit by a bus before there’s no one left to maintain the project. In some cases, motivated programmers adopt orphaned open-source code. There are other things developers can do to help future-proof their work. They can, for example, transfer the copyrights to a foundation, such as the Apache Foundation. But many open-source projects essentially start as hobbies, so programmers may not think to transfer ownership until it is too late. Another alternative is to utilize something like a “dead man’s switch” on their platform, which would allow programmers to automatically transfer ownership of a project or an account to someone else if the creator doesn’t log in or make changes after a set period of time.

Leave A Comment