產品開源需遵守 4 個規則

當用開源軟件來構筑產品時有4種規則來理解。一個產品團隊（工程，產品管理，市場）需要去理解這些規則最好去參與一個開源項目社區和交付產品同時服務于客戶。

這四個規則是開始于所有關于開源產品空間的討論的。

規則#1：你總是給予的少，獲得的多

超時的投資在一個技術上跟隨的是一個正態分布。試想以一個開源項目的投資作為堆積條形圖，公司和個人貢獻被同時占據，并且替換一個個人公司的投資。那么在 一個開源項目集合投資看起來就和作為個人投資開發封閉產權軟件產品一樣。個人和公司貢獻來滿足他們的私欲（個人需求）。這是一個完美的不對稱關系，投資者 放棄了一些相對少的價值，隨之得到的是一些實質的回報（一個完整的可用的軟件）。一個可以看到 Openstack 或者 Linux Kernel（linux 內核）行為最好的可度量的方法。而不是看著這個作為一個贈送的知識產權，它需要被看起來是獲得所有的產權。

代碼行數和 COCOMO 計算來自于Openhub.net 爬蟲的代碼倉庫。我可以確切的理解代碼行數有多滿。我理解對于 COCOMO 精度背后的關注，但是他們是代表模型，如果不是完美的，并且他們表示出了近似的趨勢。

規則2: 不要把項目和產品弄混

這一點有時很難理解。首先，我們假設我們討論的是一個正常運行，成功的開源項目。（更多參見規則3和規則4）一個項目是一個軟件集，可以安裝運行，解決某 個有趣的問題。它是相對較少，擁有寫入權限的幾個開發人員（如：代碼提交者）之間通過代碼進行的協作與溝通，希望有大量用戶和貢獻。產品是解決用戶的問題 并獲得金錢。

項目不是產品。 盡管很多來自開源項目的優秀軟件緩解了工程師的工作（見規則1），但仍然有大量的工作要做才能把它轉化成產品用來解決用戶的問題。Linux 內核是一個項目，Fedora 是一個發行版項目，RHEL 是一個產品，“但 Ubuntu 是什么“，你哭了？它有多種商業模型。Ubuntu 是一個發行版項目，長項目支持版本（LTS）是 Canonical 多個產品的基礎。

產品通過滿足用戶對金錢價值的期待。它們安裝于盒子之外，運行并提供保障和賠償，服務（支持，更新，培訓，咨詢），文檔。產品可以通過服務或硬件的 方式把項目打包。產品的就像市場中用戶獲取金錢的需求一樣具有多樣性。盡管好的項目解決了前兩個盒子（安裝和運行），但它們不解決用戶關注的其他問題。和 用戶想解決的問題相比，項目只解決了很窄的一些問題。

不要被開源許可和它們是否“商業友好”搞暈了。不同的提供商針對不同的許可采用不同的策略。每一個 OSI 批準的主要許可都有相關成功或失敗的故事。與業務執行相比，許可證是無關的。

規則3：不要把社區和客戶搞混

如果有什么難以理解，這個規則會和規則2直接交織在一起。如果規則2是關于工程師和商業模型，那么規則3就是信息和銷售。社區和客戶存在于不同的價值空 間。社區有閑沒錢。客戶有錢沒閑。也許一個更好的說法是：客戶拿錢加速解決方案和消除風險，而社區（社區的個人開發者）沒有錢。

傳統意義上，工程為流水線提供產品，市場提供信息，銷售通過封閉交易將有價值的人拉入，在執行上是一件很簡單的事。很多公司使用開源項目并認為項目社區也 是這條流水線的一部分，在社區論壇找到客戶后他們更進一步這樣認為。他們可能甚至認為社區項目就是購買前的一種試用。但這是錯誤的。

與 一家公司（產品管理，工程，市場）具有的相關社區的對話和與支付客戶的對話是不同的對話方式。每個對話都具有特定的工具和契約規則。成功企業（公司）理解 怎樣進行這些對話。他們有良好理解的構建工具和具有資格的管道（渠道)。他們有同等良好理解的工具和為開發成功社區（規則#4）的規則。每種工具鏈和對話 有不同的矩陣來捕獲和考慮。

