前言
其實想寫寫關於開源的文章已經好久了，從在2010年開始接觸Hadoop到現在已經有六個年頭了，從最早的Hadoop使用者和Contributor，再成為Committer，最後成為PMC (Product Management Committee，專案管理委員會) 委員，挫折、 欣喜都在交替在我跟開源打交道的每一天，這裡想分享個人的一些想法。
本文僅為個人意見，不代表我的僱主Hortonworks以及Apache Software Foundation的觀點。
版權宣告：本文由leftnoteasy釋出於 http://leftnoteasy.cnblogs.com, 本文可以部分或者全部的被引用，轉載請保留版權宣告全文，有問題可以聯絡wheeleast (at) gmail.com, 也可以加我微博 @leftnoteasy
什麼是開源呢？
相信很多人對於開源這個概念很模糊，我在之前的一篇部落格《程式設計師的選擇》裡面也略微談了一下，這裡想展開說一下。
開源心態
首先要清楚的是，開源是一種精神，這種精神是，我希望把我的東西能夠分享出去讓更多的人去使用它。對於開源者來說，能夠從中獲得什麼東西各有不同，有些人為了金錢利益，有些人為了興趣。但是清楚的第一點是，一旦你開源出去，別人怎麼用它就跟你沒有任何關係了。
所以有在我之前的部落格上有評論說，我不想開源主要是不希望別人拿我的程式碼出去賣錢，對於這種心態我只能說可能開源未必適合你。
開源協議
對於開源軟體來說，需要選擇一個合適的協議（License），不同的協議之間差別很大，具體可以參考：如何選擇開源許可證。如果上面的這些開源許可證都不適合你，那麼你也可以寫一個自己的許可證。
這裡拿一個比較流行的協議，MIT協議來舉個例子來說裡面要求了什麼東西，由於協議的英文比較冗長，這裡摘錄部分已經加上了註釋
…including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software
你拿我的程式碼去怎麼改，怎麼打包賣掉都可以！
…THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED…
程式碼就這樣了，不提供任何的質量保證！
…IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY…
用壞了我不負責！
MIT協議屬於比較寬鬆的協議，也會有些更嚴格的協議比如說GPL：如果你程式用了我定義的介面，那麼你也必須用GPL協議開源，之前小米就捲入了一些關於GPL協議的糾紛。所以根據不同的情況選擇不同的協議比較重要，同時當你引用了別人的開源程式的時候，也要注意是否違反了作者的開源協議。
開源社群
開源社群是開源軟體賴以生存的生態系統，所謂社群是由使用者和開發者組成了。
開源社群使用者
使用者一般會來自於五湖四海，他們會使用、抱怨（可能會非常尖酸刻薄）和貢獻開源軟體，比如說Hadoop社群裡面就有很多的使用者會把自己碰到的問題釋出到使用者\開發者郵件列表以及JIRA（bug資料庫）中，這樣的話，社群的開發者就能夠有機會看到並且修復這個問題了。有些對於開源軟體理解深刻的使用者會嘗試從程式碼裡面看到到底是哪裡出了Bug並且能夠提出解決方案，這種使用者是最受歡迎的使用者了。
開源社群開發者
開發者可能來自於不同的公司也可能來自於同一個公司，取決於不同的目的。比如說Hadoop的核心開發者都是來自於不同的深度使用或者賣Hadoop相關產品的公司，比如說Yahoo、微軟、Hortonworks、Cloudera之類的。也有一些開源軟體不希望別的公司的人來參與，比如說Google開源的產品一般很少有來自其他公司的貢獻。比如說Tensorflow、Android。
一個良好的開源社群裡面會非常的良性迴圈：使用者用軟體，找到Bug和提出改進的方案；開發者通過使用者的反饋來不斷的改進產品；不斷有新的開發者來加入到社群裡面進行開發，這樣就算是有老的開發者不做了專案也能夠繼續往前發展。
而相對的，一個壞的開源社群會很少有人蔘與，對於使用者的反饋置之不理，沒有辦法釋出新的版本，最後徹底成為一個死掉的專案。
開源社群的開發者都是哪些人？
開源社群的開發者都是不拿工資的嗎？
對於開源開發者來說，有很多人的認識是：開源社群裡面的人都是技術大牛，視技術如生命，視金錢如糞土，上班幹著公司的活，下班幹著開源專案的活。
其實這個是一個很大的誤解，其實開源社群裡面絕大部分的開發者是在工作的時候貢獻程式碼的，因為這些開源專案就是公司IT的基礎架構之一。當然裡面有很多大大牛是能夠憑著自己的興趣就可以創立最牛的軟體，個人最佩服Linus，完全憑著自己的技術、經驗和興趣創立了Linux和Git。
開源社群是一片技術的淨土嗎？
另外一個普遍的誤解是認為開源社群就是一片淨土，裡面的程式設計師都活在自己的技術世界裡，兩耳不聞窗外事，一心只會碼程式。其實有人的地方就有江湖，朋友志傑寫過一篇關於Hadoop兩黨制的文章，非常值得讀一下。
跟一般的公司一樣，開源社群的開發者有著一些不那麼好的個體：
- 幹活不行只會去搶別人的功勞的
- 愛拉幫結派搞政治，在各個不同的討論主題上面嚼舌根的
- 對於自己不同意的意見出口成髒人身攻擊的
但是不得不說，好的開源社群裡面還有有著比一般公司更多的技術大牛和更好的氛圍，所以希望上面的言論不要把你給嚇到：雖然它不是一片淨土，但是它比一般的地方乾淨純粹得多。
開源專案怎麼掙錢呢？
開源專案的掙錢方式也很多，不是因為開放了原始碼你就變成了一無所有為別人做嫁衣裳了（當然有時候還是有點這種感覺）。對於公司而言（除開純粹個人興趣開源的），開源最主要的原因是沒辦法繼續賣閉源的產品了。
舉個例子來說，如果沒有iOS，Android會開源嗎？沒有Unix、Windows，也很難說Linux是否會開源。所以作為老二，如果要打敗老大，最好的方式就是把老大的最重要的技術開源出去。
一旦開源出去，掙錢的門路就多了，比如說：
- 賣技術支援，你用我的開源軟體，但是裡面出了問題我可以幫你解決，我也可以幫你把你需要的功能給加進去。這個是最普遍的盈利方式，但是最大的問題是利潤率相對低，因為技術支援的人力成本比較大。
- 賣培訓，跟上面差不多，因為只有我最懂這個開源軟體了，你想要學習當然得找我了。
- 賣高階功能，一些開源軟體會在開源的基礎之上提供更多的高階功能，這些功能往往是閉源的。這方面做得比較成功的是Redhat，但是問題主要有幾個
- 1）使用者可能會擔心被你給困住（lock-in），對於選擇開源軟體的企業使用者而言，很多情況是希望不要困在某一個軟體提供商的軟體裡面，以防這個軟體提供商倒閉或者漫天要價。
- 2）這個高階的功能帶來的價值是多少，有沒有類似的開源免費的軟體能夠做到這些功能。
- 賣雲服務：現在很多的公司也會把開源的軟體作為雲服務提供，比如說Tensorflow就能夠在Google Cloud Platform上面，Docker也能在Docker自己的雲上跑。這個也是現在比較火的開源軟體盈利方向。
不管怎麼說，開源專案相關的產品比之前的相似的閉源產品一般會便宜很多，如果有一個健康的社群，在幾年之類就會越來越少有人去用那些閉源的軟體了。舉個例子來說：Teradata由於各種開源專案的衝擊，在這個上一個季度的收入比全年同期下降了不少，見Teradata Reports 2016 First Quarter Results。
開源專案代表著最高的程式碼質量嗎？
簡單來說不是。
這種事情經常發生在大部分的開源社群：有些開發者更新了程式碼後發現”我擦居然這個東西都能夠被提交進程式碼庫“，然後就發起一個新的討論主題開啟罵戰模式。
開源社群的程式碼質量主要是由下面的幾個原因導致的：
1）雖然說好的開源專案都有非常嚴格的程式碼檢查（Code review）政策，所有進到版本庫裡面的程式碼都需要有相關領域的負責人來檢查通過後才能夠被Commit，但是很多時候，一些開發者的經驗不足和Code reviewer的疏忽會導致一些不那麼好的程式碼被提交。
2）此外開源社群有時會進行很多低效的討論，在不同的需求情況下，有時做出最後的決策是妥協了的結果。
所以如果看現在的IT領域，一般來說開源的專案並不是最好的，比如說分散式系統裡面Google的內部GFS應該遠遠領先Hadoop HDFS；Google Borg比YARN、Mesos、K8S領先了好多年。
但是還是得說一下，有些東西不能只看點，如果你能夠在Hadoop裡面找到一些弱雞的問題並不代表所有的程式碼都是一坨狗屎，裡面大的程式碼架構設計、使用者介面設計和那些很核心的程式碼都是由大牛主導，通過很多的思維碰撞而得到的。
另外由於在開源社群裡面，由於你的每一行程式碼都會經過別人的眼睛，從個人的名譽來說，一般人會更加重視進入了開源社群的程式碼；同時，那些老是把低質量程式碼提交進去的開發者來說，會被打上”不靠譜“的標籤，之後就很難在社群裡面混了。
所以總的來說：
雖然開源專案程式碼質量不是最好的，但是也是相當不錯的，而且由於開源社群是由眾人拾材火焰高，所以好的專案會活得更久，因為就算是之前做這個專案的負責人、公司不做了，專案還是能夠繼續活下去的。
好吧作為科普文，先寫到這裡了，之後準備談談關於開源更深入的一些主題。