2011年在 Nicole Sullivan舉辦的 Velocity大會上我介紹了第一個CSS代碼質(zhì)量工具 CSS Lint， 我們花費(fèi)之前的兩周瘋狂的編碼， 嘗試著構(gòu)建一個終用戶有用并且易于修改的應(yīng)用. 我們所有人都沒有啟動這樣一個開源項(xiàng)目的經(jīng)驗(yàn)， 因此我們也在這過程中學(xué)到了很多.

　　初期經(jīng)過一段時間的試錯， 項(xiàng)目后進(jìn)入正軌， 現(xiàn)在也時常獲得CSS Lint用戶和CSS Lint貢獻(xiàn)者們的贊許. 其實(shí)在你經(jīng)過思考確定目標(biāo)之后創(chuàng)建一個成功的開源項(xiàng)目并沒有想象的困難.

　　你的目標(biāo)是什么?

　　這一段時間， 好像很多人寫了一代代碼加上一段開源軟件協(xié)議， 再把它發(fā)布到GitHub， 然后說: "我把它開源了". 創(chuàng)建一個開源項(xiàng)目并不僅僅是讓你的代碼可以自由的被訪問獲取. 所以， 在向世界宣稱你開源了那么些除了你自己在空閑時間使用而還沒有其他人使用的東西之前， 停下來問一下你自己， 對于這個項(xiàng)目， 你的目標(biāo)是什么?

　　首要的目標(biāo)通常是: 創(chuàng)建點(diǎn)有用的東西. 對于CSS Lint， 我們的目標(biāo)是為提升CSS 代碼質(zhì)量，創(chuàng)建一個易適應(yīng)各開發(fā)者開發(fā)流程且易擴(kuò)展的工具. 而不論這開發(fā)流程是否是自動化的. 另外， 通過找尋做類似項(xiàng)目的人， 并且想清楚你面向的用戶基數(shù)有多大來確保你所提供的東西是有用的.

　　在那之后， 應(yīng)該被放在第一位的是 決定為什么你要開源這個項(xiàng)目. 僅僅是因?yàn)槟阆敕窒砟阃瓿傻臇|西? 你有打算持續(xù)開發(fā)這些代碼還是僅僅只是把他們?nèi)拥酵饨缭僖膊还? 如果你沒有打算持續(xù)開發(fā)這些代碼， 那么這篇文章剩下的部分不適合你. 確保在你代碼庫中的readme文件里面清晰的聲明了你會持續(xù)開發(fā)這一點(diǎn)以避免找到這個項(xiàng)目的人對此感到困惑.

　　如果你準(zhǔn)備持續(xù)開發(fā)你的代碼， 你考慮過接受別人的貢獻(xiàn)嗎? 如果答案否定， 再一次， 這篇文章不適合你. 如果答案肯定， 接下來你有些工作要做了. 創(chuàng)建一個接受外界貢獻(xiàn)的開源項(xiàng)目的工作量比它表面上看起來需要做的多. 你不得不創(chuàng)建一個環(huán)境， 這個環(huán)境可以讓那些不熟悉這個項(xiàng)目的人都能很快上手并應(yīng)用此項(xiàng)目迅速提高他們的開發(fā)速度和生產(chǎn)能力， 要做到這點(diǎn)需要一些計(jì)劃.

　　這篇文章是讓你了解如何開始一個開源項(xiàng)目并達(dá)到下面這些目的：

　　創(chuàng)造一個對他人有幫助的東東

　　制訂項(xiàng)目計(jì)劃并不斷完善你所創(chuàng)造的項(xiàng)目

　　接受其它人貢獻(xiàn)的代碼(也許會有money)

　　選擇開源許可證

　　在發(fā)布你的代碼之前，重要的一個事情是選擇一個開源許可證。選擇不同的開源許可證會影響你項(xiàng)目的參與者。所有的開源許可證都會保留你個人作為代碼創(chuàng)建者的版權(quán)。雖然許可證的授權(quán)概念有點(diǎn)復(fù)雜，但一些常用的許可證和基本的東西還是要了解的。(如果你的開源項(xiàng)目屬于公司性質(zhì)，在選擇許可證之前先咨詢一下公司的法律顧問)

　　GPL

　　GNU公共協(xié)議是為GNU項(xiàng)目而創(chuàng)建，并且隨著linux作為一種可變的操作系統(tǒng)已被大家所接受，GPL許可要求任何使用基于GPL授權(quán)的組件也必須要在GPL下可用。簡單而言之，任何使用基于GPL授權(quán)的組件在任何方式下都必須在GPL許可下開源。GPL授權(quán)的程序沒有在使用上限制，這個限制僅僅和派生作品的修改和發(fā)布有關(guān)

