Open Source Resistance: keep OSS alive on company time
275 points
• 5 days ago
• Article
Link
这份宣言主张：在公司工作的开源软件维护者，不应再为修复和维护其雇主已经依赖的开源代码而事事请示许可。核心观点是，维护开源基础设施本身就是一项正当的工作，而不是只能挤到个人时间去做的爱好。公司每天都在从开源中获益，维护者在工作时间做这类关键性基础设施工作是合理的，不应被要求走繁琐的审批或寻求上级"赐予"的许可。作者把这种做法称为"默默抵抗"——在上班时间专业地完成必要工作，把它当作任何技术债务或基础设施任务一样对待。
宣言提出三条原则。第一，去做该做的事：审查 pull request 、更新依赖、在你的工作范围内发布修复。第二，保护自己：核实雇佣合同、将公司机密隔离出来，并确保你对所贡献的开源代码拥有相应的知识产权或许可。第三，保持平衡：这不是要把全部工作时间都投入开源或以此冒险丢掉饭碗，而是在日常工作中可持续地把必要的维护工作纳入其中。
作者承认存在其它路径，例如 Open Source Pledge（公司向维护者付费）或 Open Source Friday（公司拨出时间）。这些都是积极的进展，但本宣言主张在管理层拒绝把开源维护正式视为工作时，个人可以采取更直接的行动。重点放在个人能控制的事，比如如何安排自己的工作时间，而不是被动等待公司的预算或政策变化。
针对常见反对意见，作者反驳这是"偷窃"的说法：公司几十年来一直在享受免费的开源红利，维护关键基础设施并不是在掠夺股东利益。要求维护者每次都要请示的做法只是维持一种权力不平衡，把人当成必须额外牺牲私人时间的资源。这与"安静辞职"不同：这里做出的工作是必要的基础设施维护，只是被公司拒绝承认为正式工作。优秀的雇主已经允许这种做法，本宣言针对的是那些不允许的公司。
作者 Mike McQuaid 以他作为 Homebrew 长期维护者和 GitHub 员工的经历为例说明实践可行性。他在每份工作中都谈妥了知识产权协议以合法化开源贡献，自从有了孩子之后，他超过 90% 的开源贡献都是在工作时间完成的。他强调，没有人应被要求为企业依赖的工作无偿贡献私人时间，维护者需要让自己的工作方式可持续，而不是等待他人来解决这个问题。
宣言同时声明这不是法律建议，个人在具体问题上应咨询专业律师。雇佣合同、公司政策和发明归属条款可能会主张对雇佣期间完成工作的权利，因此维护者应在开始前认真阅读合同并争取书面的开源例外或知识产权约定。作者建议以书面形式要求开源豁免，并以 GitHub 的 Balanced Employee IP Agreement 作为参考范本。保密与安全也很关键：维护者不得泄露公司机密、不得绕过安全控制。
作者也承认这种做法的局限性：在按客户计费的时间、初级工程师缺乏谈判筹码或受监管行业中，这种做法风险更大；相反，对于为雇主修复其正在使用的公开依赖的资深维护者，这种做法最为可行。最理想的情形是把开源维护作为工程工作的一部分——维护你已经参与的项目、改进与你工作相关的共享工具。
总体目标不是"从工作中偷走时间"，而是平衡企业从开源中获得的利益与你能回馈的贡献。未向公司披露并不意味着鲁莽行事；在政策或合同发生变化时，维护者应当凭判断评估风险。与其为一个随时可能用新人替代你的公司耗尽精力，不如通过可持续的方式把开源维护纳入职业生涯中，这对个人和社区都更健康。
This manifesto argues that open source software maintainers who work at companies should stop asking for permission to fix and maintain the open source code their employers already depend on. The core idea is that maintaining open source infrastructure is legitimate work, not a hobby to be done only on personal time. Companies extract value from open source every day, and it is reasonable for maintainers to use work hours for this essential infrastructure work without needing formal approval, paperwork, or a manager's blessing. The author frames this as "quiet resistance" — doing the necessary work professionally and on company time, treating it like any other technical debt or infrastructure task.
The manifesto outlines three main principles. First, do the work: review pull requests, update dependencies, and ship fixes where your work already involves open source. Second, protect yourself by verifying your employment contract, keeping confidential information separate, and ensuring you own the open source IP you contribute. Third, maintain balance: this is not about spending 100% of work hours on open source or getting fired, but about integrating necessary maintenance into your regular work life sustainably.
The author acknowledges alternatives like the Open Source Pledge, where companies pay maintainers, and Open Source Friday, where companies donate time. These are seen as positive steps, but the manifesto positions itself as the next evolution: taking direct action when management refuses to formally recognize open source maintenance as work. The focus is on what individuals can control, like how they spend their working time, rather than waiting for company budget decisions.
Addressing objections, the author counters that this is not theft, as companies have benefited from free open source subsidies for decades. Maintaining critical infrastructure is not stealing from shareholders. The argument that maintainers should ask permission is dismissed as preserving a power imbalance, comparing it to not needing permission for basic necessities. This is distinguished from quiet quitting, as it produces essential infrastructure work that companies refuse to classify as legitimate. Good employers already allow this practice, and the manifesto targets those that do not.
The author, Mike McQuaid, shares his personal experience as a long-time Homebrew maintainer and GitHub employee. He has negotiated IP agreements at every employer to legitimize his open source work and now does over 90% of his open source contributions during work hours since having children. He emphasizes that nobody is entitled to unpaid personal time for work that businesses depend on, and maintainers must make their work sustainable without waiting for others to solve the problem.
The manifesto includes important caveats: it is not legal advice, and individuals should consult qualified professionals for their specific situations. Employment contracts, policies, and invention assignment clauses can claim work created during employment, so maintainers should read their contracts and negotiate IP agreements before starting. The author recommends asking for open source carve-outs in writing and points to GitHub's Balanced Employee IP Agreement as a model. Confidentiality and security are critical: maintainers must not disclose private company information or bypass security controls.
The author acknowledges limitations: this approach is weakest for client-billed time, junior engineers without leverage, or regulated environments. It is strongest for senior maintainers fixing public dependencies their employers use. The cleanest version is treating open source maintenance as part of engineering work, maintaining projects you already work on, and improving shared tools your job touches. The goal is not to "steal" from work but to balance what work takes from open source with what you can give back. Undisclosed does not mean reckless, and maintainers should use their judgment when policies or contracts change the risk. A sustainable performance review is healthier than burning out for a company that could replace you tomorrow.
84 comments • Comments Link
• 将开源贡献表述为公司的商业利益而非个人慈善，是获得雇主批准的关键。把贡献定位为免费获得专家级代码审查并通过向上游修复来消除未来维护成本，这符合公司利益，且实践中证明有效。
• 一位开发者在能将其对 Kafka Streams 的重大改进开源之前被裁员——这些改进包括带背压语义的非阻塞 IO 。该工作仍为专有，但由于时间已久且未涉及专利，他们正在考虑从头以 FOSS 方式重新实现。
• 修复开源项目中的 bug 通常为雇主可接受，但新增功能则需更严格的法律与合规审查。在贡献前取得适当审批很重要。
• Apple 对 FOSS 贡献极为谨慎，即便是在个人时间，哪怕只是修复 bug 或提交 GitHub issues 这类简单行为也会受到严格限制。在公司时间内这种谨慎可理解，因为公司需要审计是否可能泄露商业机密。
• 一些公司在招聘时要求提供 GitHub 资料，并在合同中加入排他性雇佣条款，禁止任何外部贡献，即便在个人时间。这类条款在许多司法管辖区属非法，应拒绝或重新谈判。
• 一位开发者成功将标准的"我们拥有你所有工作"的条款协商为"你所有工作将以 GPL 发布"，说明有关知识产权归属的合同条款是可以修改的。
• Kafka Streams 在阻塞 IO 方面存在设计限制，尤其在替换用作外部状态存储的系统（如 Redis 或 PostgreSQL）时问题明显，因为往返延迟成本高。具有内置批处理语义的非阻塞方法能更好地摊销这些成本。
• 法务常在复杂的知识产权归属问题上陷入僵局，例如在可向客户计费的工作时间内写的补丁是否可公开发布，尤其当合同将所有 IP 转让给客户时。这些问题往往没有明确答案，妨碍贡献。
• 在大多数司法管辖区，雇主默认拥有工作时间内创建的代码权利，这也适用于在公司设备上或办公时间内编辑的代码。一些合同甚至宣称拥有从工作中获得知识派生的知识产权，但其可执行性各不相同。
• 加州劳动法第 2870 条禁止雇主主张个人时间开发且与工作无关的知识产权，从而为加州开发者提供了重要保护。
• 一种务实做法是在个人时间、使用个人硬件、且不与工作职责或在工作中获得的知识重叠地开展项目。如果发生争议，这种做法能保持清晰界限。
• 部分公司有合理的开源政策，只需事先告知经理、不以公司名义行事、且不发布机密信息。这种方式在实践中运作良好。
• 随着资历增长，面试公司时可以询问其对团队所依赖 OSS 项目贡献的态度。公司的回答有助于评估是否值得加入。
• 宣言作者维护 Homebrew，认为公司内部的维护者应在工作时间里花足够时间维护那些公司受益的开源项目，而不是通过 Open Source Pledge 或 GitHub Sponsors 等外部项目"礼貌地"请求公司贡献。
• 责任问题使开源贡献复杂化，因为公司担心代码将来可能成为诉讼对象。法务需要能够证明风险的合理性。
• 许多公司对请求开源贡献时间的回答是"在你空闲时间做"，即便已给出理由。以利润为导向的环境优先考虑短期价值，而非长期生态系统健康。
• 一些公司以前会为个人项目分配时间（例如每周四小时），但在 COVID-19 等财务压力时期取消了这些安排。
• 本宣言面向那些在公司内部默默建立可持续 OSS 实践的维护者，这些公司依赖他们的工作。宣言承认并非每个人都会获准，个人应在贡献前确保获得允许。
讨论突出了开源贡献的实际利益与法律 / 合同障碍之间的紧张关系。许多开发者通过将贡献表述为公司利益而获得成功，但也有开发者面临严格公司政策或冗长法律审查，实质上被阻止参与。对话强调了各司法管辖区的显著差异（加州对个人项目保护力度明显高于荷兰等地），以及实现公司允许贡献的方式多样——从低调的个人行动到正式政策变更。作者的宣言主张更积极的做法：维护者应直接投入所需时间来维护对公司有益的开源项目，而不是局限于礼貌式的请求许可。 • Framing open source contributions as a business benefit rather than personal charity is key to gaining employer approval. Positioning contributions as a way to get free expert code review and eliminate future maintenance costs by upstreaming fixes aligns with company interests and has proven effective in practice.
• A developer was laid off before being able to open source significant improvements they made to the Kafka Streams library, including non-blocking IO with backpressure semantics. The work remains proprietary, but they're considering reimplementing it from scratch as a FOSS project since enough time has passed and there were no patents involved.
• Fixing bugs in open source projects is generally acceptable to employers, but adding new functionality requires more careful legal and compliance review. Getting proper sign-offs before pursuing contributions is important.
• Apple was extremely strict about FOSS contributions, even on personal time, even for simple actions like bug fixes or opening GitHub issues. This caution is understandable when working on company time, as companies need to audit for potential disclosure of trade secrets.
• Some companies ask for GitHub profiles during recruitment and later include exclusive employment clauses prohibiting any outside contributions, even on personal time. Such clauses are illegal in many jurisdictions and should be refused or renegotiated.
• One developer successfully negotiated replacing a standard "we own all your work" clause with "all your work will be released under the GPL," demonstrating that contract terms around IP ownership can be modified.
• Kafka Streams has design limitations around blocking IO, particularly problematic when substituting external state stores like Redis or PostgreSQL where round-trip latency becomes expensive. A non-blocking approach with built-in batching semantics would better amortize these costs.
• Legal departments often get tangled in complex questions about IP ownership, such as whether a patch written during hours billed to a customer can be released publicly when the contract transfers all IP to the customer. These questions frequently go unanswered, blocking contributions.
• In most jurisdictions, employers own code created during working hours by default. This extends to code edited on company devices or during office hours. Some contracts also claim IP derived from knowledge acquired at the company, though enforceability varies.
• California Labor Code Section 2870 prohibits employers from claiming IP developed on personal time that's unrelated to company work, providing important protections for developers in that state.
• A practical approach is to work on personal time, using personal hardware, without overlapping with job duties or knowledge gained at work. This keeps things clean if disputes arise.
• Some companies have reasonable open source policies that simply require asking your manager first, not acting in the company's name, and not releasing confidential information. This approach has worked well in practice.
• With seniority, developers can interview companies by asking about their position on contributing to OSS projects the company relies on. The answer helps determine if the company is worth joining.
• The author of the manifesto maintains Homebrew and argues that maintainers inside companies should take the work time they need to maintain open source projects those companies benefit from, rather than asking companies nicely to contribute through programs like Open Source Pledge or GitHub Sponsors.
• Liability concerns complicate open source contributions, as companies worry about code that might later become subject to litigation. Legal departments need to be able to justify the risk.
• Many companies respond to requests for OSS contribution time with "do it in your free time," even when justification is provided. Profit-oriented environments prioritize immediate value over long-term ecosystem health.
• Some companies previously allocated time for personal projects (e.g., 4 hours per week) but eliminated these programs during financial difficulties like the COVID-19 pandemic.
• The manifesto is intended for maintainers who have quietly built sustainable OSS practices inside companies that depend on their work. It acknowledges that not everyone will approve and that individuals should ensure they're allowed to contribute before doing so.
The discussion reveals a tension between the practical benefits of open source contribution and the legal/contractual barriers that prevent it. While many developers have found success by framing contributions as business benefits rather than personal projects, others face strict company policies or lengthy legal review processes that effectively block participation. The conversation highlights significant jurisdictional differences, with California offering stronger protections for personal projects than places like the Netherlands. There's a growing sentiment that companies benefiting from open source should allow contribution time, though the mechanisms for achieving this range from quiet individual action to formal policy changes. The author's manifesto represents a more assertive approach, arguing that maintainers should simply take the time they need rather than asking permission through polite channels.