近年来，国内互联网大厂相继设立开源办公室（Open Source Program Office，简称 OSPO），其中有部 分企业在 OSPO 建设方面更是颇有成效。虽说 OSPO 并不是什么新鲜事物，但却少有人揭开其神秘面纱， 因此它常常为外界所误解，甚至有人说是形同虚设，其存在是浪费资源。因此，开源中国邀请了四位业内专家， 来谈一谈真实的 OSPO 到底是怎么样的。

主持人

王晔倞（头哥）：支流科技技术 VP、Apache APISIX Committer

观察员

tison：“夜天之书”公众号作者、Apache Member & 孵化器导师

分享嘉宾

Keith Chan：CNCF 中国区总监、LF 亚太区策略总监

堵俊平：现为华为计算开源业务（OSDT）总经理、LF AI & DATA 基金会主席

边思康：蚂蚁集团技术战略发展部资深专家、开源办公室执行负责人

王晔倞（头哥）：什么是 OSPO？它有哪些形式？先请观察员 tison 来谈一谈。

tison：OSPO，全称叫Open Source Program Office，翻译成中文的时候，把 Program 去掉了，所以叫开源办公室。从一些企业用例来看，还挺贴切的。对于“OSPO是什么”，没办法用一句话来回答。

如今，几乎所有的商业活动都建立在软件之上，而软件总会依赖某些开源组件。因此，企业或多或少都会参与到开源之中，总结起来无非是使用开源、参与开源、发起开源项目。

在此过程中，企业肯定会遇到很多问题，因此就需要“OSPO”这样的部门来解决这些问题。

OSPO 职能涉及很多方面。其最基础的职能是法务和安全，比如要处理开源合规、软件缺陷修复、安全漏洞等问题；还涉及到研发，毕竟开源的核心还是软件；此外，与市场、运营等部门也有一定的关系，因为开源可以被当做一种免费增值的手段（比如 MongoDB），且其本身还自带品牌效应、传播优势。

关于 OSPO 在企业的架构形态，总结如下：

在我国，OSPO 最普遍的形态是虚拟组织。它跟实体部门很不一样，没有可以汇报到 CEO 的汇报线。当前国内大部分企业对 OSPO 的态度都处于尝试阶段，因此倾向于组建一个虚拟部门，典型的如 PingCAP。PingCAP 的 OSPO 在法务、合规以及安全方面，会有全职雇员，或至少有一部分工作与之相关，研发、市场营销专员也会参与进来。

OSPO 作为整体市场策略的一部分，常见于开源技术创业公司。对他们而言，开源软件或者说开源生态是公司的核心竞争力之一，因此往往会借鉴一些成功案例，将开源作为营销方式之一，把 OSPO 跟市场部门挂钩，或者并入到市场部门，作为整体市场策略的一部分。有的创业公司把研发看得比较重，会单独成立一个技术架构委员会，这跟 OSPO 还是有些区别的。技术架构委员会是一个纯粹的技术部门，大部分情况下关注技术领域，而 OSPO 是涉及法务、安全、研发、市场、运营等多维度的部门。开源社群主要分为用户社群、开发者社群，这类 OSPO更关注的是用户社群。

OSPO 作为实体部门单独存在，可以直接汇报给 CEO；或挂靠在研发部门，汇报给 CTO 或者技术 VP。至于 OSPO 是要处理什么事情，很多时候取决于部门招到什么样的人。如果招聘的是研发出身，那么侧重于技术开发，如果是法务或者安全方面的人才，那么自然会偏向自己擅长的方向。

 这三类 OSPO 的共性在于，都属于横向赋能部门，就算是虚拟部门也不例外，虽然与其他部门有业务合作关系，但不会或很少直接承担业务。

也有少部分 OSPO 是纯粹的横向部门，提供完整的开源咨询能力，但很少参与具体业务的经营或执行，最多会安排联络员作为咨询师参与到其他部门。

总结一下，从务实的角度来讲， OSPO 要解决的，就是在使用开源、参与开源、发起开源项目遇到的方方面面的问题。从务虚的角度来讲，OSPO 是一种文化。比如红帽的开放文化在某种程度上，也可以认为是 OSPO 的一部分，当然，这也是企业文化。

Keith Chan：我用比较简单的比喻来解释吧。我觉得，OSPO 就是一个外交官，既是外部的外交官，也是内部的外交官。

每一家公司的 OSPO 有自己的定位，职能也都不一样，但是总的来说，必须要建立起沟通的能力。即使是一件很简单的事情，比如开源合规，也要与研发部门沟通。

