方法论：蚂蚁集团关于 OSPO 的思考

出品|开源中国

嘉宾|边思康

开源办公室（Open Source Program Offices，OSPO），这两年在国内大厂之间慢慢流行开来。2021 年初，蚂蚁集团也成立了 OSPO，时间虽不算长，却也渐渐摸索出了一条自己的路。开源中国编辑部邀请了蚂蚁集团 OSPO 执行负责人边思康，来谈一谈蚂蚁集团的 OSPO 究竟形成了怎样的方法论来指导开源实践。

01 既是运营官也是外交官

蚂蚁集团的 OSPO 成立于 2021 年初。这个时间节点，好像是蚂蚁特意等来的时机成熟，又好像是顺其自然迎来的恰到好处。当开源的过程中积累了一些问题，边思康的一句 “可以试试”，OSPO 就这么开始了。

边思康：一个公司成立 OSPO，这件事最好是自然发生的，而不是刻意的。一定是先有开源，再有 OSPO 。

很多 BU （Business Unit，业务单元）都会涉及到优秀的开源项目，而项目在发展过程中，会逐渐积累一些问题，比如风险、成本和成效等问题。之后，大家慢慢会对这些 “痛点” 有所感知，继而有所认知，然后形成判断 ——“需要有个组织来系统性地承载类似需求”。

成立 OSPO 的逻辑，可能和成立效能部、安全部等部门的思路是一致的。业务发展到一定规模之后，能有一个组织来进行业务统筹、治理和运营，会给整体效率的提升带来更大帮助。

我来公司不久后，就接到了这个命题，一时有点懵，因为跟原本预想的方向不太一样，但抱着 “非我莫属” 的精神，还是觉得可以试试看。后来在大家支持下做出了些心得，慢慢地，也就更加得心应手了。

蚂蚁集团的 OSPO 是虚拟组织，有核心成员，参照了 Todo Group、基金会（比如 CNCF ）等组织的设计。

我们考虑的维度可能没有那么复杂。从 “我们想解决谁的什么问题” 开始，明确用户，明确短期目标，然后明确所需的专家经验和资源，取得共识，明确机制后，就开搞。如果还缺少某些方面的专家支持，组织可以随时进化调整。这一设计在内部也是开放的，可以根据收集的建议向前迭代。

我很喜欢一本书《硅谷生态圈：创新的雨林法则》。这本书讲的是，世界上很多地区试图模仿硅谷，以建造能够孵化伟大公司的科技园和创意园，但是鲜有成功的，它们欠缺的不是资金和人才，而是一个利益各方多赢的生态圈。这对开源同样适用。

书中提到一个词，叫做 “deal maker”，指的是在硅谷的那些社会网络节点，能够链接资本和创业者，让创新能自然发生的那些人。

OSPO 扮演的就是这种角色。OSPO 对内要像运营官一样思考，如何让开源项目更好地协同和发展；对外则要像外交官一样思考，如何寻求与社区的合作，共同追求可持续的互惠互利健康发展，以及如何通过开源更好地抓住创新的机会。

02 承载蚂蚁开源的核心宗旨：把关键技术开放

OSPO 是什么？要解决的问题是什么？它在蚂蚁集团的定位是什么？是如何对开源项目产生影响的？除了推动项目开源之外，OSPO 还有哪些作用？对此，蚂蚁集团已经有了一些答案。

边思康：蚂蚁开源的核心宗旨，是把关键技术开放给大家用。而 OSPO 是该核心宗旨的一个承载。

开源项目的生命周期，类似 CNCF 的 sandBox（沙箱） - incubation（孵化） - graduation（毕业） 的孵化思路。

一个项目的成长，也是从 sandBox 阶段开始。该阶段的项目有开源的意愿和业务需求，但有点类似于人类幼崽，并不能很系统地自主操作一些事情。这时，OSPO 就能提供成长支持。

其中非常重要的一点就是 OSPO 会协助开源团队理清楚 “开源的目标是什么”。目标明确之后，项目会进入到孵化阶段，OSPO 则能够帮助团队做一些落地开源的筹备工作。

与此同时，OSPO 还会协调内外部资源来配合孵化，确保项目在开源之后，以更专业的方式来打造优秀的社区。我们遇到过部分很优秀、有潜力的开源项目因团队对项目发展方向考虑不到位而暂停开源的情况。当然，在与团队业务 leader 理清思路之后，最终我们成功地将其开源。

