转载

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

大多数人在启动一个开源软件项目的时候，是不会坐下来等待和人们一起来讨论品牌架构模式的，但是他们中的绝大多数针对项目都有长远的目标，其中包括如何逐步地推出收费的产品或者是公司要基于项目的代码来提供服务和支持。

所以，尽早地考虑品牌策略是没有什么坏处的，但是随着项目的成长过一段时间考虑也是可以的。我希望你已经读过了我的上一篇文章: 如何为你的开源项目选择一个具有品牌效应的名称。这是你的项目迈向成功的第一步！

另外一个非常重要的步骤是理解常见的品牌架构模式，即开源的组织如何考虑项目、产品和公司的品牌，以及这些不同的模式都有哪些优点和缺点。就我们在 New Kind 所做的工作而言，多年以来我们为很多个开源的公司提过意见，依据我们的经验对于每个项目而言没有完美的品牌模式。

我们可以看到每种模式都有优点也有缺点，理解它们的优点和缺点才是作出最好的决定的关键，那种模式才是最为适合你的企业。

一旦你开始思考关于项目、产品、以及公司品牌之间的未来的关系的话，首先应该问问自己下面几个问题：

应该保持项目、产品、公司是一样的品牌吗？还是尝试创建和保护多个品牌？有很好的理由来考虑几个不同的策略的。
你打算你的项目有多独立？通常一个开源项目，若是由企业进行严格的控制，那就很难吸引到社区的志愿者。社区志愿者通常不怎么乐意去为背后有公司的开源项目做贡献。如果公司和其产品的品牌是一致的，该公司若选择项目的品牌和现有的品牌一致的话还是有很大风险的。
你要对于项目有多大的控制力？如果你在大型项目社区待过的话，知道很多的项目成员来自不同的组织且对不同的项目感兴趣。你会发现在公司、项目和产品品牌之间的密切协调并不能使他们有长远的工作动力。

以下是我所见过的三种最为常见的品牌架构场景，可以回答上述的问题，以及我从品牌的视角来看它们各自的优缺点。

我在上面所指出的，从品牌的角度讲只是讲了拼图中的一小部分而已。所以我邀请大家有任何的想法都可以追加到后面的评论，不过请务必谨记所描述的每个场景。另外值得注意的就是，我已经对此三个品牌架构的选项做了很大的简化。在实际的环境中，每种情形都会有不同的角度来看待，还有我尽可能集中在一篇文章中来覆盖尽可能多的场景。

场景一：项目、产品、以及公司使用相同的品牌

在此场景中，开源项目和商业的产品以及公司使用的是单一的品牌。在大多数情况下，他们会将一个付费的产品从免费的项目中分离出来，并会注明做了何种改进。也有对公司品牌和开源项目品牌稍作修改，但是无论哪种情况，核心的品牌对于这三者来说都是处于中心位置的。

案例

公司名称：NGINX

产品名称： NGINX plus

项目名称： NGINX

公司名称： Puppet

产品名称： Puppet 企业版

项目名称：开源 Puppet

此种方式的优点

由免费的积极的正面特质向付费产品和公司转变：如果开源的项目开发有了很好的声誉，可以声称它已经稳定、可靠，这时就可以进一步的考虑，让产品和公司都来沾项目品牌的光，有些使用免费项目的用户可能这时会考虑其产品和公司，因为他们对此熟悉而且信任项目的品牌。
简单而且熟悉：人们很容器获得此种方法，因为它相对较常见。而且它也毋需太多的解释，“品牌 Foo是一家公司，是品牌 Foo 项目背后所支撑的公司，我们拥有的产品名称为品牌 Foo 专业版，是免费项目的高级付费版。” 收到，明白！

此种方式的缺点

