vivo互联网技术

开源V话:S1 OSPO 与开源 | x06 从索取到贡献

【开源V话】旨在以图文并茂的方式通俗易懂地传播开源文化及相关知识,分享开源实践及洞见,成为开源文化及开源生态发展的参与者、贡献者和布道者。

欢迎来到第一季“OSPO 与开源”,共8期,本文是S1x06期。


Image

开源并非免费午餐,记得回馈上游。

只索取不贡献?请留心“公地悲剧”。

Image
OSPO的进阶任务是建立 Upstream First 的文化。 这不仅是情怀,根本逻辑是利益:
  • 如果不把补丁合并回上游,每次版本更新你都要重新合并维护(Technical Debt);顺利的话只是重复劳动,增加变更次数,不顺利的话出现冲突,合并的复杂度和难度越来越大,最终会拖垮一个项目。

  • 参与上游治理,贡献公共解决方案,隔离私有需求实现,最终才能影响技术走向。Be a good citizen.

S1x06 从索取到贡献

(Upstream & Culture)

许多企业在使用开源时存在短视行为:为了快速满足业务需求,直接在下载的开源代码上进行“魔改”(Fork & Patch),却从不考虑是否要将修改回馈给上游社区。

这种做法会导致严重的技术债务(Technical Debt):

  • 当上游项目发布新版本(包含安全修复或新功能)时,企业因为代码差异过大,最终可能无法合并及时升级,导致系统逐渐僵化,面临高危漏洞风险,维护成本指数级上升。

OSPO 需要推动 "Upstream First" (上游优先) 策略:

  1. 补丁回馈:鼓励工程师将 Bug 修复和通用功能合并回上游主干。

  2. 消除障碍:简化员工对外贡献的审批流程(例如:对于非核心IP的修改,实行“过程记录”甚至“事后报备”而非“事前审批”)。

  3. 社区治理:支持员工竞选开源项目的 Maintainer 或委员会成员,从而在技术路线图上拥有话语权,保护企业的长期利益,支持开源生态可持续发展。

🔗参考资料与扩展阅读:

vivo开源实践与思考

盲目倡导企业内部开发者为开源项目做出贡献,或者是设置复杂冗长的代码贡献审批流程,可能都不太可取。在vivo,我们首先要考虑的是产品与服务的用户体验和业务发展及其技术需求,把开源软件供应链的底层逻辑梳理并理解透彻,通过OSPO的协调和组织,帮助业务降低风险、提升效率/质量,促进创新;这是我们正在持续推动建设的核心开源能力,阶段性目标是建立一个合理的开源软件供应链健康度指标。

  • 技术对于业务成功来说不仅仅是研发成本,更是一种投资,我们经过不同业务领域的实践验证,并深刻理解这一点。因此,合理管理技术债务,按周期滚动追求ROI的最大化是更加务实可取的一种策略。

  • 企业员工为开源项目做出贡献是值得鼓励和倡导的行为,但也需要考虑现实的问题,该开源项目到底与公司业务的关联度如何,在开源软件供应链中处于什么环节。

  • 作为 OSPO,我们也在影响采购部门,推动对商业软件和开源软件同等看待和一致评估,平衡当下显性成本与未来隐性成本,追求更长远的健康和可持续发展。

  vivo开源 

说明:
  • 本文在创作中使用 AI 工具作为辅助
  • 本系列内容采用 CC BY-SA 4.0 许可发布

第一季 OSPO 与开源 

  1. S1 OSPO 与开源 | x01 OSPO概述

  2. S1 OSPO 与开源 | x02 为什么你需要它?

  3. S1 OSPO 与开源 | x03 OSPO 应该在哪儿?

  4. S1 OSPO 与开源 | x04 组建你的“复仇者联盟”

  5. S1 OSPO 与开源 | x05 那层看不见的盾