区分开源产品与上游供应商的 18 种方法

在本系列的前三部分中，我探讨了开源作为供应链、什么是产品，以及产品经理做什么。在这第四篇文章中，我将探讨从上游开源项目区分开源软件产品的多种方法。

由于开源项目本质上是信息产品，这些方法很可能适用于许多与信息相关的产品（例如 YouTube 创作者），这些产品都有免费赠送价值的组成部分。当构建产品的所需信息和材料可以免费提供给用户时，产品经理必须发挥创造力。

创造和获取价值

产品经理负责创建能够吸引和留住客户的解决方案。要创造客户，他们必须提供价值以换取金钱。像优秀的销售人员一样，产品经理不应该为他们的产品收费而感到内疚（请参阅 John Mark Walker 的如何销售开源产品）。

基于开源构建的产品从根本上讲与任何其他产品或服务没有什么不同。它们必须为客户创造价值。事实上，它们必须创造足够的价值，以便客户自愿支付足以支付开发成本并获得利润的价格。这些产品还必须与竞争产品和服务以及上游项目区分开来。

图片来源

^{（Scott McCarty，CC BY-SA 4.0）}

虽然基于开源软件构建的产品与其他产品和服务没有根本区别，但仍然存在一些差异。首先，一些开发成本由所有开源贡献者分摊。这些成本可能包括代码、测试、文档、硬件、项目托管成本等。但是，即使开发成本在开源中分摊，供应商在将代码产品化时也会产生费用。这些费用可能包括员工的研究、分析、安全、性能测试、认证流程（例如，与硬件供应商、云提供商等合作）以及销售和营销费用。

图片来源

^{（Scott McCarty，CC BY-SA 4.0）}

成功的开源产品必须能够收取足以支付分摊的上游开源贡献（开发成本）和下游产品化成本（供应商成本）的费用。换句话说，产品只有在创造的价值只能通过客户付费才能获取时，才能收取足够的价格。这听起来可能很苛刻，但这是所有产品的现实。产品管理中有一句话：祈求付费是行不通的。话虽如此，不要太担心。有道德的方式可以获取价值。

价值类型

从根本上讲，有两种类型的价值：专有价值和非专有价值。专有是一个在开源软件中不太好的词，但在制造业、金融业和其他行业中却是一个有吸引力的词。许多金融公司会强调他们的专有算法，制药公司和制造流程也是如此。在软件中，专有价值通常被认为与自由和开源软件完全不协调。人们常常认为专有价值是一个二元决策。如果没有受到许可的限制，人们很难想象开源软件环境下的专有价值。但是，正如我们将尝试证明的那样，情况并非如此。

从开源产品管理的角度来看，您可以将专有价值定义为客户很难或几乎不可能自己重新创建的任何东西，或者潜在客户不认为他们可以重新创建的任何东西。商品价值与专有价值相反。商品价值是客户认为他们在给定足够的时间和金钱的情况下可以构建（或重建）的价值。

仅当重建商品价值比购买产品更便宜或更容易时，重建才有意义。换句话说，好的产品应该比客户自己构建解决方案更能节省资金。开源产品就是在这个成本差距中存在和发展。

对于建立在或主要建立在开源供应链上的产品，客户保留“构建与购买”的决定，并且可以随时停止付费。这对于开源核心产品来说通常也是如此。只要大部分供应链是开源的，客户很可能可以重建一些组件来获得他们需要的东西。开源产品经理的工作与任何其他产品或服务的工作相同：通过提供值得付费的价值来创造和留住客户。

开源产品经理的差异化因素

像任何艺术家一样，产品经理以价值作为他们的媒介进行交易。他们必须为他们的产品定价和包装。他们必须不断努力将他们的产品与市场上的竞争对手以及作为该产品供应商的上游项目区分开来。然而，供应链只是产品经理可以用来区分和创造客户的工具之一。

