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

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

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

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

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

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

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

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

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

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

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

　　選擇開(kāi)源許可證

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

　　GPL

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

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

　　MIT

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

　　BSD3

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

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

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

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

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

　　jQuery: MIT license

　　YUI: BSD3 license

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

　　Backbone: MIT license

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

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

　　代碼組織

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

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

　　文檔

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

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

　　終用戶文檔

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

　　開(kāi)發(fā)者指南

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

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

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

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

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