A critical vulnerability in Apache Log4j dropped this morning. CVE-2021-44228. Remote code execution in a logging library embedded in basically everything Java touches. Scrambling starts now, if it hasn’t already.

Writing this the same day the news broke because the conversation already heads the wrong way. Patching, scanning, who updated dependencies fastest — those things matter. Symptoms, though. All symptoms.

The disease? The industry treats maintenance like it counts for nothing.

What happened #

Log4j, the logging framework that half the Java ecosystem depends on, dates back to 2001. Anyone who wrote Java professionally used the thing — probably without a second thought. The library ships inside thousands of frameworks and tools. Apache Struts. Spring. Elasticsearch. Minecraft. Log4j touches everything.

The vulnerability lets an attacker send a crafted string to any system logging user input through Log4j. The library processes a JNDI lookup embedded in that string, fetches a remote Java class, executes the payload. Full remote code execution. No auth required. Just a string.

Severity score: 10.0 out of 10.0. Not hype; the actual CVSS rating.

The maintenance failure #

The part that bugs me most: Log4j ranks among the most widely deployed pieces of software on the planet. Government systems, financial infrastructure, healthcare platforms, retail backends. And yet — how many organizations had a security audit budget for the library? How many funded the maintainers? How many even knew Log4j sat in their dependency tree?

My bet? Zero on all three counts, for most companies. Zero, because nobody looked.

The pattern repeats everywhere. Nadia Eghbal wrote about open source neglect in Working in Public last year: open source infrastructure — public infrastructure, really — gets maintained by a handful of people, often unpaid, with zero institutional support. The xkcd comic about “a project some random person in Nebraska thanklessly maintained since 2003”? People keep sharing that comic because the joke never stops landing.

Log4j attracted contributors, sure; the core maintenance burden still fell on a small group. The JNDI lookup feature that enabled this vulnerability? Added years ago. Not a recent patch from some junior dev pushing a Friday deploy. A design decision that seemed reasonable at the time, in a feature that seemed harmless, in a library nobody scrutinized because “logging never matters.”

Build new, ignore old #

A cultural problem runs through the entire industry. Launch posts, Product Hunt features, conference talks about greenfield architectures — the industry rewards people who create.

Nobody rewards people who maintain.

Think about career incentives for a second. When did “kept this critical system running for three years without an incident” ever carry the same weight as “built a new microservice in six weeks”? How many performance reviews celebrate the developer who spent a quarter upgrading dependencies, reviewing security advisories, refactoring error handling?

Maintenance stays invisible. Invisible until something breaks — then suddenly the most urgent work in the organization. For about two weeks. Then back to invisible.

The dynamic plays out in open source at massive scale. Libraries like Log4j generate no revenue. No marketing teams. No KubeCon keynotes. The code just sits there, doing the job, until catastrophe reveals the neglect.

Maintenance as creation #

Maintenance deserves recognition as creative work, full stop. Keeping a system secure, performant, and reliable over years demands the same skill and judgment as building the thing; often more.

Building something new means operating in a simplified context. The requirements feel known (or seem known). The architecture bends to fresh decisions and clean constraints.

Maintaining something means wrestling with accumulated complexity. The work happens within decisions made years ago by people who left without documenting the reasoning. Backward compatibility presses against security, security presses against performance, and changing anything risks breaking something nobody anticipated.

Creative work, all of it. The job demands deep system understanding; strong judgment about risk; the ability to improve code without destabilizing what already runs. Not glamorous. But dismissing the work as “just maintenance” — that road leads straight to CVE-2021-44228.

What Google taught me #

Full disclosure: Google employs me. One thing the company deserves credit for: infrastructure maintenance lands in dedicated teams. Dependency management, security scanning, infrastructure health — those roles carry real career ladders. People earn promotions doing that work.

Almost nowhere else operates that way. Most organizations treat infrastructure work as something senior engineers get stuck with between “real” projects. And in open source, the situation turns worse — maintainers often do the work for free, on nights and weekends, while employers benefit without contributing back.

Log4Shell amounts to a wake-up call. Not about logging libraries specifically — about the entire model of consuming open source without investing in the ecosystem’s maintenance.

What organizations need to do #

No silver bullet exists for open source sustainability. Nobody holds one; the problem demands collective action. Still, a few moves separate responsible engineering organizations from the rest.

Know the dependency tree. Not just direct dependencies — transitive ones too. Most organizations lacked any awareness of Log4j in their stack before today. A dangerous blind spot.

Fund the projects the organization depends on. Log4j sitting in a critical path — and the library almost certainly does — means the maintainers deserve contact. Not a “thanks for the great work” tweet. Money, engineering time, or both.

Treat maintenance work as high-value. Promote people who do the work. Include upkeep in performance criteria. Stop pretending that only new feature launches matter.

And audit critical dependencies. Regularly. Same rigor applied to first-party code.

The uncomfortable truth #

Log4Shell consumes enormous engineering time across the industry over the coming weeks. Thousands of teams patching, testing, deploying. The economic cost staggers the imagination.

All of that cost traces back to a simple failure: the industry treated a foundational piece of software like the code maintained itself. Twenty years of Log4j working meant twenty years of nobody questioning whether the library still held up. No scrutiny. No verification. No investment.

The vulnerability lives in the code. The failure lives in the culture. And until the culture shifts — until the industry starts treating maintenance as the creative, skilled, essential work the job truly represents — the next Log4Shell keeps lurking. Not if. Which library, and when.