不同的缺乏导致吸引付费用户的困难重重：这确实是一个大问题，若是不考虑免费的项目和付费的产品之间的特性和功能的不同的话，仅仅考虑品牌，人们为什么要花钱买一个可以免费获得的同样的品牌？有时候一致的项目和产品有必要深入的挖掘特性，从而可以强调彼此的不同。从项目中区分出不同的产品的重任，若以不同的品牌来解决的话当然是再好不过的了。
越往后越难以改变策略：假如你开始了三品牌一致的道路，如果你顺利的通过了上述的考验，使哪些令人难以信服的人们成为了你的付费客户。你会发现你在公司和产品的品牌投入了很多，乃至社区的品牌也投资了很多，这时没有人愿意放弃它。抛弃有问题的品牌，再加上创建一个新的品牌或多个品牌，是件非常痛苦的事情。以我个人的经历为例，当年红帽从红帽 Linux 分离出红帽企业版 Linux（产品）和 Fedora （项目）就是铁证。在红帽的例子中，从其这么多年的运作中，无论是红帽企业版 Linux 还是 Fedora 项目，均是巨大的品牌资产。现在返回来看，当年的决定无比的英明，但是这在头一、两年非常的令人不安，无论是公司、和它的客户，还是社区均经历了分裂的痛苦。

场景二：产品和公司使用同样的品牌，但项目使用不同的名称

案例

在此场景中，公司的品牌和产品的名牌是一致的，项目是采用了不一样的品牌名。在一些例子中，公司／产品的品牌可能会以某种方式作出一些微妙的（也有不那么微妙的）联系，视觉上来通过 logo，或者是通过名称本身。

公司名称：Hortonworks

产品名称：Hortonworks Data Platform

项目名称： Hadoop

公司名称：Datastax

产品名称： Datastax Enterprise

项目名称： Cassandra

此种方式的优点

公司可以把控自己的未来：在很多情况下，组织都会在最终倾向于此种结果，因为他们既不想无法控制－或者是不想过分的绑定到一个开源的项目中。作出这样的决策有可能是因为转向需要不同的技术往下走，又或者是他们想保持开放想抛出更多的开源技术。通过不把自己定在单一的开源品牌下，是让未来有更多的选择。
很容易的找到不同点来让用户付费：在开源的世界里，哪些潜在的客户的想法通常都是（无论他们是否自觉的意识到）：“为什么我要花钱去购买一个我本可以免费得到的东西？”。不同的名称在什么是可以免费得到和什么是需要付费方能获得之间创建了立竿见影的效果。
产品和项目可以有不同的品牌特征：或许你打算将开源的项目推到使用前沿技术的境地，一致将其推到极限。但是你又会让客户所购买的付费产品是他们可以信任的稳定的、可扩展的解决方案。两个品牌的名称赋予你将一组特性关联到一个品牌，将另外不同的一组特性关联到另外一个品牌的能力。再举红帽的例子，其红帽企业版 Linux （稳定、可靠、安全）而 Fedora 项目（最新的技术，创新），这就是最鲜明的最好的实例。当产品和项目使用同一个品牌名称时候很难做到如此显著的不同。

此种方式的缺点

管理更加的昂贵：更多的品牌等同于更多的品牌曝光，若是只有很少的预算以及没有足够的市场资源的话，想构建一个品牌就非常的困难了，就不用提两个了。如果你没法去承担开发者社区的重任，这个问题可能会稍轻点，但是，正如我通常给一些公司的建议一样，尽量集中投资到最小化的品牌上，因为每个额外的品牌也就意味着分裂品牌资产且会缩小经济体的规模。
难以构建项目和产品之间的联系：产品／项目的分离就是一把双刃剑，好的一面就是拥有两个不同的品牌会让你为付费产品创建独特的价值主张，它可能很难让人们会意识到产品是构建在相同技术的项目之上的。当年我们构建红帽品牌的时候，如果我们无法利用其人们和红帽 Linux 的关系的话，我们会异常困难的找到付费用户。会发生“如果你喜欢免费的红帽 Linux 版本，你应该去尝试一下你所信任的完全支持的版本。”这样的事情。

场景三：项目和产品使用相同的品牌，公司则使用另外的品牌

在此场景中，公司的品牌既和产品品牌不同也和项目品牌不一样。

案例

** 公司名称 ** ：Canonical

** 产品名称 ** ： Ubuntu Advantage

