開源軟體需遵守 4 個規則（10 張 PPT）

當用開源軟體來構築產品時有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 個字。我期望大家能提點問題作點評價。