# Chapter?3.?技術基礎設施 自由軟件項目依賴于選擇性捕獲和信息集成的技術。對這些技術的使用越是熟練，并說服別人去使用這些技術，你的項目就越成功。隨著項目的成長，這一點愈發正確。好的信息管理系統應該能夠防止開源項目在布魯克法則的重壓下崩塌[[12](#)]，也就是說向一個已經延期的項目增加人力，只能使項目延期更多。佛雷德·布魯克觀察到，項目的復雜性同參與人員數量的*平方*成正比。當項目中只有少數幾個人時，大家可以容易的互相交談，但當有上百人參與時，不可能讓每個人都能知道別人正在做什么。如果說優秀的自由軟件項目的管理是讓每個人都感覺是在同一個屋子里共同工作，很明顯問題在于：當在一間擁擠的房間內，在同一時刻每個人都想發出聲音，會發生什么？ 這不是一個新問題。在現實中的擁擠房間中，解決方案是*會議程序*：我們需要正式的指導規則：包括如何在一個大型團隊中進行即時的討論，如何保護重要的異議不會在一片“我也是”的回復中淹沒，如何形成小組委員會，如何識別出何時作出決定等等。會議程序的一個重要組成部分是指明團隊如何同它的信息管理系統互動。有些評論“為了被記錄”而存在的，有些則不是。記錄本身經常是被直接處理的，不能根據字面意義去理解，而是代表了團隊已經確立達成*共識*。記錄并非一成不變，為不同的目的會有不同的形式。它可以包括個人會議記錄、每次會議的完整記錄、摘要、議程及其注解、委員會報告，來自未出席通信者的報告，活動項目列表等等。 因為互聯網并不是一個真實的房間，所以我們也無須擔心去復印諸如讓部分人在別人講話時保持安靜之類的議會程序。但當它和信息管理技術接合時，一個運作良好的開源項目就會是打了興奮劑的會議程序。由于開源項目中的交流都是通過書寫方式完成的，由此發展出了復雜的系統：為了恰當導向和標記數據；為了避免會造成誤解的重復；為了儲存和檢索數據；為了糾正錯誤和廢棄的信息；以及為了在發現不相關信息的新關系時進行關聯。開源項目中的活躍參與者已經將掌握了其中的很多技術，并且經常為了確保信息被正確的導向而進行復雜的手工任務。但是所有的努力都是依賴于復雜的軟件支持。交流媒體應該盡可能地依靠自身完成發送、標簽和記錄工作，應該確保人盡可能方便地得到這些信息。當然在實際中，在整個過程中的很多方面還是需要人的干預，并且重要之處在于軟件使得這種干預也是方便的。但總得來說，如果人能確保首次進入系統時信息的導向和標簽都是正確的，軟件應該被配置成可以充分利用這些元數據。 此章中的建議都是非常務實的，都是基于明確的軟件和使用模式的經驗。但這里不僅僅是教授實用的技術。而是通過許多小范例來演示一種總體態度，這種態度可以最大程度的促進你項目中的好的信息管理。這種態度包含了技術技巧同人力技巧的結合。并且技術技巧是關鍵，因為當新的需求出現時，信息管理軟件總需要配置，以及一定量的持續維護和調整（例如，關于如何處理項目成長的討論參加本章后面的[the section called “Bug跟蹤的預過濾”](# "Bug跟蹤的預過濾")）。人力技巧也是不可或缺的，因為人類社區也需要維護：如何利用這些工具的優勢有時候不是立刻就很明顯，在有些項目案例中甚至有沖突的習慣（例如，參見[the section called “郵件列表”](# "郵件列表")中的關于在外發的郵件列表通告中設置`Reply-to`頭的討論）。應該鼓勵項目相關的每一個人在正確的時間、正確的地點盡自己的職責來保持項目信息組織的良好。貢獻者參與的程度越深，就越能預期她能學習更復雜和專業的技術。 信息管理沒有現成的解決方案。有著眾多的不確定因素。你可能好不容易才把所有事情都按照自己的意愿完成配置，并且社區的大多數人參與進來，但隨著項目的成長讓某些實踐不能擴展。或者本來你的項目正在穩步發展，技術基礎架構也能使開發者和用戶的社區關系融洽，但突然某些人出現，發明了一個全新的信息管理服務，很快新來的會質問為何你的項目不用它—例如很多在維基（參見[http://en.wikipedia.org/wiki/Wiki](http://en.wikipedia.org/wiki/Wiki)）發明之前建立的自由軟件項目就正面臨這一問題。很多問題需要決斷，比如權衡生產信息的方便性還是消費信息的方便性，或者權衡花在配置信息管理軟件上的時間與其為項目帶來的益處。 小心過度自動化的誘惑，請自動化那些真正需要人們關注的東西。技術基礎架構是重要的，但推動一個自由軟件項目運轉的是參與的人的意愿—用智慧的方式表達的意愿—通過人的參與。技術基礎架構只是為人門達到這個目標提供便利。