【案例】成功完成天網千帆開源專案的感受

一個真實的案例,可以說是一個具有開源特點的專案管理過程,對於開源的專案運作,是有借鑑作用.更可貴的是,他記錄的非常完整和全面.

【開源嘗試】
　　2004年4月至8月，作者有幸進行了一次開源開發，期間感受頗多，在此撰文向大家做一簡單介紹我們開源專案的前前後後，並穿插很多開源相關的知識，以饗讀者。

【背景】
在教育網，尤其是高校的學生中，北大天網檔案搜尋引擎（舊稱北大天網FTP搜尋引擎）大概是使用頻率最高的檔案搜尋引擎了。它是一個執行了多年的較成熟的檔案搜尋引擎，每天有大約30萬的查詢量。我有幸從它的主要開發者陳華手中接過它，作為唯一的維護、開發人員。但系統從2000 年至今，經過多次的增刪改，結構相當複雜，加之秉承了高校專案的一貫問題——文件不全、程式碼可讀性較差，致使後續維護和開發相當困難。
　　人力問題大概是首要的問題，我首先向負責老師申請學生和我共同開發，但由於實驗室本身容量的限制，已經不可能有其他人和我共同工作了。或者說，封閉

開發這條道路已經被堵死了。
　　不得已，我只有另擇它途。如果從外面吸引人，傳統的開發模式已經不適用了。很快，“開源”這條路映入了我的腦海，也許這是一條通往成功之路。

【開放原始碼專案的開發模式】
光有目標是不夠的，還需要腳踏實地，我決定先學習前輩的經驗，看看開放原始碼專案的具體開發模式是怎樣的。
現有的成功的開放原始碼開發模式主要有：
1. 小型開源軟體開發模式
2. 中型開源軟體開發模式
　　其特點為擁有3-5 名核心維護人員，參與開發的人員10人-40 人之間，採用CVS 進行程式碼管理，透過maillist/irc進行開發交流，有明確的開發計劃和日程。

使用者提出的錯誤報告和修正數量很多，並且有一些分支產生。
3. 完全封閉的商業Open Source軟體
4. 比較封閉的大型Open Source軟體的開發
5. 由商業軟體轉化過來的大型Open Source軟體開發.
6. "獨裁"式的大型Open Source軟體的開發.
7. "民主"式的大型Open Source 軟體的開發.
  在瞭解、比較了各種開發模式後，考慮到自己專案的特點，決定採用“中型開源軟體開發模式”，並根據我們自己的特徵作適當調整。

【開源專案的風險】
　　“風險是專案管理的最大敵人”。
　　確定了開發模式，又瞭解到中國開源的現狀，我決定首先把風險一一列出，防止專案半途夭折。
　　和一般的專案相比，開源專案主要的風險有：
　　人員交流：由於開發人員往往不在同一個辦公室，因此交流會成為最大的障礙。網路的普及在一定程度上緩解了這個問題。“但同時也在一定程度上掩蓋了交流的風險”。
　　工作時間：由於開源專案的開發人員都是志願者，大家是在業餘時間進行開發，因此開發時間很難保證，更要為中途被迫離開專案組的壞訊息作準備。
　　開發熱情：沒有資金、沒有裝置、沒有薪水，甚至沒有一杯水，完全憑藉一腔熱情，靠的住嗎？這也是一個問號。
　　開發人員的水平：在一般人眼中，開源專案的開發者，尤其是國外的開源專案的開發者，往往都是經驗豐富，編碼水平甚高，擅長Linux開發的高手，甚至是編碼的天才。但我們招的到這樣的人嗎？什麼人願意參與專案開發呢？
能找來志願者嗎？
究竟會不會有志願者來參與我們的專案呢？我想起我曾經在較早的時候做過一次調查報告。調查分成7天，每天一個問題，最後一個問題是“你是否會作為志願者參與我們的專案，並選擇何種工作？”這個問題當時共485人參與回答，結果為：
參與美工（9.1%),網頁設計（16.2%),欄目管理（16。2％），程式設計（18。3％），運作與策劃（29。9％），不參與（10。2％）
　　但考慮到本次投票時長和前6次一樣，（約24小時），但得到的票數卻是最少的，對於這次減少的票數，初步分析是他們預設選擇為“不參與”，因而沒有投票

