如何为你的开源项目选择正确的品牌架构

大多数启动开源软件项目的人并没有坐等别人与他们讨论品牌架构模型，但他们中的许多人确实对他们的项目有长期目标，包括最终看到它成为付费产品，甚至成为围绕服务和支持项目代码而建立的公司的基础。

因此，尽早开始思考你未来可能想要应用的品牌战略绝不会有害，那时你的“孩子”已经长大。希望你已经选择了你可以保护的项目名称。这是为你的项目未来的成功奠定基础的第一步。

另一个重要的步骤是了解开源组织为项目、产品和公司品牌考虑的常见品牌架构模型，以及不同方法的优点和缺点。在我们 New Kind 的工作中，我们多年来为许多开源公司提供咨询，并且可以根据经验告诉你，没有适用于每个项目的完美品牌模型。

我们见过的每个模型都有优点和缺点，了解这些优点和缺点是就哪种模型最适合你的情况做出明智决策的关键。

当你开始思考项目、产品和公司品牌之间未来的关系时，以下是一些最重要的考虑问题：

1. 你应该为项目、产品和公司使用相同的品牌吗？还是应该尝试创建和保护多个品牌？有充分的理由考虑几种不同的方法。
2. 你希望项目有多大的独立性？通常，一个由企业利益严格控制的开源项目更难吸引志愿者社区。社区志愿者通常可能希望项目具有一定程度的自主权，而公司母公司不愿意授予这种自主权。如果公司和产品品牌与产品品牌相同，那么如果社区的决策将项目带向不利于公司利益的方向，公司也将面临风险。
3. 你将对项目有多少控制权？如果你只是一个大型项目社区中的一个利益相关者，其中可能包括在具有不同利益的不同组织工作的社区成员，你可能会发现公司、产品和项目品牌之间的紧密结合在长期内行不通。

以下是我见过的解决这些问题以及更多问题的三种最常见的品牌架构方案，以及我对每种方法从品牌角度来看的优缺点的解读。

我想预先指出，品牌视角只是这里难题的一部分，我邀请大家在下面的评论中权衡并提出在每种情况下都应牢记的其他考虑因素。另请注意，我在这里将事情大大简化为三个基本的品牌架构选项。在现实世界中，每种情况都是略有不同的雪花，并且可能的情况比我可以在一篇博文中涵盖的要多得多。

方案 1：项目、产品和公司使用相同的品牌

在这种方案中，开源项目与商业产品和公司共享一个品牌。在许多情况下，产品可能具有描述性修饰符，以将付费产品与免费社区项目区分开来。公司品牌或开源项目品牌也可能有一个修饰符，但位于中心的核心品牌在所有三者中保持不变。

示例

公司名称： NGINX
产品示例名称： NGINX Plus
项目名称： NGINX

公司名称： Puppet Labs
产品示例名称： Puppet Enterprise
项目名称： 开源 Puppet

此方法的优点

• 利用品牌规模经济： 建立品牌是昂贵的。因此，对于一家刚起步的小公司来说，尝试拥有一个品牌而不是两个甚至三个品牌是很有意义的，因为你投资的每个新品牌都需要花钱来建立和支持。
• 将免费项目的积极品牌特征转移到付费产品和公司： 如果开源项目建立了良好的声誉，例如稳定、可靠和具有前瞻性，并且产品和公司也都共享这个品牌名称，那么已经使用免费项目品牌的人可能更愿意考虑产品和公司，因为他们已经熟悉并信任项目品牌。
• 简单且熟悉： 人们理解这种方法，它相对常见，并且不需要太多解释。“BRANDFOO 是 BRANDFOO 项目背后的公司。我们有一个名为 BRANDFOO Pro 的产品，它是免费项目的优质付费版本。” 明白了。

此方法的缺点

• 缺乏差异化使得人们更难从免费产品转向付费产品： 这是最大的问题。在不考虑免费项目和付费产品之间的功能或特性的差异的情况下，仅考虑品牌，人们为什么要为他们可以免费获得的相同品牌付费？有时，为项目和产品使用相同的品牌使得有必要深入研究功能，以便沟通差异化。当你可以依靠不同的品牌来开始区分产品与项目的繁重工作时，情况会更好。
• 以后可能难以更改策略： 如果在未来，你遇到上述问题，即你难以说服人们成为付费产品的客户，你可能会发现你已经从公司和产品的角度在这个品牌上投入了太多，并且社区也对同一个品牌投入了太多，以至于没有人愿意放弃它。像 Red Hat 在将 Red Hat Linux 品牌拆分为 Red Hat Enterprise Linux（产品）和 Fedora（项目）时所做的那样，“撕掉创可贴”并创建一个或多个新品牌的过程可能是痛苦的。在 Red Hat 的案例中，从长远来看，它运作良好，因为现在付费的 Red Hat Enterprise Linux 产品和 Fedora 项目品牌都拥有巨大的品牌资产。回顾过去，这显然是正确的决定，但对于公司及其客户和社区来说，在转型的前一两年肯定很痛苦。

方案 2：产品和公司使用相同的品牌，项目使用不同的品牌

在这种方案中，项目品牌是不同的，但公司品牌和产品品牌是相同的。在某些情况下，公司/产品品牌可能会以某种方式引用项目品牌，以进行微妙（或不那么微妙）的关联，视觉上使用徽标，或通过名称本身。

示例

公司名称： HortonWorks
产品示例名称： HortonWorks Data Platform
项目名称： Hadoop

