如何才能運作好一個開源專案?
將一個專案的程式碼開源出來很容易,但是將它長久維護下去,並吸引更多人蔘與,這就比較難了。開發者Jim Cowart結合自身的開源專案維護經驗,給出了本文這些建議,希望能為你的開源之路帶來一些幫助。
1. 堅持遵循Wheaton法則
Wheaton法則的中心思想是“Don’t be a dick”,意思是不要成為一個不顧別人感受的人。在這裡,我想說的是,你要耐心對待你的開源專案的使用者。
我以前是一個音樂家,但是後來開始喜歡編寫軟體。我常常認為我的知識和同事相比就如同瑞士乳酪(千瘡百孔),但是很快我發現,每個人與其他人相比在某些方面都存在一些優勢和差距。因此,對於那些在某些知識領域不如你的人,要有耐心。
每個開源專案,無論大小,都會產生一個與它相關的文化。當你創造了這樣一個文化,也意味著你已經創造了一個空間,供各知識水平的人來交流學習。要知道,能夠成為其他人學習新事物路上的一個嚮導,將是一種榮譽。
2. 選擇一個開源許可證
我選擇的許可證是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. 不要害怕放棄
我之前開發過幾個專案,當時我認為這些專案的想法很偉大,但是現在我已經放棄了這些專案。如果還有人發現你的專案有用並正在使用它們時,你很難放棄。但如果你因為學到了一些更好的方法,使得你放棄這個專案,你需要解釋一下原因,有可能這會促成一個新的開源專案,並可以更好地幫助這些使用者解決問題。如果你因為沒有時間而放棄,你可以問問其他人是否願意接管這個專案。
如果你放棄了一個有人在使用的專案,使用者可能會沮喪。不幸的是,這就是現實。你要從長遠來看。比如,我之前寫了很多工具,但現在看來,這些工具充斥著各種糟糕的程式碼,似乎放棄這些是一個明智的決定。
總結
開源是美麗而危險的。美麗是因為可以讓很多人為了一個目標而努力,危險是因為你需要有持之以恆、樂於分享的精神。
現在的一些光輝奪目的開源專案並不能代表所有,每天都會有大量的開源專案被創造,也有大量的開源專案死亡。你會發現一些對你有很大幫助的專案有可能在不久的將來會消失,除非該專案獲得了足夠多的貢獻。這就是為什麼持之以恆的精神和創造力對於一個開發者和開源專案來說比其他方面更重要。(編譯:王果 / 審校:張紅月)
相關文章
- 如何發起並運營一個開源專案
- 如何熟悉一個開源專案?
- 如何去參與一個開源專案
- 成功運作一個開源專案的 15 個要點
- 如何找到並快速上手一個開源專案
- 開源一個文字分析專案
- 企業開源指南:建立一個開源專案
- 如何重構一個過萬Star開源專案—BetterScroll
- 如何為你的開源專案釋出一個版本
- 如何做一個真正牛X的開源專案
- 怎樣做好一個開源專案
- 開源一個機器學習文字分析專案機器學習
- 一個檔案的開源專案,開啟你的開源之旅
- 企業開源指南:啟動一個開源專案
- 運作開源專案的一些經驗
- 找個開源專案
- 我寫了一個開源專案AlphabetPyAlphabet
- 介紹 Moby 專案:推進軟體容器化運動的一個新的開源專案
- 開源一個線上專案 WeAre-AR相簿
- 記錄一個開源專案排名網站網站
- 手把手教你如何構建一個優秀的開源專案
- 如何選擇一個適合自己的開源專案來閱讀
- 如何開始參與開源專案?
- 開源專案推薦:提高研發效率的5個開源專案
- 聊聊第一個開源專案(內網穿透) - CProxy內網穿透
- 一個令人驚豔的ChatGPT專案,開源了!ChatGPT
- PlantUML 是繪製 uml 的一個開源專案
- 我如何用Django開發一個專案Django
- 分享個 golang 開源小專案Golang
- 如何正確使用開源專案?
- 如何開始做一個開源專案?他的親身經歷值得參考
- 程式設計師如何選擇並開始一個有價值的開源專案?程式設計師
- StarFlow一個商業專案運用
- [譯]過去一個月最 ? 的 10 個 Swift 開源專案Swift
- 開源一個功能完整的SpringBoot專案框架Spring Boot框架
- 我的第一個開源專案 Kiwis2 MockserverMockServer
- 給你的開源專案加一個綬帶吧
- Hi,我是ChunJun,一個有趣好用的開源專案