，因此我們將對上面的資料重新整理。上面幾次投票的平均投票使用者數為1281 人次，考慮到前一天投票數量已經有所降低（850 人），我們不妨假設這次為1000 人。而這1000 人中沒有投票的使用者的選取均為“不參與”，則資料重新整理為：
參與美工（4.5%),網頁設計（8.1%),欄目管理（8。1％），程式設計（9。2％），運作與策劃（15。0％），不參與（55。0％）
　　可以看到，雖然多數人並不願意成為志願者（約55％），但仍有相當多的人願意參與天網檔案搜尋引擎的開發、運作，考慮到天網每天僅30萬的查詢量，這個是一個非常可觀的數字了。由此看來，招募志願者本身應該沒有什麼問題。
　　究其原因，為什麼會有這麼多人願意成為志願者呢？我想可以歸納為以下三個原因。
1．想參與開源專案的開發。如果我們招募志願者，我們必定會以開源專案的方式運作，國內雖然成功的開源專案不多，但有熱情的人員還是很多的。
2． 被天網本身吸引。這個不是大話，在教育網內，天網確實知名度較高。比如在我們的這次調查中，就有一個署名的使用者留言說“ 天網帶給我很多的方便和樂趣，我非常願意為天網做事。”
3． 想透過這次開發工作提高自身。我不瞭解國外的同行持這種想法的人多不多，不過這確實是一個合情也合理的動機。

【人員招募方式】
　　說幹就幹，確定了開發模式、分析了風險後，決定立即啟動我們的開源專案的第一步工作：人員招募。
　　開源專案的人員招募通常可以採用以下方法：
1．從身邊入手，拉上幾個志同道合者。這個方法簡單實用，在小的開源專案中還是不錯的方法。而且同身邊的人一同開發在交流合作上都較方便。但是專案較大，人較多的話往往就不那麼試用了。
2．透過sourceforge等開源網站公佈自己的專案計劃，吸引開發者。如果自認為專案有足夠的吸引力，不妨考慮完全透過網路開發，透過一些提供開源開發支援的網站進行開發。在中國有“共創軟體聯盟” 等網站。不過採用這種方法要確保你的專案有足夠的吸引力，否則也許會發生過了一兩個月還沒有人報名的尷尬事情。
3．自己撐起一面大旗，招兵買馬。不過專案已經有了足夠的影響、不是從頭做起，並且有足夠資訊的話，也完全可以親自發布廣告，招兵買馬。
考慮到天網搜尋引擎本身的的吸引力，我決定自己動手。
　　首先我透過北大的一個linux社團進行一場類似“宣講會”的報告。報告在2004年4月10日進行，在簡要介紹了檔案搜尋引擎技術之後，重點介紹了新的開發計

劃以及招募活動。報告本身很成功，吸引了相當多的聽眾。但是報名的人卻少的可憐——只有人。現在分析，我認為聽眾多半是希望瞭解天網檔案搜尋引擎的技術，而非希望參與專案開發。
　　一招不靈，另換一招。我直接在我們的大本營——天網檔案搜尋引擎上面做了一個連結廣告說明開源專案一事，並安排了約10天的報名時間。網上的報名果然相當踴躍，而且各個省市、各種背景的人都有。很快就有超過100人報名，主要都是應聘開發人員。
　　最終的招募情況是：核心開發人員5人，美工1人，專案顧問2人，法律顧問1人，由於對於一般開發人員的人數需求和工作內容都尚未明確，因此沒有確定一般開發人員的名單。實際招募開發人員還是以學生為主。
　　在人員招募的過程中，我首先招募了專案顧問，然後才開始開發人員的選取。考慮到前面的風險分析，為了規避“人員交流”的風險，我們重點招募了能夠見

面的北大學生。最終五名核心開發人員的分配為：北大學生3名，北京學生1名，外地學生1名。這樣，即使在最壞的情況下：即如果只有能夠當面交流的開發人員參與了開發，仍然有60%的開發人員的保證。招募的五名核心開發人員對搜尋引擎的瞭解都非常有限，技術水平屬於中上。
　　在後續的開發中，隨著具體開發工作的需要，又有多名開發人員加入，最多時整個專案組達到了16人。

【基本運作方式】
前面已經說道，我們招募了專案顧問。我們的基本運作方式也是透過和專案顧問共同商量確定下來的。這讓我在專案開始前已經感受到開源的作用了。
下面是我們的開發模式（這裡暫且稱為“千帆開發模式”）與標準的封閉原始碼開發模式和標準的開放原始碼開發模式的比較。可以看出我們是在一般的開放

原始碼開發模式的基礎上又借鑑了部分封閉開發模式的內容。

