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

这个世界是由观念所塑造的，也就是说经济和社会是由于人们的观念指导下的行动所成就的，开源需要对应的观念，尤其是在和商业模式利益纠缠的情况下，这方面或许我们只看到RedHat在努力，当然也要看决策层的认知。Brian Proffitt 是为数不多的多年都在为开源的价值呼号的布道者，尽管他只承认自己是一位记者。

Wed Sep 17, 2025 | 7200 Words | 大约需要阅读 15 分钟 | 作者： Brian Proffitt @CHAOSS mini-summit | 译者： 「开源之道」·适兕 && 「开源之道」·窄廊

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

大家好，非常感谢邀请我在 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 直接亮给客户。
  • 市场人员只要持续同步：
    • 客户可提前适配新特性；
    • 潜在用户可能被吸引进来参与社区；
    • 公司形象 = 透明、技术引领。

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

当我们谈论业务价值时，有些事情你绝对不应该做。我之前已经提到过其中一些。你的社区是一个宝贵的资产，但无论如何，都不要把他们当作潜在客户资源。在红帽公司，我们一次又一次地看到，新来的销售人员和市场营销人员都非常兴奋，他们想赚大钱，我理解这一点。但随后，他们却做出了一些对社区不健康的事情。其中之一就是去向现有社区成员推销产品。这通常是你不应该做的事情。你不想跟踪软件用户数据。在许多国家，隐私问题实际上将这种行为定义为不受欢迎的行为，有时甚至是非法行为。而且，这种行为通常也不是一个好的做法。如果你开始在未经用户许可的情况下监视用户并试图弄清楚他们的行为，你最终会疏远你的客户群体。当然，遥测技术在某些情况下是有用的，而且是在获得许可的情况下进行的，每个人都清楚正在收集什么数据、为什么收集以及如何使用这些数据。这些是好的做法。但如果遥测技术被用于生成潜在销售，那么在开源社区中，这种行为通常不受好评，也不会得到回报。你绝对不想在社区活动中强行推销产品。我永远不会向你推销红帽公司的任何产品。这不是我的工作，而且如果我那样做，那将是粗俗的、荒谬的，尤其是在像今天这样的场合。所以，这不是你的公司应该做的事情。不要忽视社区的贡献。有时你会得到一些新功能或新的漏洞修复，而这些并非来自你公司的员工。你要认可这些贡献，使用它们，将它们纳入其中，并确保给予社区用户应有的认可。开源不是关于哪家公司做得最好，开源是关于哪个社区成员参与最多或有最好的想法。我们都喜欢得到认可，我们都希望为我们的工作得到回报，这就是一个方法。所以，不要通过排斥或忽视社区贡献来疏远你的社区。

那么，你可以做些什么呢？我刚刚已经讲了，这些是不好的行为。那么，哪些是好的行为呢？你总是要保持对上游社区的积极关注，这最终会给你带来回报。这并不容易，而且进展缓慢。这也是企业在开源方面面临的一个问题：他们不一定能立即看到回报。但只要你坚持不懈，建立信任，做积极的事情，你最终会得到回报。在财务增长方面，我曾说过，你不应该从社区中挖掘潜在销售的数据。然而，你可以关注那些对新闻通讯做出回应的人，或者在活动中与你交谈的人，这些我们称之为“软性潜在客户”。所以，如果有人在类似SCALE或开源峰会这样的活动中找到我，问我关于某个产品的问题，我可能无法向他们提供太多信息，因为，再说一次，我不是销售人员，我也不是产品工程师。然而，我可以收集他们的信息，并将这些信息转交给其他相关人员。因此，沟通的机会是存在的。只是你不想成为挖掘这些信息的人，但你应该在那里与人们交流，并可以将人们适当地引导给合适的销售和市场营销人员，也许可以促成销售。只要这是由社区成员主动发起的，这是完全可以的。我们已经在红帽公司这样做了有一段时间了。我们确实会追踪来自上游用户的销售。所以，尽管我们没有积极地去接触这些上游用户，也没有主动将他们引入我们的生态系统，但当有人例如从 Ovirt 社区过来，实际购买了红帽虚拟化的下游产品支持时，我们会记录下来，并表明，虽然我们没有主动促成这笔交易，但这显然是社区带来的一次胜利。追踪这类指标确实能让人们看到社区的价值，尽管这是一个非常被动的过程，我们也不应该主动去招募人员，但当他们主动加入时，这确实是一个值得记录的胜利。然后，再说一次我之前提到的，你与社区贡献合作，建立合作伙伴关系，开发新功能，让社区成员参与进来，你不仅在改进你的产品，还在建立关系，这些关系最终应该会为你的公司带来某种财务收益。

