开源产品团队做什么？

如果你去参加任何热门的产品管理会议，你都会听到关于产品团队的信息。至少，一个产品团队有一个产品经理，但它通常包括营销、技术架构甚至用户体验 (UX) 方面的角色。本系列之前的文章已经介绍了开源作为一种供应链模型和在开源软件供应链中定义产品，而本文特别关注产品团队中产品管理的角色。

产品团队有哪些人？

产品经理和产品营销经理是最常见的两种产品管理角色，但产品管理可以进一步细分为许多角色，包括竞争分析、业务战略、销售支持、收入增长、内容创建、销售工具等等。对于非常大的产品，甚至产品管理角色也可以被分解为单独的角色。你甚至可能会听到诸如技术营销经理、产品传播者和业务所有者之类的头衔，更不用说个人贡献者团队的人员管理角色。为本文的目的，我将所有这些角色统称为“产品管理”。

产品管理是一项艰难的职业，并且有很多框架可以学习和理解它。其中最古老和最成熟的框架之一是 Pragmatic Framework，它定义了 37 个不同的责任领域。 Pragmatic Framework 对于本文来说有点过于复杂。相反，我将强调适用于开源产品的任务子集

• 市场问题：与客户交谈并弄清楚他们需要什么
• 产品路线图：确定哪些功能将被添加到产品以及何时添加
• 构建：投资于内部构建技术
• 购买：从另一家公司购买技术
• 合作：通过利用合作伙伴的技术向客户交付解决方案
• 定价：确定价格
• 打包：确定价格中包含的内容
• 渠道培训：培训销售人员，以便他们可以教育潜在客户

本系列的其余部分将探讨这些不同的角色如何影响开源供应链以及如何受到开源供应链的影响。

构建、购买或合作？

业务需求还是技术更重要？ 这可能是商业战略的经典悖论。 答案都不是。 执行力才是最重要的。 产品管理团队的任务是创造和留住客户。 这可以通过构建技术、购买技术或合作来获取技术或服务来实现，这些技术或服务在结合时可以为客户提供价值。 例如，如果客户需要软件产品中缺少的一项加密功能，则产品经理可以

• 要求工程团队构建、测试、记录和维护它。
• 影响执行团队购买提供该功能的公司或软件包。（但是，只有不到 2% 的产品经理有权访问损益数据，更不用说购买公司的预算了。）
• 通过经过验证的合作伙伴将其交付给客户。 如果合作伙伴已经提供解决方案，这是交付解决方案的最快方法，但它可能会提高产品的价格或要求客户购买额外的软件。

对于传统的专有软件产品和服务，这可能意味着构建、购买或合作以获得基础软件，例如数据库。 对于基于开源软件构建的产品，这可以被认为是选择一个开源项目作为供应商。 通过贡献工程时间、代码、文档、测试、基础设施等来进行购买。 因为开源不是免费的，必须有人编写、测试、记录等。 如果你不向上游贡献，就很难为客户提供价值。

这种构建、购买和合作伙伴交付功能的组合区分了产品，无论是开源还是专有。 专有许可并不能区分产品。 让我再说一遍：专有许可并不能区分产品。 人们将专有许可与为客户提供价值混淆。 专有许可证是一种完全有效且有用的货币化用户的方式，但它们并不能为客户提供更多价值。 许可证不会创造价值； 它们有助于提取价值。 如果你认为开放核心或混合许可是在开源中赚钱的唯一方式，请将这一段读五遍直到它深入人心（提示，专注于创造价值）。

开源产品和专有产品都必须创造价值。 客户购买功能作为解决方案的一部分（即，他们以前无法做的新事物）。 如果产品管理花费更多的精力来交付功能，而不是确定哪些可以通过专有许可保留，那么客户会更快乐、更忠诚，并获得更多的价值。

基于开源构建的产品类型

大多数现代软件产品都是通过为开源供应链提供的价值增加新价值来交付的。 这可能包括额外的下游测试、文档、质量工程、性能测试、安全测试、行业认证、合作伙伴生态系统、培训、专业服务，甚至是不包含在上游的额外专有代码（开放核心）。 通过考虑这种新模式，可以澄清许多关于开源的旧辩论