千帆開發模式

開發隊伍組織模式：
分散開發人員透過Internet組成開發隊伍釋出版本時間:
固定時間釋出，但有模組完成時儘早釋出模組提供原始碼物件：對公眾釋出負責測試部門:
無專門測試部門管理手段：
按照專案生命週期管理，強調協作，自願參與
　　
　　為了加強交流，對於能夠到會的人員每週進行一次專案例會，不能到會的則參與每週一次的網路會議。專案的第一次例會在4月28日啟動，原計劃在8月15日結束，以周為時間劃分，共計16周，

【第一次大會】
　　在4月27日下午，也就是專案啟動的前一天，我緊急聯絡了剛剛招募的在天津的美工王志壽，希望他能在第二天下午之前完成我們的專案網站，好在第二天正式啟動我們的專案團隊。我現在還清楚的記得，當天下午我透過QQ和他進行溝通，簡單表達了自己的想法後，他在幾個小時後，也就是當晚八、九點鐘的樣子，就給我展示了網站的首頁——一個看上去很成熟的站點首頁，並於第二天按時釋出了我們的網站。如果這個工作由我個人來做，可能也能夠完成，但質量一定遠遠不如他，並且一定會影響第二天的會議準備。
　　那邊是美工在忙，這邊我也趕緊找來另一個成員陳朝巖，他幫著我們很快假設好了我們的伺服器——一臺裝有Redhat 9 Linux的伺服器。
　　透過大家的不懈努力，我們於4月28日釋出了我們的工作網站，並於當天晚上召開第一次專案會議。在這次會議的籌備過程中，大家就已經深深感受到了開源的魅力——一群素不相識、甚至不能謀面的人因為開源而聚到了一起，併為了共同的目標而興奮的工作著。
　　第一次會議大家興致很高，在各自完成自我介紹後，我向大家暢想了我們美好的“前程”，大家也都談論了各自對於新系統的一些想法。會後大家合影留念。

【多種開發方法並行】
　　專案團隊建立起來後，就開始了正式的團隊運作。
　　為了規避風險，我們最初曾經考慮全部嚴格遵循軟體工程，並借鑑了TSPi（小組軟體開發過程）的思想。整個開發週期計劃從4月28日至8月15日，共16個星期。專案採用迭代式開發，分為兩個階段。
　　但很快發現一個現實，面對一個鬆散的開源團隊，單純的較嚴格開發方式反而並不高效，我們便調整了開發方式。我們在專案總體採用兩階段的需求、設計、實現、測試的基礎上，根據功能的需要，在某些獨立模開的開發上採用下面兩種並行的開發方式。
　　一、對於需求非常明確、有相當的把握開發成功的成熟的獨立模組，可以交付給熟練的開發人員獨立開發，開發人員可以按照自己喜愛的開發方式，只要在規定的時間內完成開發即可，不必嚴格遵循軟體工程的各個流程、但要保證開發的模組的質量。
　　二、對於無把握的或需要探索的新功能模組的開發，由於風險很大，也獨立提出。要求本模組的開發人員在較短的時間內完成功能演示的開發。因為只是功能演示，對其程式碼質量不進行要求，但需要能夠明確模組的實現方法，便於真實系統的應用。
　　這樣，整個開源團隊就存在這三個並行前進的三條線路：遵循軟體工程進行迭代開發的主團隊、進行成熟模組開發的小分隊、以及進行新功能嘗試的探索的探險隊。