为什么要做这件事？许可证有没有问题？版权有没有问题？这些问题都是要讲清楚的，尤其是涉及出口更要搞清楚。不是每一个人都了解这些，因此沟通能力非常重要，这也是我称 OSPO 为外交官的原因。

很多公司的领导层，不太知道开源的重要性，尽管他们使用的软件或多或少都跟开源有关系，都是睁只眼闭只眼，至于为什么要管理开源，用了多少开源，这些开源项目有多重要，都不知道。有人还会把这些问题扔给研发去管。我看到很多公司都面临这样的问题，既没有在战略上把开源管理好，也没有足够的精力去付诸行动。

事实上，不管是对内还是对外，都应该由 OSPO 来把这些事讲清楚。

话题2：OSPO要解决什么问题？

王晔倞：从企业的角度来看，OSPO 主要想解决什么样的问题，具体怎么去落地的？

堵俊平：为什么要有OSPO这么一个组织？抛出这个问题的前提，一定是在开源的使用或者贡献过程中遇到了一些障碍。

开源已经席卷了 IT 史三十多年，诞生了 Linux、MySQL、K8S 等一批熟悉的开源软件。在早期，开源软件数量不多，可能并没有太多的问题出现。但现在，很多企业的IT 基础设施底座基本上都以开源为主体。之前 Linux 基金会发布的报告显示，全世界 80% 以上的软件都是基于开源软件开发而来。

不仅仅是 IT企业，传统企业也无法脱离开源，华为也经历了好几个过程。大概在 20 多年前，华为还在做硬件卖盒子的时候，开始逐渐使用开源软件，比如 Linux，这时面临的问题是如何用好管理开源软件。在很长一段时间内，OSPO 都不是一个成型的部门，但有一个类似的职能部门负责开源的管理，包括引入、选取。我们知道，随着开源软件供应越来越丰富，社区也越来越多样，如何选用一个可以发展或适合承载业务使命的开源软件越来越重要。选用不合理的开源软件对整体业务来说，相当于一笔巨大的技术债务。

因此，在早期，华为的 OSPO 主要解决的问题是如何选好开源软件，如何支撑业务发展，如何合规使用。 

差不多从十年前开始，华为的业务从传统产业转向 IT 产业，计算业务、云业务都涉及大量开源软件。到了这一阶段，除了使用开源，华为还贡献开源，甚至有一些自有的优势项目要开源出去，去构建一个产业生态，做大自己的伙伴圈，从整个共享生态当中获益。这就是OSPO 另外一个职能，也就是构建所谓的开源战略。

开源战略一定是围绕业务的。业务有多种形态，是面向硬件，还是面向软件，又或者是云，亦或者消费者？不同的业务形态，开源战略的打法也不一样，但基本的原则和目的是一样的，就是服务好我们的业务战略，构建起整体的产业生态。OSPO的作用，就是要识别出重要的、关键的开源领域，在里面持续发力，包括构建开源文化，提升技术影响力，把整个生态做大做强。

话题3：OSPO 面临的难题是什么？

王晔倞（头哥）：开源管理的复杂性，到底在哪里？复杂到需要建设一个专门的机构来解决这个问题吗？

堵俊平：正如 tison 介绍的那样，OSPO有不同的组织形式，有的是虚拟组织，有的是实体组织，这两种我都经历过。华为的 OSPO 是实体组织，有专职的团队在做开源。但我之前所在的公司，其OSPO 是一个虚拟组织，各业务团队会抽调一些人加入这个虚拟组织，来解决开源相关的问题。

虚拟组织和实体组织，面临的挑战是不一样的，因为它承载着不同业务的使命。

一种观点认为 ，OSPO 是一个能力中心。什么叫能力中心？就是由专家组成一个 OSPO 团队，在各业务部门有法务、技术、运营或营销需求的时候，为其提供帮助。

这种模式的问题在于，当其他部门有需求时，不能很快地响应，无法支持高频次地调用。对于采用虚拟组织形式的 OSPO 来说更是如此。实际上，很多业务决策，是有时效性的，最佳窗口期错过就没了。当然，在一般情况下，能力中心是足够支撑业务的，是没有问题的。比如怎么用好开源，怎么正确地避坑，怎么制定开源版本规划等等，这些问题的时效性并不那么强。

另一类观点是，OSPO 是业务中心，要承载一些业务使命，作为整个生态团队的一部分配合公司的业务。这种情况下，如果是虚拟组织，可能就不太适合。因为虚拟组织无法及时有效地响应，可能会导致更多问题。