OK。那么除了企业的软性价值以及销售和市场营销方面——这些是比较难以追踪的——有没有办法在纸上追踪开源社区的投资回报率（ROI）呢？事实证明，确实有，我们在红帽公司也在采用一些方法。有些我们现在正在做，有些我们还在试验中。在我接下来的讲解中，我会非常清晰地定义我们现在在做什么以及我们想要做什么。所以，投资回报率（ROI）的神秘之处在于，它一直很难衡量，因为当你参与一个社区时，你通常会在活动上花钱，在基础设施上花钱，你有内部开发人员在社区中工作，所以你在他们的工资、差旅费以及他们完成工作所需的一切上都在花钱。但你并不总是能看到你以实际美元金额的形式得到了什么回报。同样，我们之前谈到了销售价值和营销价值，但这些通常是更难衡量的东西。不过，有一些事情你可以做。一个简单直接的方法是，假设我有一款软件，我知道我在开源社区中分发它，甚至免费提供。如果市场上有竞争对手的类似软件，它是专有的，但我知道他们的销售额，无论是通过公布的销售数字还是我自己的合理猜测，我都可以做一个简单的假设，比如，如果我的软件应用程序与这款基本功能相同的专有应用程序一样，而我知道他们每年能赚这么多钱，那么我就可以说，这就是我为我的客户提供的等价值。然后我还可以接着说，我以这样的成本做到这一点，这就是我的实际利润、成本与产生的收入之间的对比。这是一种简单的等价值模型。对于非常专业化的应用程序来说，使用这种方法是可以的。但对于像红帽这样的公司，我们开发的是一个平台，好吧，我们开发的是一个平台，最终是一个操作系统，它就像Mac和Windows一样运行。那么我们是否可以在这个平台上采用等价值模型呢？其实并不能，因为你知道，我们的软件通常运行在服务器上，它很少运行在台式机上，所以它并不是一个桌面操作系统。因此，等价值模型在这种情况下就行不通了。所以，你可以在一些专业化的场景中使用这种方法，但并不总是适用。另一种方法是，即使是Linux基金会——你知道，它显然是Chaos项目的母基金会——我们过去也这样做过，我实际上也参与了其中的一些项目。你可以查看软件代码行数，然后按照等效模型计算开发这些代码的成本，然后将这个成本与你实际产生的收入进行对比，这样你就可以计算出软件的价值。然而，最难衡量和量化的是创造力的价值。我们始终认识到，开源的一个最大价值就是创造力价值。如果我与来自其他国家、其他文化、其他公司的人合作，这些人来自不同的教育体系，这些体系培养了他们，那么我几乎可以肯定地获得一种创造力，以及新的想法和新的思维方式，而这些是我自己工作或者即使在我自己的公司内部工作时都无法获得的。文化和公司往往会趋于同质化，使事物变得相似，而当它们一起构建东西时，这种现象更为明显。但在多样化的开源社区中，你不会看到这种情况。因此，你获得了创造力的价值。这可能是我们在谈论开源的投资回报率时最难衡量的东西。

关于人力小时的例子。这又是我很久以前在Linux基金会时参与过的事情，当时我们对Linux内核的价值进行测量。其基本方法是代码行数乘以每小时工资，再除以开发所需的时间。这样你就可以大致估算出重新创建该软件的成本。然后你可以考虑实际成本，比如是否支付服务器费用，是否支付员工工资，以及是否支付参与上游社区的合作伙伴的费用。接着你会得到收入，你基本上可以将实际成本减去创建价值，再加上收入，这样就得到了你的投资回报率（ROI）。我们目前正在尝试这些方法，尤其是最后那个ROI公式，因为其中有一些细微差别并不适用于每一个社区。这是一个非常直接的关于投资回报率可能看起来像什么的简化模型。我们目前在红帽公司正在尝试这种方法。我再次强调，我们在红帽尝试这种方法并不是因为我们想做别的事情。我们始终会做开源。即使你始终会开同一种车，或者骑同一种自行车，或者骑同一种摩托车，而这正是你热爱的机器，了解这台机器的工作原理也没有坏处。确保这台机器以最佳状态运行也没有坏处。红帽始终会是一家开源公司，这就是我们所做的事情。但我们可以通过更高效的方式做得更好。通过更高效地运作，我们可以更好地扩展规模，从而对开源生态系统产生更广泛的影响。

