Coding Like the Dickens

The modern web is Dickensian at its core: glittering towers of technology, sprawling empires of enterprise, and beneath them, orphans keeping the machinery running. It is a true tale of grief, trial, and sorrow. Each open-source library is an Oliver Twist — small, overworked, essential — holding up trillion-dollar industries that would prefer not to ask how the sausage gets made. Orphans are useful precisely because they’re cheap, invisible, and disposable. The cruelty isn’t hidden; it’s structural. We’ve built our critical infrastructure on children of the codebase, and then convinced ourselves that resilience was somehow included.

Consider the irony: the people building the libraries you rely on daily are human. They have jobs, families, illnesses, bills. They die. And yet, in the eyes of the global digital economy, they are treated as if they’re immortal...and unworthy of compensation. Coding like the Dickens, indeed.

If you’ve been reading my other posts, you’ll notice a common thread: companies are externalizing costs while collecting benefits. It’s a theme that dates back to the industrial revolution, to the Victorian era. I’ll talk more about it in future posts, because it’s everywhere. It’s a force that drives much of the world’s economy. And it hurts us all in different ways, and to varying degrees.

From Local Workshop to Industrial Factory

In the early days, open source resembled a modest workshop more than a sprawling industrial plant. A few maintainers crafted their libraries carefully, tending each function and dependency as a skilled artisan might care for a lathe or loom. Contributions were voluntary; joy was found in creation, not in external reward. Users would arrive, pull up a chair, perhaps help with a minor fix, and leave with gratitude. Everyone understood the limits of human labor, and the pace was sustainable.

Then the scale shifted. The workshop was swallowed by the factory. The global web demanded endless output. The tiny artisans, the maintainers, were suddenly expected to staff assembly lines 24/7, producing code, reviewing pull requests, patching vulnerabilities. The machines they had lovingly built, their libraries, were no longer instruments of craft; they were cogs in a sprawling industrial apparatus. And yet, the pay? Minimal. The recognition? Scarce.

Trillions of dollars came to depend on open-source projects, the majority of which are shepherded by just one person each. Corporate giants and platform monopolies arrived like factory owners, expecting output without understanding the human cost...some people are nobody’s enemies but their own, yer know. Meals were skipped, nights consumed, personal lives surrendered...all in service of libraries the world could not afford to stop using. The workshop had become a Dickensian factory, and the orphans — skilled, invisible, indispensable, unpaid — became the laborers, expected to respond with, “Please, sir, I want some more,” in a masochistic quest for gruel and unusual punishment. Even a single bug could halt production elsewhere; a maintainer missing a week of work could ripple through the global software supply chain. Yet the orphans continued to toil under pressure and without relief, because the factory demanded it.

The lesson is stark: these are not whimsical wards in a communal hall; they are overworked laborers propping up a digital empire too vast for any single person to bear.

The Free Rider Crisis in the Factory

Josh Bressers’s survey of ecosyste.ms identifies 11.8 million open-source projects, 7 million maintained by a single human, and likely more in similarly dire straits. Each dependency is a machine likely run by a solitary human. Each machine is critical. Yet the world expects continuous output without regard for the laborer.

Corporate consumers act as industrial magnates who demand 24/7 production while refusing to contribute. They sit in offices far from the shop floor, complaining if a machine stalls, oblivious to the human laborer behind it. This is the free-rider problem writ large: benefits widely distributed, costs concentrated, labor invisible until catastrophic failure occurs. And those failures have occurred with increasing regularity:

• Left-pad: an 11-line JavaScript library that briefly brought npm to its knees; the entire ecosystem paused because a single person rage quit.
• Log4Shell: a logging library vulnerability whose discovery and remediation rested on very few shoulders, putting the entire web at risk.
• event-stream: compromised when its maintainer transferred control, exposing just how thin the chain of guardianship can be.

Burnout is rational; abandonment inevitable.

Even if these maintainers work tirelessly, skill asymmetry introduces latent risk: popular libraries may be widely used not because they necessarily are excellent, but because the herd believes they are. The industrial analogy makes the human cost impossible to ignore: the factory demands endless labor, yet provides neither protection, verification, nor safety. Pull requests arrive like hastily delivered tools to an empty workstation. Forks appear, but the majority of the factory still points at the old, unmaintained, and potentially flawed machine.

When incentives reward adoption and speed over stewardship, neglect is predictable...and priced in.