现在已经不是二三十年前开源稀缺的年代了，不是开源一个项目，别人马上就会拿来用。在开源项目之外，还要做运营、做推广。有很事情要考虑的，比如推动开源项目，你要和哪些人建立合作关系；做宣传推广的时候，要如何持续定点地去突破。如何做好外交家，是业务中心要解决的一个难点。

开源社区是由各种不同背景的人组成的，不管是用户、贡献者，甚至是旁观者，都有各自的想法。推广开源项目的时候，出现了争议声音，要如何解决？那么，如何进行有效沟通，化干戈为玉帛，持续把产品有效地推广出去，与大家建立连接；如何把社区的声音带回内部，以推动工程团队来改进技术产品，这些都是 OSPO 团队要解决的问题。

边思康：有一点不能忽略的是，OSPO 既要解决内部问题，也要解决外部的问题。OSPO 的成员要同时扮演 COO、CMO 的角色，甚至是 CTO 和 CEO 的角色。当然，这些事情可能不是一个人来做，而是 OSPO 的所有成员群策群力。这种情况下，一般业务的复杂性就翻了一倍。

做技术的的时候，大家会考虑得很具体：业务用户是谁，想要什么样的效果，可以提供什么样的技术解决方案，做成一个什么样的设计...... 这个链路非常清楚。然而，在开源的环境下，不再是“一对一”或者“一对 N”的模式，更像是 “N 对 N” 的交流。

另一方面，做开源肯定会与规范、安全产生联系，因为开源本身就是一个相应的风险点。与此同时，开源会有大量的对外交流，会与市场部门产生联系。这些关系错综复杂，导致 OSPO 要解决的问题很多。即使我们对所有的问题进行二级抽象，它仍然是一个复杂度很高的事，因为我们并不能解决所有人的所有问题。

然而，在这过程中， OSPO 如果去教别人做事，也是不合适的。开源本来就是一个自适应、社区型的生长环境。我们常常拿雨林来做比喻开源，就是因为开源没有一个固定形态。我们也会从其他组织那里学习很多先进做法，但直接拿来用又不现实。

最后，我认为做开源，核心的还是那句话——“授人以鱼不如授人以渔”。其实，我们可以花多一点时间，让大家把这个心智培养起来。但这里的核心难点是，我们如何能够系统化地把开源讲清楚？因为开源不是一个非常具体的事情。

话题4：OSPO 的运营困境是什么？

王晔倞（头哥）：tison，作为局外人，你看到的 OSPO 现在面临的一些客观问题是什么？

tison：华为、蚂蚁这样的公司，更多是关注战略上的东西。其 OSPO 做开源治理、开源使用，更多的工作还是局限于公司内部，还是比较封闭的。从研发角度来看，开源软件的开发不是一个企业独自地开发，并不是企业开发者开发了一个软件拿出来就叫 “Open Source”，这与真正的开源大相径庭。

现实中，企业会把一些开源软件捐赠给开源基金会，基金会有一些基础规则来帮助开源项目，比如要怎么做决策。这对企业传统的开发者来说，遵循这些规则是一个挑战。不过，像 Apache 软件基金会这样的社群，有很明显的企业参与痕迹，如此一来，企业开发人员从社群里成长出来之后，自然就会明白如何做好协同。

如果缺少了这样的能力，不知道如何外界协同、不知道怎样基于行业力量去发布软件，那么就还是停留在封闭的软件开发模式之中。开源协同的开发效率要远远高于封闭的开发，Linux 有数百万贡献者，这是企业无法相比的。

运营也是一个很典型的问题，很多企业尤其是技术型创业公司在这方面表现得最明显。大企业的项目也可认为是一个小型的、虚拟的技术创业公司，会遇到这些的挑战。

有时候运营对外去输出内容（比如一篇文章），但他自己并不知道具体需求是什么？反正文章就这么出去了。国内的大部分运营的经验还是面向 C 端，而不知道面向开发群体应该是什么样的。在很多企业，研发和运营之间的沟通是断裂的，运营永远不会跟研发说，你的文章哪里写得不好，顶多会反馈为阅读量不好。

更多的时候，企业应该依靠开源社群获得资源，而不是企业花钱雇佣一大堆员工，整天去回答社群问题，这是很吃亏的。让用户能够自发地互相去解答问题，才能让社群更加健壮。

一些大厂本身不依赖开源软件赚钱，他们的目标是吸引开源人才。运营发挥得好，对企业的品牌建设和行业影响力的提升有很大帮助。如果你在开源社群建立起了声望，就会吸引到很多人才。比如谷歌就因为发表了很多影响力巨大的论文，吸引了很多工程师。

