【工程师维护开源项目，到底是摸鱼还是履职尽责？】

快速阅读：开源软件不是工程师的业余爱好，而是公司业务赖以生存的基础设施。与其在业余时间疲于奔命，不如将维护开源项目视为一项正当的工程任务，在工作时间内完成对依赖链的加固。

很多公司在享受开源红利的同时，却把维护者的贡献视为一种“慈善”。这种逻辑很荒谬：公司业务跑在开源代码上，却要求工程师在下班后的私人时间去修补这些漏洞。

其实换个说法，沟通效率会高得多。不要去求老板“允许我做点公益”，要告诉他：“我申请利用工作时间，向行业顶尖专家获取免费的代码评审，并把修复提交到上游，从而消除公司未来重复维护这些代码的成本。”这本质上是在处理技术债，是极其合理的工程决策。

但现实很骨感。有网友提到，在一些大厂，哪怕只是提一个 GitHub issue，都可能触发严苛的合规审查。甚至有人在入职时发现，合同里竟然规定即便在私人时间，所有的智力成果也全归公司。这不仅是法律边界的问题，更是职业尊严的问题。

有观点认为，如果管理层无法理解“维护依赖项就是维护基础设施”这一点，那这种公司本质上是在进行寄生式经营。

当然，这不意味着可以无底线地“摸鱼”。这需要一种极高的职业素养：严守商业秘密，确保提交的代码不包含公司私有逻辑，并且在法律层面理清 IP 归属。对于资深工程师来说，与其追求那种透支生命的“A级绩效”，不如追求一种可持续的、能让互联网灯火长明的“B级状态”。

毕竟，当公司因为裁员而消失时，你留在上游社区的代码，才是真正属于你的资产。

如果你在工作期间修复了公司依赖的库，这究竟是在“偷窃”股东的时间，还是在履行工程师保护系统稳定性的职责？

ossresistance.com