Orphan Projects: Open Source Projects After the Death of Their Premier Developer

Every major open source project has at least one quiet hero who doesn’t become a household name but whose lines of code are at the basis of the very web ecosystems we rely on.

Such was Jim Weirich of Ruby programming language fame. A developer-turned-entrepreneur and blogosphere personality, Weirich passed away in 2014 and left behind several open source legacies. Like an original Picasso, the question on the minds of many post-Weirich’s passing was to the effect of his estate. His Rake build tool garnered over 74 million downloads, and his Builder legacy came in at just over 57 million downloads at the time of his death. Who was going to take the reigns of these abandoned libraries? Who was going to take ownership of the orphaned Ruby tools?  

Keeping Up Appearances

When Weirich passed away he left a gaping hole in the ongoing maintenance and further development of the Ruby tools he created. It would be up to other Ruby developers to maintain the code written by Weirich, offering fixes for vulnerabilities and security patches. But without a centralized manager overlooking these fixes, who was going to authorize them? And just as urgently, who was going update these libraries to ensure their compatibility with new software that floods the tech world daily? Who, in other words, was going to keep Weirich’s work alive and relevant?

At the time of his death, Weirich’s projects went to his co-manager who was a fellow veteran developer and knew Ruby well. Unfortunately, having a co-manager is not always the case and a competent one is less likely than one can expect. “If the knowledge exists only in one person’s head, you’re going to have a problem,” noted Justin Searls, a Ruby developer and co-founder of the software company Test Double along with Weirich.

Ownership of orphaned projects is a real problem and developers even have a name for it. They call it the “bus factor” and what they mean by it is the number of developers that would have to get hit by a bus until there was nobody left in the project to maintain it. Gruesome much? Maybe. But the grain of truth is there and it's a reality check for open source projects.

Committing to a Project

By committing to a project a developer is committing to a project.

This is not a mere play on words.

By writing some lines of code, by offering a bug fix or a patch here and there, a committer comes to have a stake in the project. And it is this element of responsibility bundled up with knowledge that causes project managers to strive for multiple contributors. Other than pushing out better quality, an abundance of committers ensures that there will be a next in line to the throne should something happen to the project founders.

We are dealing with humans and their mortality is inevitable. Actually, it doesn’t have to be a case of physical death, it could be other things, too, like founding fathers moving on to greener pastures or jumping ship to start new projects. If orphaned projects, whether by death or choice, are a reality, the open source community needs to deal with then adopted projects are the flip side.

Adoption is a term that comes from the “other side” of open source usage. From the consumer side. It is a term used to describe the process of using open source components and integrating them into your code. On the consumer side, companies will require their developers to treat the open source components they choose to use as if they were written by them. It is a process of appropriating what isn't yours.

In a way, developers assuming ownership of abandoned projects are being asked to do the same. Because taking a project under your wing is not merely maintaining it, it is learning the ins and outs of it so that an ad hoc manager is able to authorize fixes as readily as he is able to write the fixes himself, offer patches as seamlessly as he is able to update versions.

RIP Weirich, Your Projects are in Good Hands 

Let’s tell it like it is. Again. Open source creators are not your average hero. They don’t come with the big names and fancy titles that other cats in the software space come with.

You don’t know them by name and their images don’t pop up next to the six-digit figure of commits they made, but you’ve almost certainly used apps built by these guys or surfed sites that are based on their work.

When they are no longer with us their legacy is thrown back to the community. Their orphaned projects lay silently in wait until the right developer picks them up and makes them his own. In a roundabout way, that is the very nature of open source and the mindset behind the open source enterprise. It belongs to nobody, and it belongs to everybody. There’s a kind of tragic beauty in that.   

Rami Sass is CEO and Co-Founder of WhiteSource