开源：开发模式、商业模式还是其他形式？（一）

“开源”一词是在1998年由开放源码组织(OSI)举行的战略会议上提出的。OSI维护着开源定义(OSD)，它对任何声称是开源软件的发行条款做出了规定。OSI还制定了一个符合这些准则的官方开放源代码许可列表。

OSD给出了开源软件的明确定义，但没有提供太多关于开源软件如何影响公司构建和人们需要的产品或服务能力的见解。换句话说，关于在开源基础上建立企业的最佳方式，仍然存在巨大的争议。

在这个由多个部分组成的系列的第一篇中，我将为理解什么是产品，产品经理做什么，以及如何将开源视为一个供应链奠定基础。在以后的文章中，我将深入探讨这些主题，但我将从剖析一些常见的、但从根本上说令人困惑的词汇开始。

开发模式还是商业模式?

开源的采用在产品和解决方案中很常见，但这对产品团队真正意味着什么，还没有定论。开源是一种软件开发模式还是一种商业模式?即使在今天，在开源圈子里也有巨大的争论。

认为开源是一种开发模式的人强调协作、编写代码的去中心化性质，以及发布代码的许可。那些认为开源是一种商业模式的人讨论了通过支持、服务、软件即服务、付费功能，甚至是廉价的营销或广告来实现货币化。

虽然双方肯定都有合理的论点，但这些模式都没有让所有人满意。也许是因为在软件产品及其实际构建的历史背景下，我们从未充分考虑过开源。

与其把开源看作是一种开发模式或一种商业模式，也许公司应该从供应链的角度来考虑，从中来购买技术。

供应链包括创建任何产品或服务所需的组织、人员、活动、信息和资源。这包括像羊毛大衣一样简单的产品，或者像一个有成千上万个依赖关系的开源软件项目一样复杂的产品。经济学之父Adam Smith在《国富论》中，描述了一件羊毛大衣的供应链：

“牧羊人、羊毛的分拣者、羊毛加工者或梳理者、染色者、涂鸦者、纺纱者、织布者、填充者、穿衣者，以及其他许多人，都必须加入他们不同的技艺流程中，以完成这种普通的生产。”

我们大多数人可能没有听说过一件羊毛大衣的供应链所涉及的角色，但有一点是显而易见的：劳动分工和协作是健康供应链的关键，特别是在开源方面。

产品还是项目?

如果你接受开源是一个构建解决方案的供应链，这就导致了围绕项目和产品的另一个误解。红帽公司的首席执行官Paul Cormier对开源项目和开源产品进行了务实的区分。

虽然我同意Paul的观点，但我不得不承认，世界上大多数人并没有认识到这种明显的区别。在与客户、合作伙伴、用户、分析师、记者，甚至我自己的家人的谈话中，大多数人都在交替使用项目和产品这两个词。

我将试图通过提出一个简单的定义来澄清：产品是人们用货币购买的东西，而项目是人们参与、贡献或使用的东西。这就为更好的定义提供了部分途径，但要真正理解，你需要定义什么是产品，以便清楚地看到什么不是项目。

软件产品，像任何其他产品或服务一样，有一系列的活动需要把它们推向市场。它们有商业计划、定价和包装、定位和信息传递、分销策略、销售支持、组合调整、构建/购买/合作伙伴决策和路线图。

管理这些产品的团队进行焦点小组，分析潜在市场，向记者和分析师介绍他们的产品如何融入市场，带领客户了解路线图。最重要的是，根据付费客户的需求来定义这些路线图。产品团队花费了大量的时间和金钱来了解客户的问题，但这很少是社区成员的工作成果。

产品团队对他们在产品中使用哪些供应商有一个基本的选择。这可能意味着在一个产品中使用两个、三个、四个、甚至十个不同的上游项目。也可能意味着当上游项目不再满足购买产品的客户需求时，就会切换到上游项目。

最后，它也可能意味着定位合作伙伴的解决方案或产品组合的不同部分，以填补客户需求的空白。产品团队也可以决定将开源作为供应链的一部分，将专有软件作为另一部分，从而将产品与项目区分开来。他们甚至可以使他们的产品只作为一种服务提供;这就是定价和包装的力量。

几乎所有的产品都是通过向一组由供应商提供的商品组件添加一层差异化的价值而建立的。无论它们是建立在开放源码还是专有组件上。换句话说，上游供应商不能提供与下游产品相同的解决方案。

当上游项目和下游产品处理完全相同的商业问题时，就会出现差异化程度很低的现象。这类似于上游供应商和下游产品公司都在销售轮胎--上游供应商需要销售轮胎，而下游产品公司则需要销售汽车。

