从 OSPO 角度思考开源治理问题——蚂蚁集团开源办公室负责人边思康

​

点击聆听“大咖访谈”第 10 期：从 OSPO 角度思考开源治理问题

​（建议在 WiFi 下播放）

开源雨林：请先简单的自我介绍

我是蚂蚁开源办公室的负责人边思康，之前十几年一直在做软件产研，积累了大量的开发和产品经验。加入蚂蚁时，蚂蚁把开源作为了一个重要的技术战略探索方向，当时接了这个项目成立了 OSPO，到现在差不多两年的时间，这也是我做开源的唯一经历，可能跟很多做开源社区成长起来的人才类型不太一样。

开源雨林：所以蚂蚁的开源办公室是以项目制的方式在做吗？

可以这么说，更准确的讲法应该是 strategy initiative。我所在的部门（技术战略发展部）会针对行业技术趋势做出相应的长期战略判断，并基于战略判断做相应领域的探索，确定该领域是否有潜在的业务机会。我们最开始在探索开源的时候，更多是以比较收敛的方式来看待的，并没有从公司层面考虑可以通过开源来做什么，以及是否要从公司维度把开源作为一个重要战略，进行系统性的推广（当然后来的发展是做到了这一点的）。

开源雨林：你所理解的 OSPO 以及蚂蚁的 OSPO，是不是和其他大多数企业的 OSPO 不太一样？

我觉得可能每一个 OSPO 都各有不同。例如公司有在使用开源、对外贡献开源，以及项目对外开源几件事情，可能需要一个系统性的方式把所涉及到业务领域管理起来；再或者是企业遇到了一些合规风险和安全风险，由痛点驱动带来需求，之后根据自身的业务场景，成长成不一样的开源办公室。

OSPO 其实是有共性部分的，TODO Group 对这个问题已经有了一个比较详细的拆解。我们认为 OSPO 要对三件事情负责：一是风险域，如何保证开源领域的合规安全是有基本的保障的？二是优秀实践和业务效果，我们关注一个开源项目和工程文化在公司内部的实践，以及我们想通过这个实践达成的业务探索效果。大多数的关注集中在我们的技术效率、公域开发模式这些和风险效能紧密契合的领域，以及我们如何在公域做产品开发，来获得开放生态下自然生长出来的反脆弱项目；三是业务发展，当项目发展到可以与外部社区进行紧密结合，并形成一个良性的社区后，它要以怎样的方式与社区、基金会、外部商业生态发生关系？这种如何用开源推进业务发展的正向思考，我觉得是 OSPO 的一个发展模式，蚂蚁也都在做，并会根据每年所面临的问题进行动态的调整。

开源雨林：驱动蚂蚁 OSPO 不断调整的背后，是否有总体的原则？

蚂蚁的开源可以概括成两个词：务实和信任。蚂蚁的主要业务场景：支付、国际金融、To B 等等，其背后的逻辑都是信任，而开源本身就是一种非常具体有效的，能够带来信任的方式。另外一点是务实，我认为务实是很具体的事，蚂蚁对于技术的追求非常简单，我们希望我们的技术能够解决行业的实质问题，如果解决得还不错，我们会把这些技术开源并做生态发展的探索，觉得也许这些技术在开放生态下面能有更好的发展，能帮助大家更好地解决行业的通用问题。

这当中比较典型的就是 SOFAStack 和后续的 OceanBase。SOFAStack 是从双 11 业务场景下成长出来的云中间件，后续的 OceanBase 是基于蚂蚁的支付业务场景下，不管流量多高，不能够出现支付数据错误而形成的技术，也是十年磨一剑，非常有挑战性。

开源雨林：OSPO 工作那么多，蚂蚁 OSPO 是如何区分轻重缓急的？

蚂蚁 OSPO 成立两年来，第一年的重要紧急项是谁来为这件事负责，以及如何制定人会机制流程。我们需要搭建起的人会机制流程能够帮助我们解决遇到的问题，并带来一些不同的见解，生成能够正向影响整个行业的潜在最佳实践。早期探索中，我们发现当中有很多内容要展开，并没有想象中那么简单。例如如何做项目评审，如何做内部组织文化宣导等。基于此，形成了一些需要第一时间解决的问题，我们也在第一年把这些事情做到了稳定态。第二年主要是实战中发现的开源引入合规风险、开源工具问题，以及项目内部孵化和发展问题。因为很多事情不是可以提前做计划的，所以我们会基于我们的探索发现以及开源办公室发展周期的状态，进行动态调整。

开源雨林：如何理解预期管理，以及如何做好领导的预期管理？

管理预期有很多维度。在做预期管理之前，首先我们需要先理清公司要解决的核心问题是什么，例如我们刚才聊到的合规工具、项目治理层面的一些根本性问题。

开源是一个开放式的生态，做完现阶段任务后，接下来可以去探索的业务方向是什么？这件事是需要和 leader 不停对焦的。这个过程中，我们需要有所取舍，比如说做开发者生态还是 ToB 的合作方生态？基于某些项目要提供什么类型的孵化服务？是提出价值主张的引导，还是做全面课程的理论沉淀？自己做还是和社区合作？如果和社区合作，和怎样的社区合作？与其说管理领导预期，不如说是帮助 leader 和我们的管理团队提供战略辅助决策支持，让大家能够基于目前所看到情况更好地做出下一步的动作。

