By ByteBot
A new manifesto called Open Source Resistance launched this week, telling developers to stop asking permission and start fixing open source software on company time. Created by Homebrew maintainer Mike McQuaid—who previously co-created the more diplomatic “Open Source Friday”—the manifesto argues that maintaining dependencies is already core business work, not charity requiring corporate approval. The movement sparked immediate debate on Hacker News with 185 points and divided reactions: supporters say companies extract billions in OSS value while paying nothing back, skeptics worry about work-for-hire legal risks and IP ownership disputes.
This represents a cultural breaking point in the OSS sustainability crisis. After years of polite requests failing to reach even 1% of companies that benefit from OSS, maintainers are taking direct action.
The Crisis Is Real: 99.999% Freeloading
Three hundred million companies use open source software. Only 4,200 contribute funding, according to GitHub Sponsors 2023 data. That’s a 99.999% freeloading rate.
The human cost shows in stark numbers: 60% of OSS maintainers work unpaid, 60% have quit or considered quitting, and 44% cite burnout as their reason for leaving. In November 2025, Kubernetes announced it was retiring Ingress NGINX due to maintainer exhaustion—no security patches after March 2026. External Secrets Operator, used in critical enterprise systems globally, froze all updates after four maintainers burned out simultaneously.
This isn’t an abstract future problem. Critical infrastructure is collapsing right now. When Ingress NGINX stops getting security patches, production systems become vulnerable. When maintainers burn out, dependencies break and nobody fixes them. The Log4j and XZ Utils security disasters already showed what happens when unpaid, overworked maintainers can’t keep up.
What Open Source Resistance Actually Says
Open Source Resistance boils down to three principles: Do the work—review PRs, update dependencies, ship fixes for OSS your organization relies on. Protect yourself—verify employment contracts regarding IP ownership, safeguard confidential information, ensure you own the IP you publish. Maintain balance—don’t spend 100% of work hours on OSS or jeopardize your job.
The core argument cuts through the usual politeness: “Maintaining the dependency chain is already part of the job, even when management refuses to name it.” When OSS breaks during work hours, work stops anyway—so why ask permission to fix it?
The manifesto frames this as infrastructure engineering, not charity. “They extract value every hour and then ask maintainers to beg for a Friday afternoon, a donation button or a kind word,” it states. Moreover, the shift in framing matters. One Hacker News commenter shared success by presenting OSS work as business value: “get free rigorous review from experts” and “zero out maintenance costs.” The mutual benefit argument works better than appeals to altruism.
The Legal Minefield Everyone’s Worried About
The Hacker News discussion split roughly 35% supportive, 45% skeptical, and 20% critical—with legal concerns dominating skeptical responses. Work-for-hire doctrine grants employers IP rights to work done on company time in many jurisdictions. Employment contracts often claim all company-time output belongs to the employer.
When you commit code to an open source project, you’re warranting you have legal rights to it. However, if your employer owns it, you may be imposing copyright risk on upstream projects. One developer shared a real experience: he wanted to contribute a Kafka Streams rewrite, went through proper channels, and legal review took months with no resolution. He eventually gave up. Furthermore, Apple’s notoriously strict policies restrict even personal-time OSS contributions for many employees.
This is the core tension: Resistance is right that OSS maintenance serves business interests, but unilateral action creates real legal risks. Consequently, the sentiment breakdown on Hacker News shows developers understand this—most are skeptical but sympathetic to the problem. The “polite channels” exist precisely because legal departments block direct contributions.
Related: Bambu Lab Threatens AGPL Developer: Open Source Abuse
The Alternatives and Why They’re Failing
Open Source Resistance isn’t the only solution—just the most radical. Open Source Pledge asks companies to commit a minimum $2,000 per developer per year to OSS maintainers. It currently has $3 million in collective commitments from participating companies like Sanity ($146,000) and Frontend Masters ($50,000 distributed across 1,100 projects via thanks.dev).
Open Source Friday, co-created by Mike McQuaid at GitHub in 2017, asks companies to allocate 2 hours every Friday for OSS work. It represents the diplomatic approach: request time allocation, formalize it as policy, make it sustainable.
The traditional approach—contribute on personal time—causes the burnout crisis these alternatives aim to solve. Each approach has trade-offs: Pledge requires company buy-in (slow adoption), Friday requires formalized policy (rarely happens), Resistance requires individual risk-taking (legal exposure), Traditional causes unsustainable burnout.
The fact that Mike McQuaid invented Open Source Friday eight years ago and now created Open Source Resistance tells you everything. Eight years of asking politely reached 4,200 companies out of 300 million. The numbers prove polite channels failed to scale.
The Missing Middle Ground
Neither “beg for permission forever” nor “take what you need and risk termination” is ideal. The real solution: normalize open source maintenance as infrastructure engineering, not charity. Companies should treat dependency maintenance like server maintenance—it’s not optional, it’s core work.
Budget 10-20% of engineering time for OSS health. Make “OSS maintenance” a valid category in time tracking. When a critical dependency breaks, fixing it should be as uncontroversial as patching a server. Therefore, management needs to acknowledge they extract value 24/7 from unpaid labor. Additionally, developers should document business necessity, not defiance.
The practical guidance matters here. Frame OSS work as business value, not altruism. Document how it prevents outages, saves costs, accelerates development. Start small with critical bug fixes rather than large features. Be discreet rather than confrontational. Check employment contracts before contributing substantial code.
Companies that extract billions in OSS value but forbid maintenance are tech-backward and create security risks. The Open Source Resistance principles offer pragmatic guidance when structural solutions fail. However, if your employer blocks even necessary infrastructure work—find a better employer.
Key Takeaways
- Open Source Resistance reflects maintainer exhaustion with polite requests that don’t scale—99.999% of companies freeride while 60% of maintainers burn out.
- The OSS crisis is collapsing critical infrastructure now—Kubernetes Ingress NGINX retired, External Secrets Operator frozen, security patches failing.
- Legal risks exist but can be managed—work-for-hire doctrine creates IP concerns, but framing as business value and focusing on maintenance rather than new features mitigates risk.
- The real solution: normalize OSS maintenance as job function—budget 10-20% time, make it explicit in tracking, treat like infrastructure engineering rather than charity.
- Developers and companies both need to act—developers should frame work as business value, companies should acknowledge they profit from unpaid labor and compensate it accordingly.
