开源V话：S1 OSPO 与开源 | x03 OSPO 应该在哪儿？

位置决定话语权。

OSPO 该归谁管？

法务、工程，还是产品？ 

根据 TODO Group 的调查，

向 CTO 汇报是最常见的选择（约 40%）。 

但关键不在于汇报给谁，而在于授权。

一个没有跨部门协调能力的 OSPO，

最终只能沦为盖章机器。

你的 OSPO 在哪一层？

S1x03 OSPO 应该在哪儿？

OSPO 的汇报线直接决定了它的执行力和侧重点。在 TODO Group 的年度调查中，OSPO 的位置通常有以下几种模式，各有利弊：

1. 向 CTO/工程副总裁汇报（约40%）：

   优势：最主流的选择。OSPO 贴近研发一线，能直接影响技术选型和工程文化，工具链落地容易。

   劣势：可能在处理复杂的法律条款或跨部门（如市场、HR）协调时显得话语权不足。

2. 向 CIO/IT 部门汇报：

   优势：侧重于资产管理、安全性与标准化，流程管控严格。

   劣势：可能容易变得官僚化，可能扼杀开发者的创新热情，变成单纯的审核机构。

3. 向法务总监（General Counsel）汇报：

   优势：合规性和风险控制做到极致。

   劣势：容易形成“防御性”思维，使得开源贡献和社区互动变得极其困难。

🔗参考资料与扩展阅读：

• TODO Group Guides: 

  《Creating an Open Source Program Office》章节中的组织架构部分。

  https://todogroup.org/resources/guides/how-to-create-an-open-source-program-office/

• TODO Group OSPO 案例

  https://todogroup.org/resources/case-studies/

• VMware/ Microsoft OSPO：可以参考这些企业公开分享的 OSPO 组织结构图 

  VMware：https://blogs.vmware.com/opensource/

  Microsoft OSPO：

  https://github.com/microsoft/OSPO

• 开源治理案例 https://ospo.co/case-studies/

vivo开源实践与思考

vivo 的 OSPO 到底是如何组织的？向谁汇报呢？要回答该问题，需要回归到我们的企业文化与价值观。早在统一进行开源治理之前，我们的业务就已经在基于开源软件来常态化开展研发活动；随着业务发展和用户规模持续增长，不同业务线的需求越来越多，就会出现“谁最痛，谁喊得最响亮”的情况，我们的文化中对于此类情况会倡导“有人负责我配合、没人负责我负责”。因此，最早的两个OSPO团队就从互联网业务和OS业务先后“涌现”了。

• 两个OSPO团队都设立在各自业务线的工程团队，向工程VP/GM 汇报。

• 公司层面统一使用“vivo开源”标识，基础能力和系统共建共用，统一运营。

• 对外协作与沟通，也统一使用“vivo开源”/"vivo Open Source"标识，根据各自不同业务特点和需求，参与不同的基金会、社区、会议，如Linux基金会、CNCF、C2PA、TODO Group等，以及KubeCon&CloudNativeCon、KCD、OSPO Summit等。

• 随着基于大模型的AI技术持续发展，我们的开源阵地也从 GitHub 拓展到 HuggingFace 等。