《大教堂與市集》（the cathedral and the bazaar: musings on linux and open source by an accidental revolutionary）一書中提到了軟工工程的兩種開發模式，即大教堂模式和市集模式。作者認為「given enough eyeballs, all bugs are shallow」，也就是支援市集模式。
我沒有讀過這篇文章，只是從維基百科上了稍稍了解了這本書的內容。從其觀點來看，我認為，作者寫這篇文章，是鑑於當時的自由軟體開發的現狀。他不滿於當時開發軟體的低效率，而且，他認為，低效率的原因在於除錯階段花費了大量的時間。由此，他把開源軟體的開發模式分為兩種，一種是大教堂模式，原始碼公開，但是開發過程有乙個團體控制；一種是市集模式，同源原始碼公開，且原始碼放在網際網路上供人閱覽，並可以貢獻**，進行開發。並且提倡市集模式，認為在足夠的人的檢視之下，bug
將無處藏身。
這篇文章的影響是巨大的。目前，從開源軟體的繁榮課件一斑。不過，這並不意味著市集模式是完美的。poul-henning kamp的文章generation lost in the bazaar（中文版《有人負責，才有質量：寫給在集市中迷失的一代》），就是對於市集模式的批判。這篇文章從目前freebsd
的雜亂無章的現狀入手，認為正式集市模式造成了這一切。
kamp
認為，作為軟體，所謂質量，只有在某人對它負責時才有意義，而這個「某人」
只能是乙個人，不能是幾個人
——二重奏除外。而目前的市集模式，沒有乙個人對某個東西負責，或者說所有人都對其負責，就意味著沒有人負責。這就造成了現如今的freebsd系統中眾多的軟體沒有規則的相互依賴，且眾多的軟體功能相似，沒有完成軟體工程一貫追求的**復用。
在我來看，市集模式既然能為全世界所接受，必有其優點所在。所謂「眾人拾柴火焰高」，當然軟工工程不能模擬於「拾柴」，不過道理確實是這個道理。而後來kamp
的文章，則點明了其缺點所在——人多反而礙事。
其實，以我目前的觀點，不論是市集模式還是大教堂模式，都有其優缺點所在（這在上文中已經可以看出），關鍵是找到其適用的場景。這個觀點雖然中庸，不過確實是實話。我以為，大教堂模式，適用於小的專案，或者是團隊中有乙個技術大牛帶領，不需要過多的人來指點。而市集模式，則是那種涉及的方面比較廣泛的專案，且不論如何，應該有乙個幾個人的團體對於專案的整體走向、**有絕對的控制力，否則，會造成kamp
所說的那種混亂局面。
我們當前的專案（學霸系統的ui之使用者管理部分），可以說是類似於大教堂模式。之所以說，類似，是我們的原始碼並非在網際網路上公開的，只是相像而已。一來因為專案比較小，如果非要應用市集模式，可能會有意見無法統一，浪費資源的問題。此外，除了本組的人外，也並沒有人其他的一些人關注這個專案，不具備市集模式的要求，no enough ebyballs，bugs will not shallow。
題外：在讀這些文章的時候，總是會有想睡覺的衝動。我覺得原因主要是兩個，一是閱讀英文吃力，往往讀了半天都讀不進腦子；二是關於軟工工程的文章並不是那麼的吸引人，既無**的引人入勝，亦無技術書籍的技術提公升快感。如何解？
大教堂和市集
linux 的發展史促生了一些關於軟體工程的驚人理論。我有意的在乙個成功的開源專案 fetchmail 中測試了這些理論，並在此加以剖析。這裡討論了兩種根本上不同的開發 模式 大多數商業專案使用的 大教堂 模式和 linux 世界 的 市集 模式。我們將看到，這兩種模式源於對軟體除錯工作的本質的兩種...
讀 Eric S Raymond 大教堂與市集
你常常在第一次實現乙個解決方案之後才能理解問題所在，第二次你也許才足夠清楚怎樣做好它，因此如果你想做好，準備好推翻重來至少一次。我有一句相似的話 第一次購買總會失敗，所以不要指望第一次購買一種東西時買得讓自己滿意。我有乙個發生在自己身上的聯想 當我狀態好時 當我有正確的態度 我會對所有事情感興趣 相...
讀 Eric S Raymond 大教堂與市集
你常常在第一次實現乙個解決方案之後才能理解問題所在，第二次你也許才足夠清楚怎樣做好它，因此如果你想做好，準備好推翻重來至少一次。我有一句相似的話 第一次購買總會失敗，所以不要指望第一次購買一種東西時買得讓自己滿意。我有乙個發生在自己身上的聯想 當我狀態好時 當我有正確的態度 我會對所有事情感興趣 相...