A wake-up call for the OSS community

02. Nov 2023

With large corporations and commercially-backed projects taking the lead among OSS contributions by a long shot, unfortunately, the rest of the OSS community isn’t exactly thriving. There’s an abundance of poorly-maintained projects which were never intended to have more than a couple of users but have since blown up to millions of monthly downloads and active users.

Behind those projects are developers who never intended to provide support for something they made in their spare time, poorly organised dependencies, development practices which used to be good enough for whatever the original authors needed, half-implemented solutions waiting for someone to get around and finish their work, incomplete documentation with no instructions on how to build and test the software, and people who long-since moved on with their lives. And yet, everything from integrated circuits in your home appliances to satellites in outer space often relies on those projects.

According to the data from CodersRank, large corporations, including Microsoft, Google, Amazon, and Intel, are some of the most significant contributors to popular OSS projects like the Linux kernel, Python, Android Open Source Project, Kubernetes, and many more. That’s unsurprising since those companies rely heavily on OSS in their products, either directly (e.g. through selling Android apps and app integrations) or indirectly (e.g. by selling cloud infrastructure aimed at Linux-based servers). GitHub Octoverse report also shows that a significant amount of OSS contributions goes towards commercially-backed OSS projects, with 50% of first-time contributors working on such projects in 2022.

What does this mean for the OSS community? For one, the number of outdated, legacy, and unmaintained or unmaintainable projects is only going to grow. The number of projects using outdated OSS will also grow as various breaking changes keep maintainers from updating dependencies. On the other hand, a growing preference towards sponsored and commercially supported OSS projects means that new developers rarely pick up less-recognised OSS projects unless they have a significant incentive to do so. If this trend continues, it’s only a matter of time until we reach a tipping point and a “mass extinction” of active OSS projects.

You’re not changing that ABI because I will crush you!

- Linus Torvalds, DebConf 14

1. Don’t break what you don’t have to

   Some people in the OSS community love to get anal about specifications and the “right” way of doing things, and other people fucking hate it when things break for no apparent reason. PDF.js recently stopped supporting Buffer objects as input, citing the performance impact of converting a buffer to an array; however, most users have to perform that conversion anyway, except now they need an extra line of code everywhere they use PDF.js. All pain, no gain.

2. Don’t remove

   There have been several incidents where developers thought removing vulnerable or otherwise problematic versions of their software would limit the damage but ended up causing more damage when package installers worldwide started failing due to missing dependencies. FFS, put up a notice, hide the version from the downloads page, just don’t delete it, because somewhere, someone needs that specific version. And if you need to migrate your project, keep an archive of old versions - it’s much easier than trying to recreate a particular version from 5 years ago.

3. Write it down

   I know I will forget how I used to build / test / update my projects unless I write it down, and so will you. You don’t need a full-blown CI pipeline; just put whatever commands and setup the project uses in the readme. Do at least the bare minimum not to leave yourself and other developers in complete darkness when someone needs to pick up the project in the future.

These are the three main factors which keep developers from using and contributing to OSS projects. But more than that, these things make the lives of all OSS contributors easier. They give other developers an incentive to contribute solutions rather than problems and arguments. They help users avoid unexpected issues and frustrations with OSS. In a way, they build confidence about OSS projects and the OSS community as a whole. Without them, non-commercial OSS projects will slowly lose support and go down the same path as other once-popular products and ideas.