一个几乎人人都遇到过的难题
（配图由大模型 sensenova-u1.5-lite 与 skill sn-image-base 生成：左盘是票据与秒表，右盘是一块实心石头——能称的，和值得称的，通常不是同一样东西。）
任何在组织内部做开源工作的人，无论身处开源项目办公室（OSPO）、其他团队，还是在企业、学术机构、非政府组织或公共部门，大概都撞过同一堵墙：如何证明这项工作的价值。
Dawn Foster 在过去 25 年里一直在帮企业战略性地思考如何使用与贡献开源，其中很大一部分工作就是用数据和指标去证明开源项目的价值。她在 Intel 与 VMware 任过职，也长期在 CNCF 做志愿者，担任过贡献者战略技术咨询小组（Contributor Strategy TAG）联合主席，参与治理工作组，与上百个开源项目打过交道。
但她开场的第一句话，方向就和「指标崇拜」相反：
我深度参与了 CHAOSS（社区健康分析开源软件）项目，但我不喜欢孤立地思考指标。我更愿意做战略层面的思考：如何利用从指标中学到的东西，去改进我们的开源工作。
这也是为什么这场演讲的重点不在指标本身，而在于把指标放回「证明价值」这件事里的正确位置。
一、先承认：这是一场度量权的冲突
在讲方法之前，有一层更根本的东西值得先摊开。
开源团队被要求证明价值时，通常拿到的是组织既有的那套度量工具：FTE 折算、ROI、交付数量、工单吞吐。这套工具是为可分配、可计价、可归属于某个责任主体的活动设计的。而开源工作的核心产出——上游信誉、社区信任、对路线图的影响力、危机发生之前的预警——恰恰不具备这三个属性。
于是出现一个很典型的处境：你不是没做出东西，你是做出了这套尺子量不出来的东西。
Dawn 没有用这套语言，但她描述的每一个困境都是它的症状：
- 说「我们为社区做贡献」，听起来像慈善；
- 报「提交数、维护者数、PR 数」，只证明了投入时间，没证明换回了什么；
- 领导层问「哪些项目最重要」，合规团队递上来的却是出现频率最高的小工具清单。
她在 VMware 做的那个动作特别值得记住。高管问「哪些开源项目最重要」，她没有去优化那份频率清单，而是换了一个问法去问业务部门的产品人员：
「离开哪些开源项目，你们就无法交付产品？」
这一换，本质上不是报表技巧，是把度量权从「谁在数」重新拉回「数什么」。
二、目标对齐：从组织目标出发，而不是从活动出发
CHAOSS 常被误解为「一堆工具和指标」。实际上它近年做了「从业者指南」系列（Practitioner Guide Series）：每份指南聚焦一个主题，价值不在指标，而在如何跨越关键领域做出真正有意义的事。覆盖贡献者可持续性、组织参与度、响应速度、可行性与研究软件影响力等方向。
其中一份专门讲「在组织内部展示开源努力的价值」。大多数指南被设计成入门指引，唯独这一份是个硬骨头——因为它面对的不是「怎么做」，而是「怎么被允许多做」。
两种常见但失效的说法
第一种，慈善叙事。「这是为了社区的利益。」这当然是事实，但它几乎不可能打动正在分配预算的人。
**第二种，工作量概览。**提交数、维护者数、代码量。它只能说明人们花了时间，没有证明这些时间换回了什么（return）。
展示开源工作价值的最好办法，是证明这项工作如何帮助组织实现其目标。
领导层必须放眼全局，把资源给影响最大的工作。这意味着你真正的对手不是「不理解的领导」，而是组织内其他同样在争夺有限资源的团队。你要证明的不是「我们很努力」，而是「我们这件事值得排在别人前面」。
案例：Pivotal 与 Kubernetes
Dawn 在 Pivotal 做开源战略师期间（VMware 收购之前），Kubernetes 是产品战略的关键一环。当时公司正把主要产品的底座从 Cloud Foundry 迁到 Kubernetes，那是 2018–2019 年，Kubernetes 远不如今天成熟。
这是个大转弯：Pivotal 是 Cloud Foundry 的创建者之一，在那个项目里影响力巨大；对 Kubernetes 却是新手。
她做了三件事——和推动这次转型的 CTO 反复谈，和各个产品线的负责人谈，搞清楚未来几年的目标；同时进 Kubernetes 社区，和自家工程师讨论各领域的优劣；然后把「我们未来需要什么」与「Kubernetes 需要改进什么」对上。
落点是一份很长但清晰的书面策略：把公司的开源 Kubernetes 工作与整体使命、目标、产品战略一条条接起来；说明长期产品战略依赖 Kubernetes 的哪些具体领域；概述需要在哪些地方贡献才能支撑这些产品。
结果是为上游项目争到了人员编制。此后团队持续跟踪贡献，用数据向公司交付证明。
值得注意的是：她争到的不是「预算」，是「人」。在开源这件事上，人员配置才是真正的资源承诺——预算可以买服务，编制只能靠理由。
其他环境：大学、公共部门与外部出资人
在大学、学术界或公共部门，还多一层：你往往要向外部出资人证明价值。比如 Sloan 基金会资助了多所大学的 OSPO 工作。
这时你不仅要向已经出钱的人证明，还要向未来的出资人证明。逻辑与企业类似：了解特定出资人的目标，确保你的工作与其拨款策略或公开征集要求一致。这是企业环境之外额外的一层工作。
还有一层是与法规、指令对齐，在公共部门与非营利 OSPO 中尤其重要。欧盟及其他地区正在推动「数字主权（digital sovereignty）」，把开源视为数字领域战略独立性的关键。这可以成为论证某些开源倡议的正当理由——把工作价值表述为更广泛数字主权努力的一部分。
同理，政府指令与法规也会影响企业环境中的开源与供应链，例如软件物料清单（SBOM）相关指令与欧盟《网络弹性法案》（Cyber Resilience Act，CRA）。合规本身也是一种价值，只是它属于「不出事」的那一类价值。
三、关键性：判断标准是「能不能轻松替换」
确定目标之后，第一步是排优先级。CHAOSS 的指南给出一个框架：把项目关键性（criticality） 与项目健康风险（project health risk） 结合起来。
先看关键性——它定义的是项目对你这个组织的重要程度。这里有两点必须分清：
- 这里的「关键性」是组织视角的，与 OpenSSF 的关键性评分不同，后者度量的是项目对整个生态系统的影响力。
- 「被频繁使用」不等于「具有战略意义」——前者是规模问题，后者是替代性问题。
我判断的方法是：我是否可以轻松替换它？
- 小型代码库，能用别的库替掉或自己重写 → 大概率不是关键项目；
- Kubernetes 或 Linux 内核这种复杂度，换不掉、也重写不了，而你依赖它跑关键业务 → 它就是你的关键项目。
在 VMware，她的团队维护「战略项目清单」。合规团队那份「出现频率最高」的清单之所以没用，正是因为它统计的是规模，不是替代难度。而向业务部门问「离开哪些项目你们就无法交付产品」，问的是后者。这份清单后来有三个用途：给高管一个窗口、帮业务部门在同一个项目上协调、为分配人员去贡献提供理由。
在大学与学术环境，关键性依然成立，只是换一种说法——「研究软件的影响力（research software impact）」：开源软件在实现教育与研究目标中有多重要。在公共部门，如果开源工作影响基础设施、网站或面向公众的关键服务，它的价值就可被论证。
四、健康风险：优先级不是「重要×重要」，而是「重要×脆弱」
有了关键性，还要看项目健康。有些项目比其他项目更健康、更可持续。一个关键且健康的项目，优先级可能低于一个同样关键但濒临失修的项目——因为后者需要你出手才能变得安全，而前者不需要。
Dawn 常把健康风险表述为可行性（viability） 问题：这是管理风险、降低中断几率的起点。CHAOSS 有一份基于 Gary White（Verizon）工作的从业者指南，提供了框架与指标，覆盖治理、社区、合规、安全四个面向。
思考健康风险，不只是识别风险，还要想你如何把它改好——改善本身也是价值论证的一部分。
可以分配员工时间提升贡献者可持续性、组织参与多样性等，尤其是那些对你极其关键的项目。
优先级 = 关键性 × 健康风险。
这个乘积每家组织都不一样，它的意义在于：告诉你在有限资源下，哪一块最值得动手。
一个很少被说出口的推论是：这套框架让「投入上游」第一次有了可辩护的理由。不是「我们应该回报社区」，而是「这个项目对我们关键且脆弱，必须由我们（或我们资助的人）去修」。前者是道德诉求，后者是风险管理——而风险管理是能进预算表的。
五、沟通价值：衡量重要的事，并用数据讲故事
确定关键项目、排好优先级，剩下的是沟通。这一步最容易走偏。
太多时候，OSPO 倾向于测量「容易计算的东西」（比如提交数），而不是「真正有价值的活动」。
与领导、出资人和利益相关者的沟通，必须精准落在价值上。可以问的具体问题是：你需要的功能是否完整且稳定？你关心的问题是否已被解决？你依赖的项目是否健康且可持续？
归结起来就一句：衡量重要的事情，并用数据讲述价值的故事。
四个维度：Linux 基金会的 OSPO 价值框架
Linux 基金会的 Ibrahim Haddad 博士在 2026 年 6 月的报告《Measuring OSPO Value: A Framework for ROI, Resilience, Risk Foresight, and Strategic Influence》中，提出了四个相互关联的维度：
- 成本规避（Cost Avoidance / ROI）：OSPO 通常不产生直接收入，但能减少重复劳动、提高效率、降低维护成本，实现财务合理化。核心问题是「没有 OSPO 我们会多花多少」。
- 韧性（Resilience）：通过主动度量，避免高调危机发生。
- 风险预见（Risk Foresight）：在问题仍然可控时发现它。如果韧性是承受中断的能力，风险预见就是在中断还治理得了的时候检测到它的能力。
- 战略影响力（Strategic Influence）：组织从被动依赖开源，转向主动参与生态，从而获得能动性、杠杆与技术选项权（technology optionality）。
这四维之所以重要，是因为它们没有一个是活动量指标。它们衡量的都是「没有这件事会怎样」——而「没有它会怎样」，恰恰是唯一能进入高层决策语言的开源价值表述。
问答环节
Q1：我们的产品不是软件，管理层认为开发软件是供应商的事。如何证明开源工作的价值？
这确实更难。但即使你们不开发软件，软件仍是你们向客户提供服务不可或缺的一部分。关键是设法把开源底层技术与组织的整体业务目标——交付服务、提升效率——接起来。
Q2：对想开始使用和贡献开源软件的公司，如何说服管理层？
强调「不要重复造轮子」。现有开源软件已经成熟、可靠且安全。与其把大量工程时间花在内部重造上，不如利用已经存在的技术。同时可以引用大型银行（如 FinOS 领域）和政府部门安全使用开源的例子来提供背书。
结语：难的不是方法，是承认尺子错了
这场演讲给出的路径其实不复杂：先对齐目标，再用「能不能轻松替换」判断关键性，用健康风险排优先级，最后用利益相关者听得懂的话把兑现的东西讲出来。
四个步骤里没有一个技术动作。它们全都是制度性动作——把「我们做了什么」翻译成「不这么做会损失什么」，把「道德诉求」翻译成「风险管理」，把「社区利益」翻译成「组织目标」。
这也解释了一个长期存在的不适：为什么 OSPO 明明在做难事，却总在解释为什么自己该存在？
因为它被要求用别人的尺子证明自己的价值。Dawn 这场演讲真正的贡献，不是给了四步法，而是示范了可以换尺子——只要你愿意把默认的问句从「你们做了什么」改写成「离开哪些项目你们就交不出东西」。
前者只能得到一张报表。后者能得到一份清单，一份策略，和编制。
演讲信息
- 讲者：Dawn Foster（Fast Wonder；CHAOSS 项目长期贡献者，CHAOSS OSPO 工作组联合主席，曾任 CNCF 贡献者战略 TAG 联合主席）
- 场合：Open Source Summit Europe 2026（与 Embedded Linux Conference Europe 2026 同期举办），2026 年 10 月 7–9 日，布拉格会议中心（Prague Congress Centre），捷克
- 视频：YouTube · The Linux Foundation
- 整理说明：本文依据讲者提供的演讲脚本与公开材料整理，非逐字翻译；引述处保留原意，评论部分为整理者所加。
参考资料
- Dawn Foster, A Strategic Approach to Demonstrating the Value of OSS Efforts（演讲），Fast Wonder — https://fastwonderblog.com/
- 演讲视频（YouTube，The Linux Foundation 频道） — https://youtu.be/8b4W4pgapaM
- Open Source Summit Europe 2026 会议主页（2026 年 10 月 7–9 日，布拉格） — https://events.linuxfoundation.org/open-source-summit-europe/
- Embedded Linux Conference Europe 2026（与 OSS EU 2026 同期举办，布拉格） — https://elinux.org/ELC_Europe_2026_Presentations
- CHAOSS Practitioner Guide: Demonstrating Organizational Value — https://chaoss.community/practitioner-guide-demonstrating-org-value/
- CHAOSS Practitioner Guides 总览 — https://chaoss.community/practitioner-guides/
- CHAOSS（社区健康分析开源软件） — https://chaoss.community/
- Ibrahim Haddad, PhD, Measuring OSPO Value: A Framework for ROI, Resilience, Risk Foresight, and Strategic Influence, The Linux Foundation, June 2026 — https://www.linuxfoundation.org/research/measuring-ospo-value
- 该主题的汇总页（Software Stewardship Lab）— https://stewardshiplab.org/reports/demonstrating-oss-value
- 欧盟《网络弹性法案》（Cyber Resilience Act, EU 2024/2847）— European Commission
- OpenSSF Criticality Score — https://github.com/ossf/criticality_score
- CURIOSS（Community for University and Research Institution OSPOs）— https://curioss.org/