將一個項目的代碼開源出來很容易，但是將它長久維護下去，並吸引更多人蔘與，這就比較難了。開發者Jim Cowart結合自身的開源項目維護經驗，給出了本文這些建議，希望能爲你的開源之路帶來一些幫助。
1. 堅持遵循Wheaton法則
Wheaton法則的中心思想是“Don’t be a dick”，意思是不要成爲一個不顧別人感受的人。在這裏，我想說的是，你要耐心對待你的開源項目的用戶。
我以前是一個音樂家，但是後來開始喜歡編寫軟件。我常常認爲我的知識和同事相比就如同瑞士奶酪（千瘡百孔），但是很快我發現，每個人與其他人相比在某些方面都存在一些優勢和差距。因此，對於那些在某些知識領域不如你的人，要有耐心。
每個開源項目，無論大小，都會產生一個與它相關的文化。當你創造了這樣一個文化，也意味着你已經創造了一個空間，供各知識水平的人來交流學習。要知道，能夠成爲其他人學習新事物路上的一個嚮導，將是一種榮譽。
我選擇的許可證是MIT。如果必要的話，你可以使用雙許可證。你可以參考http://choosealicense.com/網站，或者閱讀opensource.org中具體的許可證規範。
3. 不要急於發佈1.0版本
你需要一些空間來對項目進行迭代、改進、重構和更改。
如果有人使用了你的v0.2.3版本，那麼說明他們認爲你的項目中存在的風險是可以接受的，即使項目還在起步階段。你可以在README或者其他文件中提醒用戶該項目還處於實驗階段，並可能隨時會更改。
雖然我們都知道標上“1.0”標籤在某些時候並不意味着完全可用於生產環境，但是大部分開發者都會有這種感覺。因此，不要急於將項目標記爲1.0狀態，這將有助於項目後續的改進。
4. 不要害怕重建API（但要負責任地做）
在早期維護postal.js這個項目時，我犯了一個大的錯誤——沒有以我希望的方式重建API，現在回想起來，這樣做似乎使得項目開發工作滯後了幾個版本。
但我最終更改了API，我覺得這個項目有了新的生命，按我的想法進行擴展變得更加容易。
5. 不要害怕說“不”、“請提交測試”，“請修復{X}”等
有時你會收到一個有可怕想法的pull請求。但有時它也可能是一個偉大的想法，但不應該屬於代碼基本功能（也許應該作爲一個插件）。
有時你會得到一個沒有經過測試的pull請求。這些情況下，你需要以某種方式說“不”。當你這樣做的時候，請參照第1條，應該禮貌地說明你的理由，而不應該只有一個“不”字。
如果你因爲他們沒有進行測試而說“不”，那麼你最好也應該先對自己的代碼進行測試。此外，如果你有一個特定的代碼風格（製表符、空格等），請在你的README中說明。
6. 明智地選擇合作伙伴
如果你的項目已經增長到需要合作伙伴的地步，那麼可以考慮讓其他開發者來作爲項目共同所有者或維護者。前提是，你要明智地選擇這些人。
要知道，沒有人的想法會和你完全一樣（這是很好的事情），但是你要確保你們的想法大部分能夠重疊，以便項目能夠朝着一個方向發展。無論一個人有多麼博學或受歡迎，如果他是一個dick（見第1條），那麼就不能讓他成爲項目所有者。如果在開源項目中出現派別爭鬥，那麼項目離結束就不遠了。
一些好的做法是，給予貢獻者和所有者不同的權限。如果一個初級開發者想參與修復問題，不要給他所有者的權限。
7. 不要吝嗇讚美和鼓勵，給予貢獻者應得的榮譽
作爲一個開源項目所有者，如果有人爲你的項目貢獻了一條非常好的建議，一定要在公開場合經常表揚他。這樣可以鼓勵更多的人貢獻更多的想法或代碼。
我現在和一些人一起工作，如果他不能給我一些應得的榮譽的話，我想我在大多數事情上會對他產生不信任——不只是在開發工作上。
8. 不要害怕放棄
我之前開發過幾個項目，當時我認爲這些項目的想法很偉大，但是現在我已經放棄了這些項目。如果還有人發現你的項目有用並正在使用它們時，你很難放棄。但如果你因爲學到了一些更好的方法，使得你放棄這個項目，你需要解釋一下原因，有可能這會促成一個新的開源項目，並可以更好地幫助這些用戶解決問題。如果你因爲沒有時間而放棄，你可以問問其他人是否願意接管這個項目。
如果你放棄了一個有人在使用的項目，用戶可能會沮喪。不幸的是，這就是現實。你要從長遠來看。比如，我之前寫了很多工具，但現在看來，這些工具充斥着各種糟糕的代碼，似乎放棄這些是一個明智的決定。
總結
開源是美麗而危險的。美麗是因爲可以讓很多人爲了一個目標而努力，危險是因爲你需要有持之以恆、樂於分享的精神。
現在的一些光輝奪目的開源項目並不能代表所有，每天都會有大量的開源項目被創造，也有大量的開源項目死亡。你會發現一些對你有很大幫助的項目有可能在不久的將來會消失，除非該項目獲得了足夠多的貢獻。這就是爲什麼持之以恆的精神和創造力對於一個開發者和開源項目來說比其他方面更重要。
文章來源：Open Source Project Advice