内部开源的困境

「开源」这个词，大家肯定都不陌生了，今天想说一下和它相似的另外一种协同模式：「内部开源」，全称是「公司内部的开源」。

近年来，越来越多的优质人才涌进互联网行业，公司人变多了，极大程度上满足了公司业务发展的需要，但也带来了一些小的负面效应，其中就包括：卷起来了。比如某 A 姓互联网大厂，拿前端举例，今天 X 部门搞了个 UI 组件库，明天发现 Z 部门也搞了一个，组件库的作者拿着这套代码升了职，就再也没维护过。后来越来越多的人开始效仿，公司内的组件库变得越来越多，而这些在组织层面都没什么好处的，除了内卷，就是内耗。

解决这个问题，其实从大方向上看，很简单，那就是大家都去开发、维护同一套组件库，收敛人力，本着开源的精神，这个组件库肯定也会越变越好。

理想很丰满，那现实怎么样呢？下面是我以第一人称视角、结合自己的体验的、看到的、听到的总结出来的一些问题，内容纯属胡掰，如有雷同，可以交个朋友。

开源精神 vs KPI

虽然是「内部开源」，但也是「开源」，就不得不扯到开源精神。虽然我活跃在 Github 上已经有快 5 年的时间了，也有过接近 100 star 的个人项目，但我还是无法准确地对「开源精神」下定义，不过倒是能提供一些关键词：不逐利、自由、开放、平等、极客… 其实每个词都包含了很多层理解。从这些关键词就能看到：开源和“打工人来上班赚钱”这件事情从骨子里就有一些冲突。打工人在工位上花时间写开源代码的时候，肯定都会不自觉地问自己：这事能让我升职加薪吗？

能力不合格的人选

如果迫于某些问题，内部开源变得很紧迫（看似很紧迫？），项目的参与人选会通过一些筛选到岗，不过筛选条件不是“谁愿意”和“谁能行”，而是“谁有空”。这是个比较糟糕的事情。对比一下团队招人，候选人通常会面临一轮又一轮的技术测评和综合素质测评，通常由直属 leader、部门 leader 和 HR 共同把关，只有通过了这些测评，才意味着候选人有能力和现有团队一起共事。而内部开源，尤其是被迫开始的内部开源，那些“有空”的不合格人选得到了和现有团队一起共事的机会，这无疑是对现有团队技术规范和协作模式的一种挑战（or 破坏）。

跨团队技术管理困难

公司内部的项目往往都是业务驱动的，而在业务型产品中做技术管理，是件不容易的事情。当问题又加上了「跨团队」的 buff，情况可能会更糟糕。

拿我的真实经历举例子。

当得知自己团队的 A 项目即将迎来开源共建时代的到来，加班加点的在工具层面做了代码规范强校验的限制（husky + commitlint + eslint + lint-stage），也根据代码的提交情况，把有问题的代码拎出来公示在 Issue 里并附带改造方案。但是结果并不乐观，比如：

• 索性关掉代码检查
• 相同的问题反复出现
• 大量地复制粘贴，不思考复用的可行性
• 缺少有效注释
• 代码易读性和可维护性差

其实还有很多问题，都需要额外消耗精力去解决。如果精力不够，项目代码的熵越来越高，用不了多久就会变成屎山。

需求跟踪困难

参与开源的团队多了，需求方也多了。这些来自四面八方的需求如何做到统一评审？如何保证需求评审不是走形式？对于有争议的需求，谁能决策到底做不做？怎么确保需求的提出和实现是统一的？开发者们的代码实现了，有没有人力来测试？这些现实问题都很棘手。

最后

总结两条：

• 「内部开源」是把双刃剑，用对了地方，能产生很大的价值，但如果用错了，会造成很多不好甚至是不可逆的后果。
• 不管是什么范围内的开源，参与的「人」不靠谱，在别的地方整啥花活都没用。