• 开源产品：进入产品的整个代码供应链都是开源的。 这可以包括多个上游项目，例如企业 Linux 发行版或复杂的产品，例如 Red Hat Satellite 或 OpenShift。
• 开放核心产品：进入产品的部分代码供应链是开源的，而其他部分是专有的。 这种许可混合可用于控制定价、打包和分发。 它也可能具有使对产品的工程贡献与开源供应链发生冲突的缺点（请参阅 再见，开放核心——对糟糕的垃圾说再见）。
• 付费软件即服务产品：SaaS 产品的供应链可以由开源语言和库组成，而内部构建的业务逻辑通常是专有的。 这允许产品经理通过非常可衡量的分发渠道来严格控制定价和打包。 有许多在线公司使用这种模式的例子，包括客户资源管理平台、数据库、缓存层、身份管理、文档管理以及办公和电子邮件解决方案。
• 免费 SaaS 产品：免费 SaaS 产品的供应链（例如，Facebook、Google Search、YouTube 等）本质上与付费 SaaS 产品相同。 产品不是通过严格控制定价和打包来实现盈利，而是通过用户数据或广告来实现盈利。
• 云提供商与软件供应商：通过将开源视为供应链和 SaaS 视为定价和打包模型，可以更好地理解最近对新的准开源许可证的兴趣和创建，例如 服务器端公共许可证、Redis 源代码可用许可证或 PolyForm。 这些新许可证对来自开源供应链的买家如何为其产品定价和打包施加了一些控制（例如，限制大型云提供商如何交付基于免费可用代码和二进制文件构建的服务）。 这并非闻所未闻，即使在传统的制造供应链中也是如此。 这是一种防御策略，因为这些许可证不会为客户提供新的价值。
• 开源即认知： 在这种模式下，围绕上游项目的热度被用来提高基于该项目构建的产品的认知度。在营销中，对技术的认知是让产品客户在其基础上进行构建的关键第一步。例如，如果用户了解并信任 Kubernetes，那么他们就是基于 Kubernetes 构建的产品的潜在客户；当寻找 Kubernetes 解决方案的人们听说您的产品是基于 Kubernetes 构建的，他们会立即成为潜在客户。在某种程度上，这类似于联想笔记本电脑宣传“Intel inside”或Arm & Hammer 洗衣液宣传 OxiClean 作为其供应链的一部分。如果您喜欢 OxiClean，您会喜欢 Arm & Hammer 洗衣液。
• 开放核心即营销： 这种模式比开源即认知更进一步。几乎总是由一个单一的供应商控制进入开放核心产品的上游开源项目。他们试图利用供应链，但往往不成功，来产生市场认知度，这被认为是免费或廉价的营销和潜在客户生成方式。开放核心产品宣传它们包含开源项目，以提供核心价值主张。回到 Arm & Hammer 的例子：如果您喜欢开源，您会喜欢我们包含开源优点的专有软件。

供应链

延续我上一篇文章中的类比，当通用汽车开发汽车时，产品团队不会告诉博世他们想要什么样的燃油喷射器。他们会告诉博世新车的功率是多少，需要有多少牵引力等等。他们给博世一套技术要求。然后，博世向通用汽车提供燃油喷射解决方案，该解决方案不仅包括燃油喷射器，还包括线束，甚至可能包括使其运行的软件。对于几乎每辆车都在使用的组件，依靠供应链通常更便宜且质量更好。

就像汽车一样，软件产品的总和大于各个部分。当制造商交付汽车时，它不仅仅是制动、转向、动力系统、信息娱乐系统、融资和机械维修计划。它还具有相关的品牌、建造质量、可靠性和体验。大多数部件在供应商之间没有差异。软件产品，尤其是建立在开源供应链之上的产品，也没有什么不同。产品管理需要将他们的产品与供应链中的底层软件组件区分开来。软件产品的价值是在依赖项供应链之上构建的差异化层。这种价值是产品管理必须关注的。

差异化价值

产品管理不是关于挑选和选择在上游或下游修复哪些错误。它不是关于在开源项目中保留足够的价值，以便用户购买该产品。它不是关于提出特殊许可来货币化开源项目的用户群。它是关于创造客户愿意为此付费的差异化价值。它是关于倾听他们的需求，理解他们，并深入了解他们。它是关于影响供应链、切换供应链以及建立一个赋予你的产品引力的合作伙伴生态系统。

那些考虑在开源供应链之上建立差异化价值的产品经理可以轻松回答以下问题

• 作为一名开源产品经理，我应该参加上游项目的会议吗？当然，因为它就像参加你的供应商的贸易展览会。
• 产品管理应该如何处理上游项目无法满足客户需求的情况？增加更多投资。如果开源社区是健康的，它会产生你所需要的。
• 当上游社区在贡献方面遇到困难或不健康时，产品管理应该怎么做？就像制造商在供应商因为失败而失去与他们最大的两个竞争对手的合同后会做的那样：更换供应商。

在下一篇文章中，我将深入研究在产品中创造的独特价值，重点关注上游项目无法提供的价值。如果产品管理做得好，上游供应商和下游产品之间就不会存在不自然的紧张关系。如果做得正确，上游项目和下游产品都会创造独特且差异化的价值，从而满足用户和客户的需求。