　　GNU寬通用公共許可證是一種GPL更加寬松的版本。基于LGPL授權(quán)的組件可能關(guān)聯(lián)到程序，但是程序本身并不必開源或者基于GPL或LGPL授權(quán)，換句話說，LGPL和GPL相似，因此任何派生作品也必須開源。

　　MIT

　　亦被稱為X11協(xié)議。該協(xié)議相對寬松，對于使用該協(xié)議的項(xiàng)目，協(xié)議的遵循者必須自動放棄對該項(xiàng)目代碼發(fā)布權(quán)以及使用權(quán)的私有，而賦予公眾相應(yīng)權(quán)利。因此，遵循MIT協(xié)議的代碼或許被會被引用在一些沒有聲明遵循某項(xiàng)協(xié)議的特定代碼中。此外，MIT協(xié)議與GPL協(xié)議兼容，所以你完全可以用MIT協(xié)議下的代碼來開發(fā)GPL協(xié)議的應(yīng)用。

　　BSD3

　　協(xié)議有點(diǎn)松，有點(diǎn)松……該協(xié)議相對寬松，對于使用該協(xié)議的項(xiàng)目，協(xié)議的遵循者必須自動放棄對該項(xiàng)目代碼發(fā)布權(quán)以及使用權(quán)的私有，而賦予公眾相應(yīng)權(quán)利。此外，項(xiàng)目中任何以二進(jìn)制形式發(fā)布的代碼(譯者注：貌似.bin文件之類的)，也需要在許可文檔中聲明該協(xié)議。那么，該協(xié)議與MIT協(xié)議的區(qū)別在哪里呢?當(dāng)該協(xié)議的標(biāo)的物(譯者注：一般，這里的“標(biāo)的物”是聲明使用該協(xié)議的代碼，為了保證嚴(yán)謹(jǐn)性，在此進(jìn)行注釋)被其他人使用時，他們不可以用該標(biāo)的物的所有權(quán)人的名字進(jìn)行商業(yè)宣傳。例如，如果我寫了一段遵循該協(xié)議的代碼，而你把他用著自己的應(yīng)用里面，你是不可以用哥哥我的名字去做宣傳的，除非經(jīng)過我的同意。后，BSD3協(xié)議也是和GPL兼容的。

　　好吧，其實(shí)還有很多開源協(xié)議本文沒有介紹，但是以上協(xié)議應(yīng)該是受大家關(guān)注的。

　　需要注意的一點(diǎn)是 Creative Commons許可證并非設(shè)計(jì)來于軟件的. 所有的 Creative Commons許可證都是為"創(chuàng)造性工作"制定的， 例如音頻， 圖像， 視頻和文字. 制定 Creative Commons 的組織他們自己也不推薦將 Creative Commons許可證用于軟件， 應(yīng)該在軟件中使用專門為軟件制定的許可證， 通常也是上文討論的四種.

　　因此， 你應(yīng)該選擇哪個許可證呢? 這點(diǎn)大部分由你想別人怎么使用你的代碼決定. 因?yàn)長GPL， MIT 和 BSD3都和GPL完全兼容， 這還不是需要關(guān)注的. 如果你想所有你軟件的修改版本都只被用于開源軟件， 那么你應(yīng)該選擇GPL. 如果你的代碼是設(shè)計(jì)成一個不需要修改而可以直接引入別人的項(xiàng)目使用的組件， 那么你可能會考慮LGPL. 否則， MIT和BSD3許可證時比較通常的選擇. 個人比較趨向于喜好MIT許可證， 而商業(yè)上可能更加的偏向于喜好BSD3許可證以保證他們的公司名稱不會被未授權(quán)的使用.

　　為了幫助你做決定， 看一下這些流行的開源軟件項(xiàng)目都使用了些什么協(xié)議:

　　jQuery: MIT license

　　YUI: BSD3 license

　　Dojo Toolkit: dual-licenced under BSD3 and Academic Free License

　　Backbone: MIT license

　　另外一個選擇是直接把你的代碼發(fā)布為 public domain(公有領(lǐng)域)， 在 public domain中的代碼沒有版權(quán)擁有者， 這些代碼可以完全隨意使用. 如果你沒有打算保持你對代碼的控制全 或者 你只是想向世界分享你的代碼而不打算持續(xù)開發(fā)它， 那可以考慮一下把代碼發(fā)布到 public domain.

　　想進(jìn)一步了解許可證與它們相關(guān)的法律問題以及這些許可證如何工作， 請閱讀 David Bushell的 Understanding Copyright and Licenses.