OSPO 的工作，还是要按照需求来。有些团队的开源经验丰富，可以自运营社区；有些团队需要利用开源来发展业务，但实际执行的人员没有接触过开源，也缺少社区经验，我们会在这样的项目和人员身上投入更多的精力。

OSPO 是一个新兴的、待明确的业务方向，要深入认识它，其实需要我们系统性地、自上而下地、整体地思考。这就要回到老子的 “道法术器” 模型。

“道” 的层面，我们觉得 OSPO 是一个 “catalyst of enablement”，也就是催化剂，而不是化学反应本身。催化剂有两个作用，让不可能发生的化学反应发生，或者让发生的化学反应更高效。

往下拆解一层，“法” 是回答 “我们需要解决的问题是什么”。对内，OSPO 解决的是控制风险、降低成本、提升产出等问题；对外，OSPO 关注的是如何促成与开源圈的合作，如何寻找业务机会，如何助力业务结果。

到 “术” 的层面，OSPO 提供具体的机制流程、最佳实践、优质案例以及人才培养等。当方法论成型之后，再辅以相应的 “器” 来进行工具升级。

OSPO 整体思路的核心还是从业务诉求出发，先解决缺少机制以及因为缺少机制所带来的风险敞口的问题，然后服务好项目，提升整体开源认知水位。

总体来说，开源不能急功近利，它是一件长期的事情，这点必须要跟所有人达成共识。

在企业内部达成开源共识并不容易。在一个概念尚未被系统性普及，且大家接触比较少的时候，都会面临 “难以达成共识” 的挑战。比如，大家很容易对 “数据库” 形成共识，但对 “元宇宙” 包含什么、怎么做，则不太容易形成共识。

国内开源的整体状态，其实还处于以用为主的阶段，至于 “贡献开源”，还有蛮大的进步空间。因此，很多人常常意识不到开源蕴含的巨大价值。

“回馈上游，异步沟通，重视文档” 等开源方法论，可以用于企业内部赋能技术开发和技术文化。只不过，大家经常会忽略 “开源” 和技术文化的联系，认为我不做开源，它跟我也没有什么相关性。这是一个常见误区。

另一个问题是，对开源的认识容易走向极端。有人会过度美化开源的价值，认为项目开源后就会有发展，会有人来用，也会有人来贡献，这个想法其实还需多加斟酌；有的人担心开源的潜在风险，认为代码外部可见会导致更多合规和安全问题被发现，这都是对开源理解不够全面的表现。

OSPO 的作用就是在一定程度上应对这些挑战并找到解决方法。如果没有 OSPO，相应的挑战可能就会变成 “无人区”，项目团队容易基于当时的认知来做判断，从而留下后遗症。有了 OSPO ，就可以把开源社区专家的经验以及对内部业务的系统了解结合起来，得到一个融合的、有效的解决方案。

03 OSPO 提供开源专家支持，自主决策权仍在团队

一个项目要长期、可持续发展，少不了多个部门通力协作，在涉及开源时更是如此，那么此时明确主次就很重要。在蚂蚁集团，不论是使用开源，参与开源，还是发起开源项目，OSPO 的角色定位始终都很明确。

边思康：使用开源的过程比较复杂，同时也不是孤立的。当然，其中涉及到的业务决策、安全决策、合规决策等，其实在有 OSPO 之前早就存在了，这点需要明确。

在开源使用层面，由团队自主决策比较适合，尤其是业务选型和安全判断。因为这并不是一个开源场景，而是比较具体的技术选型和软件供应链问题。

在个别场景下，我们会对开源组件的使用有一定限制，但这并不会因为是开源有很大不同，毕竟闭源组件引入和技术选型，也是有相应风险的。OSPO 在这个维度上，一般是作为业务和安全侧的 “开源专家支持” 出现。

开源参与层面，首先还是要明确，团队会有自己的自主决策权，OSPO 提供的是专家经验。举个例子，如果业务团队认可现有的某个开源项目能更好地解决技术问题，那么该团队很可能就会变成项目社区的参与者，fork 这个项目，按照社区的要求结合内部的业务需求来推进。如果团队与社区的想法不可调和，则可能会形成一个内部分支，但大多数情况下都是以回馈上游和共建为主要思路。

另一方面，参与开源本身并不需要相应的激励机制，因为 “使用项目支持业务” 的外在动因足够强。我们技术同学关注的领域也都是相对前沿的，对于一些出名的、好用的开源项目，会有足够的内在动因去参与和贡献。举个例子，我们是 Ray 社区的重要参与方，因为 Ray 很好地解决了我们面临的业务问题，所以我们并不需要依靠激励来动员大家贡献，业务的存在已经足够驱动大家做出贡献。

