Do the work
Review PRs, update dependencies and ship fixes where your work is already OSS.
đź“ś The Manifesto
Open Source software is not a “hobby” for your spare time. Literally every company you have worked for couldn’t run their business without any OSS. They extract value every hour and then ask maintainers to beg for a Friday afternoon, a donation button or a kind word in an all-hands.
We reject the begging. Maintainers inside companies should and can just take work time for the necessary work on the OSS code those companies already depend on. No paperwork required. No internal programme. No request for a manager’s blessing. Treat it like the infrastructure and technical debt work it already is and just crack on.
This is not a new idea. We’re just saying the quiet part out loud. It’s the way most open source has always been done. Maintainers keep the internet’s lights on without waiting for meetings, sprints or product managers to tell them what to do, when to do it and that it’s OK.
Review PRs, update dependencies and ship fixes where your work is already OSS.
Verify your contract, keep confidential information at work and make sure you own the open source IP you ship.
Don’t spend 100% of your work hours on OSS, get fired and blame anyone except yourself. This is about balance, not taking the piss.
🤝 Alternatives
The Open Source Pledge asks companies to pay maintainers (US$2,000 per developer per year). Open Source Friday asks companies to donate time (at least two hours every Friday). You can take the polite path and try to convince your employer first. All are net positive and worth supporting.
Alternatively, join The Open Source Resistance. We are the next step in this evolution. We state maintaining the dependency chain is already part of the job, even when management refuses to name it. Take things into your own hands. What’s in your locus of control? What a company does with its budgets is not. How you spend your working time is.
⚔️ Objections
Companies already extract value from open source maintainers every day. Shareholders have received free open source subsidies for decades. If your employer depends on OSS, maintaining it is infrastructure work on the commons, not theft. Companies made open source business-critical. For maintainers the balance is life-critical.
Asking permission preserves the power imbalance. Maintainers should not and do not need their manager’s blessing to maintain the infrastructure their employer already depends on. You don’t need to ask permission to go to the toilet any more either.
Quiet quitting produces less work. This produces the OSS infrastructure the internet is built on. The problem is not the work; it is that companies refuse to classify it as work. That is their problem, not yours.
Good employers avoid the issue by allowing open source maintenance during work time, funding maintainers and/or joining the Open Source Pledge. That is great for the ecosystem. It may still not maintain your project today. You can.
⚠️ Caveats and legal disclaimers
I am not a lawyer and this site is not legal advice. It is a political and ethical argument; not advice about your contract, your employer, your immigration status, your licence obligations or your specific situation. If your stakes are high, talk to someone qualified before acting.
As per almost all open source licences: no warranties are provided. This is supplied “as is”, without warranty of any kind, express or implied. If you lose your job: it is not my fault, but please let me know so I can publicly shame your employer here!
Employment contracts, handbook policies and invention assignment clauses can claim work created during employment, on employer equipment or within assigned duties. Some states limit those claims for work done on personal time and equipment, but the details matter.
Read your employment contract before doing this. Make sure your employer does not own the open source IP you intend to publish. If the machine, network or account changes ownership risk, use your own.
IP assignment is often negotiable. When you accept a job offer, ask for an open source carve-out in writing before you sign; read your employee IP agreement first so you know what to push back on. I have negotiated contract changes away from the standard at almost every employer I have worked for; most pushed back far less than you’d expect.
Point your prospective employer at GitHub’s Balanced Employee IP Agreement , it is open sourced under CC0, already used in production by a large public company and designed so the employer keeps what it pays for while the employee keeps the open source work that does not compete with the business. Ask for the same, or for the relevant clauses, by name.
Do not disclose private repositories, credentials, incidents, customer data, roadmaps, unreleased vulnerabilities or internal discussions. Do not use access you would not otherwise be allowed to use. Do not route around security controls.
Direct action is not an excuse for making private company information public. It is a reason to keep public work public and clearly separate from commercial secrets.
Undisclosed does not mean reckless. Use your own judgement when a policy, contract, client obligation or safety rule changes the risk. You may need to do this work on your own machines, accounts and networks. The point is not to “steal” from work. The point is to balance what your work takes from open source with what you can give to it.
You may get worse performance reviews than co-workers who spend every visible hour feeding the company machine. This is fine! A sustainable B grade is healthier than burning your life for an A grade at a company that can still fire you tomorrow and claim AI has replaced you.
This argument is weakest where your time is billed to a specific client, grant, government body, defence project or regulated environment. It is weakest for junior or precarious engineers without the leverage to absorb the downside. It is strongest for senior maintainers fixing the public dependencies their employers already use.
The cleanest version is not “do whatever you want during work hours”. It is “treat maintenance of open source as part of engineering work”. Maintain projects you already maintain. Improve shared tools your job touches. Skip anything unrelated, anything proprietary and anything that would make you miss a real commitment.