　　代碼組織

　　決定在你的開源項(xiàng)目中使用何種許可證以后， 這幾乎是時候把你的代碼放出來了. 但是在這之前， 你得先看看代碼是怎么組織的. 不是所有代碼都會得到大家的貢獻(xiàn). 如果一個潛在的貢獻(xiàn)者無法通讀你的代碼， 那么他非常可能也沒法做出任何貢獻(xiàn). 在你分享你的代碼給公眾之前， 你組織代碼的方式， 包括文件目錄結(jié)構(gòu)， 代碼風(fēng)格都是需要認(rèn)真考慮的因素. 別隨意把你胡亂寫的代碼扔出來. 多花點(diǎn)時間考慮別人可能會怎么閱讀你的代碼以及他們在這過程中可能會遇到什么問題.

　　對于CSS Lint， 我們選用了一個基本的 頂層目錄結(jié)構(gòu): src 用于主源代碼， lib 用于外部依賴， test 用于測試代碼。 src目錄進(jìn)一步分為子目錄， 分類相關(guān)的文件。 所有的CSS Lint規(guī)則都在 rules 子目錄; 所有的輸出格式化都在 formatters 目錄等等。 test目錄劃分子目錄與src目錄相同， 這樣可以標(biāo)示測試代碼和主代碼的關(guān)系。 隨著時間過去， 我們因?yàn)樾枰�已�?jīng)添加了頂層目錄， 但基本結(jié)構(gòu)和開始做的是一樣的。

　　文檔

　　很多對開源項(xiàng)目的抱怨是由于缺乏文檔。寫文檔往往沒有寫程序來得有趣，但對于開源項(xiàng)目成功卻至關(guān)重要。如果你不想要別人使用你的軟件，不想要人們貢獻(xiàn)代碼，那么只要不提供文檔行了。我們的CSS Lint一開始犯了這個錯誤。項(xiàng)目剛啟動時，我們沒有提供文檔，結(jié)果大家都不知道怎么用這個東西。不要重蹈我們的覆轍，在啟動項(xiàng)目之前，一定要做好文檔的工作。

　　文檔應(yīng)該很容易被更新，而且不需要push代碼可以更新，必須能根據(jù)用戶的反饋快速地修改。也是說，不要把文檔與代碼放在一個倉庫里。如果你把代碼放在GitHub上，那么可以用GitHub內(nèi)置的wiki來放文檔。我們的CSS Lint是把文檔放在wiki上。如果你的代碼不是放在GitHub上，那么可以用自己的wiki或其它類似的系統(tǒng)來放文檔，以便實(shí)時地更新它們。好的文檔系統(tǒng)應(yīng)該是很容易更新的，否則你可能永遠(yuǎn)都不會去更新它們。

　　終用戶文檔

　　無論你寫的是命令行程序、應(yīng)用框架、工具庫還是其它什么東東，都要把終用戶深深地放在腦海里。終用戶并不是修改你代碼的人，而是使用你代碼的人。拿我們的CSS Lint來說，大家一開始不知道怎么用，因?yàn)槲覀儧]有給出終用戶文檔。爭取不到終用戶，也爭取不到貢獻(xiàn)者。對你的代碼滿意的終用戶們后會成為貢獻(xiàn)者，因?yàn)樗麄兛吹搅颂N(yùn)含在代碼中的價值。

　　開發(fā)者指南

　　即時你的代碼布局合理，文檔豐富，也無法保證一定會有貢獻(xiàn)者出現(xiàn)。你需要一份開發(fā)者指南，讓那些貢獻(xiàn)者們快速融入進(jìn)來。一份好的開發(fā)者指南應(yīng)該有下面這些內(nèi)容：

　　如何獲取源代碼：你當(dāng)然希望貢獻(xiàn)者們都知道怎么check out代碼，但世事無。一份友好的介紹總是受人歡迎的。

　　代碼是如何組織的：即使你的代碼和目錄結(jié)構(gòu)很清晰，完全能自我說明，也好寫下來，總有用處的。

　　如何設(shè)置構(gòu)建系統(tǒng)：如果你用了某種構(gòu)建系統(tǒng)，那么應(yīng)該提供一份怎么設(shè)置這個系統(tǒng)的說明。如果構(gòu)建時的一些依賴項(xiàng)沒有包含在你的倉庫中，那么這份說明中還應(yīng)該包括怎么獲取這些依賴項(xiàng)的信息。

　　如何構(gòu)建：如何進(jìn)行構(gòu)建以及單元測試的步驟。