近年来,国内互联网大厂相继设立开源办公室(Open Source Program Office,简称 OSPO),其中有部 分企业在 OSPO 建设方面更是颇有成效。虽说 OSPO 并不是什么新鲜事物,但却少有人揭开其神秘面纱, 因此它常常为外界所误解,甚至有人说是形同虚设,其存在是浪费资源。因此,开源中国邀请了四位业内专家, 来谈一谈真实的 OSPO 到底是怎么样的。
主持人
王晔倞(头哥):支流科技技术 VP、Apache APISIX Committer
观察员
tison:“夜天之书”公众号作者、Apache Member & 孵化器导师
分享嘉宾
Keith Chan:CNCF 中国区总监、LF 亚太区策略总监
堵俊平:现为华为计算开源业务(OSDT)总经理、LF AI & DATA 基金会主席
边思康:蚂蚁集团技术战略发展部资深专家、开源办公室执行负责人
话题1:OSPO 是什么?
王晔倞(头哥):什么是 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