这是一个不完整的列表，应该给你一些关于产品经理如何区分他们的产品和创造价值的想法。在阅读列表时，请深入思考，如果给定足够的时间、金钱和意志力，客户是否可以重新创造每个给定的价值。

• 供应链：选择上游供应商非常重要。与基于竞争性上游项目的产品相比，上游社区的健康是一个卖点。这种差异化的一个完美例子是 OpenShift、Docker EE 和 Mesosphere 等产品，它们分别依赖 Kubernetes、Swarm 和 Apache Mesos 作为上游供应商。类似于电动汽车正在取代汽油发动机，技术及其供应商的选择提供了差异化。

• 质量工程：上游持续集成和持续交付 (CI/CD) 以及用户测试是构建产品的绝佳基础。但是，至关重要的是要确保下游产品（通常由多个上游项目组成）能够与所有组件的特定版本协同工作。将整个解决方案放在一起进行测试，对于区分上游供应商和竞争产品都同样重要。客户想要开箱即用的产品。

• 行业认证：特定类型的客户，例如政府、金融服务、运输、制造和电信，通常具有认证要求。通常，这些与安全或审计有关，而且通常非常昂贵。认证非常有用，因为它们可以将产品与竞争对手和上游区分开来。

• 硬件或云提供商认证：廉价硬件的肮脏秘密是它一直在变化。通常，这种硬件具有具有不同成熟度级别的新功能。硬件认证提供了一定程度的信心，即软件将在特定的硬件或云虚拟机上运行良好。它们还提供了一定程度的保证，即产品公司和它认证运行的平台正在致力于使其协同工作。潜在客户总是可以自己审查硬件，但他们通常与硬件供应商和云提供商没有深入的关系，这使得他们难以要求修复和补丁。

• 生态系统：这代表了访问来自第三方供应商的大量附加解决方案。同样，生态系统提供了一些保证，即所有实体协同工作以使事情顺利进行。小公司可能会发现很难或不可能要求单个软件供应商认证他们私下构建的平台。对于个人用户来说，像这样的集成通常非常昂贵，最好由产品的客户分摊。

• 生命周期：上游项目非常棒，因为它们发展迅速并且不断创新。但是，许多不同上游项目的许多不同版本可以进入单个产品的供应链。确保不同上游项目的所有版本在给定的生命周期内协同工作是一项艰巨的工作。更长的生命周期使客户有时间获得投资回报。换句话说，用户花费大量时间和金钱来计划和推出软件。产品的生命周期承诺确保客户可以使用该软件并在合理的时间内从他们的投资中获得价值。

• 打包和分发：一旦供应商承诺在给定的生命周期（例如，五年）内支持某个产品，他们还必须承诺在该时间内提供打包和分发。产品和云服务都需要为客户提供规划路线图、执行推出以及在所需的生命周期内扩展的能力，因此包或服务需要保持可用以供客户使用。

• 文档： 这一点经常被开源项目和供应商忽视。将产品文档与产品生命周期对齐，而不是与上游供应商的文档对齐，至关重要。同样重要的是，要记录整个解决方案如何协同工作，无论是安装还是最终用户的使用案例。对于客户来说，拥有适用于他们所使用的特定组件组合的文档是有益的。

• 安全性： 与产品生命周期密切相关，供应商必须承诺在产品支持期间提供安全性。这包括分析代码、对漏洞评分、修补这些漏洞以及验证它们是否已修补。对于产品来说，这是一个从上游供应商中脱颖而出的绝佳机会。这确实是通过数据创造价值。

• 性能： 同样与产品生命周期密切相关，供应商必须承诺在产品的生命周期内提供性能测试、调整建议，有时甚至会向后移植性能改进。这是产品的另一个绝佳机会。

• 赔偿保证： 这本质上是一种保险，以防止使用该软件的公司被专利流氓起诉。通常，公司法律团队根本没有必要的技能来为自己辩护。虽然潜在客户可以为法律服务向第三方付费，但他们会像您一样了解该软件吗？

