大厂争先成立的 “开源办公室” 有啥门道？

Posted 2022-06-13 程序员大咖

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了大厂争先成立的 “开源办公室” 有啥门道？相关的知识，希望对你有一定的参考价值。

👇👇关注后回复 “进群” ，拉你进程序员交流群👇👇

文 | lola

出品 | OSC开源社区（ID：oschina2013）

最近，有消息称字节跳动在内部邮件中正式官宣了 “开源委员会” 的成立。其实，这在国内大厂里并不少见，华为腾讯百度等都早已成立了自己的 “开源办公室”，字节跳动的动作更像是一种 “顺势而为”。

“软件吞噬世界，开源吞噬软件” 这句话都已经被说烂了，因为事实就摆在那里，现代应用程序已经被开源组件所占领，企业既绕不开也躲不掉。况且，开源软件还能为组织带来节省成本、提高代码质量等诸多好处。

因此，企业内部针对开源成立专门的组织机构几乎是命中注定。Open Source Program Office（简称 OSPO），也就是我们所说的 “开源办公室”，就是这样的背景下诞生的。

事实上，国外企业在 OSPO 上的脚步，要比国内走得更快更远。早在 2004 年，谷歌就已经成立了自己的 OSPO，这也是最早成立的一批 OSPO。随后，微软、Adobe、Netflix、英特尔等知名科技公司纷纷跟进，普及速度迅速。

在 Linux 基金会名下，有一个专门致力于普及 OSPO 的工作组，叫做 TODO。TODO 最近的一项调查发现，虽然 OSPO 在科技行业的普及率仍然是最高的，但是在教育和公共部门等也正在兴起。OSPO 开始渗透到国外的大学、政府和民间机构当中。

可以预见的是，OSPO 的实践也会渐渐地在我国普及开来。但是，我们对 OSPO 的认识却又少之又少。在观察了各家企业的 OSPO 实践之后，小编总结了 OSPO 在设置上的以下几个特征：

1、企业不搞，员工也会 “暗搓搓地” 搞

现实情况中，就算企业不搞开源，也不能避免员工会遇见开源代码。很多人在讨论，一些企业对于开源持有抵制态度，会限制对开源软件的使用，其实不然。在十多年前，这种情况是有可能的，比如说微软在坚决反对开源的时候，的确有听闻他们会禁止员工参与和阅读开源代码。但随着对开源态度的转变，微软现在的开源参与情况大家都有目共睹。

因此，一个企业对于开源的态度重点其实不在于反不反对，而在于重不重视。企业很少会阻止自家员工去接触开源，但是如果这个企业足够重视的话，它不会放任这些内部的开源力量是散漫无组织的状态。

这一路径基本符合大多数公司 OSPO 的建立过程。比如雅虎、优步等，都在官方的陈述中表示自家的开源之旅是由小部分热情的工程师 “非正式” 地开始的。

然而，仅凭工程师的兴趣和热情是不够的，不加以规范和约束往往会造成问题。就拿刚刚成立 OSPO 的字节跳动为例，它在开源合规性上吃了不少亏。2021 年 10 月，抖音前端团队宣布开源其设计系统和 UI 库 Semi Design，却涉嫌抄袭；2021 年 12 月，抖音海外版还因为违规使用 OBS 等源码，被推上了舆论的风口浪尖。一系列的事件这让字节意识到了问题的所在，于是今年他们开始成立 OSPO，引入公司级的开源策略、规范和流程机制，也就不奇怪了。

无独有偶。从 2010 年开始，Twitter 的开发人员开始发现回馈开源项目是一件很难的事情，因为公司的法律部门对代码许可和相关问题非常担忧。针对这一问题，Twitter 最后找到的解决方案是 —— 创建 OSPO，把合规流程抓起来。

基本上，对公司和员工来说，成立 OSPO 是一个双赢局面。规范流程让工程师们在一定支持的情况下，安全地参与到开源中去；而公司也可以借此防范风险、留住人才。

2、OSPO 团队普遍 “人少”

OSPO 作为一个不产出收益的办公室，自然是编制越精简越好。一些说法认为，每 1000 名开发人员中大约需要 1-5 人负责监视 OSS 相关活动。因此，绝大多数企业的 OSPO 其实是一个很小的团队。

当然，这个比例并不是定死的，更多情况下要视企业自身而定。例如，倾向于在集团层面进行统一管理的 Bloomberg 在 6500+ 开发人员的规模下，其 OSPO 仅有两名全职；而对细节管理比较注重的 Comcast 尽管才 1000+ 开发人员，它的 OSPO 团队也达到了 5—10 人。

谷歌 OSPO 办公室经理 Will Norris 曾透露，他们办公室只有大约 15 名团队成员，其中包括了一个合规团队、两名律师、一个负责活动参与的外展团队和一个技术团队。这 15 人要服务的是谷歌 72000 多名员工。

当然，全职团队虽小，但一些企业会采取 “虚拟职位” 的形式。所谓 “虚拟职位” 是说：这些职位是虚的，员工是在兼职干这件事，他们有自己的本职工作和实际部门。这取决于 OSPO 必须与公司内多个不同部门合作的特性。

其中的经典例子就是 SAP，SAP 在 2018 年初成立了自己的 OSPO，将其开源项目办公室组建为一个虚拟团队，由来自不同领域的多个团队组成董事会。

