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

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

　　你的目標是什么?

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

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

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

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

　　這篇文章是讓你了解如何開始一個開源項目并達到下面這些目的：

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

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

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

　　選擇開源許可證

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

　　GPL

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

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

　　MIT

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

　　BSD3

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

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

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

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

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

　　jQuery: MIT license

　　YUI: BSD3 license

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

　　Backbone: MIT license

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

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

　　代碼組織

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

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

　　文檔

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

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

　　終用戶文檔

　　無論你寫的是命令行程序、應用框架、工具庫還是其它什么東東，都要把終用戶深深地放在腦海里。終用戶并不是修改你代碼的人，而是使用你代碼的人。拿我們的CSS Lint來說，大家一開始不知道怎么用，因為我們沒有給出終用戶文檔。爭取不到終用戶，也爭取不到貢獻者。對你的代碼滿意的終用戶們后會成為貢獻者，因為他們看到了蘊含在代碼中的價值。

　　開發(fā)者指南

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

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

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

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

　　如何構建：如何進行構建以及單元測試的步驟。