【工具的使用】
　　對於透過網路協作開發的開源專案，協同開發工具自然也不可少。現在想來，我們用到的工具還真是相當的多。
　　網站：首先建立自己的網站，確保團隊內外的人都能明確瞭解專案的進展，這是整個專案對外的視窗，我們的美工在第一時間完成了一個精美的網站，一下子給人以高起點的感覺。
　　版本控制工具：由於程式碼量越來越大，在開發中，每個成員都要保留一個副本，在開發中非常容易引起衝突。因此版本控制工具是非常必要的。CVS是個可以用在小組協作環境下的原始碼版本管理系統。同類的軟體有AT&T的SCCS（Source Code Control System），還有PVCS等。CVS是用得最為廣泛的，因此我們選擇了它，它從技術上可以提供如下功能：同步修改、維護不同的版本、查詢歷史記錄。
　　開發工具：因為專案較大，人員較多，我們使用的開發工具也不少。
　　建模：稍大的系統就需要一個全域性的規劃，這方面我們使用了Rose和Visio。
　 　程式碼開發：vi, emacs都是常用的linux下的工具，eclipse +CDT也是一個不錯的選擇，magic c++是我們發現的另一個有點“神奇”的工具，它可以讓你在windows下透過類似VC的介面來編寫、除錯linux下的程式，在我們這次開發中也得到了廣法的應用。
　　文件建立工具：doxygen，我們發現是一個不錯的文件建立工具，可以透過分析原始碼中制定的標記建立多種不同形式的文件。
　　程式碼格式化工具：這方面雖然工具不少，但我們還沒有足夠的精力去挑選。唯一使用的工具ident，居然把我們的原始碼修改錯誤了，造成編譯無法透過。
　　編譯、除錯工具：我們選擇了應用最為廣法的GCC, GDB。
　　釋出工具：隨著專案的進行，也許需要釋出了，autoconf，automake，tar是必須的。rpm也是現在一個比較流行的釋出工具，也可以考慮。
　　Bug管理：可以考慮使用Bugzilla，不過我們還沒有使用任何bug管理工具。
　　除了上面說的這些開發相關的工具，我們發現最重要的其實還是下面這些用於交流的工具：
　　空氣：“空氣是交流工具嗎？”，它是我們當面交流時聲音傳輸的媒介啊！沒錯，經過實踐，我們發現當面交流依然是最重要、最高效的交流工具。所以只要有可能，還是當面交流吧，而不必要透過QQ去和身邊的開發者說悄悄話。
　　即時通訊工具：如QQ，MSN等，它幾乎已經成為第二高效的交流方法了。
　　此外，網路語音聊天工具，論壇，簡訊息，郵件列表，網路會議，wiki，電子郵件等幾乎全部能夠想到的方式幾乎都被我們採用了。而且事實證明——這依然毫不過分，交流是最重要的！

【第一個模組的釋出】
專案只運作了不到三個星期，我們“進行成熟模組開發的小分隊”的謝翰就釋出了第一個模組——TCP埠掃描模組，用於搜尋提供FTP服務的主機的掃描器。這個模組採用了新的方式，把原先需要1個月才能完成的工作提高到只需要幾個小時！
第一個模組的釋出大大提高了整個開源團隊計程車氣，我們這個專案在民間的影響力也初步體現。

【問題不斷】
專案繼續進行，第三週很快過去，沒有什麼特別的事情發生。隨著第四周的到來，相當多的成員面臨期末考試的壓力，只好停止開發工作。整個專案在第四周的前幾天基本上出於停滯狀態。我決定改變這個現狀，臨時招募了幾名沒有期末考試壓力的成員，但因為是半途加入，在很短的時間內工作開展的又不是有效。
一個百無聊賴的第五週結束後，發現在核心開發人員缺席的這段時間內專案進展的非常緩慢。隨著第六週的到來，多數開發人員已經結束期末考試，我們的黃金開發時期——假期已經到來。但緊接著又出現了新的問題：開發人員一下子多了起來，原先的組織結構已經不能適應新的狀況了。

【組織結構的變化】
　　專案啟動之初，人員不多，組織結構也較簡單　　
　　考慮到實際對專案的把握和時間投入，專案組長同時也承擔了開發經理的工作，並直接領導美工。顧問協作專案組長的工作。每個核心開發人員負責一個具體子系統的開發，考慮到專案組長工作較重而繁瑣，其中一個核心開發人員同時承擔一些開發經理助理的工作，專案組長本身不擔任核心開發工作。
　　到了第六週，人員達到了16人的規模，原有組織結構已經不能滿足此時的管理要求，調整勢在必行。起初我們想按照一般的做法，把開發團隊分成2－3個小組，每個小組選出組長，組長則向專案領導彙報。如下圖：
　　
　　但這個調整又是相當困難的：一方面開發工作已經開始進行，讓原有人員調換角色或者調整開發內容將是非常困難的；另一方面，整個開發團隊中除了專案組長之外，其它人都缺乏對全域性的系統的足夠了解和足夠的工作時間，因此很難選出合適的人員承擔小組長的角色。經過和專案顧問的多次商討，最終的組織結構如下：

這個看起來略顯複雜的結構其實基本思想很簡單：
1． 保證已經開始工作的核心開發人員的工作內容基本不變，輔助開發人員配合核心開發人員工作；
2． 為了不增加核心開發人員的管理工作量，沒有設定開發小組長的角色；管理工作直接由專案組長負責；
3． 為了防止專案組長事務工作過多，加強開發經理助理這一角色的作用；同時多安排一個輔助開發人員來配合其工作。
總的說來，新的組織結構圖在實施中還是比較合理的。但專案組長要承擔很多的管理、協調工作，在實際中還有一些開發工作，比別人辛苦。但作為唯一的全職工作人員，這一點還是可以接受的。