Mortality, Fragility, and Ghosts in the Machine

Every single-maintainer project is fragile. Life intrudes: maintainers become parents, care for sick relatives, fall ill themselves, lose jobs, or die.

Consider Annette, a hypothetical project owner. She worked full-time, patched her project code nightly, and merged pull requests over weekends. Then she was diagnosed with pancreatic cancer and died six weeks later. We need be careful how we deal with those maintainers, when every death carries to survivors thoughts of so many PRs unmerged — of so many things forgotten, and so many vulnerabilities which might have been repaired! Yet her library persists. Downloads continue. Dependencies resolve. But the human labor behind it vanished. The machinery hums, but the worker is gone.

Ghost workers staff the global factory, and few notice.

Annette was skilled, but even she might have taken a shortcut, misunderstood a corner case, or missed a subtle bug. Downstream developers continue to rely on her, and the wider factory relies on the herd’s trust that her libraries are correct. Popularity becomes a proxy for quality, and trust becomes systemic risk. When Annette died, not only was her labor gone, but the ecosystem lost a point of quality verification...a double fragility.

Now, contrast this with the corporate “factories” consuming these libraries. Corporations have Business Continuity Plans (BCPs) for catastrophic events: servers fail, data centers burn, employees leave. Contingency plans, succession strategies, and backup teams are in place. Yet these same corporations build critical infrastructure atop libraries that can’t have BCPs. There is no secondary maintainer in the wings, no documented succession plan, no redundancy to ensure continuity.

What makes this situation catastrophic is skill specificity. Unlike the unskilled labor of Victorian factory children, these libraries require tribal knowledge...an intimate understanding of why certain functions exist, the subtleties of API interactions, the historical context of past bugs. One cannot simply hand a library to a random contributor and expect continuity. Pull requests may be submitted, but when the sole maintainer is gone, there’s no longer anybody home to approve the requests. Forks may exist, but the world continues to point to the original project, unaware that a new “maintained” version exists. The knowledge transfer fails; the ecosystem teeters.

Thousands of companies depend on a library once maintained by Annette. Every pull request languishes. Every vulnerability festers. Every downstream project remains connected to a project with no living steward. Unlike a child at a Victorian loom, Annette is irreplaceable. And yet, the factory expects production to continue.

Pollution, Digital Smog, and Factory Waste

Neglect produces consequences far beyond individual failure. Orphaned libraries release digital smog: unpatched vulnerabilities, broken dependencies, cascading risks. These are economic externalities masquerading as technical inconveniences.

Unlike a replaceable assembly-line worker, each orphaned library is operated by a skilled artisan, a maintainer with intimate knowledge of the code. But skill is uneven. Some maintainers are brilliant, some competent, some…less so. Few downstream developers possess the expertise to verify the quality of the code they inherit. And the few who do, simply don’t have the time to review everything within their domains. When the artisan disappears, the machinery continues to hum, but the underlying quality may have always been suspect. Downstream projects inherit not just functional dependencies, but the compound risk of human absence and latent incompetence...a risk BCPs can’t mitigate.

Consider event-stream again. When a maintainer transferred control to an untrustworthy contributor, the digital smog rippled through countless dependent projects. Unlike a factory with redundant operators trained in multiple roles, there was no backup maintainer, no succession plan, no quality oversight. Forks exist, but the ecosystem is largely unaware, leaving the majority of users pointing to a library with no living steward...and, perhaps, no assurance that it ever worked correctly. The toxicity accumulates.

These failures propagate like industrial pollution through a river system. Each orphaned library is a chemical spill, invisible to most, yet corroding the ecosystem over time. Trust in the herd can be fatal. Unlike physical factories, where machinery can be calibrated, repaired, or inspected, these libraries rely on human knowledge, judgment, and integrity. When that knowledge disappears, or was never adequate to begin with, the hazard remains indefinitely.

The lesson is simple, if uncomfortable: digital infrastructure built on single humans produces unavoidable pollution. You cannot apply a patch without an artisan to approve it; you cannot transfer authority without a steward to guide the hand. And yet the factory continues to demand output, expecting resilience that the system is fundamentally incapable of providing.

Working Without Annette

GitHub Sponsors, OpenSSF initiatives, and bug bounties exist. Yet while 96% of companies rely on OSS, only 3% of project owners report compensation for it.

