技术学习分享_一航技术 技术资讯 开源办公室(OSPO)大揭秘

开源办公室(OSPO)大揭秘

广告位

近年来,国内互联网大厂相继设立开源办公室(Open Source Program Office,简称 OSPO),其中有部 分企业在 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

本文来自网络,不代表技术学习分享_一航技术立场,转载请注明出处。

作者: 一航技术

上一篇
下一篇
广告位

发表回复

返回顶部