开源的度量指标和商业业务(演讲实录)

原视频链接（点击图片可打开）：

大家好，非常感谢邀请我在 CHAOSSCon 做主题演讲。我叫 Brian Proffitt，是红帽开源项目办公室社区外联团队的高级经理。今天很高兴和大家分享一个红帽非常关注的话题——如何衡量开源的“商业价值”。稍后我会解释具体含义，核心思路是：把我们现在用于衡量社区健康的指标，与企业真正想了解的开源参与价值结合起来。我们都知道开源社区蕴含巨大价值，现场无需再多说，但企业往往即便认同，也会因“纸上看不到明确商业收益”而犹豫是否全力投入。因此，在介绍红帽和其他企业关注哪些价值之前，我先统一几个术语，方便大家同频。

上游（upstream）与下游（downstream）

红帽常用这对比喻：

上游 = 开源社区驱动的项目，多组织甚至个人参与，靠近“河流源头”。

下游 = 基于上游代码做商业发行的产品，通常由单一组织主导（也开源，非专有）。

举例：RHEL ← CentOS Stream ← Fedora ← 众多更上游的组件项目。

关于许可证

今天谈价值，我想先对许可证说一句——“其实不重点讨论许可证本身”。我们不会谈论许可证。在这次对话中不谈。许可证很重要，但它们并不适用于我们正在讨论的价值类型。实际上，这也是为什么我们目前在商业领域看到很多混乱的原因，因为有些新创企业认为开源是一种商业主张。它不是。它是一种开发者模式和开发者方法论。因此，许可证的作用是为社区设定规则：如何接受贡献？如何进行分发？但它们不会改变价值等式。它们是完全分开的。

所以，如果我提到相关内容时，我还会使用一些术语，并且我倾向于互换使用这些术语。有“自由软件”，这些项目使用的是我们所说的限制性许可证，基本上要求如果你对软件进行了更改，并且你分发了该软件，这些更改必须向上游共享，并且也必须分享给获得该软件的其他人。此类许可证包括 GNU 通用公共许可证（GPL）和 LGPL。

然后我们提到“开源软件”，这些是宽松许可证。更改可以保持私有，也可以公开，随你喜欢。你不必将更改推送给全世界，如果你不想的话。这类许可证包括 Apache 公共许可证、MIT 许可证、BSD 许可证等。所以，如果我使用这些术语，这就是我们的意思。但重申一次，许可证并不是这次关于价值的讨论的核心内容。

业务价值

那么，企业到底在关注哪些“价值”呢？——既然与许可证无关。 下面我会按不同业务维度，梳理企业在评估一个项目时真正看重的价值点；这些价值都超出“销售收入”这种明面指标。 销售收入价值（Sales Value）的常见误区： “上游免费可下载，功能还够强，会抢走我商业版本的生意！”

事实：
- Red Hat 卖的不是软件，而是专家能力（支持、咨询、长期服务）。
- 上游使用不会导致下游销售流失；相反，它是未来客户的孵化池。

消除误区的做法：
- 让开发团队尽量在上游工作，只在必要时才 downstream 定制；流程单向透明（上游 → 下游）。
- 紧急下游热补丁只能偶发，且事后必须回传上游。
- 在社区会议中树立思想领袖地位；当潜在客户认可你的技术话语权，合同自然水到渠成。
- 提前接触用户——别把他们当“准客户”硬推销，但要洞察他们的真实需求，以便后续产品化。
- 把社区当“临时 R&D 部门”；以 Fedora 为例，大量实验性功能先扔给社区快速试错，稳定后再进入 RHEL。
- 用户也乐当“早期体验者”，因为价值=第一时间玩到最新最酷的功能；偶尔崩了也认。

上游不是销售敌人，而是价值放大器；免费用户 today → 付费客户 tomorrow，关键是你得让他们看见你的专业度与持续交付能力。

市场价值

再往下聊，就是“市场价值”（Marketing Value）。它比销售价值更“虚”，更难量化——销售终归能写进财报，“卖了多少钱”一目了然；市场价值向来是软指标。

1. 混淆“上游”与“下游”消息是常见坑

• 红帽内部以及客户、伙伴的市场同事，常把两者宣传口径混在一起，结果自乱阵脚。
• 解法：品牌隔离
  • 尽量让上游项目与下游产品叫不同名字（例如 Ansible 上下同名，就要特别说明“改的是上游还是下游”）。
  • 对外讲功能、讲路线图时，先分清“代码放在哪”。

2. 客户问题 → 先进上游，而非直接塞下游

• 很多公司图快，把客户定制直接推进下游，再“有空”反向移植（backport）；除非 Day-0 漏洞或极紧急修复，否则应先在上游解决。
• 让市场团队把客户痛点汇总成“需求管道”，直送上游开发，再顺势宣传：“客户的诉求我们第一时间在社区落地。”

3. 用“上游案例故事”打品牌

• 我当年负责 oVirt 社区时，大量撰写oVirt（上游）的生产案例，而非只讲下游的 Red Hat Virtualization。
• 目的：
  1. 证明“上游也能扛生产线”，打破“开源=业余/不稳定”的刻板印象；
  2. 为下游产品做信誉背书——“社区都敢用，商业版更没问题”。

4. 公开上游功能路线图，让客户“提前看见未来”

• 专有软件只能猜“下周放什么大招”，而开源可把上游 Roadmap 直接亮给客户。
• 市场人员只要持续同步：
  • 客户可提前适配新特性；
  • 潜在用户可能被吸引进来参与社区；
  • 公司形象 = 透明、技术引领。

总结： 市场价值来自“品牌清晰度 + 客户痛点直达上游 + 上游成功案例 + 公开路线图”。做到这四点，上游就不再是“影子项目”，而成为对外展示技术实力与前瞻性的最佳窗口。

关于作者

Brian Proffitt 是 Red Hat 开源项目办公室社区外展高级经理，专注于支持、社区指标以及基金会和贸易组织关系。Brian 的社区管理经验包括社区入职、社区健康和业务协调方面的知识。在 2013 年加入红帽之前，他是一名专注于 Linux 和开源的技术记者，也是 22 本消费技术书籍的作者。

关于译者

「开源之道」·适兕

「发现开源三部曲」（《开源之迷》，《开源之道》《开源之思》。）、《开源之史》作者，「开源之道：致力于开源相关思想、知识和价值的探究、推动」主创，Linux基金会亚太区开源布道者，TODO Ambassadors & OSPOlogyLive China Organizer，OSPO Group 联合发起人。

「开源之道」·窄廊

来自于大语言模型的 Chat，如DeepSeek R1、Gemini 2.0 Flash thinking expermental、ChatGPT 4o、Grok3、甚至整合类应用 Monica等， 「开源之道」·窄廊 负责对话、提出问题、对回答进行反馈等操作。