如何為你的開源項目選擇正确的品牌架構

大多數人在啟動一個開源軟體項目的時候，是不會坐下來等待和人們一起來讨論品牌架構模式的，但是他們中的絕大多數針對項目都有長遠的目标，其中包括如何逐漸地推出收費的産品或者是公司要基于項目的代碼來提供服務和支援。

是以，盡早地考慮品牌政策是沒有什麼壞處的，但是随着項目的成長過一段時間考慮也是可以的。我希望你已經讀過了我的上一篇文章:如何為你的開源項目選擇一個具有品牌效應的名稱。這是你的項目邁向成功的第一步！

另外一個非常重要的步驟是了解常見的品牌架構模式，即開源的組織如何考慮項目、産品和公司的品牌，以及這些不同的模式都有哪些優點和缺點。就我們在 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，從來沒有聽說過背後還有個公司了。”

員工：（無語、尴尬、欲哭無淚）

可以大量推廣的結論

社群和公司的關系愈緊密，越是對保持一緻的公司、産品和項目有利。這裡的關鍵在于從項目向公司轉換時的品牌考量。

開源公司最大的弱項就是很難說服讓哪些可以免費獲得的産品的人們掏腰包，這就對于付費的産品的價值主張要明确而有力！

對于社群和公司關系較松散而言，就需要考慮多品牌的解決方案的意義。這讓公司可以保持自己的選擇權，但是需要更多的精力去解釋以及花銷更多的品牌費用。

我曾經見過一個小公司擁有三個不同的品牌，項目、産品、和公司各占一個，我以為這是在自殺，一家收入沒有達到一億美元的公司想支撐三個品牌簡直是異想天開。我奉勸他們不要做，他們後來對我感激不盡。

正如我原先所強調的一樣，這些基本的品牌架構政策僅僅隻是冰山的一角，但是還是希望本系列文章的解釋能夠帶給讀者在考慮接下來要走的路上澄清了一些疑惑，并開始思考自己日益增長的開源項目的品牌架構的未來。