The tragedy is structural. Corporations treat libraries as machines in their factory, expecting output, continuity, and safety, all while maintaining robust BCPs for their internal employees and systems. Meanwhile, Annette, the now-deceased orphan pressed into service, has had none. The labor is invisible, the risk concentrated. The system survives temporarily because humans endure the impossible...for a time.

Without enforced support or succession, orphaned projects face inevitable collapse. Pull requests may arrive, forks may proliferate, but when working without Annette, continuity fails. Technical debt accumulates like soot in a poorly ventilated factory. The pollution is systemic, not local. This isn’t just a bus factor of one; it’s a business continuity factor of zero.

Even proposals like GitHub Sponsors or corporate contributions remain voluntary, disconnected from actual risk exposure. The factory consumes the output without assuming responsibility for the human keeping the machinery alive. Annette labored under the illusion that the factory will continue to operate smoothly...but in truth, each absence, burnout, or death introduces cascading fragility.

The structural fragility is clear: skilled labor can’t be replaced overnight, and human lives are finite. This is the tragedy of the commons in full Technicolor: the digital factory benefits from collective reliance on code while externalizing the human cost, with no enforcement, no incentives, and no safety net. Another example of costs externalized, benefits collected.

There isn’t a single solution to all negative externalities; a suite of remedies is warranted. Let’s look at some possible remedies for open-source software (OSS).

Adoption, Guardianship, and Resilience

What would real stewardship look like in a system if we truly acknowledged human limits? Some attempts have already been made to address it. The Open Source Pledge has a program with a per-developer minimum contribution. But the organization doesn’t actually handle the money; instead, companies are expected to choose among free open source software (FOSS) foundations. And it’s entirely voluntary, which does little to stop the problem of free riders.

And Germany has introduced the Sovereign Tech Agency, which aims to fund FOSS through a grant application system. While admirable in concept, in practice it risks burdening the very community it intends to help. The developer is expected to go to the trouble of learning how to write a grant application, then actually write it, and then submit it to the German government...without any assurance of anything in return. And because the funds are distributed politically, as all government grants are, the return is not only uncertain but unpredictable. That’s a heavy lift for someone already overburdened just keeping their code alive.

What’s missing is an impartial structural mechanism...a way to scale adoption and guardianship beyond goodwill and politics. Adoption at scale requires structure, and impartiality requires elimination of subjective criteria. What if the model already exists? The music industry solved a similar problem via the American Society of Composers, Authors and Publishers (ASCAP). Performers couldn’t individually license every bar, restaurant, or radio station. Instead, ASCAP collects blanket fees and distributes them back to artists based on usage. Open source could do the same. Call it the Open Source Software Collective for Assurance and Payments (OSSCAP): a collective that tracks usage across package registries and Software Bills of Materials (SBOMs), collects license fees from corporations, and pays the actual maintainers. Maintainers need do nothing more than register, and OSSCAP would distribute funds based on data collected from SBOMs. And the SBOM submissions could be automated as part of the build processes, so that there’s almost no corporate process overhead. Enforcement could happen through requiring proof of proper OSSCAP payments as part of SOC 2 audits, for example. SOC 2 audits and SBOMs are increasingly becoming table-stakes requirements. Companies could still opt out by avoiding SOC 2, but they do so at the risk of losing an increasing number of customers.

A model like OSSCAP would finally align incentives with reality: maintainers would be compensated in proportion to the risk they shoulder, and corporations would pay according to their use.

Until things change, though, the ghosts remain. The orphans continue at their stations, the machinery still humming. Trillions of dollars flow through code they wrote, yet some writers themselves are gone, others invisible, unpaid, irreplaceable. The empire they sustain never stops, even after humans behind it have vanished. Like Oliver Twist, they asked for just enough to survive, just enough recognition to matter. And still, the factory expects “more.”

Just this week, a compromised npm account pushed poisoned packages into code downloaded billions of times, reminding us that ghosts don’t just linger quietly...they sometimes haunt.

The question, then, is not whether we can afford to fund adoption, but whether we can afford not to. Before your next product review, list your top ten OSS dependencies...and think about who, exactly, is their guardian. The moral is stark: the digital economy runs on ghosts. When the next critical library fails, it will not be a technical glitch that collapses the system. It will be the absence of the hands that once kept it alive.

Ghosts of code. Ghosts of labor. Ghosts of oversight. The factory has no conscience.

And the Twist? When the next library collapses, the world may finally see the ghosts in its own machine...though by then, it may already be too late.