Home

Awesome

License: CC0-1.0 License: CC0-1.0 GitHub Twitter GitHub Reddit

NOTE: This list and classification is still not complete and should be seen as work in progress!

Awful OSS Incidents

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

Context

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.

xkcd comic © xkcd comics

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:

Incident Categories

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.

Trademark infringements

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

Potential Solutions

Programming mistake

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

Potential Solutions

Package Ownership Disputes

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

Potential Solutions

Usage Disputes

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

Potential Solutions

Security Problems / Hacked Accounts / Criminal Intentions

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

Potential Solutions

Cyber-Warfare / Protestware

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

Potential Solutions

Developer Burnout

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

Potential Solutions

Examples for working Monetization

Misc / Aftertoughts

<!-- * other maintainer account takeovers [`ua-parser-js`](https://github.com/advisories/GHSA-pjwm-rvh2-c87w) --> <!-- * NPM project reconstruction: ... might be problematic as copyright, brand, and name (handle) is owned by the author/maintainer and assuming the identity of the author is borderline illegal (at least the companies are liable and take warranty that the offered (old) versions are correct) -->

General Links

Author: Jörg Rech @ PayDevs.com et al.