為什么RackN要徹底改變它的開放核心許可模式

開源創(chuàng)新中一個比較有趣的領(lǐng)域是公司用來將其商業(yè)化的許可模式。多年來，許多公司都依賴于開放核心模型，其中產(chǎn)品的核心是開放源碼許可的，而附加功能(如高級安全性)則是專有的。在與RackN首席執(zhí)行官Rob Hirschfeld的談話中，他指出了這種模式的一個奇怪之處:很少有人對項目的核心做出貢獻，但是很多人都想在邊緣做出貢獻。

對于Digital Rebar開源項目的主要贊助商RackN來說，這種“啊哈”式的認(rèn)識使他們徹底顛覆了他們的開源核心模型，開源了他們的擴展生態(tài)系統(tǒng)，同時關(guān)閉了他們的核心。它工作嗎?讓我們來看看。

無論開源項目是什么，都很難在代碼的核心部分獲得太多的參與。為什么?因為…時間?；蛘撸_切地說，是缺乏。也就是說，開發(fā)人員需要花很多時間才能跟上特定項目的進度——大多數(shù)人無法承擔(dān)時間承諾，除非他們的貢獻得到了報酬。

參見:如何建立一個成功的開發(fā)人員職業(yè)(免費PDF)(TechRepublic)

在2005年MySQL用戶大會上的一次演講中，當(dāng)時的MySQL CEO(現(xiàn)在的HackerOne CEO) Marten Mickos捕捉到了這一點，隨后我將其打包成我2006年OSCON演講的一部分:

無論是好是壞，這張幻燈片中的想法在我第一次展示它們之后的很多年里仍然是相關(guān)的。現(xiàn)在的情況仍然是，一個給定的開源項目的絕大多數(shù)工作都是由一小群貢獻者完成的。你越接近項目的核心，這就越正確。正如上面提到的，這通常只是一個時間問題:只有那些付出了重大貢獻的人才能夠跟上項目的步伐，并且能夠隨著時間的推移建立信譽，從而被邀請成為項目維護者。

這讓我們回到了Digital Rebar，這是一個數(shù)據(jù)中心自動化、供應(yīng)和基礎(chǔ)設(shè)施即代碼(IaC)平臺。

Digital Rebar最初的名字是Crowbar，這是戴爾在近10年前在開源許可下啟動的一個項目，Hirschfeld說，部分原因是“這是我們在戴爾內(nèi)部傳輸代碼的唯一方式?！痹赗ackN的贊助下，項目進行了幾年(以及名稱的變更)，RackN對其社區(qū)進行了評估?！拔覀儗彶榱?數(shù)字螺紋鋼)代碼庫，看看我們實際上從哪里獲得貢獻。在我們建立這個項目的過程中，我們沒有任何核心的貢獻?！?/p>

而不是“幾”。而不是“一些”。答案是“沒有”。

我想，數(shù)碼鋼筋在這方面也不會特別不典型。對于有大量商業(yè)贊助者的項目，由于各種原因，外部對核心的貢獻往往很少(包括，如上所述，時間)。要建立一個由開發(fā)人員參與的社區(qū)并從中獲得樂趣是比較困難的。然而，更容易的是聚集一個商業(yè)開發(fā)者社區(qū)來從中獲利。然而，要達到這個目標(biāo)，真正需要一個充滿活力的社區(qū)的并不是核心。

的生態(tài)系統(tǒng)。

盡管Digital Rebar社區(qū)似乎對更改核心平臺不感興趣，但他們對在其上擴展功能表現(xiàn)出了興趣。例如，RackN最近看到一個貢獻者在內(nèi)容包中添加了對Chef Server的支持。“這意味著社區(qū)成員可以加入并添加擴展，然后它就成為我們維護的目錄的一部分，”Hirschfeld說。因此社區(qū)得到了一個精心策劃的、受支持的生態(tài)系統(tǒng)。好了。

與此同時，赫施菲爾德說，這一變化使RackN能夠更積極地升級平臺。在更改之前，RackN工程師希望在后端性能方面實現(xiàn)10倍的改進，這要求更改平臺存儲對象和管理內(nèi)容的方式。Hirschfeld說:“我們在向開源代碼庫提交更改時會遇到很多麻煩，因為這是一個巨大的IP更改?！蓖ㄟ^顛倒模型并關(guān)閉核心，RackN能夠在對用戶社區(qū)的影響最小的情況下進行更改，用戶社區(qū)對項目邊緣的創(chuàng)新更感興趣。

從定義上講，Open Core告訴用戶:“這個開源代碼還不夠好?！蹦阈枰髽I(yè)版。”對赫施菲爾德來說，這被證明是有問題的，并導(dǎo)致公司拋棄了開放式核心模式?！昂诵谋仨毎l(fā)揮作用。它必須堅如磐石……[相比之下，開放核心]則是[西]自身。(顧客不想要)b級的東西?！?/p>