運作開源專案的一點經驗
阿新 • • 發佈:2018-12-30
上週我在 PHPUK 上面講了一些關於開源專案的內容。我想把它們整理一下都記錄下來,以免忘記。也許我不太適合來給出一些這方面的建議,但這些都是我運營 joind.in 的一些真實、重要的總結。
社群(Community)
你喜歡一個專案,分享了它的程式碼,並且公佈了它,這就算是開源專案嗎?在我看來這不是,開源專案必須有一個社群。作為興趣,你這麼做可以,但是你想要其他人也參與這個專案,事情就大不同了。
為了讓別人參與貢獻,你必須建立一些基礎設施,可以讓別人能夠順利溝通,看到專案的進展。作為專案的負責人,你需要管理這些基礎設定。Joind.in 使用google groups的郵件列表,問題跟蹤系統(atlassian為開源專案提供免費的授權)以及IRC頻道。我們也有一個部落格,以及twitter賬戶來發表公開的宣告。我們使用了多個郵件列表,外聯、功能、開發。這樣就可以讓不同的人選擇自己感興趣的資訊,而不會被其他資訊淹沒。
如果你的專案還不是很有名,你需要通過部落格,twitter,stack overflow等各種渠道來讓人們知道它。
說明檔案(README)
在專案能獲得其他人的貢獻之前,你首先要保證其他人能順利的配置你的專案。你最好在網頁,wiki,部落格,以及專案中都有README資訊,因為你不知道人們習慣從哪裡看這些資訊。
專案規劃(Roadmap)
有一個清晰的專案規劃是非常有用的。當用戶給你提出一些新功能的時候,你可以說“it's on the roadmap”,或者讓他們去郵件列表討論。人們也知道你們正在幹什麼。
貢獻程式碼(Code Contributions)
這一點有點複雜。大部分的開源貢獻者只對他們感興趣的東西感興趣,其他的功能或者系統的其他部分很難引起他們的興趣。但是恰恰其他部分是系統的關鍵部分。還有,作為專案負責人,你需要及時稽核,測試,合併,部署這些貢獻的程式碼。當某些貢獻不能被採納的時候,你需要告訴別人為什麼,以及如何改進。
以我的經驗來看,區分真正有用的貢獻,以及一般般、沒用的貢獻是比較困難的。有可能那個貢獻者提交了程式碼以後就消失了,剩下你來維護這個程式碼。這個問題似乎只能靠直覺去解決。你能做的就是誠懇的對待貢獻者,說出你心裡真實的想法。
透明化(Transparency)
對我來說,這是運營開源專案最重要的一點!人們能看到程式碼,能看到問題列表,郵件列表,甚至持續整合伺服器。我可以向人們求助,指出哪段程式碼不工作。有時候,在我還沒有意識到問題的時候,就會有人跳出來指出我的錯誤。
對於和我一起工作的人來說,他們可以看到哪些“pull request”是開放的,誰評論了什麼,哪些程式碼在什麼時候被採納了。我會提交我參與的所有分支到githut。所以當有人問我一個功能的進度的時候,我往往直接告訴他們最新的版本號。
把專案的所有東西都拿出來給人看有點像是在熨燙一件髒衣服,讓人有點不適。但是這樣做的好處是你可以聽到各種各樣的建議。好幾次我在twitter上貼出了一個bug連結尋求幫助,有不少人去留言,給建議,也有人直接去測試程式碼。