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? Read the full article