蚂蚁集团相信微小而美好的改变，所以最开始打造 OSPO 的时候，我们核心的对外开源宗旨是希望大家 “有信心，有目标” 地开源。一方面，要求项目能带来实在的技术业务价值，另一方面也要求项目能够 “可持续” 地健康发展，吸引外部参与，从根本上推进技术和行业的长期进步。

OSPO 成立之初最主要的工作，就是制定一套能够实现这些愿景的机制，然后明确开源必须要走流程。同时，我们对流程进行了相应的文化配套，有专门的自服务文档来辅助团队同学进行开源设计，明确开源目标、社区治理和运营方式。之后，项目会参与开源评审。

走过这一流程的同学，会提升对开源的整体认知。这种认知的提升对于长期的开源成功是必不可少的。

04 结合行业需要，在借鉴的基础上创新

一年多的时间，蚂蚁集团 OSPO 一步步建立起了自己的开源管理流程。事实上，在这个过程中，蚂蚁并不是单打独斗，已经有不少先行者留下了丰富的经验。当然，在将这些理论和经验用于内部实践时，蚂蚁会根据自己的情况有所侧重，找出自己的创新点。

边思康：“一步步” 背后的核心逻辑，其实是优先级问题。我们的核心痛点是上面提到过的 “对外开源的整体设计和收口”，做好这件事情其实会牵扯蛮大的精力。这之后，我们再慢慢把工作拓展到像开源使用、开源孵化这样的重要但没有那么紧急的部分。

Linux 基金会和 Todo Group 其实提供了蛮多很不错的教育文档，我们有所参考。有趣的是，虽然我知道 Todo，但是在最早开展业务的时候，其实我没有仔细看 Todo 的所有设计，而是从内部的业务需求开始，以产品设计思维结合用户体验设计，与主管一起找出并决定了我们要做的前几件事情和整体的工作目标切分。而这些事情做完之后，有一次我仔细看 Todo 的内容，才发现很多内容与我们的情况一致，殊途同归了。

这种殊途同归的发现，其实也直接展现了我们的创新点。创新机会一在 “把事情做实”，讲求 “为世界带来一些微小而美好的改变”，所以我们更重视 “未开源还不知道怎么做” 的项目和人，帮助他们把一些相应的准备工作做实，让大家更懂开源。这也是个 “风险左移” 的过程，可以在更上游管控潜在风险。

另一潜在创新点在开源 OSPO 的服务边界。现在业界对于 “如何开展和衡量开源办公室的工作范围” 这一问题，仍然处于早期探索阶段，且没有达成共识。我们的一些探索和实践，比如开源相关的工具和方法论，则可能成为一种创新。

蚂蚁的 OSPO 会去看行业需要什么，在这个维度上寻求双赢甚至多赢的机会。如果目前国内开源圈需要的是标准和工具支持，那么我们会去思考，要如何结合内部的业务诉求来对外提供帮助。

企业推广开源与社区推广开源，核心上并没有很大不同，毕竟要触达到的人群是类似的，需要找到的同路人也是类似的。

社区开源强调的是工程师文化、合作共建等，而企业作为盈利机构，在这之上，还会有更明确的商业目标，但这并不是一个社区冷启动时要考虑的事。毕竟一个项目要解决实际问题，并且社区足够吸引人才能带来相应的成长，只靠运营是没有意义的。

企业推广开源需要注意的方面还蛮多，如果挑重点说的话，应该是对于 “开源社区” 要有足够的好奇心和敬畏心。开源社区是个很有意思的存在，一方面是 “理科得不能再理科” 的代码，另一方面是 “人文得不能再人文” 的 “共同体”，认知范围非常广。

弄懂开源需要大量的技术知识储备、历史储备和社会科学储备，如果不敬畏这种沉淀，则可能会导致一些不受社区认可的风险。

05 绩效量化确实很难，但有迹可循

就当前普遍情况来看， OSPO 的工作无法立即显效，而且难以量化和评估，但并不意味着无从下手，仍然有一些可用的指标可以考虑。关键是如何用互联网的方式，小步快跑，快速迭代，总结出一些规律来。

边思康：评估 OSPO 工作成效的确很难，且没有那么快能解。开源是需要长期主义精神的一个领域，这是我们必须要接受的一件事。

如果为了做成绩而做开源，则很容易跑偏，比如过度注重发声的频率和影响力。作为开源生态中一部分，OSPO 也要接受这一事实，并在这一事实的制约下去做事。情况是否会变好？我认为是肯定的。当然，这也要靠大家群策群力来形成共识，共同推进。