** 项目名称 ** ： Ubuntu

** 公司名称 ** ：Continuum Analytics

** 产品名称 ** ： Anaconda Pro

** 项目名称 ** ： Anaconda

此种方式的优点

项目和产品品牌之间的紧密联系更容易的去考量产品：如果某人已经使用了免费的项目了，而且想进一步的指望更多的特性和获得更多的支持，他会找寻相同品牌的付费产品，同样，这也是一把双刃剑，因为如果人们已经获得了免费的版本，若要吊起他们对付费版本的购买欲望，付费版本的优点要非常的明确，能够让人们有强烈的愿望去升级。
分离的公司品牌远离了产品和项目：这里有几个原因说明为什么一家公司要和产品的品牌保持距离。首先，公司打算投资多个产品／项目，且不想将整个品牌仅仅和一个产品关联起来，如果是那样的话，可能会限制发展。第二，它限制了未经公司同意的项目方向上的风险，公司可以随时将项目砍掉，切换到新的产品／项目品牌的方向，还不需要进入更改公司名称／品牌昂贵的流程。

此种方式的缺点

管理多个品牌的昂贵代价：此策略通常会强制公司作出决定，那就是在那个品牌投入更多的钱：是产品／项目品牌还是公司品牌？对于一家成长性的公司在市场上全力支持和促进两个不同的品牌是一件异常困难的事情。
将项目和公司联系起来异常的困难：对于很多人来说不够清晰，因为在公司和项目之间缺乏一个强关联的纽带。Canonical 在这方面就是一个非常好的例子，绝大多数来自开源界的人们都听过 Ubuntu，但是只有很少一部分人听说过 Ubuntu 背后有个公司叫做 Canonical，所以 Canonical 做了一个慎重的决定，投资项目和产品的品牌，而不是公司的品牌，公司使用此策略的后果就是类似下面这样的对话的结局：

员工：“我在甲公司工作”

路人：“谁呀？”

员工：“我们就是做了非常酷炫的开源项目Foo的背后的公司。”

路人：“哦，我非常喜欢酷炫的开源项目Foo，从来没有听说过背后还有个公司了。”

员工：（无语、尴尬、欲哭无泪）

可以大量推广的结论

社区和公司的关系愈紧密，越是对保持一致的公司、产品和项目有利。这里的关键在于从项目向公司转换时的品牌考量。
开源公司最大的弱项就是很难说服让哪些可以免费获得的产品的人们掏腰包，这就对于付费的产品的价值主张要明确而有力！
对于社区和公司关系较松散而言，就需要考虑多品牌的解决方案的意义。这让公司可以保持自己的选择权，但是需要更多的精力去解释以及花销更多的品牌费用。
我曾经见过一个小公司拥有三个不同的品牌，项目、产品、和公司各占一个，我以为这是在自杀，一家收入没有达到一亿美元的公司想支撑三个品牌简直是异想天开。我奉劝他们不要做，他们后来对我感激不尽。

正如我原先所强调的一样，这些基本的品牌架构策略仅仅只是冰山的一角，但是还是希望本系列文章的解释能够带给读者在考虑接下来要走的路上澄清了一些疑惑，并开始思考自己日益增长的开源项目的品牌架构的未来。

关于作者

如何为你的开源项目选择正确的品牌架构 Chris Grams 是 New Kind 的总裁及合伙人，也是毋需广告的品牌建设：成功在数字世界建设品牌的秘密》一书的作者。他的联系方式有：

Twitter帐号、领英主页、电子邮箱：chris(at)newkind.com

本文由作者 Chris Grams 发表在Opensource.com上： How to Choose the right brand architecture for your open source project 。经授权，在InfoQ中文站翻译共享。本文在 Creative Commons BY-SA 4.0 许可证下发布。

感谢张龙对本文的审校。

给InfoQ中文站投稿或者参与内容翻译工作，请邮件至editors@cn.infoq.com。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号： InfoQChina ）关注我们。

原文 http://www.infoq.com/cn/articles/the-right-brand-architecture-for-open-source-project

正文到此结束