供应链组件和下游产品之间缺乏差异化，是开源公司遇到问题的地方。

每天，产品团队都必须在付费客户的驱动下做出定价、包装、构建、购买、合作伙伴和路线图的决策。这就是产品的差异化，也是它与社区驱动的开源项目的根本区别所在。

从开源供应链中购买

“Free”是言论自由的自由，而不是免费啤酒的免费。任何人都可以下载和使用开源软件，但只要你出售使用开源的产品，你就必须对客户负责。这种责任包括检查软件是否打过补丁，是否安全，是否运行良好。一个产品团队对客户有承诺，并对供应链中选择的每个部分负责。

换句话说，在开源软件上构建一个产品并不是免费的。它需要花费时间或金钱。因此，用 "购买 "这个词来描述产品团队和为这些产品提供技术的上游开源项目之间的关系，是正确的。

从产品团队的角度来看，每个上游项目都可以被认为是一个供应商。产品团队可以通过贡献工程师、文档编写者、测试人员等的时间和精力来向开源供应商“购买”。由于时间就是金钱，花在上游工作上的每一个小时都可以用美元来衡量。

无论你的企业是销售基于开源的产品，还是构建供内部使用的解决方案，都存在从开放源码供应链消费的成本。在开源基础上构建任何东西，都隐含着对所选择和使用的组件的责任。但是，与传统供应链不同的是，1美元可能不是1美元。

在开源供应链上投资的每1美元可能会换回2美元、3美元，甚至10美元的价值回报。投资回报可能更高，因为其他人和公司也在贡献价值，以及多样化的想法。从开源供应链上消费的每个人都继承了总价值。如果社区是健康的，那么所获得的价值就会远远超过所做的贡献。

从开源供应商那里采购还有一个隐藏的好处。与传统供应商不同的是，社区驱动的开源项目不是利润驱动的实体，没有销售、营销和进入市场的成本。这类似于从非盈利实体购买，但再次强调，它不是“像免费啤酒一样的免费”。从开源供应链采购，并向你的客户提供产品，肯定是有成本的。

一个更好的产品比喻

也许从来没有人认为开源是以产品为中心的，因为它是与互联网和网络公司的繁荣一起成长起来的。这是一个在没有太多商业计划的情况下，就把资金扔给想法的时代。试图应用传统的业务理解，导致了对开源与开放核心的定义，以及产品团队的角色和责任的争论。

众所周知，软件行业，尤其是开源行业，在产品管理和上游工程的配合上一直感到困惑。项目和产品之间的模糊界限甚至导致了对上游项目应具备的功能上的误解。

作为推动世界上最大的开源产品Red Hat Enterprise Linux路线图的产品团队的一员，我想谦虚地提出一个新的范式来思考开源软件:开源是一种供应链模式。

这不是一个巨大的智力飞跃，但这对思考利用开源产品的讨论、辩论和认知负荷有深远影响。

利用开源获取价值

近年来，有人提出了这样的论点，断言永远只能有一个红帽公司。这种说法意味着只有一家公司可以通过销售支持而发展成为数十亿美元的企业。这种说法是有问题的，因为红帽并不靠支持赚钱，甚至可以说，红帽网络是开源的第一个SaaS。

其次，其他公司，如SUSE、Cloudera和Chef，已经获得了相当大的价值。最后，许多企业从SaaS模式开始，延伸到邻近的企业内部业务，如CloudBees。

所有这些企业都能够成功地将开源作为供应链来创造价值，同时通过满足上游项目无法单独解决的复杂业务问题来获取价值。从根本上说，SaaS和硬件/软件的组合没有什么不同，尽管可以说它们更容易实现货币化。

各位产品经理，我建议你们开始考虑将开源项目作为你们产品的供应链。它将使你在做出产品驱动的决策时有新的明确性，并关注业务需求而不是技术。在所有的供应链中，产品经理必须公平地对待他们的供应商。

例如，下游的产品团队不能告诉上游的供应商该怎么做。下游产品团队还必须向供应商支付足够的费用，以保持他们的业务并继续提供技术。这只是两个例子，说明把上游的开源项目当作供应商来对待，可以使双方的关系更加健康。

音乐界有一句话：关键不在于你演奏的音符，而在于你不演奏的音符。约束力孕育着创造力。如果你知道你不能根据上游供应商的代码来区分你的产品，你的产品团队就必须要有创造力。你必须找出其他值得购买的价值。我将在本系列文章的后面挖掘这个问题;在下一篇文章中，我将对什么是开源产品以及如何用它创造价值的范围进行补充说明。（雪薇）