公司名称： Datastax
产品示例名称： Datastax Enterprise
项目名称： Cassandra

此方法的优点

• 公司掌控自己的命运： 在许多情况下，组织最终会选择这条道路，因为他们要么不控制，要么不想与一个开源项目过于紧密地联系在一起。这也可能是因为他们希望对未来转向使用不同的技术持开放态度，或者他们可能希望对探索其他开源技术保持开放态度。通过不将自己与单一开源品牌联系起来，他们为未来保持了选择的余地。
• 更容易区分付费品牌： 在开源世界中，潜在客户脑海中潜在的问题——无论他们是否意识到——通常是“我为什么要为我可以免费获得的东西付费？” 不同的名称会在他们免费获得的东西和他们需要付费的东西之间立即产生差异化。
• 产品和项目可以具有差异化的品牌特征： 也许你希望开源项目以尖端技术而闻名，始终突破极限。但你希望购买付费产品的客户知道他们拥有可以信任的稳定、可扩展的解决方案。两个品牌名称使你能够将一组特征与一个品牌相关联，并将另一组特征与另一个品牌相关联。同样，Red Hat Enterprise Linux（值得信赖、可靠、稳定）和 Fedora 项目（最新技术、创新）是这种差异化的良好示例。当产品和项目共享相同的品牌名称时，这种差异化就很难明确。

此方法的缺点

• 管理成本更高： 品牌越多，品牌推广费用就越高。在预算较小且营销资源不多的情况下，围绕一个品牌建立资产已经很困难，更不用说两个品牌了。如果你没有进行构建开发者社区的繁重工作，这可能不是什么大问题。但我总是建议公司投资尽可能少的品牌数量，因为每个额外的品牌都意味着品牌资产的分散和规模经济的减少。
• 更难在项目和产品之间建立关联： 产品/项目关联是一把双刃剑。虽然好消息是拥有两个不同的品牌可以让你为付费产品创建独特的价值主张，但这也可能使人们更难意识到该产品基于与项目相同的技术。当我们最初建立 Red Hat 品牌时，如果我们无法利用人们对 Red Hat Linux 的积极联想，我们将很难为我们的付费产品获得大量受众。“如果你喜欢免费版本的 Red Hat Linux，你应该试试我们你可以信任的完全支持的版本。” 诸如此类。

方案 3：项目和产品使用相同的品牌，公司使用不同的品牌

在这种方案中，公司拥有一个与产品和项目都不同的品牌。

示例

公司名称： Canonical
产品示例名称： Ubuntu Advantage
项目名称： Ubuntu

公司名称： Continuum Analytics
产品示例名称： Anaconda Pro
项目名称： Anaconda

此方法的优点

• 项目和产品品牌之间的紧密联系有助于引导人们考虑产品： 如果有人已经在使用免费项目，并且他们正在寻找额外的功能或支持，他们会首先寻找同一品牌的付费版本。同样，这是一把双刃剑，因为如果他们已经免费获得了该品牌，那么付费版本的优势将需要非常清晰且令人向往，人们才愿意升级。
• 公司名称的分离创造了与产品和项目的距离： 公司可能希望与产品品牌保持一定距离有几个原因。首先，公司可能正在考虑投资多个产品/项目，并且不希望其整个品牌与一个产品相关联，这可能会在未来受到限制。其次，它可以限制在项目朝着公司不同意的方向发展时的风险。公司始终可以切断与项目的联系，转向具有新产品/项目的另一个方向，而无需经历昂贵的公司更名/品牌重塑过程。

此方法的缺点

• 支持多个品牌成本高昂： 通常，这种策略迫使公司在他们将投入最多的品牌之间做出选择：项目/产品品牌还是公司品牌。对于一家成长中的公司来说，在市场上充分支持和推广两个不同的品牌是困难的。

• 更难将公司与项目联系起来： 由于缺乏强大的品牌关联，人们可能不清楚公司与项目相关联。Canonical 就是一个很好的例子。开源世界中的大多数人都听说过 Ubuntu。但是，很少有人知道 Ubuntu 背后的公司名为 Canonical。因此，Canonical 做出了有意识的决定，将投资投入到产品和项目品牌而不是公司品牌。使用这种品牌策略的公司将熟悉以下对话：

  员工： “我在 CompanyCo 工作。”
  路人： “谁？”
  员工： “我们是制作 CoolOpenSourceProjectFoo 的公司。”
  路人： “哦，哇！我喜欢 CoolOpenSourceProjectFoo。从不知道背后还有一家公司！”
  员工： （沉默地嘟囔。）

对一些结论进行广泛概括：

• 社区和公司之间的关系越紧密，为公司、产品和项目保留一个品牌就越有利。品牌考虑从项目到产品的转移是这里的关键。
• 这种方法最大的缺点可能是很难说服人们为他们可以免费获得的品牌付费。付费产品的价值主张清晰而强大变得更加重要。
• 项目和公司之间的关系越松散，考虑多品牌解决方案就越有意义。这使公司能够保持选择的余地，但也需要更多的解释和更高的品牌建设费用。
• 我还没有见过小型公司为公司、产品和项目分别拥有三个不同品牌是有意义的情况。对于任何收入低于 1 亿美元的公司来说，尝试支持三个独立品牌都是品牌自杀。直接拒绝，以后感谢我。

正如我之前提到的，这些基本的品牌架构策略只是触及了表面。但希望这种解释开始阐明你在展望未来并考虑为你的成长中的开源项目构建未来品牌架构时应该考虑的一些事情。