Open Source Resistance: A Manifesto for Working‑Time Contributions

What the manifesto claims

The document, authored by long‑time maintainer Mike McQuaid, declares that developers should be allowed to spend a portion of their paid work hours fixing and improving the open‑source libraries their companies rely on. It rejects the current pattern where companies extract value from community code and then ask maintainers to fund their work through donations, sponsorship buttons, or occasional “open‑source Fridays”. Instead, the manifesto calls for:

1. Doing the work – reviewing pull requests, updating dependencies, and shipping fixes as part of normal duties.
2. Protecting yourself – confirming that employment contracts permit open‑source contributions, keeping confidential information out of public repos, and ensuring the company owns the IP that is released.
3. Balancing effort – allocating only a reasonable share of time to open‑source work so that core responsibilities are still met.

What’s actually new?

The ideas themselves are not novel. Open‑source contributors have historically patched the libraries they depend on without formal permission. What is new is the explicit framing of this practice as a right rather than a favor: the manifesto asks companies to treat open‑source maintenance as infrastructure work, comparable to paying down technical debt. It also consolidates several existing community‑driven proposals:

Existing effort	Main mechanism	Relation to the manifesto
Open Source Pledge	Companies commit $2,000 per developer per year to maintainers	Provides a financial safety net; the manifesto says money is nice but not required
Open Source Friday	Employees donate at least two hours each Friday to OSS	Encourages regular time‑boxing; the manifesto pushes for integration into normal work schedules
GitHub Sponsors	Direct sponsorship of individual maintainers	Supplements the argument that contributions should be compensated, but not a prerequisite

By positioning itself as the “next step”, the manifesto attempts to shift the conversation from optional programs to an implicit job responsibility.

Limitations and practical concerns

Legal and contractual hurdles

Even if a developer wants to contribute during work hours, the employment contract may restrict the release of code under certain licenses or require prior IP assignment. The manifesto advises checking the agreement, but in many large organisations the legal review process can be lengthy. Without clear corporate policy, a well‑intentioned contribution could expose the employee to disciplinary action.

Managerial buy‑in

The document assumes that managers will tolerate a few hours per week of open‑source work as long as deliverables are met. In practice, performance metrics often focus on feature delivery and bug resolution for internal products. Convincing a manager to re‑classify open‑source fixes as “infrastructure” may require data showing reduced downstream maintenance costs, which is rarely collected.

Risk of over‑commitment

The manifesto warns against spending 100 % of work time on OSS, but it provides no guidance on how to quantify a safe allocation. Teams without explicit time‑tracking may inadvertently allow a few developers to shoulder most of the maintenance burden, leading to burnout.

Impact on hiring and compensation

If companies adopt the manifesto’s stance, they may expect new hires to already be active maintainers. This could raise the bar for entry‑level positions and unintentionally favour candidates from open‑source‑rich ecosystems, narrowing the talent pool.

How to apply the manifesto in a real team

1. Create a policy document – Draft a short internal memo that lists the open‑source dependencies the team relies on and states that up to 10 % of each engineer’s time may be spent on their maintenance.
2. Map contributions to business value – Track metrics such as reduced version‑upgrade incidents or fewer security patches required after a contribution. Use these numbers in performance reviews.
3. Legal checklist – Work with the legal team to confirm that the company’s contributor licence agreement (CLA) covers the intended work and that no confidential data will be exposed.
4. Transparent reporting – Maintain a public or internal changelog of the OSS contributions made during work hours. This builds credibility and helps other teams see the benefits.
5. Fallback plan – If a manager refuses, employees can still participate in “Open Source Friday” or external sponsorships while continuing to negotiate internal policy.

Conclusion

The Open Source Resistance manifesto reframes a long‑standing informal practice as a legitimate component of a developer’s job description. It offers a clear three‑step approach and aligns itself with existing community initiatives. However, turning the idea into reality requires navigating legal contracts, securing managerial support, and preventing over‑commitment. Companies that manage these challenges stand to reduce technical debt and improve the reliability of the open‑source stack they depend on, while developers gain a more sustainable path to contribute.

---

Mike McQuaid’s background includes co‑creating Open Source Friday, leading the Homebrew project, and working on GitHub Sponsors. The manifesto is a personal ethical stance, not legal advice.