有種交互是介于一家公司社區和客戶之間的。社區成員們為項目（所以這也是公司品牌的價值的一種周到的表現形式）進行傳教（原意是福音傳教）。社區成員們，在再次加入產品生產渠道（管道）之前，提供支持和專業技能給那些潛在的在項目社區中能夠自我勝任的顧客。
社區也提供一種為了終極的產品解決方案的慣性，通過漸漸的給予專業和時間的投資。這種挑戰是保持事物清晰流暢的在社區和顧客之間分離，就好比，你可以又快又方便的認知在你面前的這個正在一邊玩同時適度指導他們的人，是什么角色。一定從來沒有信息（蓄意或者別的）的混亂發生過。

比如說，產品是給客戶使用的。如果你有一個試用版，買之前先試用，那么“買”就在這，所以，需要跟客戶溝通。如果你有一個社區版本，然后構建一個社區 (規則 #4)，否則你就只是簡單的遵循開源授權協議發布一個軟件，而沒有從一個開源社區獲取任何的好處。這是兩個分開的東西，但是可以讓我們了解最后一個規則。

規則4：成功的開源社區遵循簡單易用的模式和實踐

所有成功的開源社區項目都遵從同一種類型的模式和實踐。項目開始的時候只是一些核心的開發者在溝通討論。所以，你需要構建 3 個入口點。第一個是驅動使用和加強用戶群，因為這樣會促使開發者找到你的項目。 (你需要不請自來的用戶！這就意味著你成功了！)軟件必須容易安裝和運行。用戶會告訴你他們想要什么，比如，你收到一個 bug 報告和特性請求，這就是成功的例子。更重要的是，開發者找到了你。

第二，使得構建軟件變成已知的，測試過的狀態更容易。這允許開發者可以自己選擇和實驗他們的需求。假定一個聰明的開發者指出拋掉開發周期是不可以 的，那么他們就不會這樣做。沒有人想要浪費他們的時間在你的懶散和缺乏紀律之中。他們將會陷在挫折和厭惡之中。讓他們回到正常狀態很難，但不是不可能的。 正確處理這個問題，你會得到下一組更困難的 bug 報告和建議修正。

最后，告訴開發者怎么去做，在哪里可以貢獻和怎樣更方便地去做。感謝他們的貢獻，如果其他事情超過了代碼而感到振奮，設置這些貢獻頻道可以讓他們能更方便。常常說“謝謝”，用盡一切方法，鼓勵分支，尤其是當你是一個公司的時候。

建立社區是一項很艱難的工作。但是對自由社區卻不是這樣。相反，自由社區在從使用者和開發者的貢獻中帶來價值，同時也帶來了對技術的粘著力。

這 一領域的最后的實踐是要理解基金會在開源軟件中所扮演的角色。基金會在IP管理制度上進行組織和分類。基金會可以做很多其它的事，但如果他們不把這個中心 事情做好，那么他們在社區成長潛力這個項目上是失敗的。將中立的IP所有權分類有助于專門投資增長，這一專門的投資來自于有志于整個生態系統的成長的參與 者和貢獻者，換句話說公司致力于為用戶解決問題。

基金會創造了一個中立的空間，在這空間中公司可以以平等的社會關系參與進來。一個公司從不是由他們發起也并非屬于他們的開源項目（比如 SUSE 和 Linux，HP 和 Openstack 等）中做產品需要清晰的理解他們的貢獻是怎樣被處理的，他們并非簡單地在做其他人的產品。同樣地，一個公司發起一個開源項目并希望驅動圍繞著這一項目的生 態系統的采納和成長，這將很好地貢獻于項目的軟件IP，這些IP區分非營利性質的基金會（或者在適當時創造一個）如 Google 最近和 Kubernetes 所做的項目，或者 Pivotal 和 Cloud Foundry 所做的項目。這是最終獲得權利的四分之一個匝道。

總結

因此情況就是這樣。我將這 20 多年來所了解到的有關對開源項目的支持，基金會的參與和產品工程總結為這四條規則，10 張 ppt 和將近 1600 個字。我期望大家能提點問題作點評價。