Emacs、Python和Qt項目有一套對付這個問題的好辦法，就是讓目錄名中包含版本號。這里有Qt庫安裝后的目錄結構的例子（${ver}是代表版本號的變量）：<p>/usr/lib/qt<br>/usr/lib/qt-${ver}<br>/usr/lib/qt-${ver}/bin # moc程序所在目錄<br>/usr/lib/qt-${ver}/lib # .so共享庫所在目錄<br>/usr/lib/qt-${ver}/include # 頭文件所在目錄<p><br>這樣組織目錄結構可以讓多個不同版本的檔案共存。客戶程序可以根據需要選用具有特定版本號的庫，因此為了不讓這些接口影響客戶程序，還是需要付出一些小小代價（制定版本號）的。<p>提供RPM包<br>安裝可執行文件包（二進制包）的事實標準就是使用RedHat包管理器將可執行文件打包成 rpm 包。許多流行的GNU/Linux發行版都是這么做的，同時也有許多發行版雖然主要不是rpm包格式但是也支持rpm包（除了Debian和 Slackware以外，而且Debian還支持rpm的安裝）。<p><br>因此一個好的項目除了有tar包的源代碼以外，最好也提供直接可安裝的rpm 包的下載。<p>如果您能把您的源代碼tar包和Makefile文件中用于生成rpm包的相關信息寫入rpm的spec文件中就再好不過了。spec文件是有著&quot;.spec&quot;后綴的文件，這就是帶 -t 選項的 rpm 命令如何在 tar 包中尋找它的方法。<p>還有一個要點是，您可以用一個腳本程序自動的從Makefile或version.h 文件中找出版本號，并用這個版本號來生成您的spec文件。<p>注：如果您還打算提供源碼的rpm包，最好用BuildRoot工具來將程序編譯到/tmp或者/var/tmp目錄中。如果不這么做，在安裝過程中執行 make install命令時就會直接將那些源程序直接安裝到最終的目錄位置下。這樣就會導致即使在發生文件覆蓋沖突，或者您本意并不想裝那個包的時候，安裝動作依然被執行。因此安裝完成后，文件是被裝到了系統中，但是系統的RPM數據庫卻并沒有記錄這些信息。這種愚蠢的SRPM安裝動作是非常危險的，理應避免。<p><p><center><A HREF="#Content">[目錄]</A></center><hr><br><A NAME="I646" ID="I646"></A><center><b><font size=+2>好的文檔編寫慣例</font></b></center><br>6.好的文檔編寫慣例<p>最重要的文檔編寫慣例就是多寫一些！很多程序員都輕視這些事情。但是下面兩個理由可以讓您明白您必須去做文檔工作：<p>文檔可以指導您的實踐。 寫文檔的最佳時機是在您一行代碼還沒有編寫時就應該開始，此時您需要想想您打算做點什么。您會發現用自然語言思考程序應該完成什么功能可以促使您從更高的層次考慮軟件是什么樣以及她該如何工作。這種思考可以節省許多以后的時間。<p>文檔是代碼的招牌。 許多程序員為他們的程序只提供了少的可憐、內容匱乏、語言差勁的蹩腳文檔，這實際上等于向其他人展示說，寫這個文檔的程序員對潛在用戶的需求也同樣會粗心大意、馬馬虎虎。相反，好的文檔則會向其他人傳達出文檔背后的程序員是非常聰明、專業的人。如果有一些類似的項目正在與您的競爭，一定要寫出好的文檔來，至少不能讓潛在用戶瞥了兩眼您的文檔后就立即否定您的項目。<p>這份文檔雖然著眼于文檔編寫實踐，但并不是一份專門介紹如何寫出好文檔的詳細講義。因此下面我們將重點介紹文檔格式和編寫工具的選取。<p>雖然開源社區長期的傳統就是擁有強大的文檔格式化工具，但是為數眾多的文檔格式仍然使得整個系統的文檔支離破碎，很難用一種統一的方法全局檢索和閱讀文檔。下面我們將先介紹各種流行的文檔格式的用途以及他們的優劣，然后再給出一些編寫好文檔的建議。<p>現行的一些好的做法<br>這里將列出一些在開源軟件開發群體中流行的一些文檔格式。當我們文中提到“展示”標記，就是指那些控制文檔顯示的標記（如字體）。當我們提到“結構”標記，就是指那些描述文檔結構的標記（如段落、強調標記）。當我們提到“索引化”，則是指從眾多文檔中萃取出可檢索的關鍵字集合的過程，“索引化”可以幫助用戶在整個文檔中可靠的找出自己感興趣的資料。<p><br>man手冊頁<br>這是最普通的文檔格式，來源于UNIX系統，是一種原始的“展示”標記格式。 man(1)命令提供了頁顯示和原始的搜索手段。這種格式不支持圖象、超鏈接和“索引化”功能。不過這種格式轉化成Postscript進行打印的效果還不錯，就是轉成HTML格式不太方便（主要是純文本）。man 的相關工具在各個Linux 系統中幾乎都有。<p>手冊頁格式做為命令用法解釋或者短小的參考文檔還是不錯的，對一個有經驗的用戶這樣做可以非常節省內存。那些有著復雜用戶界面和很多選項的程序會讓系統負載非常重，如果交叉鏈接太多的文檔甚至會讓整個系統不堪重負。（Man手冊格式不支持超文本鏈接）。<p>HTML文檔<br>自從1993－1994年互聯網流行起來后，HTML標記格式開始流行，這種標記格式有一定的結構，也便于“展示”，還可通過網絡瀏覽器瀏覽，對圖象和超級鏈接也有支持。不過自帶的“索引化”功能很有限，因此搜索引擎技術得到了大力的發展。這種格式也可以很好的被打印出來，相關的制作工具數不勝數。<p>HTML標記語言非常靈活，非常適用于各種文檔。實際上她太靈活了，甚至可以展示Man手冊頁格式的信息。不過問題在于她很難自動檢索，因為這種格式中太多的標記被用于描述“展示”信息，而鮮有標記描述文檔的結構。<p>Texinfo文檔<br>Texinfo格式是自由軟件基金會推薦使用的格式。她是在強大的Tex格式引擎上建立的一套宏。擁有許多結構信息和部分表示信息。可以用Emacs瀏覽，或者用專門的info程序閱讀。這個格式支持超級鏈接，但是不支持圖象﹔無論是打印出來還是在線閱讀都可以很好的“索引化”﹔如果您裝了某個 Texinfo格式的文檔，該文檔的信息就被整合到系統的全局目錄表中。這種格式還可以很好的被轉換為Postscript格式和HTML格式，相關工具在大多數 Linux系統中都是預先安裝好的，當然您也可以從自由軟件基金會的網站上下載(http://www.gnu.org)。<p>Texinfo有著很好的設計，非常適合于完全字符編排的書籍和小的在線文檔，但是和HTML格式一樣，她也是一種兩棲格式──既有表示“結構”的標記，又有表示“展示”的標記，“展示”標記給文檔進一步處理帶來了一些麻煩。<p>DocBook格式<br>DocBook是一種強大且精巧的基于SGML（當前XML的前身）的標記格式。和前面幾種文檔結構不同，這個標記格式只包含“結構”信息，而沒有“展示”信息。她可以很好的支持圖片和超級鏈接﹔支持“索引化”﹔很易于轉換成HTML格式和便于打印的Postscript格式（而且隨著工具功能的增強，打印效果還可進一步提高）。該格式的文檔和相關工具可以從DocBook的網站(http://www.docbook.org)下載。<p>DocBook在處理大而復雜的文檔中表現出眾﹔她被特意設計成可以支持各種技術文檔并可以將他們用不同的輸出格式“展示”出來。不過她的回溯功能非常復雜，工具也沒有完全發展成熟（雖然進步很快），入門級的文檔非常少而且常常寫得很混亂。<p>也許未來會有些更好的做法<br>2000年7月，世界一些重要的開放源碼項目開發組（包括GNOME、KDE、自由軟件基金會、Linux文檔項目組、開源首創）在加州Monterey舉行了高級首腦會議。該次會議的重要議題就是試圖建立一套共同的工作慣例和共同的文檔交流格式，以便為自由軟件制作出更豐富、更統一的文檔資源。<p>具體的來說，會議的目標就是要制定一種文檔包的標準，使得當某文檔被裝入系統中后，文檔包就立即被集成到整個系統的搜索數據庫中，系統可以通過某種一致的手段查找、搜索各種文檔。實際上GNOME和KDE組已經開始在朝這個方向努力了，大家都明白這并非是一種標記語言就可以解決的問題，而需要建立一套結構化的系統體系。<p>會議簽署了一個意向文件，清晰的指出一些關鍵的開源項目正在著手或者已經采納使用Docbook格式做為項目文檔的首選格式。<p>與會者最后也決定了采用“Dublin core”元數據格式（一種根據庫管理程序開發的與數字資料索引有關地國際標準）做為文檔搜索的標準，這個標準的細節正在制定中，因此最終DocBook標記中會添加一些信息用于支持嵌入DocBook文檔的Dublin Core元數據。<p>目標是明確的，基于索引標記和Dublin core元數據可以提高DocBook文檔的自動搜索能力，從而使得DocBook的用途如虎添翼。雖然還有一些工作尚未完成，但是它們將會被不斷填充進整個體系中。老的基于描述的標記語言文檔所剩下的日子已經不多了。（本文檔在2000年8月已經有了DocBook格式的版本。）<p>因此新的開源項目應該注意這種動向，如果現在就采用DocBook格式的文檔編寫，這可以幫助他們省去以后將文檔格式轉檔的麻煩。<p><p><center><A HREF="#Content">[目錄]</A></center><hr><br><A NAME="I647" ID="I647"></A><center><b><font size=+2>好的溝通方式</font></b></center><br>7.好的溝通方式<p>如果除了您自己之外沒有人知道您辛苦開發出來的程序，那么您的程序就不會對這個世界帶來太大的用處。因此，在互聯網上充分的展示您的項目可以幫助您獲得用戶的支持，還可以找到志同道合的開發人員的參與。下面是一些常用的與其他人溝通的做法。<p>在c.o.l.a和Freshmeat上公布<br>在comp.os.linux.announce 新聞組對您的項目發布公告。這個新聞組除了有大量的閱讀群外，她也是許多其它站點，比如Freshmeat，公布新消息的地方。<p>在相關主題新聞組中公布<br>在USENET中找到一個與您項目密切相關的討論組，并在那里發布您的項目也是一個極好的方式。需要注意的是只能在與您項目相關的地方公布，并且不要灌水。<p>比如，當您用Perl寫了一個查詢IMAP服務器的程序，您可以在comp.mail.imap 新聞組公布。但如果這個程序并非是一個反映Perl最新技術的例子的話，就沒有必要把這個消息公布在comp.lang.perl新聞組上了。<p>另外，您的帖子中應該包含您的項目網站所在的URL地址。<p>建一個與項目相關的網站<br>如果您想圍繞項目建立一個用戶、開發者的網上社區的話，最好應該建一個網站。一個標準的項目網站一般包括如下內容：<p><br>項目的特點（為何要有這個項目，誰會對此項目感興趣）。<p>下載項目源代碼的地方。<p>指明如何加入項目相關的郵件列表。<p>一個常見問題解答列表。<p>HTML格式的項目文檔。<p>與項目相關或競爭的其他項目或網站的鏈接。<p>有的項目站點甚至還有指向源碼結構樹的匿名訪問鏈接（便于跟蹤項目進展）。<p>維護一個項目相關郵件列表<br>維護一個項目開發專用的郵件列表幾乎是必須的，透過這個郵件列表項目的合作開發者可以互相交流并討論對程序補丁的建議。您最好再建立一個讓其他人及時獲知項目進展狀況的公告郵件列表。<p>比如您的項目名稱為“foo”，那么開發郵件列表就可以命名為 foo-dev 或者 foo-friends，公告郵件列表就可以命名為 foo-announce。<p>在各大主要項目庫站點中發布<br>在過去的幾年中，Metalab集中營(http://www.metalab.unc.edu/pub/Linux)成為了Linux各種軟件集散的最重要的站點。<p>自1999年秋建立以來，SourceForge 也獲得了爆炸性的發展。這個站點并非只是一個簡單的資料與發行版的匯集之處，雖然很多人都認為就是那樣。這個站點更是一個為自由軟件項目提供一整套開發環境的虛擬主機，包括針對項目提供硬盤空間、網絡訪問服務、郵件列表服務、錯誤跟蹤、聊天室、CVS管理等各種服務。<p>還有其他一些重要的網站是：<p>Python站點(http://www.python.org) （針對所有用Python寫的程序）。<p>CPAN(http://www.perl.com/)，綜合Perl資料網。（針對所有用Perl寫的程序）。<p><p><center><A HREF="#Content">[目錄]</A></center><hr><br><A NAME="I648" ID="I648"></A><center><b><font size=+2>好的項目管理經驗</font></b></center><br>8.好的項目管理經驗<p>由于參與者都是志愿加入某一項目的，因此要想組織好一個自由軟件項目的實施必然面臨許多獨特的挑戰。這是一個非常大的話題，在這份HOWTO文檔里還難以說清。幸運的是，許多有價值的論述已經指出了這其中的關鍵問題，相信他們會給您帶來幫助。<p>關于基本開發模式的討論和對“早發布常發布”的集市開發模式的論述請參考《大教堂和集市》一文。<p>關于心理動機、社群習俗和化解各種沖突的討論請參閱《開拓智域》一文。<p>關于開源軟件經濟學基礎和各種商業運作模式的討論請閱讀 《魔法大鍋爐》一文。<p>需要指出的是這些文章并非自由軟件開發的終極論斷，不過他們都是經過深思熟慮后的思想結晶，還沒有其他文章超越了他們的深度（文章的作者非常希望未來某一天有人超越他們）。<p><p><center><A HREF="#Content">[目錄]</A></center><hr><br><A NAME="I649" ID="I649"></A><center><b><font size=+2>自由項目實施</font></b></center><br>×××××××××××××××××××××××××××××××××××××××××××<br>作者：王樂珩<br>歡迎訪問joyfire.net<br>×××××××××××××××××××××××××××××××××××××××××××<p>　　這篇文章分析自由軟件項目的常用實施工具和方法流程，以及已有的成熟建議，但不是從技術角度介紹軟件使用方法（讀者可以在“joyfire linux筆記”的其他部分或者joyfire.net找到有關技術的資料）。本文要討論的更接近法律、文化以及社團傳統。我不會探討常見的自由軟件理念和純粹的哲學問題，這方面已有很多經典作品，例如Eric S. Raymond的五部曲。<br>　　這篇文章是提供一些自由軟件項目實施的經驗和建議，合適的讀者應該是已經對自由軟件熟悉并感興趣，認同自由軟件理念，希望在這中間做點什么的人。換句話說，不是“Why”和“What”，而是“HOW”。<br>　　在航行之前要考慮清楚自己的目標和能力，做好充分的準備，然后，就是勇氣和耐心了。Lucky!<p><center><A HREF="#Content">[目錄]</A></center><hr><br><A NAME="I650" ID="I650"></A><center><b><font size=+2>GNU</font></b></center><br>&nbsp;&nbsp;&nbsp; 在最初，你需要謹慎地考慮和選擇。對自己的項目和打算作出規劃。然后進一步了解法律和文化細節，看看別的項目是怎么做的，確保自己的項目有一個堅實的基礎。<p>1.平臺<p>　　GNU首先是指GNU項目的各種軟件，以及由它們組成的軟件環境或者平臺，例如linux、bash、gcc等等。<p>　　顯然，如果新的自由軟件可以建立在以前的自由軟件的基礎上，或者和眾多其他自由軟件相互支持，那么無疑會增加成功的機會。同時相似的自由軟件的環境也有利于宣傳和改進。當然，沒有必要一定采用哪種環境，但是因為很多系統基本工具本身就不是開源的(open source)，所以會出現問題。例如Windows平臺下的很多編譯工具，API和COM控件，也許是免費的，但是它是專有的，不允許自由修改和二次發布。<p>　　舉個例子，Win32 API是Windows平臺下最基本的API，在一般情況下，它的確是可以無條件使用的。如果你的程序僅僅是應用(Application)，那么沒有問題，你使用的僅僅是Win32 API的“界面”。但是如果你的程序是一個編譯器或者類似的東西，你就必須得到微軟的許可，因為嚴格講，你已經把Win32重新包裝發布了。由于這樣的原因，VC的競爭對手，例如著名的編程工具Delphi，要把Win32 API包裝到自己的類庫，就得支付使用費用，而且無法調用很多Windows操作系統默認的對話框（例如“打開對話框”“存儲對話框”“查詢對話框”），必須在類庫里重新實現一遍，這就是Delphi生成的可執行程序比同類VC的要稍微大幾十K的原因。這是微不足道的損失，但是這種專有形式的阻礙可能會對你的軟件性能產生障礙。<p>　　當然，在MS Windows和其他非自由的平臺下同樣擁有很多優秀的自由軟件。只是這需要你更加小心，避免在技術上或者法律上進入尷尬境地。<p>2.GPL協議<p>　　GNU重要的核心就是GPL協議，它是自由軟件的法律基礎。接受這個慣例，是標明自己open source的立場的最直接方法。這份文件的作者已經為自由軟件體系建立了一套完備邏輯的法律體系，可以使一個自由軟件在保證自己“free”（注意，這個詞是雙關的，即表示自由，又表示免費）的初衷不會被其他人因為私人利益而改變，又可以保護大多數的用戶可以不受限制的充分使用，甚至可以通過保護一種游戲規則保護以發布自由軟件賺錢的軟件商的利益。<p>　　這個協議形成的版權系統(copyleft)和普通的私有軟件版權協議(copyright)是完全不同的，如果你一但在前人的基礎上開發，就必須公開源代碼，否則你就失去了使用前人代碼的資格，這是遞歸的過程．至于對程序收費，GPL沒有禁止，但是公開代碼本身就決定發布者不能把價格定的太高（你的競爭對手可以重新編譯你發布的源代碼然后比你更低價出售，只要它對自己的修改公開源代碼，就不違法）。<p>　　現存的linux或者自由軟件商業模式都是建立在提供服務上的，也就是替企業制作特別的解決方案，或者為硬件廠商開發特殊的版本。例如為手持設備廠家開發嵌入系統，為工業控制設計工控系統，或者為企業提供咨詢服務。這種工作的客戶就要求源代碼的控制權。MS也對自己的大的特殊客戶提供有限的共享代碼服務。但是他們的軟件對企業級用戶限制太多了。<p>　　自由軟件是一種信仰，更是一種商業潮流，是利益而不是其他使IBM等企業強力支持Linux，因為他們本來就不是靠release賺錢，他們的核心都是對用戶的服務。建議閱讀Eric S. Raymond五部曲最后的The Magic Cauldron，生動描述了這種商業模式怎樣占領幾十億美元的IT市場的。<p>　　要說明兩點。首先，不只GPL一種自由軟件發布協議，很多著名的自由軟件，例如Apache、X系統等，都采用自己的獨特的自由軟件發布協議，當然具體條款的約束是不同的，例如X就很松（允許使用者修改源代碼但是不公布，把這變成自己的私有財產），而Apache就比較民主（它的社團通過投票決定下一版本的工作）。其次，不要把自由軟件和盜版聯系起來，自由軟件和私有軟件僅僅是兩種不同法律體系、世界觀和商業模式，Gates和Linus都是值得尊敬的知識英雄（當然，你可以對某人有自己的看法，實際上我也有，但不管怎么說，他的成功不該被貶低，尤其是很多非議夾雜著個人潛意識里的嫉妒）。而盜版，就是剽竊。不管無知之輩如何把盜版和Free相提并論（一般還會加上對MS的種種攻擊），盜版不符合Free精神，就好象把偷竊和共產主義并列一樣滑稽。<p><p><br>