XOOPS發布有期：誰說開源不計劃？

█ 文/姜太文 高瑾

1.寫在前面

近年來，開源軟件在中文用戶中日漸流行。尤其是今年，隨著微軟黑屏時代的降臨，很多用戶終于拋棄堅守多年的盜版方針，開始發現和探索開源軟件。雖然開源進入中國已經相當長時間，可是在普通用戶甚至 IT 業界人士中，仍然存在很多認知誤區。這一點是所有參加開源項目的人們應該注意并努力改變的。

這些誤解中，關鍵的錯誤是對開源項目管理的理解。比如，很多人以為，一個開源項目就像從長江源頭開始漂流的一葉輕舟，興之所至，漂到哪里算哪里，停留和出發都僅僅是偶然的。這種誤解造成的嚴重后果就是對開源軟件某種程度的懷疑。確實，一群人毫無計劃地聚在一起、縱橫捭闔地做出來的東西，聽起來雖然瀟灑，可是恐怕不夠嚴謹細致。

其實，計劃對于開源項目來說，至關重要。可以說，開源項目如果沒有計劃，必定失敗。

2.為什么認為計劃是開源項目最重要的？

開源項目與公司體制下的商業項目相比，在開發管理模式上缺乏強制性的組織管理機制，從而決定了開源項目計劃的重要性。開源項目一般都是由來自不同地方的參與者在志愿方式的基礎上進行遠程管理協調和開發測試，在開發過程中缺乏面對面及時有效的交流溝通。開源項目參與者的工作需要依靠統一的計劃保證進度的統一性。如果沒有靈活完善的項目計劃，基于松散組織的開源項目的開發必將會陷入各自為政的混亂狀態，無法保障項目的健康發展。因此，如何設計并制定靈活有效的計劃對于開源項目特別是有多人異地參與的較大規模開源項目來說是至關重要的，也是隨著開源項目的發展壯大而不斷更新的研究課題。

3.開源產品經理與其他產品經理的不同點在哪？

在商業公司或團隊中，產品開發計劃由產品經理負責制定并監督執行。在開源項目中，不存在“產品經理”這個職位，其功能職責一般由相關團隊負責人共同完成。

商業團隊的產品經理根據公司一定時期的發展策略和相關規劃設計產品功能并制定開發計劃，并依此配備相關人力資源，保證產品開發的進度和質量。而開源項目的項目開發計劃則主要根據主開發和架構師的前瞻規劃并參考來自用戶社區的需求制定一個時間段的項目設計和開發計劃。同時考慮到開源項目參與者組織模式和開發模式的特殊性，開源項目的計劃制定更側重于功能計劃，難以對時間進度作強制規定。同時無論功能計劃還是時間進度規劃都要根據可用開發資源即開發者的時間可用性和不斷變更的社區功能需求作及時更新調整。

4.具體來說，開源項目的計劃一般應該怎么做？

一個成功的開源項目是一般由兩部分組成，開源軟件本身和由開源軟件開發者和用戶組成的社區。

具體來說，主開發員和架構師制定項目的整體開發路線圖，并制定任務分解方案；核心程序員按開發路線圖制定并分解核心功能開發計劃；普通參與者可根據細分的計劃方案制定個人開發計劃，與系統開發步驟保持一致。社區管理團隊制定社區管理方案和年度活動組織計劃，每個功能團隊根據社區年度計劃制定自己團隊的工作計劃，與相關團隊協同開展工作。

5.作為Sourceforge十佳項目的開源項目，門戶管理系統XOOPS是怎么做的？

XOOPS是世界上流行的一個開源門戶系統，產生于2000年底，至今已有八年的開發歷史。XOOPS 系統分核心層和模塊兩部分，核心團隊負責核心層功能的設計和開發，功能模塊由第三方開發者或公司提供。

核心功能如何定義？XOOPS第一個版本的故事

與其他大部分開源項目一樣，XOOPS 是由一群有共同開發興趣的開源開發者和愛好者共同發起的，在phpnuke基礎上對原系統做了重寫，經過大約一年的設計開發在2001年底發布XOOPS第一個公開版本。

XOOPS社區建立的TODO list

