What Happens When Developers Leave Their Open Source Projects?
Open source software is the heart of enterprise business tech. Without projects like Docker, Kubernetes, Rust, NGINX, MariaDB, Apache, and so many others, big business would struggle under the unbearably slow and inflexible weight of proprietary software.
The open source projects leading enterprise computing stand as some of the biggest success stories in the modern era of computing. But not every open source project enjoys such sweet victory. In fact, you’ll find the various repository landscapes rife with abandoned projects. Dig deep enough and you’ll even find outdated or abandoned open source components in proprietary software.
Although one might be led to shrug this off, so long as the components and software still functions. But when a project is abandoned, and users continue employing the project, it leaves those users open to security risks.
Consider this: A project is abandoned and left in a repository. Users desperate to get something to work fail to check for when the last update occurred and install the package. There’s no telling what security vulnerabilities were discovered since that project was last updated. Those vulnerabilities are now found on that user’s desktop or server. So this isn’t just about whether or not a project will still function, long after it’s abandoned — it’s more about why the abandoned project is still available.
One might be inclined to believe the abandoned projects should be automatically culled from a repository, after X months of inactivity. And that would probably be a viable solution. However, there’s one other thing to consider, one that I’ll illustrate with a rather infamous project that rose to serious popularity and then, seemingly overnight, was abandoned.
The Truck Factor
Before we get into that example, let’s talk about a term most projects would rather not consider. One of the first questions that might come to mind is why are projects left behind? Or what does it take for a project to be designated as “abandoned”?
For this, you must consider the Truck Factor. Truck Factor defines the minimal number of developers that must leave before a project becomes unsustainable. In most cases, Truck Factor only applies to projects that include a small number of developers. Where does the name “Truck Factor” come from? How many developers must get hit by a truck… It’s a bit morbid, but that’s the only origin story I can find for the nomenclature.
Oftentimes, open source projects are abandoned because of time. A developer creates a passion project and works on it while in school or during their “off hours.” But then life happens. Work. Family. Children. Those pet projects—even ones with respectable user bases — fall to the wayside. Other times, projects just hit an immovable force. Say, for example, the Google Drive Linux client, Grive. This project was a darling of Linux desktop users, as it was one of the few options that made it possible to sync Google Drive. However, Google made serious changes to how sync functioned, and Grive no longer worked.
Out of those ashes rose a fork of the abandoned Grive, Grive2. Grive2 works with the Drive REST API as well as partial sync. Grive2 is still in active development and makes it possible for Linux desktop users to sync Google Drive.
For an incredibly detailed look into the Truck Factor, read the paper, “On the abandonment and survival of open source projects: An empirical investigation“, written by Guilherme Avelino, Eleni Constantinou, Marco Tulio Valente, and Alexander Serebrenik.
CyanogenMod
Around 2010, a new operating system exploded onto the mobile market, CyanogenMod. This project caught the attention of users, developers, investors, and even Microsoft and Google.
CyanogenMod came into being from a method of rooting Android, which would allow modified firmware to be installed on any rooted device. When the rooting process was discovered, Stef Kondik (who goes by the handle Cyanogen) developed a modified Android firmware she dubbed CyanogenMod.
This, of course, didn’t sit well with Google and, thanks to a collection of proprietary apps (Gmail, Google Maps, YouTube, and the Google Play Store), Kondik received a cease and desist order demanding the proprietary GApps be removed from CyanogenMod.
Unfortunately, GApps are core to Android and, without those apps, Android becomes considerably less desirable. However, developers and the open source community didn’t approve of Google’s tactics and brought this to light. Instead of facing down that criticism, Google softened their stance and made it such that the GApps could be included (by way of backing them up from the original firmware and reinstalling them with CyanogenMod).
By 2013, CyanogenMod was struggling, so Kondik started a new business, called Cyanogen Inc, with the sole purpose of monetizing CyanogenMod. In 2014, Kondik turned down an offer from Google to purchase CyanogenMod. Then, in 2015, Microsoft was set to invest in the company (as a possible replacement for it’s failing Windows Mobile platform), but this never came to fruition. Next, a partnership with OnePlus failed, because of a deal Cyanogen Inc. made with MicroMax.
On Dec. 23, 2016, Cyanogen Inc. released the following notice:
“As part of the ongoing consolidation of Cyanogen, all services and Cyanogen-supported nightly builds will be discontinued no later than 12/31/16. The open source project and source code will remain available for anyone who wants to build CyanogenMod personally.”
The project was officially abandoned.
As Harriet Wheeler once sang, “Here’s where the story ends.”
Only it doesn’t.
On Jan. 22, 2017, the first release of LineageOS was made available. LineageOS was a fork of the abandoned CyanogenMod. The LineageOS project is still in active development, the latest release, 17.1, based on Android 10.
The moral of that story? There is metaphorical gold to be mined in some abandoned projects.
And that’s where the idea of culling abandoned projects gets tricky.
Forks happen.
Often.
Sometimes a developer will have an idea that is similar to a previous project. Why reinvent the wheel, when you can simply improve upon its design? So sometimes those abandoned projects can be picked up, dusted off, forked, and made relevant again.
This is only possible, because those projects are open source.
The WordPress and Jenkins Approach
One of the biggest problems with abandoned projects is finding them. If you head over to GitHub, and search for a project, the only way to know if that project has been abandoned is by checking the last update. Sourceforge does include the Inactive tag, which makes it easier to filter for abandoned projects.
WordPress has a different approach. With one of the world’s largest repositories of add-ons, WordPress had to develop a means to tag abandoned projects. By using the adopt-me tag, WordPress makes it easy for developers to find open source projects to adopt. At the moment there are only two pages of projects looking for a new owner, but that list is always changing.
The Jenkins project has adopted a similar tact, with Adopt A Plugin. With this effort, you can email the Jenkins Developers mailing list and request to be made a maintainer of an abandoned project.
What Needs to Be Done
Open source projects get abandoned all the time. Sometimes those projects should be abandoned and sometimes not. It’s that latter case that needs to be addressed. For any developer considering abandoning a project, if you believe the project still has value, consider putting that project up for adoption. Of course, to make this actually work, a service such as GitHub would have to make it possible for developers to easily search for projects up for adoption. At the moment, that feature does not exist. Instead, abandoned open source projects languish in GitHub.
It’s time GitHub helped make it not only possible, but easy for those projects to be resuscitated. This wouldn’t be terribly difficult. All they would have to do is regularly scan repositories for last commit dates. If a commit hasn’t occurred within a set time frame, an email to the maintainer is triggered informing them they have X days to reply until the project is tagged as abandoned. Once tagged as such, the project could then be moved to a special (searchable) repository designated for abandoned projects, making it easy for developers to find. After all, there are plenty of developers out there looking for projects to work on. There might be an abandoned open source project waiting on GitHub for you — one that could change the very landscape of IT or how users interact with services and software.
You never know.
But until GitHub makes this change, finding an abandoned project to dust off can be a challenge.