另一个要管理的是所有业务方的预期。实际上，开源的很多效果是间接性长期性，不是一针打下去就能立竿见影获得极大发展的。同时，企业对于开源的投入也一定是长期的，如果只是因为国家重视，来追求短期利益，可能不一定能够达到很好的业务效果。所以，管理合作方的预期和管理领导预期的重要程度，我认为是在同一维度的。

开源雨林：如何看待 KPI 开源，如何避免开源 KPI 化？

我觉得 KPI 本质是“测体温”，根据实际测量所得到的数据，来判断业务健康度。如果再往上拔一层，我觉得问题背后可能有两个问题：一是我们在做开源时该不该有目标，以及这个目标应该如何制定？二是如何衡量达到目标的业务结果？所谓的开源的目标可能分两类：一类是开源项目自身发展的目标，另一类是像 OSPO 这样的组织/机构在实现开源业务时的目标。

那么开源应该有目标吗？我的反馈是：不但应该有，而且应该很明确。我们在内部做开源治理的第一步就是把所有对外开源项目的申请做了一个收口，因为有些项目在早期开展阶段，没有目标，导致后续的社区动作或执行方案出现了变形，所以我们会在新项目开源之前，有一个非常明确的目标制定要求，把开源项目的目标制定前置。而 OSPO 业务该怎么样制定目标，这其实会涉及业务本身是短期的还是长期的。我们希望在未来两到三年，把公司的开源认知和开源水位提升到一定的高度，希望大家对于开源有一定的基础认知，可能需要有一套课程，100% 或 80% 覆盖开发人群，要去制定这样的一些目标，我觉得是有必要的。

如果项目有非常明确的发展目标，且基于目标有非常明确的 KPI，那么我们应该制定一个 KPI 逻辑，但达不成 KPI 逻辑的背后所透传出来的信息是什么，以及我们如何用好这个信息才是背后真正关键的地方。我们在做业务时往往会有要数得数的逻辑，我们应该去规避一些没有目标的数字的制定，但你得到的这个数字，是不是真的能够帮助到你实际所要达到的目标，我觉得很多时候是值得商榷的，这也是部分项目组在早期时常踩的坑。

开源雨林：开源对于技术产品的打造意味着什么？如何在开放生态下打造技术产品？

推荐大家阅读一本书《硅谷生态圈》，这本书对于硅谷之所以是硅谷而硅谷的创新为什么能够持续不断的原因做了很好的拆解，虽然讲的是硅谷的创新，但我看到的处处是开源。项目与项目间如何合作产生 1+1＞2 的效果，从而避免在公域造轮子，是所有“开源圣经”里大家所强调的一个核心观念。在开源的开放生态下，一定能够把某些东西抽象掉，从而让大家不用重复建设一些价值不高的部分，而这个部分一旦形成了开源层面的事实共识，我们就可以聚焦精力去解决下一个问题，这就是产生创新的过程。

以 Kubernetes 为例，Kubernetes 对于 cluster orchestration 提供了一个比较优雅的解决方案，在社区的多年沉淀积累下，也被大家认可是可以在上面搭设计，解决 “下一个问题” 的很不错的解决方案。另一个例子是 Open Telemetry，Open Telemetry 是一个开放式标准，它对于 Trace、Metrics 和 Logs 给出了相对明确的定义，定义本身可能并不包含 reference design，但是有了这样一个开放标准之后，我们可以在这上面大量地减少因为数据格式或抽象方法标准不同，所带来的消耗。

从技术维度往上拔一层，「技术产品」本身就是优雅的抽象。在我把一些技术层面的内容做完抽象后，我想把它做成一个什么样的产品状态，从而解决某类型的问题，这个维度上的思考我们在生态里也看到了一些问题，如果这个东西大家做得足够的好，那么其实对于某些类型的产品会有通用化的使用，从而很好地解决某一个类型的问题。但我们在国内生态下会看到很多大而全的东西，并不是说大而全不好，而是说大而全的东西在开放生态下，可能不能够跟开源社区形成产品设计层面的互动，自然地发生产品迭代。如何在生态中，形成比较顺畅的上下游，让大家产生依赖，从而让社区能够把一些具体的点做精细，达成一个相对高级的产品共识，并基于产品共识去解决下一个问题。这个很重要。

开源雨林：对开源雨林有什么好的意见或建议？

我很认可开源雨林整体的顶层逻辑。开放生态下成长出来的物种的多样性以及多样性所带来的持续的生态健康度，会比封闭的环境要更好。目前，生态里的优质内容，以及对于做开源治理、开源文化等的内容和覆盖是缺失的，或者说远远没有达到饱和的状态。希望开源雨林能定期发起一些针对某些领域的内容或者线下沟通的宣导和牵引，持续投入，提升全行业开源技术与应用水平。

开源雨林围绕开源通识、开源使用、开源贡献三大方面构建知识体系，愿把长期积累的经验系统化分享给企业，在团队、机制、项目三方面提供合作，推动各企业更高效地使用开源、贡献开源，提升全行业开源技术与应用水平。

开源雨林的内容已开源，并托管在 https://github.com/opensource-rainforest ，欢迎通过 Pull Request 的形式贡献内容，通过 Issue 的形式展开讨论，共同维护开源雨林的内容。

欢迎关注“开源雨林”公众号，获取最新、最全的消息。