在这些方面，企业的 OSPO 有很明显的价值。而且，越是到深层次、长期的价值上，实体 OSPO 的作用越大。

话题5：什么情况下要组建OSPO?

王晔倞（头哥）：多数业务驱动型公司对 Open Source 认知不够，认为开源就是免费。我之前也走过弯路，我曾经在公司大张旗鼓地推行开源委员会，主张把中间件贡献给基金会，但事实上却很难执行下去。那么，在什么情况下，企业才需要建立或者需要思考去开始建立 OSPO 呢？

Keith Chan：无论公司大小，只要用到开源，就会发现开源可以省下大量成本。但是，如果企业只是使用开源，而没有回馈社区，还需要请很多人来维护代码。有一家规模很大的公司因为没有参与 OBS 上游，投入了 100 多人去维护项目。

不止是 IT 业，金融业或者传统行业都在用开源，现在企业使用的代码 80%～90% 都是开源的，但很少有人去想怎么去管理这些代码，慢慢就变成了“代码负债”。

而且，当下很多人才、技术大神都是从开源挖掘出来的。企业如果在开源方面没有知名度，很难吸引这些人才。因此，如果不做开源，企业的竞争力会越来越低，成本也会越来越高。

堵俊平：我非常认同 Keith 的观点。不是只有想通过开源挣钱的公司才需要建立 OSPO。只要你想用好开源，不管是节省成本、提升效率，或者是加强组织文化，都可以尝试去建立 OSPO。其中，最核心的点在于你是否遇到了痛点，不管是在使用开源或者推行开源业务遇到的。

前段时间爆出了不少开源漏洞，很多相关业务和软件都受到了影响。开源软件千千万万，上面有几千万个代码仓库，项目怎么选？选完之后怎么维护？所有公司都会面临这样的问题。

除此之外，当你分叉了一个开源项目，随着时间推移，运行过程中多多少少都要修复一些 Bug。如果你不从上游直接拿到修复代码，而是依靠自己的团队缝缝补补，最后运维团队只会越来越大。

尤其是我们互联网公司，从小公司成长起来，回头一看，发现投入的开发人员比社区现存的 PMC 还要多。为什么会出现这种情况？我认为，首先是没有长线的开源规划，没有清晰的理念；其次，没有Upstream First（上游优先）。有长期开源经历的人就会发现，上游优先是一个非常经济的管理开源的方式，它同时也契合了开源文化，开源即回馈社区。

如果没有一个有经验的开源团队，企业很可能在物质和精神层面都有损失。因此，当团队遇到搞不定的痛点，不妨去引入外部资源和人才，去组建 OSPO。

边思康：如果把 OSPO 定位为外交官，那什么时候需要去建立OSPO？就是需要去对外建交的时候。谁需要对外建交？任何一个企业都可能需要。

不要为了做开源而做开源，否则大家都不舒服。但话说回来，如果开源能够切实地帮到你，那建立这样一个外交官的角色，对沟通是有极大帮助的。

我觉得建立OSPO和其他的决策链路都是类似的。公司一开始只有十个人的时候，你不需要效能部，因为每个人都要对效能负责。当公司到 30 个人的时候，你不需要技术风险部，因为核心技术风险全部都体现在业务代码里。

但是，当解决开源问题的潜在收益出现规模效应的时候，当开源项目开始出现在公司的多个 BU （Business Unit，业务单元）里的时候，当开源出现“烟囱”的时候，那 OSPO 肯定会帮到你。

实际上，很多公司的架构部在最开始解决的其实就是 Upstream 问题。当公司内不同团队的架构重复出现，就会形成一个个的“烟囱”。很多东西都是可以被复用的，为什么还要重复造轮子？我能不能去做内源？一堆衍生问题就出来了。

我们并非一定要建立一个 OSPO ，但企业一定需要一个类似的负责人，能够提供开源方面的帮助，能把开源的事情讲清楚，并付诸实践。

除此之外，我认为不管你是不是做开源，不管你的业务是 to B 还是 to C，其实都可以了解一下开源精神是什么，开源的发展史是什么。开源精神带来的帮助，不只局限于 OSPO。因此，我认为应该更早把开源精神用起来。

王晔倞（头哥）：很多公司建设到一定程度一定会去搭建工程效能、搭建 PMO。我反问一下，为什么要搭建呢？为什么是在这个时候而不是半年前去搭建呢？是因为工程太多了、太慢了，企业才会想去做这件事。 开源也一样。当你的开源使用率够大、开源基建数量够多到一定程度的时候，就是需要去治理它。开源像空气，如果空气已经污染，人们都开始咳嗽了，不治理能行吗？

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

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