說起軟件工程這檔事，我總有種不知從何說起的感覺。作為計算機專業的學生，早年都學過一門叫做軟件工程的課，背下來一些流水線式的項目開發階段，首先是在項目定義階段要做可行性分析、需求分析這些事，再來進入到開發階段要做概要設計、詳細設計、設計實現等步驟，最后是維護階段的運行與維護。仿佛軟件開發就像《摩登時代》里的工廠流水線，分工明確。井然有序。目的是讓程序員成為流水線上的工人，使他們成為生產機器中的一個螺絲釘，無需創意，無需個性，只要夠熟練就行。很多大型企業的開發項目也確實是按照這個路數走的，很多程序員被戲稱【碼農】也正是這個原因。
但是，等我工作了若干年之后再來看這套工程管理模型，感覺這基本上就是個【計劃經濟】。首先，絕大部分軟件在開發初期根本不會有那么多人參與，通常是兩三個人要做所有的事情。分那么多階段，那么多工序是沒有意義的。再來，就算是有了一定規模的公司，他們會讓很多人參與一個項目，往往都是為了維護已有的軟件，程序員的主要任務是維護該軟件的版本，并在此基礎上開發新的版本，在這種情況下，他們其實已經有了現成的開發框架，這些人只需要根據特定的需求將該框架填充成具體的專用軟件即可。對于原框架來說，這更像是增加了一個特性分支。例如說，jetbrain是一個通用的IDE框架，而android studio是專用于android開發的IDE，它就是基于jetbrain開發出來的。我們可以將它視為jetbrain的一個分支。這更像是某種意義上的維護工作，它的可行性，需求是一目了然的，也不需要概要設計，只需要按照其原有的插件體系把功能實現即可。然后，bug修復是這個項目的主要工作。所以，如何讓那么多人一塊有效地，有序地發現bug，報告bug，解決bug成為了主要問題。
上世紀的七十年代和八十年代爆發了兩次所謂的軟件危機。那時候的許多軟件項目都出現了預算超支、發布時間嚴重拖延、質量管理缺失等問題。大量的項目因此而失敗，問題很嚴重，以致于北約這樣的組織都要開會來討論這個問題。但這些高高在上的人物討論出來的東西就是我們上面所說的軟件工程理論。按照《人月神話》作者布魯克斯的說法，這需要大量的銀彈，人員來支撐。這只有大型企業，科研機構才能做到。當然對于這些機構來說，這套理論確實能解決一些問題。尤其在互聯網時代來臨之前，這似乎也是我們唯一的選擇。
但大型機構都存在官僚主義的問題，效率低下，隨著時間的推移它們往往都會離人們的實際需求越來越遠，就像是基督教的大教堂，高高在上，定期發布信息，內容龐雜而臃腫。對于以創意為主導的中小軟件開發是毫無幫助。于是Linux之父林納斯在獨自開發Linux內核的過程中走出了一條新的道路：開源社區。簡單來說，就是由軟件項目的創始人開發出一個不成熟的初始版本，然后將其丟到一個開發者社區中，讓其在開發者自發性的修改和分享中自然生長。最后，項目創始人會根據其生長情況將自己認可的部分納入到項目的主分支中。這種亂中有序的組織形式讓Linux項目獲得了巨大的成功。給軟件開發的工程實踐提供了另一種選擇。
上世紀九十年代末期，網景公司在與微軟公司的瀏覽器大戰中敗下陣來，面臨著公司的生存危機。他們決定試試開源的方式。《大教堂與集市》這本書就是在這樣的時空環境下寫就的。它的作者埃里克雷蒙就是網景公司踐行開源運動時所聘請的顧問。這本書為開源運動奠定了理論基礎。他系統闡述了互聯網條件下的協作模式，同行審評的優勢，回答了《人月神話》中提出的銀彈問題，人員管理成本問題。如今，微軟、蘋果這些曾經的大教堂都紛紛進入了開源領域。開源軟件作為軟件工程的另一種組織形式已經毋庸置疑。
最后需要提醒的是，開源運動和理查德斯托曼領導的自由軟件運動不是一回事。開源運動更多的是一種軟件的開發方式，雖然也強調開放源碼、免費分享的黑客精神。但并不排斥世俗、商業。而自由軟件運動則更像是一種意識形態的運動，非常的理想主義。非常激烈地反對商業化，有點烏托邦化。這客觀上其實給源代碼的分享帶來了不少的阻力。
