英文原文：Thoughts on Running an Open Source Project，編譯：oschina
上週我在 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 連結尋求幫助，有不少人去留言，給建議，也有人直接去測試程式碼。