2011年在 Nicole Sullivan舉辦的 Velocity大會上我介紹了第一個CSS代碼質量工具 CSS Lint， 我們花費之前的兩周瘋狂的編碼， 嘗試著構建一個終用戶有用并且易于修改的應用. 我們所有人都沒有啟動這樣一個開源項目的經驗， 因此我們也在這過程中學到了很多.
初期經過一段時間的試錯， 項目后進入正軌， 現在也時常獲得CSS Lint用戶和CSS Lint貢獻者們的贊許. 其實在你經過思考確定目標之后創建一個成功的開源項目并沒有想象的困難.
你的目標是什么?
這一段時間， 好像很多人寫了一代代碼加上一段開源軟件協議， 再把它發布到GitHub， 然后說: "我把它開源了". 創建一個開源項目并不僅僅是讓你的代碼可以自由的被訪問獲取. 所以， 在向世界宣稱你開源了那么些除了你自己在空閑時間使用而還沒有其他人使用的東西之前， 停下來問一下你自己， 對于這個項目， 你的目標是什么?
首要的目標通常是: 創建點有用的東西. 對于CSS Lint， 我們的目標是為提升CSS 代碼質量，創建一個易適應各開發者開發流程且易擴展的工具. 而不論這開發流程是否是自動化的. 另外， 通過找尋做類似項目的人， 并且想清楚你面向的用戶基數有多大來確保你所提供的東西是有用的.
在那之后， 應該被放在第一位的是 決定為什么你要開源這個項目. 僅僅是因為你想分享你完成的東西? 你有打算持續開發這些代碼還是僅僅只是把他們扔到外界再也不管? 如果你沒有打算持續開發這些代碼， 那么這篇文章剩下的部分不適合你. 確保在你代碼庫中的readme文件里面清晰的聲明了你會持續開發這一點以避免找到這個項目的人對此感到困惑.
如果你準備持續開發你的代碼， 你考慮過接受別人的貢獻嗎? 如果答案否定， 再一次， 這篇文章不適合你. 如果答案肯定， 接下來你有些工作要做了. 創建一個接受外界貢獻的開源項目的工作量比它表面上看起來需要做的多. 你不得不創建一個環境， 這個環境可以讓那些不熟悉這個項目的人都能很快上手并應用此項目迅速提高他們的開發速度和生產能力， 要做到這點需要一些計劃.
這篇文章是讓你了解如何開始一個開源項目并達到下面這些目的：
創造一個對他人有幫助的東東
制訂項目計劃并不斷完善你所創造的項目
接受其它人貢獻的代碼(也許會有money)
選擇開源許可證
在發布你的代碼之前，重要的一個事情是選擇一個開源許可證。選擇不同的開源許可證會影響你項目的參與者。所有的開源許可證都會保留你個人作為代碼創建者的版權。雖然許可證的授權概念有點復雜，但一些常用的許可證和基本的東西還是要了解的。(如果你的開源項目屬于公司性質，在選擇許可證之前先咨詢一下公司的法律顧問)
GPL
GNU公共協議是為GNU項目而創建，并且隨著linux作為一種可變的操作系統已被大家所接受，GPL許可要求任何使用基于GPL授權的組件也必須要在GPL下可用。簡單而言之，任何使用基于GPL授權的組件在任何方式下都必須在GPL許可下開源。GPL授權的程序沒有在使用上限制，這個限制僅僅和派生作品的修改和發布有關
GNU寬通用公共許可證是一種GPL更加寬松的版本。基于LGPL授權的組件可能關聯到程序，但是程序本身并不必開源或者基于GPL或LGPL授權，換句話說，LGPL和GPL相似，因此任何派生作品也必須開源。
MIT
亦被稱為X11協議。該協議相對寬松，對于使用該協議的項目，協議的遵循者必須自動放棄對該項目代碼發布權以及使用權的私有，而賦予公眾相應權利。因此，遵循MIT協議的代碼或許被會被引用在一些沒有聲明遵循某項協議的特定代碼中。此外，MIT協議與GPL協議兼容，所以你完全可以用MIT協議下的代碼來開發GPL協議的應用。
BSD3
協議有點松，有點松……該協議相對寬松，對于使用該協議的項目，協議的遵循者必須自動放棄對該項目代碼發布權以及使用權的私有，而賦予公眾相應權利。此外，項目中任何以二進制形式發布的代碼(譯者注：貌似.bin文件之類的)，也需要在許可文檔中聲明該協議。那么，該協議與MIT協議的區別在哪里呢?當該協議的標的物(譯者注：一般，這里的“標的物”是聲明使用該協議的代碼，為了保證嚴謹性，在此進行注釋)被其他人使用時，他們不可以用該標的物的所有權人的名字進行商業宣傳。例如，如果我寫了一段遵循該協議的代碼，而你把他用著自己的應用里面，你是不可以用哥哥我的名字去做宣傳的，除非經過我的同意。后，BSD3協議也是和GPL兼容的。
好吧，其實還有很多開源協議本文沒有介紹，但是以上協議應該是受大家關注的。
需要注意的一點是 Creative Commons許可證并非設計來于軟件的. 所有的 Creative Commons許可證都是為"創造性工作"制定的， 例如音頻， 圖像， 視頻和文字. 制定 Creative Commons 的組織他們自己也不推薦將 Creative Commons許可證用于軟件， 應該在軟件中使用專門為軟件制定的許可證， 通常也是上文討論的四種.
因此， 你應該選擇哪個許可證呢? 這點大部分由你想別人怎么使用你的代碼決定. 因為LGPL， MIT 和 BSD3都和GPL完全兼容， 這還不是需要關注的. 如果你想所有你軟件的修改版本都只被用于開源軟件， 那么你應該選擇GPL. 如果你的代碼是設計成一個不需要修改而可以直接引入別人的項目使用的組件， 那么你可能會考慮LGPL. 否則， MIT和BSD3許可證時比較通常的選擇. 個人比較趨向于喜好MIT許可證， 而商業上可能更加的偏向于喜好BSD3許可證以保證他們的公司名稱不會被未授權的使用.
為了幫助你做決定， 看一下這些流行的開源軟件項目都使用了些什么協議:
jQuery: MIT license
YUI: BSD3 license
Dojo Toolkit: dual-licenced under BSD3 and Academic Free License
Backbone: MIT license
另外一個選擇是直接把你的代碼發布為 public domain(公有領域)， 在 public domain中的代碼沒有版權擁有者， 這些代碼可以完全隨意使用. 如果你沒有打算保持你對代碼的控制全 或者 你只是想向世界分享你的代碼而不打算持續開發它， 那可以考慮一下把代碼發布到 public domain.
想進一步了解許可證與它們相關的法律問題以及這些許可證如何工作， 請閱讀 David Bushell的 Understanding Copyright and Licenses.
代碼組織
決定在你的開源項目中使用何種許可證以后， 這幾乎是時候把你的代碼放出來了. 但是在這之前， 你得先看看代碼是怎么組織的. 不是所有代碼都會得到大家的貢獻. 如果一個潛在的貢獻者無法通讀你的代碼， 那么他非常可能也沒法做出任何貢獻. 在你分享你的代碼給公眾之前， 你組織代碼的方式， 包括文件目錄結構， 代碼風格都是需要認真考慮的因素. 別隨意把你胡亂寫的代碼扔出來. 多花點時間考慮別人可能會怎么閱讀你的代碼以及他們在這過程中可能會遇到什么問題.
對于CSS Lint， 我們選用了一個基本的 頂層目錄結構: src 用于主源代碼， lib 用于外部依賴， test 用于測試代碼。 src目錄進一步分為子目錄， 分類相關的文件。 所有的CSS Lint規則都在 rules 子目錄; 所有的輸出格式化都在 formatters 目錄等等。 test目錄劃分子目錄與src目錄相同， 這樣可以標示測試代碼和主代碼的關系。 隨著時間過去， 我們因為需要已經添加了頂層目錄， 但基本結構和開始做的是一樣的。
文檔
很多對開源項目的抱怨是由于缺乏文檔。寫文檔往往沒有寫程序來得有趣，但對于開源項目成功卻至關重要。如果你不想要別人使用你的軟件，不想要人們貢獻代碼，那么只要不提供文檔行了。我們的CSS Lint一開始犯了這個錯誤。項目剛啟動時，我們沒有提供文檔，結果大家都不知道怎么用這個東西。不要重蹈我們的覆轍，在啟動項目之前，一定要做好文檔的工作。
文檔應該很容易被更新，而且不需要push代碼可以更新，必須能根據用戶的反饋快速地修改。也是說，不要把文檔與代碼放在一個倉庫里。如果你把代碼放在GitHub上，那么可以用GitHub內置的wiki來放文檔。我們的CSS Lint是把文檔放在wiki上。如果你的代碼不是放在GitHub上，那么可以用自己的wiki或其它類似的系統來放文檔，以便實時地更新它們。好的文檔系統應該是很容易更新的，否則你可能永遠都不會去更新它們。
終用戶文檔
無論你寫的是命令行程序、應用框架、工具庫還是其它什么東東，都要把終用戶深深地放在腦海里。終用戶并不是修改你代碼的人，而是使用你代碼的人。拿我們的CSS Lint來說，大家一開始不知道怎么用，因為我們沒有給出終用戶文檔。爭取不到終用戶，也爭取不到貢獻者。對你的代碼滿意的終用戶們后會成為貢獻者，因為他們看到了蘊含在代碼中的價值。
開發者指南
即時你的代碼布局合理，文檔豐富，也無法保證一定會有貢獻者出現。你需要一份開發者指南，讓那些貢獻者們快速融入進來。一份好的開發者指南應該有下面這些內容：
如何獲取源代碼：你當然希望貢獻者們都知道怎么check out代碼，但世事無。一份友好的介紹總是受人歡迎的。
代碼是如何組織的：即使你的代碼和目錄結構很清晰，完全能自我說明，也好寫下來，總有用處的。
如何設置構建系統：如果你用了某種構建系統，那么應該提供一份怎么設置這個系統的說明。如果構建時的一些依賴項沒有包含在你的倉庫中，那么這份說明中還應該包括怎么獲取這些依賴項的信息。
如何構建：如何進行構建以及單元測試的步驟。