字节跳动此次成立的开源委员会，也采用来虚实结合的运作方式。也就是说，全职同学 + 不同研发团队的兼职同学，以最大程度地复用各个团队已经做过的工作。

还有一个非常特殊的例子就是 Netflix。实际上，Netflix 并没有正儿八经地成立开源办公室，而是通过一个小型的跨职能工作组来管理开源事宜。该工作组在内部邮件列表进行讨论，每月举行一次非正式会议。当然，也有观点认为 Netflix 之所以能这么做，是因为它更多是一家流媒体公司，而不是一家软件公司。

3、但职能一点也不少

OSPO 到底需要干点什么？在 Linux 基金会 TODO 小组的定义中，OSPO 的职能包括设置代码使用、分发、选择、审计相关政策、培训开发人员、确保法律合规以及促进和建立有利于组织战略的社区参与。

总的来说，OSPO 最核心的功能大致是以下几个：

首先，OSPO 经常要关注和监督公司开源合规性的各个方面。也就是说，当公司使用开源软件项目时，他们需要了解许可证和合规性，检查项目的运行状况，确保不存在安全漏洞；当公司为开源软件项目做出贡献时，他们需要确保没有知识产权问题，以确保公司的贡献能在项目中处于领导地位。

其次，OSPO 常常是公司与外部开源社区之间的 “中间人”。公司是需要与一些关键的开源项目社区保持联系的，比如苹果一直和 K8S 社区联系紧密。但是，一些公司如果把开源项目社区视为免费劳动力的话，很可能就会在沟通上出现问题，而 OSPO 则需要站在二者之间，寻找到 “平衡点”。

激怒我们开源社区朋友的后果将是毁灭性的。这不是我们想做的事情，因为我们关心这个社区，我们是其中的一部分。对于刚接触开源的公司，我认为他们经常没有认识到开源的重要性。”

—— Google 开源办公室经理 Will Norris

最后，OSPO 还肩负培养公司开源文化的重任。具体来说，OSPO 可以通过政策等手段来改进工程师们的开源实践。TODO 小组的新调查中，近 69% 的参与者表示，在组织内培养开源文化是 OSPO 的主要责任。

这是一项文化变革的努力。代码显然是其中的重要组成部分，但社区和参与是人与人之间的事情。如果你要创建一个开源项目办公室，并且尝试使它成为一个真实的东西，则必须了解文化和推广文化。开源负责人是一个真正的变革推动者。

—— 微软开源项目办公室主任 Jeff McAffer

4、高层重视的前提下，OSPO 可以特色化

其实，OSPO 并不是要千篇一律。正如 Jeff McAffer 所言，没有什么一刀切的模型，微软的经验也不能被拿过来完全复制到另一家公司。

但有一点原则却是通用的：OSPO 的建立需要得到高层的支持和重视，否则很难实行到底。因为领导层的支持，往往会起到平息争议、加大资源和资金投入等作用。然而，高管却又是常常被忽视的重要参与者，一些高管认为开源仅仅是技术实现中的一些细节。但如果高层有足够的意识，他们一定会参与到开源管理政策制定中的关键决策中去。

大多数 OSPO 都是直接向公司的 CTO/COO/CEO 这个级别汇报的。例如，字节跳动开源委员会就是由 CEO 梁汝波和两位技术最高负责人杨震原、洪定坤担任 Sponsor。在字节看来，大的开源项目往往需要长期投入，同时又需要协调公司内外很多资源。

但这并不意味着公司必须只能建立一个中央的 OSPO 来负责整个公司的开源运作。相反，如果公司更倾向于各部分独立行动，那么在各个单位中建立分散的 OSPO 也不是不可以。Comcast 就曾在这个方面探索过，该公司最终创建了两个开源项目办公室，一个用于 NBC 业务，另一个用于有线电视业务。

5、可以从 “内源” 开始，但别让 “代码被砸到墙上”

内源（Inner Source）一词最初是 Tim O'Reilly 在 2000 年创造的，是指在组织内建立类似开源的文化。也就是说，公司可能仍然在开发闭源软件，但在内部开放开发，建立透明文化。

内源其实是一个很好的企业开源过渡步骤。在百度开源办公室的自我介绍中，一开始百度仅是开源项目的使用者，然而该公司在 2013 年开始提出平台化思维战略，开始实践 “内部开源”，之后百度逐渐进阶形成了今天的开源格局。

此外，腾讯也是一样。2019 年 6 月，宣布成立开源管理办公室的同时，腾讯也公布了自己的开源战略路线图，腾讯的开源将分 “三步走”，而内部开源协同则是第一步。

但对于有点追求的企业来说，内源绝不是终点。云原生计算基金会首席运营官和 Twitter 前开源项目负责人 Chris Aniszczyk 曾说过：“你绝不希望是自己开源项目的唯一贡献者。你是期望让公司以外的人为你的开源项目做出贡献的。归根结底，你永远没办法雇佣世界上的所有顶尖人才。” 毕竟，与外界人才的沟通才是开源的精髓所在。

而且，一个好的 OSPO 往往能够将开源项目发挥到最大限度。红帽公司将那些仅仅将代码公开到一个公共仓库的开源方式戏称为 “把代码砸到墙上（throwing code over the wall）”。这种不作为导致的结果可想而知。这时，OSPO 必须发挥自身统筹的作用，通过协调各部门来使开源取得成功。

2022 年 2 月，TODO 工作组发布的 OSPO 报告里提出了 “OSPO 成熟的 5 个阶段”：