• 计算资源： 如果不付费，您根本无法访问计算资源。虽然有免费试用版，但持续使用始终需要付费，无论是通过云提供商还是购买硬件。事实上，这是基础设施即服务 (IaaS) 和软件即服务 (SaaS) 云提供商提供的最主要差异化价值之一。这与上游供应商有很大不同，因为他们永远没有预算提供免费的计算、存储和网络。

• 咨询： 提供设置和使用软件的操作知识可能是一种差异化因素。 显然，一家公司只要有足够的预算和意愿，就可以聘请到人才，但人才可能很难找到。事实上，有人可能会认为软件供应商更有可能吸引顶尖人才，从而为试图自己重构价值的用户创造人才真空。

• 培训： 与咨询类似，编写、配置、发布和大规模运营软件的公司通常最清楚如何使用它。 同样，客户只要有足够的预算和意愿，也可以聘请到人才。

• 操作知识： IaaS 和 SaaS 解决方案通常提供这种价值。 类似地，知识库和连接的体验，这些体验分析已安装环境的配置，从而为用户提供见解（例如，OpenShift、Red Hat Insights）也可以提供这种价值。 操作知识与培训和咨询类似。

• 支持： 这包括寻求帮助或提交支持票证的能力，与培训、咨询和操作知识类似。支持通常是开源产品经理的拐杖； 同样，客户通常可以重建自己的支持组织，这取决于他们希望在哪里战略性地投入预算和人员，尤其是对于一级和二级支持。三级支持（例如，内核程序员）可能更难聘请。

• 专有代码： 这是指未在开源许可下发布的代码。 客户始终可以构建一个软件开发团队，并用他们需要的缺失功能来增强开源核心代码。 对于供应商而言，专有代码的缺点是在上游开源供应商和下游产品之间造成了一种不自然的竞争。 此外，开源代码和专有代码之间的这种不自然的分裂并不能为客户提供更多价值。 它总是让人感觉价值被不自然地扣留了。 我认为这是一种非常不理想的价值捕获形式。

• 品牌： 品牌资产不易衡量。 这实际上归结为一般的信任程度。 客户需要相信解决方案提供商可以在他们需要时帮助他们，并且愿意这样做。 建立品牌很慢，失去品牌很容易。 仔细思考可能会发现，公司内部支持组织的情况也是如此。 用户将很快失去对内部支持组织的信任，并且可能需要数年才能重建信任。

通读列表，您是否认为潜在客户可以重建几乎任何这些项目的价值？ 答案几乎肯定是肯定的。 几乎任何产品功能或能力都是如此，无论是开源甚至是专有的。 云提供商构建自己的 CPU 和硬件，交付公司（例如，UPS、Amazon 等）有时会构建自己的车辆。 构建还是购买完全取决于业务及其特定需求。

在正确的地方增加价值

开源许可模式导致了可以组装成软件产品的组件的可用性爆炸式增长。 换句话说，它形成了巨大的软件供应链。 产品经理可以从完全开源的供应链（例如，Red Hat、Chef、SUSE 等）创建产品，或者混合和匹配开源技术和专有技术（例如，像 Sourcefire 或 SugarCRM 这样的开源核心）。 选择完全开源与开源核心方法不应与解决业务问题混淆。 客户只会购买解决他们问题的产品。

企业开源产品是解决问题的方案，就像汽车制造商销售的车辆一样。 开源产品的产品经理确定需求，例如生命周期（年数）、安全性（重要的认证）、性能（重要的工作负载）和生态系统（合作伙伴）。 其中一些需求可以由上游供应商（开源项目）满足； 有些则不能。

开源产品是通过上游供应商的供应链消耗的价值与创建它的公司添加的新价值的组合。 这种新价值与消耗的价值结合在一起通常更有价值，并以溢价出售。 产品团队（包括工程、质量、性能、安全、法律等）有责任在正确的时间在正确的地方增加新价值，以使他们的开源产品值得客户支付的价格，而不是构建必要的基础设施来组装、维护和支持上游组件本身。