🤬 A categorized list of incidents caused by unappreciated OSS maintainers or underfunded OSS projects. Feedback welcome!
NOTE: This list and classification is still not complete and should be seen as work in progress!
A categorized list of incidents caused by unappreciated OSS maintainers or underfunded OSS library projects. Feedback welcome!
The Goal of this classification and list of incidents is to identify and analyze reasons why some OSS maintainers do intentionally cause problems for the larger software ecosystem and to determine potential solutions.
Table of Contents
In the beginning developing OSS is often great for the maintainer - there are no constraints on the tech or features, only few bugs exists, the maintainer can work as and when they want, there are only their own expectations to fulfill, and the few users appreciate the project. Furthermore, working on the open-source project helps them to sharpen their skills, build a reputation for themselves, gain perspectives on the topic from the community, or simply help the industry by making innovations available at no cost.
But if a project gets more attention and users the heat increases. More and more users want new features, bug-fixes, more docu and tutorials, etc. Companies using the project want fixes to problems asap (e.g., for cURL) - esp. if it concerns their own SLAs - all without previously funding or currently supporting the project. And most of Companies systems and the Internet's infrastructure at large are using open-source libraries developed by few maintainers and without funding - wonderfully visualized in a xkcd comic.
This ever increasing workload and lack of funding often causes maintainers to get unhappy and sometimes even leave their project or even "run amok" and cause problems for the user base. With more funding most of the identified problems can be mitigated. Funding enables maintainers of open-source projects to:
Many incidents occurred since the advent of the registries and became famous especially in frontend web development, which has a large developer base.
We classified these incidents based on the core problem, describe them briefly, and state potential solutions to prevent them from happening again.
Please note that when descibing these incidents, we try to not take sides as every side has its own story. We just try to categorize and describe the problems, history, and consequences based on available articles.
A part of an open-source project can sometime cause problems when the name of the project, the logo, or something else used in the project causes an infringement on the Trademark, Figurative Mark, Brand, etc. Furthermore, a trademark might even have been registered after the project was created or in different jurisdictions that have not been checked (e.g., trademarks can be registered in a country (e.g., Italy), a union of countries (e.g., the EU) or internationally).
Trademark infringements are often caused by an oversight or ignorance from the open-source maintainer as well as the trademark owner or by "Trademark Trolls" registering the trademark to harm the project.
Examples
left-pad
) from NPM due to trademark infringement over the name "kik" - breaking tens of thousands of projects that depended on it. [Blog Post] [Azer's version] [kik's version]Potential Solutions
All software system can have minor or major bugs that prevent their intended use in different scenarios. When a open-source maintainer publishes a faulty project, the effect can be felt by many of its users.
Programming mistakes are causes by oversights, missing tests, integration problems, corrupt dependencies, and in general due to not having enough time to test the system in production-like environments.
Examples
openSSL
led to a vulnerability (a.k.a. Heartbleed) that allowed stealing information and passwords from users. The Heartbleed Vulnerability Website
is-promised
library that didn't adhere to the proper ES module standards causing wide-spread build errors. This release led to bugs in popular build tools used to create new projects, such as Facebook's create-react-app, Google's firebase-tools, Amazon's AWS Serverless CLI, Nuxt.js, AVA, angular-cli, and others. [Blog Post] [Forbes' Post-mortem]log4j
enabled a feature from 2013 by default that allowed loading of malicious code on any log server. [The Log4j Vulnerability]
Potential Solutions
The maintainer of a open-source library is often the owner of a package on a registry and is the only one allowed to change, delete, or publish new versions. The account of the owner in the registry is often linked to an email address and can only be transferred by the registry operators. If the ownership of a package is transferred, this can lead to incompatible libraries (with the same name) or malicious code deleting data or stealing information.
Package ownership problems are often caused by hacked password / credentials, an oversight or misunderstanding by the registry operator, or general contact problems.
Examples
bebop
published in various software repositories, Andrew Sampson found that it was unclaimed except in npm. After inquiring to the NPM registry, the ownership of the package bebop
was auto-transferred to Andrew due to a corrupt contact address of the former owner Zach Kelling. [Blog Post]Potential Solutions
The usage of an open-source project can sometimes cause problems when third-parties (e.g. Cloud provider) offer them commercially and/or the maintainer community wants to commercialize and builds a Startup.
Usage disputes are caused by different points of views on how an open-source project should be used or commercialized. Even if the positions are legally clear, the dispute can affect and impair the users.
Examples
elasticsearch-js
to not work with AWS Elasticsearch and OpenSearch anymore. [Github Issue]Potential Solutions
Most software systems have flaws that can be hacked, used to extract data, or otherwise exploited by criminals. While their existance does not necessarily break the system, it is prone to be exploited.
Security problems are often caused by oversight, no time for tests, corrupt dependencies, or intended hacks.
Examples
event-stream
by a new maintainer. The malicious package, called flatmap-stream
, contained an encrypted payload that stole bitcoins from certain applications. [NPM Incident Report]UA-Parser-JS
library was hijacked, to infect dependent systems with cryptominers and password-stealing trojans in a supply-chain attack. [Full Story]eslint-scope
, version 3.7.2. The malicious code copied the NPM credentials of the machine running eslint-scope and uploaded them to the attacker. [Post-mortem]Potential Solutions
The usage of an open-source project can cause problems when both parties (i.e., the maintainer and user) are in a legal dispute or even war.
Cyber-warfare are causes by deliberate actions of the maintainer to harm or encumber the activities of a group of users.
Examples
node-ipc
containing malicious code that would delete files from Belarusian and Russian users. This concerned even frameworks such as Vue.js, which uses node-ipc as a dependency. [Full story]sweetalert2
containing malicious code that would activate for people with the Russian language activated in their browser, visiting Russian sites. The code essentially defaces the website viewed with anti-war messages. [Pull Request]Potential Solutions
The unpaid nature of open-source projects, in connection with increasing pressure from users for bugfixes or new feature sometimes brings maintainers to the edge of exhaustion. Mild versions of burnout can cause a maintainer just to abandon their projects while fully disgruntled maintainers might commit infocide (deleting all code and data) or introduce malicious code that causes harm to user's system.
Developer Burnout is causes by pressure from users, failure to monetize, disillusionment, sometimes in addition to private problems.
Examples
colors.js
and faker.js
after failing to monetize it and getting pushed too hard by corporates. [Original Message] [Github issue] [Full Story]core-js
after failing to monetize it and getting pushed too hard by parts of the community. [Original Message (very long)] [Github issue] [Short Story]Potential Solutions
cURL
, which is maintained by Daniel Stenberg seems to have a working monetization approach [Story]Author: Jörg Rech @ PayDevs.com et al.