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.
#culture #linux #open source #feature