量化评估一个组织的效果，有三种方式，一种是 testing 选定测试维度，另一种是 benchmark 明确平均水位，第三种是专家认可。就开源领域而言，第三种衡量方法可能并不适用，所以需要从前两种入手。

测试维度其实很难有个定论，因为连我们提到的 “OSPO 工作所涵盖的范围” 可能都无法达成共识。

所以我们要对其中的一些维度加以甄别。比如治理水平、项目数量和质量、社区活跃指标等维度，肯定是需要的；但开源统筹水准、开源商业化产出、开源共建值这些，并不一定是每个 OSPO 都需要。可能我们要做的，就是用互联网公司的方式，小步快跑，快速迭代，看是否能总结出一些规律来。

如果用平均水位来评估，首先要参考我们上面提到的测试维度，其次在每一个维度上，还要比较明确地定义出水位。这就更难了。以项目数量为例，多少算多？一个组件项目和一个数据库项目是否能够等同而论？另外，如果一个项目的社区做得好，如何证明是因为 OSPO 的存在才做到相应水位？

BVP 的研究显示，不同开源类型的项目，活跃度可能会有比较大的差异，泛前端的项目活跃度会两倍于数据库和 AI 工程类型的项目活跃度。这种情况下，benchmark 还是需要考虑到各个社区的自身状态。

06 OSPO 应具备三大能力

加入蚂蚁 OSPO，是边思康从事的第一份开源相关的工作，一切都是新鲜的，同时也是混沌的。经过一年多的摸索，蚂蚁集团在建设 OSPO 方面，已然总结出了一些经验。

边思康：OSPO 是外交官，最重要的是建立起沟通的能力。这个观点来自 Linux 基金会的 Keith，他是我很尊敬的一位专家，在开源领域有多年积累。很多公司会把 OSPO 看成是一个运营的岗位，对内是工具的角色，承担合规和优化的工作。但我觉得 OSPO 还有一层角色，就是外交官，而且它作为外交官的能力被低估了，这块儿会持续探索吧。

二是战略定力要与各业务团队的支持结合。这种战略定力不能只来自于表面，还是要小步快跑，把事情做实，深入浅出地服务好各个项目的业务属性。对于成熟的项目，OSPO 要能够提供外部合作渠道以及牵引更多共建机会；而对于新的开源项目，OSPO 要能够沉下来理解业务需求，并帮忙做统筹规划和运营设计，考虑你的客户需要什么。

三是 OSPO 要懂开源。你并不需要成为最懂每个社区的那个人，但一定要对开源是什么，治理是什么，运营是什么，开源如何服务于公司的各条业务线等这些问题形成自己的认知和判断，并不停地去迭代。不要怕犯错误，也不要怕被别人认为不懂，开源圈其实是个很包容的圈子。

虽然有时候会有些自己的小骄傲和坚持，但以现在的宏观环境来说，不妨放下些姿态，因为我们需要更多对开源有兴趣、想做事的人进来，一起把这件事做起来。

最后，我以一年多的感受来收个尾吧。做开源，是需要有一种信念的。用蚂蚁人的话说，叫做 “相信相信的力量”。你可以不相信开源然后来做开源相关的工作，但总会很拧巴。我觉得开源是一股很强大的力量，是一种先进的生产关系，是一种商业手段，也是一种寻求全局最优解的、有效的探索路径，我个人很相信这种开放生态的力量。

虽然开源并不能解决 “内卷” 的问题，但 “内卷” 的反义词可以是开源！如果我们能持续推动一些开源侧微小而美好的改变，能够让我们的开源技术圈和社区专业度在全球更上一个台阶，这是很令人兴奋和开心的一件事情。

边思康蚂蚁集团 OSPO 执行负责人

边思康，蚂蚁花名 “边澄”，于 2020 年底加入蚂蚁集团技术战略发展部。2021 年年初，边思康参与了蚂蚁 OSPO 的创建，之后该方面业务成为其主要工作方向。与此同时，他还兼顾技术洞察和技术战略发展相关工作。加入蚂蚁之前，边思康一直在美国从事软件研发相关工作，先后入职微软、旧金山 Square Inc（即现在的 Block Inc，一家金融科技公司 ）。

本文来源于开源精选集《开源观止》第 2 期，更多精彩内容，请点击下载：

https://oscimg.oschina.net/public_shard/opensource-guanzhi-20220707.pdf