你公司的业务跑在开源软件上，但维护这些代码的人，却在下班后偷偷修bug。
这不是段子。全球无数企业的核心系统依赖开源组件，从Linux内核到Python库，从数据库到前端框架。但"开源维护"这件事，长期以来被包装成一种业余爱好—— something you do for fun, on your own time。公司白天榨取价值，晚上让程序员用爱发电。
一群开发者受够了这套逻辑。他们发起了一场名为"开源抵抗"（Open Source Resistance）的运动，核心主张直白得近乎挑衅：维护你工作中依赖的开源软件，本来就是工作的一部分。不需要申请，不需要走流程，不需要等老板点头。
他们的宣言写得像战斗檄文："我们拒绝乞讨。"
这不是要程序员把100%工作时间砸进开源、然后被辞退。它强调的是一种认知重构：当你的公司每天从开源生态提取价值时，你花几小时review一个PR、更新一个依赖、修复一个安全漏洞，本质上和修服务器、还技术债没有区别。都是基础设施维护，都是让业务继续运转的必要劳动。
运动的发起者承认，这个想法并不新鲜。"我们只是把大家心知肚明的事说出来了。"大多数开源维护历来就是这么做的——程序员在工位上顺手修个bug，在会议间隙回个issue，没人把这当成需要特批的"额外贡献"。互联网能运转至今，靠的不是周五下午的"开源慈善时间"，而是无数维护者默默的日常投入。
当然，他们划了几条红线：先确认你的劳动合同，确保不泄露公司机密，确认你拥有所提交代码的知识产权。以及，别做得太过火被开除，然后怪别人没提醒你。
这场运动的出现，恰逢"企业如何回馈开源"的讨论升温。Open Source Pledge倡议公司按每位开发者每年2000美元的标准资助维护者；Open Source Friday呼吁企业每周五至少给员工两小时做开源贡献。这些都是温和路线——试图用礼貌的说服，让企业主动打开钱包或调整日程。
"开源抵抗"把自己定位为"下一步"。他们认为，等待企业自愿改变权力结构是低效的。预算决策在公司高层手里，但你每天怎么分配八小时，是你能控制的。与其花三个月说服CTO设立"开源贡献KPI"，不如今天就把那个搁置已久的依赖升级做了。
反对声音 predictable：这算不算摸鱼？算不算侵占公司资源？
运动的回应同样直接：企业已经从开源维护者身上免费提取了几十年的价值。股东们享受着开源带来的成本优势，却不必为此支付溢价。如果你的雇主离不开某个开源项目，那么维护它就是维护公共基础设施，不是盗窃。"是企业把开源变成了业务关键，对维护者来说，这关系到生计关键。"
更深层的批评指向权力本身。"请求许可"这件事，本身就维持了不对等。维护者不需要经理的批准才能修复公司依赖的基础设施，就像不需要申请就能去洗手间。把开源维护特殊化、仪式化，恰恰是让企业得以继续把成本外部化给个人志愿者的机制。
这场争论没有标准答案。不同公司的合同条款、不同司法管辖区的劳动法、不同项目的治理结构，都让"在工作时间做开源"的实际风险千差万别。有人选择先走正式渠道申请，有人选择quietly just do it，有人跳槽去了把开源维护写进JD的公司。
但"开源抵抗"至少抛出了一个值得追问的问题：当开源软件成为数字经济的基石，我们是否真的接受了"维护它靠业余爱好"的叙事？还是说，这种叙事本身就是企业利益最大化的产物？
一个数据点：根据GitHub 2023年报告，全球开源维护者中，只有不到15%能获得任何形式的资助。与此同时，Fortune 500公司中，超过90%将开源软件列为关键业务依赖。
这个缺口，正在以 burnout、项目 abandoned、供应链安全事件的形式显现。Log4j漏洞的集体恐慌过去没几年，xz后门事件又敲了一次警钟。当关键维护者因为"养不活自己"而退出，整个系统都在承担风险。
"开源抵抗"的激进之处，不在于它提出了什么全新方案，而在于它拒绝继续假装这是个可以通过"更多慈善"解决的问题。它把开源维护从道德高地拉下来，还原成一份普通的技术工作——有价值，该被支付，可以在工作时间内完成。
至于企业会不会最终接受这个框架，运动的发起者似乎并不乐观，也不特别在意。"你能控制的是你怎么花你的工作时间。"这句话的潜台词是：改变可以从一个人、一个PR、一个被修复的bug开始。
毕竟，开源协作的本质从来如此。没有人拥有全局的控制权，但每个人都有局部的能动性。
热门跟贴