【第一次迭代】
到了假期這個開源專案的黃金時期，我們的專案進展恢復正常。
專案開發從4月28日啟動，一共16個星期，第一階段由於涉及五一長期、期末考試等較多不利因素，我們安排了10個星期的時間。實際第一階段在第11周結束，比計劃推遲了一週。從開發的質量來看，基本上達到了要求。

【第二次迭代】
經過了第一次跌代，第二次迭代階段則要順手的多。
專案第二階段從第12周開始，計劃第16周結束。由於在第11周很多開發成員為了趕進度，工作相當辛苦，另外考慮到我們是開源專案，我做了一個相當大

膽的決定：在第12周放假一週！
第二階段實際上從第13周開始。最後的開發也延期了一週，在第17周結束。後期由於遇到了一些技術問題，對部分功能作了裁剪，但整個系統的主題功能已經完成，可以說是取得了相當不錯的戰績，基本完成了預期的目標，取得了成功！

【專案回顧】
　　成功完成了專案，自然要回顧一下。
【專案大事記】
* 專案2004年4月5日開始第一次正式的制定計劃，算是正式啟動；
* 4月10日：第一次招募，採用類似宣講會的形式；
* 在第一次招募結束後，在4月15日進行了為期十天的網路招募；
* 4月27日：確定了成員名單：核心開發人員5人，美工1人，專案顧問2人，法律顧問1人；
* 4月28日：釋出專案網站
* 4月28日：專案組召開第一次大會，以後基本每週進行一次例會；
* 5月16日：釋出第一個模組
* 5月25日：第一次嘗試正式的網路會議，感覺效果是“可以接受”
* 5月25日至6月4日，多數開發人員複習考試，專案進入低潮
* 6月5日：假期開發計劃開始實施，專案進度恢復
* 7月12日：專案的第一次迭代在一週結束
* 7月13日至7月19日：多數成員休息一週
* 7月29日：專案的第二階段啟動
* 8月23日：整個專案在延期一週的情況下成功完成
【基本資料】
專案從4月5日開始籌備，到8月23日完成，共計141天。如果從4月28日第一次專案組會議開始計算，則共歷時118天，約17周。
專案成員最多時達到16人，其中開發人員13人，其他為顧問和美工。
實際開發的系統的總檔案數為239個，總行數39583行，類的個數為135個，類成員/方法數為1171個。
【風險回顧】
專案基本取得了成功，讓我們來回顧一下專案初始時提到的各個風險，看看解決的如何。
首先看工作時間，由於是開源專案，成員的工作時間得不到保障，這是我們預期的，但實際的情況比我們預想的還要糟很多，下表是成員的工作時間統計情況，橫軸是從專案啟動到結束的時間，小格是天，大格是周；縱軸是各個成員，圖中深色的部分表示成員完全不能參與工作的時間段。
（圖 傳不上來啊，看不到，不過可以說資料是，整個專案中24.8%的“人天”是大家完全不能工作的）從圖中可以看出，在整個開發過程中，存在著大量的成員不能參與工作的時間段，具體的原因主要有五一長假、期末複習、假期回家、外出等。這個似乎是開源專案不可避免的問題，在做計劃時需要特別注意。
工作熱情也是專案啟動時擔心的一個風險，從事後回顧來看，這個風險並沒有發生，大家的熱情都很高，沒有發現誰最後對專案缺乏熱情而離去。
再來談“開發人員的水平”，從我們這次招募的人員來看，總的說來人員的技術水平屬於中等偏上，對搜尋引擎的技術瞭解則普遍不多，基本沒有什麼招到技術高手，不過這一點絲毫不影響我們專案整體的進展。
  最後再來談談另一個風險——“交流”，這個確實是最大的風險。因為開發成員都是志願者，大家分佈在不同的實驗室，甚至不同的省市，交流起來比較麻煩。儘管我們使用了儘可能多的交流方式，但依然感覺到交流的明顯不足。我們在第一次跌代結束後做過一個調查，其中一個問題就是“你認為第一階段中出現最大問題是什麼？”從大家的回答的結果來看，交流不足是最大的問題。我們在第二階段有意識加強了交流。主要透過：管理上制定一些制度，迫使大家必須交流；提供更多的交流途徑（比如發現論壇大家用的不多就啟用了郵件列表），大家有意識加強交流等。從收效上來看確實有一定效果，但依然感到交流不足。