XOOPS是一個純社區支持的開源項目，無論是開發者還是社區管理者都是由開源參與者自愿組織開展工作。自項目成立伊始，就依托于世界上最大的開源項目管理平臺 Sourceforge，采用 Sourceforge提供的項目管理工具和自己的社區網站對項目進行規劃管理。普通用戶在論壇或文章評論里對XOOPS核心或模塊提出自己的改進建議和功能需求，由社區志愿者協助整理到Sourceforge 的功能需求列表。考慮到普通用戶的使用習慣，在社區網站的Wiki里也建立相應的功能列表，便于用戶查閱修改。在XOOPS各地分語言支持站也建立相應機制，由各支持站大使負責向總站匯總功能需求。核心開發團隊則根據XOOPS核心開發計劃和社區功能需求定期制定發布XOOPS開發路線圖和詳細的TODO list，并定期報告TODO list完成狀況。

如何吸納有經驗的代碼貢獻者以及他們在項目中的角色

XOOPS的代碼管理早期采用Sourceforge提供的CVS，后來改用SVN系統。XOOPS的核心代碼由核心開發團隊維護。主開發負責整體架構設計和任務劃分，每個核心開發員根據自己的特長和時間負責相應部分的代碼開發和接受并驗證其他開發者提供的代碼。對于長期提供核心代碼的開發者，經過一定時間的培訓考核后賦予相應的代碼提交和維護權限，逐步成為核心開發員，并幫助其他開發員參與核心代碼的開發。同其他開源項目一樣，XOOPS在某些特定時間段可能會存在兩個甚至更多開發版本同時存在。這種情況下，主開發員會指定某個核心開發員總體負責相應版本的開發和版本發布。

在這種自愿參與的機制下，循環往復，維持了XOOPS核心團隊的穩定和不斷成長。

版本升級的功能定義及裁剪

XOOPS 的發展軌跡是由大的版本和不同水平細分的小版本發布構成的。到目前為止，最新公開穩定版是2.3，內部開發版是3.0。

大的開發版本主要涉及到架構的演進和模塊開發重要接口模式的調整。這類新版本的設計規劃一般由主開發員支持，由核心團隊成員共同討論制定，并結合社區反饋意見作相應開發進度調整。該類版本的功能和特征主要由主開發員和核心開發團隊制定并發布給社區。一個大版本的發布一般要分別經歷多個Alpha、Beta和RC發布，最后發布最終版，開發周期一般在一年甚至更長。

中間版本主要在維持當前架構和模塊開發接口的前提下，對功能和性能進行改進，并根據情況增加調整新功能。這類功能調整和增減大部分來自社區的需求和反饋。發布一般要經過一個或多個Alpha/Beta版，然后進入RC版。在RC版和最終版之間維持至少兩周的測試反饋期，以保證社區測試的充分性。每個版本開發周期一般是三個月或半年。

小版本主要是bug修正，一般不涉及功能的調整。每個完整發布一般由一個或多個 RC 版和最終版構成。RC 和最終版間隔遵從兩周的時間規則。但是在出現安全問題的情況下，核心開發團隊會盡快發布補丁，不再遵從時間間隔規則。

計劃管理bug和日常工作

與需求管理類似，XOOPS團隊采用Sourceforge的Bug Tracker和社區網站的論壇對管理 bug 報告和修復。用戶在論壇里報告XOOPS的問題，由社區志愿者協助整理到Sourceforge的Bug列表。核心開發人員會及時分析 Bug List，在 SVN 提交修正并在 Bug Tracker 里更新 bug 狀態。在下個版本發布時對相關 bug 做必要的說明解釋。

XOOPS開發團隊還提供了安全問題報告機制，主開發員負責安全問題的分析，并及時作出修正，必要時會采用臨時應急處理措施。

社區維護以及反饋的規劃怎么做？

XOOPS 組織由項目負責人即主開發員和社區負責人領導下的數個功能團隊構成，分別負責項目開發和社區組織管理的相關工作。團隊成員根據用戶意愿和精力不定期調整。

社區維護團隊的工作主要以論壇維護的方式體現，志愿團隊在社區幫助新用戶了解學習使用XOOPS系統，并整理用戶報告的問題和提出的功能需求，協助開發團隊做好開發及測試規劃。

6.無冕之王的開源產品經理小結

開源項目“產品經理”對開源項目的成敗是至關重要的，是一個開源項目從項目策劃到開發及應用順利進行的保障。█