《大教堂與集市》：軟體工程的另一種選擇

說起軟體工程這檔事，我總有種不知從何說起的感覺。作為計算機專業的學生，早年都學過一門叫做軟體工程的課，背下來一些流水線式的專案開發階段，首先是在專案定義階段要做可行性分析、需求分析這些事，再來進入到開發階段要做概要設計、詳細設計、設計實現等步驟，最後是維護階段的執行與維護。彷彿軟體開發就像《摩登時代》裡的工廠流水線，分工明確。井然有序。目的是讓程式設計師成為流水線上的工人，使他們成為生產機器中的一個螺絲釘，無需創意，無需個性，只要夠熟練就行。很多大型企業的開發專案也確實是按照這個路數走的，很多程式設計師被戲稱【碼農】也正是這個原因。

但是，等我工作了若干年之後再來看這套工程管理模型，感覺這基本上就是個【計劃經濟】。首先，絕大部分軟體在開發初期根本不會有那麼多人蔘與，通常是兩三個人要做所有的事情。分那麼多階段，那麼多工序是沒有意義的。再來，就算是有了一定規模的公司，他們會讓很多人蔘與一個專案，往往都是為了維護已有的軟體，程式設計師的主要任務是維護該軟體的版本，並在此基礎上開發新的版本，在這種情況下，他們其實已經有了現成的開發框架，這些人只需要根據特定的需求將該框架填充成具體的專用軟體即可。對於原框架來說，這更像是增加了一個特性分支。例如說，jetbrain是一個通用的IDE框架，而android studio是專用於android開發的IDE，它就是基於jetbrain開發出來的。我們可以將它視為jetbrain的一個分支。這更像是某種意義上的維護工作，它的可行性，需求是一目瞭然的，也不需要概要設計，只需要按照其原有的外掛體系把功能實現即可。然後，bug修復是這個專案的主要工作。所以，如何讓那麼多人一塊有效地，有序地發現bug，報告bug，解決bug成為了主要問題。

上世紀的七十年代和八十年代爆發了兩次所謂的軟體危機。那時候的許多軟體專案都出現了預算超支、釋出時間嚴重拖延、質量管理缺失等問題。大量的專案因此而失敗，問題很嚴重，以致於北約這樣的組織都要開會來討論這個問題。但這些高高在上的人物討論出來的東西就是我們上面所說的軟體工程理論。按照《人月神話》作者布魯克斯的說法，這需要大量的銀彈，人員來支撐。這隻有大型企業，科研機構才能做到。當然對於這些機構來說，這套理論確實能解決一些問題。尤其在網際網路時代來臨之前，這似乎也是我們唯一的選擇。

但大型機構都存在官僚主義的問題，效率低下，隨著時間的推移它們往往都會離人們的實際需求越來越遠，就像是基督教的大教堂，高高在上，定期釋出資訊，內容龐雜而臃腫。對於以創意為主導的中小軟體開發是毫無幫助。於是Linux之父林納斯在獨自開發Linux核心的過程中走出了一條新的道路：開源社群。簡單來說，就是由軟體專案的創始人開發出一個不成熟的初始版本，然後將其丟到一個開發者社群中，讓其在開發者自發性的修改和分享中自然生長。最後，專案創始人會根據其生長情況將自己認可的部分納入到專案的主分支中。這種亂中有序的組織形式讓Linux專案獲得了巨大的成功。給軟體開發的工程實踐提供了另一種選擇。

上世紀九十年代末期，網景公司在與微軟公司的瀏覽器大戰中敗下陣來，面臨著公司的生存危機。他們決定試試開源的方式。《大教堂與集市》這本書就是在這樣的時空環境下寫就的。它的作者埃裡克雷蒙就是網景公司踐行開源運動時所聘請的顧問。這本書為開源運動奠定了理論基礎。他系統闡述了網際網路條件下的協作模式，同行審評的優勢，回答了《人月神話》中提出的銀彈問題，人員管理成本問題。如今，微軟、蘋果這些曾經的大教堂都紛紛進入了開源領域。開源軟體作為軟體工程的另一種組織形式已經毋庸置疑。

最後需要提醒的是，開源運動和理查德斯托曼領導的自由軟體運動不是一回事。開源運動更多的是一種軟體的開發方式，雖然也強調開放原始碼、免費分享的黑客精神。但並不排斥世俗、商業。而自由軟體運動則更像是一種意識形態的運動，非常的理想主義。非常激烈地反對商業化，有點烏托邦化。這客觀上其實給原始碼的分享帶來了不少的阻力。