開源？不好意思，你們都理解錯了

PS：文章僅為個人觀點 —— 本文的內容基於我這幾年在開源世界的觀察得出的結論，並非調查所得到的結果。

上上週，我在 GitHub 上發佈了 Ledge 知識平臺（https://github.com/phodal/ledge），我以一種“重量級”的方式來運行這個開源項目。換句話來說，以正確的方式運行起了這個項目。因為我知道怎麼運作一個開源項目，加上一些外部的原因，我開始思考個人開源和組織開源的一些困境。

開始之前，讓我講個笑話和無奈：

組織開源的四大笑話是：一次性開源、按揭開源、KPI 驅動式開源、社區是什麼？（分別代表了國內的幾加大公司的開源做法）

不好意思，你們是對開源有什麼誤解嗎？

什麼是開源

事實上，我們經常混淆了兩個概念，那就是開源軟件和開源這個行為。

開源軟件是源代碼可以任意獲取的計算機軟件，任何人都能查看、修改和分發他們認為合適的代碼。開源軟件依託同行評審和社區生產，皆以分散、協作的方式開發。—— 紅帽官網

換句話來說，你選擇一個協議，將你寫的代碼公開發布，這叫開源一個軟件。但是，它並不叫你搞開源。開源源於開源軟件，但是它現在已經成為超越軟件生產的運行和工作方式。

開源源於開源軟件生產的運行和工作方式，它是一種基於去中心化、自組織式的軟件開發模式運作的工作方式。它以社區作為根基，通過開放、透明、協作幾項原則開展的活動。

開源不是公開代碼

在那本開源的《GitHub 漫遊指南》裡，我一直在講述如何在 GitHub 上開發一個 “成功” 的開源項目。因為開源不僅僅只是說源代碼的開源，還包含了設計文檔、產品的內容等等，還要以開源的方式來運作。以 opensource.com 對於開源方式的解釋來說，需要這麼五個維度：

1. 透明度。

2. 協作。

3. 遲早發佈、持續發佈。快速建立原型，發佈第一個版本，並且不斷地快速地迭代。

4. 精英制度。根據提出的最佳方案做決定的方式

5. 社區。形成社區，提升社區參與度，轉化為社區目標。

也因此，如果只是公開源碼的話，那是走到開源的第一步，剛來到開源的起跑線上而已，還沒參與到這個遊戲中去。

一個開源項目是一個產品

作為一個資深的開源運動參與者，我有一個這樣的體會：運營一個開源項目，就好像創業一樣。我們需要採用《黑客與畫家》作者 Paul Graham 所說的創業公式：

1. <code>1. 搭建原型/<code>
2. <code>2. 上線運營/<code>
3. <code>3. 收集反饋/<code>
4. <code>4. 調整產品/<code>
5. <code>5. 成長壯大/<code>

所以，開源就像是一場小型創業，需要進行競品分析，需要制定合理的策略。當然了，如果你的東西絕無僅有，那就無需如此。而除了分析市場，針對於開發人員，還要考慮：

1. <code>1. 作為投資人（技術投資），他們能獲得什麼？提升技術？找個好工作？/<code>
2. <code>2. 作為潛在的用戶，從哪裡知道這個項目？/<code>
3. <code>3. 作為貢獻者，如何提供不同級別的貢獻計劃？/<code>
4. <code>4. ……/<code>

你並不一定非得去考慮這些問題，只要在持續完善的過程中，這些問題的答案就會浮現出來。只是呢，在你開始之前想好，可能會事半功倍。

開源的重點在於生態建設

對於個人來說，開源的目的可能是找個好工作、為以後找個好工作……；對於一家組織來說，他們考慮開源可能有多種多樣的目的：

1. <code>1. 降低開發、維護成本。由社區來幫助尋找 bug，提出一些觀點。/<code>

2. <code>2. 技術影響力招聘/<code>

3. <code>3. 建立技術壁壘。/<code>

4. <code>4. 營造生態。/<code>

5. <code>5. ……/<code>

一個好的開源作品，需要連接到上下游，即影響開發者，又影響使用者。慢慢地，它個作品就會成為一個影響行業的存在。儘管會不斷有其它的項目冒出來，但是由於穩固的生態建設，將鞏固組織在該領域的影響力。

組織需要制定開源策略

從開頭的大部分四大難題：一次性開源、按揭開源、KPI 驅動式開源、社區是什麼？。我們就會發現：國內大公司的開源策略都是錯的。

他們可能，今年發佈 Phodal UI，明後發佈 Phodal Compiler，後年發佈 Phodal OS。然後，中間靠各種公關稿，完成在社區的宣傳。

應該是這樣的，今年發佈 Phodal UI 1.0，年中發佈 Phodal UI 2.0，明年發佈 Phodal UI 3.0 和 Phodal Compiler 1.0，明年年中 Phodal UI 4.0 + Phodal Compiler 2.0。過程中，需要依賴於佈道師來進行閉環：

1. <code>1. 維護開發者關係/<code>
2. <code>2. 在社區進行宣傳/<code>
3. <code>3. 對社區進行支持、收集社區反饋/<code>
4. <code>4. 建立連接內部的通道/<code>
5. <code>5. 促進內部進行改進。/<code>

這些組織需要建立一個具備可持續性的開源策略：

1. <code>1. 明確其帶來的業務價值（如人才引進 、生態等）/<code>
2. <code>2. 專職的開發人員進行開源支持/<code>
3. <code>3. 開放式的開源團隊組織結構/<code>
4. <code>4. 合理、適當地長期 KPI 考核機制/<code>
5. <code>5. 政策和流程支持。如專項鼓勵獎金/<code>
6. <code>6. 明確地專利和知識產權機制/<code>

開源到開放式組織

領導力變化，當我們在組織中開發一個軟件應用時是以職權影響力為核心構建的；而開源方式，則是以非職權影響力構建的。

社區的每個人都可以提出自己的意見，你可以 say No，但是每個人都可以提出意見。就這一點來說，對於大部分的國內公司來說是一種挑戰，大部分的領導希望聽到統一的聲音 —— 論組織內多樣性的重要。

簡單來說，大家想來就可以來，想走就可以走。所以，開源的一個難點就在於：如何吸引到人來參與開發。

儘管大部分項目都是圍繞個人、團隊的中心化開放式組織，如 linus 之於 Linux。但是，開源還可能變成一箇中心化的組織，如 Node.js 的 IO.js 出走事件。根據開源協議，人們可以很容易派生出一個新的項目。

結論

開源，就是生態。