除了代码之外，还有其他可以在纸上衡量的东西，比如文档，更好的文档。你知道你在构建文档方面的投入，通常这会减少支持成本，所以你可以将这一点考虑进去。依赖文档的人越多，可能联系你的支持团队的人就越少，这样就提高了效率。在上游更早地发布漏洞修复和安全修复，也会减少你下游产品的支持成本，并且能够提高客户留存率。这些修复越早发布并被看到，你的客户就会越觉得你在维护他们所依赖的软件。

那么，CHAOSS 能做些什么呢？CHAOSS 社区可以做些什么呢？因为我已经谈了很多关于红帽在确定业务价值方面所做的事情，这乍一看似乎与我们努力推动的社区价值并没有直接关系。我们关注的是社区的健康、可持续性和风险因素，这些都是非常重要且关键的指标，但它们似乎与业务无关。我想说的是，也许 CHAOSS 未来可以在这方面做一些更深入的研究。我不想让我们成为一个以业务为中心的组织，但我确实认为，关注与业务相关的指标对我们来说是有价值的，因为这是双向的。开源与业务并不是单向的关系，它不仅仅是关于社区的健康，因为社区的健康也依赖于管理该社区的公司的健康，或者说是那些管理该社区的公司的健康。因此，重要的是要认识到这是双向的。那么，我们可以做些什么呢？目前还没有业务指标。企业喜欢衡量各种事物，他们渴望获取所有这些信息，以了解自己的表现。有没有我们可以借鉴并纳入社区健康的指标呢？因为社区是由个体组成的，是由管理这些社区的非营利基金会和组织组成的，也包括那些试图从中获利的企业。有些企业在这方面做得比其他企业更好。我们如何衡量企业在社区中的参与度，以及它们是否是良好的社区成员？如果它们是优秀的社区成员，我们希望它们留在社区中，但如果它们没有获得真正的业务价值，那么我们就面临风险，它们可能会改变主意，可能会改变许可证，可能会停止参与开源社区，这可不是好事。那么，我们能做些什么来预见这种情况呢？无论在什么情况下，我们都应该强调多样性。所有的多样性都是好的，无论是性别、种族、企业，还是地理位置。再次强调，参与的人越多，他们在解决问题和创新方面的差异越大，任何开源项目都会越好。我认为 CHAOSS 应该专注于这些指标，而且 CHAOSS 在这方面已经做得很好了。我认为我们应该继续这样做，并尽可能地加以扩展。最后，我们需要弄清楚如何将这些信息传达给企业，而不仅仅是谈论社区的健康，而是如果我们可以找到方法来谈论社区的价值，他们应该承担大部分的这项工作，因为他们想知道业务是如何运作的。但我觉得 CHAOSS 可以成为他们的合作伙伴，帮助他们确定开源社区对参与其中的组织的价值。这并不是为了炫耀，也不是为了竞争，而是为了确保人们仍然关注开源。在过去的几年里，我们反复看到，企业对成为开源公司感到非常兴奋。他们没有考虑清楚他们将如何实际产生收入。当收入没有进来，或者没有快速进来时，他们会感到失望。然后他们改变了他们的商业模式，将许可证改为不是开源的，而是源代码可用的。他们不知道自己要进入的是什么，或者他们假设，如果他们让产品开源，就会发生神奇的事情，他们会自动赚钱。这是不正确的。赚钱很难，这是很难做到的。如果这很容易，我们都会很富有。所以，你必须认真思考。CHAOSS 有一个独特的视角，因为我们一直在与这些社区合作，帮助教育和告知现有的企业以及新进入开源项目的企业，告诉他们：“嘿，这就是你要进入的领域。”所以，现在对开源来说是一个非常令人兴奋的时刻，它真的已经开始改变世界了。开源和社区在全球范围内的使用，以及不同国家和地区对开源的接受，将是一个真正的福音。我们现在正在与像联合国以及非洲的其他政府组织合作，为那些技术尚未普及或更难部署的地区实施开源解决方案。但现在每个人都有机会参与其中，他们有机会去构建一些东西，我们可以一起构建。让企业和其他组织参与进来，是实现这一目标的重要一步，帮助他们理解开源社区是如何运作的，我认为应该是 CHAOSS 关注的重点。

感谢大家聆听我的演讲。希望你们今年的会议一切顺利。很遗憾我没能亲自到场。期待收到大家的问题，并在接下来的一年里继续就这一话题展开讨论。再次感谢，祝大家度过美好的一天。

关于作者

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等， 「开源之道」·窄廊 负责对话、提出问题、对回答进行反馈等操作。