【商業模式】
經歷了這四個月，對開源專案有了較多的認識，但其實開源專案還有很多魅力是我們沒有感受、接觸到的，其中最重要的一點就是商業。很多人誤以為開源就是免費，其實這是一個相當錯誤的認識。開源和商業並不是衝突的。
　　軟體作為一個以人的智慧結晶為主要成本的數字產物，主要透過銷售將原始碼編譯、打包、包裝過的軟體包獲得商業價值。程式原始碼作為軟體的基礎材料，

具有可察看、可複製、可複用等特點。開放原始碼是使軟體開發者散失了獲得勞動回報的主要途徑，因此程式設計師必須在這種新的開發模式下透過其他商業模式獲得回報。
　　從上世紀八十年代開始，從事和關心開源運動的人們就不斷探索能夠為開源程式設計師獲取回報的開源商業模式。隨著時間的推移，開源運動在發展過程中逐步形成了一些較為可行的商業模式，這些商業模式主要包括：
* 雙授權
典型例項：mysql
　　透過針對個人/商用進行不同授權或不同版本（基本版本、 企業版本）進行不同授權。
* 諮詢顧問
典型例項：jboss
　　提供技術文件、培訓服務、諮詢服務、系統規劃實施等技術服務；
* 應用服務
提供基於開源軟體的網路應用服務（ASP）；
* 硬體捆綁
捆綁贊助商或開源軟體開發商硬體，如Widget Frosting：一個主要生產硬體的公司（其中的某一部分軟體不做為主要利潤來源）會選擇開源軟體來提供更好的產品，比如 IBM 塔式計算機就預裝了 Turbolinux 作業系統；
* 賣附屬品
這個聽起來有點誇張，但確實也是一條路。可以出售的商品包括書籍、T 恤衫、咖啡杯，以及 Linux 企鵝玩具……
* 提供服務
雖然送出產品，但是賣的是品牌，賣的是服務，Redhat 一直在這樣做；
* 市場策略
透過提供開源軟體使自己佔有市場，Netscape 曾經因此決定公佈 Navigator 的原始碼。
　 　如果想更深入的瞭解，可以參考在這一方面的一些經典文章，由國際自由軟體知名人士Eric Raymond 在1999年夏天發表的一篇重要著作 《魔法大鍋爐》(TheMagic Cauldron)大概是其中最為重要的一篇。這篇文章分析了開放原始碼現象不斷髮展的經濟基礎。首先推翻了一些流行的關於程式開發資金和軟體價格結構的神話。給出了一個關於開放原始碼協作穩定性的搏弈論分析。給出了九種開放原始碼開發的可發展模型，其中兩種是不盈利的，七種是盈利的。接著發展了一種定性的理論，說明什麼時候封閉程式碼在經濟上是合理的。然後考察了當前市場上發明的幾種新穎的開放原始碼開發的盈利方法學，包括贊助系統和任務市場的引入。最後做出了結論，試著對將來做了一些預測。
開源的危機
開源的發展也並非一帆風順，我們也經常能夠聽到很多不利的報導：
　　RedHatLinux將不再面向普通的個人使用者出售（eNet矽谷動力，2003年11月15日）
　　歐洲軟體專利法有變，開源社群面臨重大打擊（太平洋電腦網，2004年05月15日）
　　Redhat公司高官Chris Sharp跳槽微軟，並說研發開源軟體費錢不討好（zdnet，2004年5月24日）
　　即時像sourceforge這樣的開源軟體集散地，有人專門研究過其上的專案。其實絕大部分開發專案也只是開發者個人在工作，少有人問津，真正推出穩定的1.0版的軟體只佔很少的比例。
　　雖然媒體對開源，對linux的報導總的說來是褒多貶少，但我們也不能忽視多數的開源軟體還並不夠好這樣一個事實。
結語
　　經過四個月的嘗試，作者對開源算是有了一些切身的感受和理解，儘管它還不成熟，還面臨一些問題，但我們有理由相信：
　　“開放原始碼不僅僅只是軟體原始碼而已，它們也悠關自由、分享和社群精神；創作、美和駭客所謂的‘有趣’。它們也悠關人人心中的密碼，是我們心中至善的根源，反抗至惡，永世長存。”——匿名