“开源”一词于 1998 年在 开源促进会 (OSI) 举行的战略会议上创造出来。OSI 维护着 开源定义 (OSD)，该定义对任何声称是开源的软件的分发条款提出了要求。OSI 还维护着一份官方的 开源许可证 列表，这些许可证符合这些指南。
OSD 清晰地定义了什么是开源软件，，但没有深入说明采用开源如何影响公司构建和交付人们想要和需要的产品或服务的能力。换句话说，关于基于开源构建业务的最佳方式仍然存在巨大的争论。
在本系列文章的第一篇中，我将为理解什么是产品、产品经理做什么以及如何将开源视为供应链奠定基础。在未来的文章中，我将更深入地探讨这些主题，但我将首先剖析一些常见但从根本上令人困惑的词汇。
开发模型还是商业模型？
开源采用在产品和解决方案中很常见，但对于这对于产品团队的真正意义，结论尚未明确。开源是软件开发模型还是商业模型？即使在今天，开源圈子中仍然存在激烈的争论。
将开源视为开发模型的人强调协作、代码编写的去中心化性质以及代码发布的许可证。将开源视为商业模型的人讨论通过支持、服务、软件即服务、付费功能甚至在廉价营销或广告的背景下实现盈利。虽然双方肯定都有合理的论点，但这些模型都从未让所有人满意。也许是因为我们从未在软件产品及其实际构建的历史背景下充分考虑开源。
与其将开源视为开发模型或商业模型，公司或许应该从他们可以从中购买技术的供应链的角度来思考。
供应链包括创建任何产品或服务所需的组织、人员、活动、信息和资源。这包括像羊毛外套这样简单的产品，也包括像具有数千个依赖项的开源软件项目这样复杂的产品。在《国富论》中，经济学之父亚当·斯密描述了羊毛外套的供应链
“牧羊人、羊毛分拣员、羊毛梳理工或粗梳工、染色工、梳理工、纺纱工、织布工、缩绒工、整理工，以及许多其他人员，都必须结合他们不同的技艺，才能完成这件朴素的产品。”
（Scott McCarty，CC BY-SA 4.0）
我们大多数人可能没有听说过羊毛外套供应链中涉及的角色，但有一件事是显而易见的：劳动分工和协作是健康供应链的关键，尤其是对于开源而言。
产品还是项目？
如果您接受开源是构建解决方案的供应链，那么这将导致对项目和产品的另一种误解。红帽首席执行官 Paul Cormier 对开源项目和开源产品进行了务实的区分。虽然我同意 Paul 的观点，但我不得不承认，世界上大多数人并不认可这种清晰的区分。在与客户、合作伙伴、用户、贡献者、分析师、记者甚至我自己的家人进行了 20 年的对话中，大多数人都互换使用项目和产品这两个词。
我将尝试通过提出一个简单的定义来阐明：产品是人们用货币购买的东西，而项目是人们参与、贡献或使用的东西。这在一定程度上更好地定义了，但要真正理解，您需要定义什么是产品，才能清楚地看到项目不是什么。
软件产品，就像任何其他产品或服务一样，需要一系列活动才能将其推向市场。它们有商业计划、定价和包装、定位和信息传递、分销策略、销售支持、产品组合调整、构建/购买/合作伙伴决策和路线图。管理这些产品的团队进行焦点小组访谈，分析可寻址市场，向记者和分析师简要介绍他们的产品如何适应市场，引导客户了解路线图，最重要的是，根据付费客户的需求定义这些路线图。产品团队花费大量时间和金钱来了解客户的问题，但这很少是社区成员的工作成果。
产品团队在产品中使用哪些供应商方面有根本的选择。这可能意味着在产品中使用两个、三个、四个甚至 10 个不同的上游项目。这也可能意味着当上游项目不再满足购买产品的客户的需求时，切换上游项目。最后，这也可能意味着定位合作伙伴的解决方案或产品组合的不同部分以填补空白（即，用解决方案满足客户需求）。产品团队还可以决定使用开源作为供应链的一部分，而将专有软件作为另一部分，从而将产品与项目区分开来。他们甚至可以仅以服务的形式提供他们的产品；这就是定价和包装的力量。
几乎所有产品都是通过在由供应商提供的一组商品组件上添加一层差异化价值来构建的。无论它们是基于开源组件还是专有组件构建的，都是如此。换句话说，上游供应商无法提供与下游产品相同的解决方案。当上游项目和下游产品解决完全相同的业务问题时，差异化程度很低，这会带来挑战。这类似于上游供应商和下游产品公司都销售轮胎——上游供应商需要销售轮胎，而下游产品公司需要销售汽车。
供应链组件与下游产品之间缺乏差异化是开源公司遇到问题的地方。
每天，产品团队都必须根据付费客户的需求做出定价、包装、构建、购买、合作伙伴和路线图决策。这就是为产品提供差异化，并使其与社区驱动的开源项目从根本上不同的原因。
从开源供应链购买
开源技术是自由的，如言论自由，而不是“免费如啤酒”。任何人都可以下载和使用开源软件，几乎可以随心所欲地使用，但是一旦您销售使用开源的产品，您就对客户负有责任。该责任包括验证软件始终得到修补、安全且运行良好等。产品团队对客户做出承诺，并对供应链中选择的每个组件负责。
（Scott McCarty，CC BY-SA 4.0）
换句话说，基于开源软件构建产品不是免费的。这需要花费时间和金钱，每个人都知道时间就是金钱，所以这两者本质上是相同的。因此，使用“购买”一词来描述产品团队和为其产品提供技术的上游开源项目之间的关系是完全正确的。
从产品团队的角度来看，每个上游项目都可以被视为供应商。产品团队可以通过贡献工程师、文档编写人员、测试人员等的时间和精力来“购买”上游开源供应商的产品。由于时间就是金钱，因此在上游工作上花费的每小时都可以用美元来衡量。
无论您的组织是销售基于开源的产品，还是为内部消费构建解决方案，从开源供应链消费的成本都存在。基于开源构建任何东西都意味着对所选和使用的组件承担隐含的责任。但是，与传统的供应链不同，一美元可能不是一美元（填写您选择的货币）。
在开源供应链采购中每投资一美元，可能会获得 2 美元、3 美元甚至 10 美元的回报。投资回报率可能会更高，因为其他人和其他公司也在贡献价值，以及多样化的想法。每个从开源供应链消费的人都会继承总价值。如果社区是健康的，那么收到的价值将远远超出所做的贡献。
从开源供应商处购买还有另一个隐藏的好处。与传统供应商不同，社区驱动的开源项目不是以盈利为目的的实体，没有销售、营销和上市成本。这类似于从非营利实体购买，但同样，它不是“免费如啤酒”。从开源供应链采购并反过来向您的客户提供产品肯定存在成本。
产品更好的比喻
也许从来没有人从以产品为中心的角度来看待开源，因为它与互联网和互联网泡沫一起成长。这是一个将资金投入想法而没有太多商业计划的时代。事后尝试应用传统的商业理解导致了关于开源与开放核心的定义以及产品团队的角色和责任的争论。软件行业，尤其是开源，在协调产品管理和上游工程方面一直非常混乱。项目和产品之间模糊的界限甚至导致了对上游项目应该关注哪些功能与下游产品的误解。
作为产品团队的成员，推动着可以说世界上最大的开源产品 Red Hat Enterprise Linux 的路线图，我想谦卑地提出一种新的范式，在这种范式中思考开源软件
开源是一种供应链模型。
这不是一个巨大的智力飞跃，但这对于在思考利用开源的产品时进行的讨论、辩论和认知负荷具有深远的影响。
利用开源捕获价值
近年来，有人提出论点，声称永远只能有一个红帽；这种说法暗示只有一家公司可以通过销售支持发展成为数十亿美元的业务。这种说法是有问题的，因为红帽并没有从支持中赚钱，甚至可以说红帽网络是开源的第一个 SaaS。其次，像 SUSE、Cloudera 和 Chef 这样的其他公司也捕获了相当多的价值。最后，许多企业从 SaaS 模式开始，并扩展到相邻的本地业务，例如CloudBees。
所有这些公司都能够成功地使用开源作为供应链来创造价值，同时通过满足上游项目本身无法解决的复杂业务问题来捕获价值。从根本上说，SaaS 和硬件/软件组合没有什么不同，尽管可以说它们更容易盈利。
各位产品经理，我敦促您开始将开源项目视为您产品的供应链。它将为您在做出产品驱动的决策和关注业务需求而不是技术方面带来新的清晰度。与所有供应链一样，产品经理必须公平对待他们的供应商。例如，下游产品团队不能告诉上游供应商该怎么做。下游产品团队还必须向供应商支付足够的费用，以维持他们的业务并继续供应技术。这些只是将上游开源项目视为供应商所带来的清晰度的两个示例，并且它使关系更加健康。
（Scott McCarty，CC BY-SA 4.0）
音乐界有一句谚语：重要的不是你演奏的音符，而是你不演奏的音符。约束孕育创造力。如果您知道您无法根据上游供应商的代码来区分您的产品，那么您的产品团队必须发挥创造力。您必须确定其他值得购买的价值。我将在本系列的后面部分深入探讨这一点；在下一篇文章中，我将阐明开源产品的范围以及如何使用它创造价值。
1 条评论