What is protestware?
Engineering culture and software practice
Protestware is software that a maintainer deliberately alters to make a political or personal point. It ranges from a printed message at install time to code that damages the systems of users in a particular country. The term spread in 2022 after several widely used open-source packages were changed by their own maintainers. Because most organisations depend on packages built by volunteers they have never met, protestware is a supply-chain risk that no licence or contract addresses.
What this means
Modern software is assembled, not written from scratch. A typical product pulls in hundreds of small open-source packages, each maintained by someone, often a single unpaid volunteer. Protestware is what happens when one of those maintainers changes their own package on purpose to send a message or to cause harm, rather than through a bug or an outside attacker.
The spectrum is wide. At the mild end, a package prints an anti-war message when it runs. At the severe end, code checks where a machine is located and destroys files if the answer is a particular country. The common thread is intent: the person who is supposed to be maintaining the software is the one who altered it.
The term has a name because it describes a distinct category of risk. It is not a break-in and it is not an accident. It is a trusted party using that trust to make a point, which is exactly why it is hard to defend against and why it unsettled the industry when it happened at scale.
Why it matters
A small firm shipping a web product may depend, indirectly, on hundreds of packages it has never audited. Each of those is a point of trust. Protestware shows that the trust can be broken from the inside, not just by an external attacker, and that a permissive open-source licence grants you no promise of continued good behaviour from the maintainer.
The direct impact of the 2022 cases ranged from embarrassing to damaging: consoles filled with gibberish, builds that broke, and in the worst case files overwritten on machines assigned to particular countries. For a business, the lesson is less about any single incident and more about exposure: if you do not know what you depend on, you cannot reason about this risk at all.
There is an uncomfortable other half to the story. The same volunteers who can break a package are the ones holding up a great deal of commercial software for free. Studies of open-source usage find that the vast majority of codebases contain open-source components, and that much of the ecosystem rests on a thin layer of under-resourced maintainers. Protestware is, in part, a symptom of that imbalance, which means the buyer's response cannot only be defensive; it also has to consider the health of the projects it relies on.
How it works
Where the term came from
The word gained currency in 2022. The most cited flashpoint involved the npm package node-ipc, whose maintainer added code that, on machines with an internet address resolving to Russia or Belarus, overwrote files, and later bundled a module that dropped a peace message onto users' desktops. The peace-message module and the file-wiping behaviour are different points on the spectrum, and the destructive version was recorded as a security vulnerability. A non-profit, the Open Source Initiative, published a widely read commentary in March 2022 arguing that such weaponisation harms open source itself; it quoted a security researcher describing the episode, in part, as deliberate sabotage.
An academic literature has since grown up around the phenomenon. A peer-reviewed study in the journal Empirical Software Engineering analysed developer reactions to two cases, colors.js and es5-ext, and built a taxonomy of the arguments people made, finding that most who took a side opposed the action and that discussions often turned toxic. A companion study presented through the ACM examined the impact of protestware as case studies. The point of naming and classifying it is to let organisations reason about it as a category rather than a one-off.
The spectrum from message to damage
It helps to picture a scale. At one end sits expressive protestware: a banner, a slogan printed to the console, a message file. It is disruptive and controversial but not destructive. In the middle sit changes that degrade behaviour, such as a package that deliberately enters an infinite loop and jams anything that uses it. At the far end sits destructive protestware that targets machines by location and damages data. A business needs to understand where an incident sits on that scale in order to judge its exposure, and no further detail than that is required to make sensible decisions.
The separate burnout story
The same period produced an episode that is often lumped in with protestware but is really a different story. In January 2022 the maintainer of the popular colors and faker packages deliberately broke them, publishing versions that printed gibberish in a loop and disrupted thousands of downstream projects. His stated grievance was years of unpaid work supporting large companies for free. This is a burnout and sustainability story, not a geopolitical protest, even though the mechanism, a maintainer sabotaging their own work, looks similar. Conflating the two misleads, because the remedy for burnout is funding and shared maintenance, while the remedy for political protestware is provenance and control. The academic literature treats both under the protestware umbrella while carefully distinguishing the motives.
How experienced teams defend against it
The defences are unglamorous and effective, and they are the same practices that guard against ordinary supply-chain accidents. Pin exact versions and commit a lockfile, so an update cannot arrive silently. Review dependency updates before adopting them rather than pulling in the newest version automatically. Maintain an inventory of what you depend on, often as a software bill of materials, so you can answer the question of what you actually ship. Stage rollouts and monitor behaviour so that a bad update is caught in a controlled environment. Consider a private registry or mirror so that you control which versions reach your builds. National guidance from the UK's National Cyber Security Centre and from the US CISA sets out these supply-chain principles in more detail.
The funding question
The defensive measures reduce your exposure but do nothing for the underlying fragility. Reports on open-source sustainability, including the Census work produced by the Linux Foundation with Harvard's Laboratory for Innovation Science, document how much widely used software rests on a small number of under-supported maintainers. A commercial user that depends heavily on a project can act: sponsor it, contribute maintenance time, or fund a support arrangement. This is not charity; it is risk reduction, because a healthy, funded project is far less likely to be sabotaged by an exhausted volunteer.
Examples
A software team of eight at a logistics start-up runs its builds so that every dependency is pinned to an exact version with a committed lockfile. When news breaks of a sabotaged package elsewhere in the ecosystem, they check their inventory in minutes, confirm they do not use it, and carry on. The discipline that felt like overhead turns out to be the thing that lets them answer the question calmly.
A council department commissions a supplier to build a public-facing form. During procurement, the department asks how the supplier manages third-party dependencies, whether it keeps an inventory, and how it reviews updates. The questions are not hostile; they simply establish that someone is responsible for what the software inherits. The supplier that has good answers is the safer choice.
A charity maintains a small analytics tool that quietly depends on a package built by one volunteer. Rather than wait for a crisis, the charity sets aside a modest annual amount to sponsor that maintainer and asks a staff member to contribute the occasional fix. When the maintainer later posts about burnout, the project is already in better shape than most, because someone chose to share the load.
Common misunderstandings
The first misconception is that protestware is a hack. It is not an outside break-in; it is the trusted maintainer deliberately altering their own package, which is what makes it hard to defend against with perimeter security alone.
The second is that all protestware is destructive. Most is expressive, printing a message; only a minority damages systems. Judging where an incident sits on that spectrum is the whole point of assessing it.
The third is that an open-source licence protects you. A permissive licence grants you the right to use the code; it grants no obligation on the maintainer to keep behaving well, and typically disclaims all warranty.
The fourth is that protestware is just another form of dependency hell. This is not the same as dependency hell, which is about version conflicts and incompatibilities arising by accident. Protestware is about deliberate maintainer action, so the response is provenance and trust, rather than resolving a tangle of versions.
The fifth is that the maintainer who breaks a package out of frustration is making the same point as one wiping files over a war. The burnout story and the political-protest story share a mechanism but have different causes and different remedies, and treating them as one thing leads to the wrong fix.
Risks and boundaries
Protestware is a real but relatively rare category, and the risk of over-reaction is genuine. Ripping out open-source dependencies wholesale is neither practical nor wise, given how much value they provide. The proportionate response is knowing what you depend on and controlling how updates reach you, not abandoning the ecosystem.
The term is misapplied when every maintainer dispute or broken build is labelled protestware. Most broken builds are ordinary bugs or version conflicts. The category specifically means deliberate alteration to make a point.
The ethical debate is live and this article does not settle it. On one side, protest is a form of expression, and maintainers own their work and their labour. On the other, indiscriminate code that harms users by location or jams downstream projects damages people who have no part in the dispute, including, as the Open Source Initiative noted, those who oppose the very thing being protested. A reader should be able to weigh both positions; the aim here is to assess supply-chain risk, not to adjudicate the causes involved.
What to do next
Build and keep a dependency inventory, so that when an incident is reported anywhere you can answer quickly whether it affects you. You cannot manage what you cannot see.
Insist on pinned versions, lockfiles and reviewed updates in your own teams and your suppliers, so that no change arrives silently and automatically. Stage rollouts and monitor for odd behaviour before anything reaches production.
Put a few plain questions into procurement. Ask suppliers how they track dependency provenance, how they review updates, and how they would respond if a package they use were compromised or sabotaged.
Look at your most critical dependencies and consider supporting them. Sponsorship, contributed maintenance or a funded support arrangement reduces the burnout that drives some of these incidents and is a legitimate risk-management step, not a donation.
Treat the political and ethical debate as context to understand, not something your organisation needs to take a public side on. Your job is to manage exposure and keep your systems dependable.
FAQs
When did the term protestware become widely used?
It spread in 2022, after several widely used open-source packages were deliberately altered by their maintainers, most prominently the node-ipc case.
Is protestware the same as a supply-chain attack?
It overlaps but differs in intent. A supply-chain attack usually involves an outside party, whereas protestware is the legitimate maintainer altering their own package on purpose.
Does it always cause damage?
No. Most protestware simply displays a message. Only a minority is destructive, such as code that targets machines by location and overwrites files.
How is protestware different from the colors and faker episode?
That episode was driven by a maintainer's frustration at unpaid work, a burnout and sustainability story, rather than a political protest, though the mechanism looked similar.
Can a licence or contract protect us?
A licence grants usage rights but no guarantee of good behaviour, and typically disclaims warranty. Protection comes from your own controls, not from the licence.
What are the practical defences?
Pin versions, use lockfiles, review updates, keep a dependency inventory, use a private registry where sensible, stage rollouts and monitor for unusual behaviour.
Where can we find authoritative guidance?
National bodies such as the UK's NCSC and the US CISA publish software supply-chain security guidance aimed at organisations of all sizes.
What can we do about the underlying fragility?
Support the projects you depend on through sponsorship, contribution or funded support, which reduces the maintainer burnout that drives some incidents.