如何經營好一個開源項目
最近換了新的工作，新工作的主要內容是幫忙開發一個開源項目。因為開源項目的目標人群是廣大的第三方開發者，因此不同於公司內部的代碼庫，核心開發者會有大量的時間用在改善文檔，改善代碼，以便增進項目的易讀性以及易用性，以便於第三方開發者使用以及進一步回饋整個社區。
為了增進易讀性以及易用性，開發時為了實現同樣功能的代碼，需要花費的時間以及精力可能是原本的好幾倍。對於我們當前的這個開源項目來說，測試的代碼相對比較簡單，大約有1/3的精力都花費在寫代碼comment，以及代碼的文檔上了。
因為文檔更新其實是工作量很大的事情，所以我們常常會看到有的功能更新比較快的代碼庫，文檔的更新不太及時，並沒有解釋所有的代碼中已經實現的功能。
一般的開源代碼庫，會有兩個主要的的Git的分支。master分支用來提供當前已經穩定的代碼版本，以便大部分的用戶使用。development分支則用於當前的開發工作，上面的代碼可能每天都會有更新，因此不少功能可能不太穩定，對應的文檔也可能還沒有更新。
每隔一段時間，比如1-3個月，代碼庫可能會有一次大的發布（release），在把development分支上面所有的功能全部測試，文檔全部更新完全以後，用development來代替master分支。至於master上面的舊代碼，就會放入一個歷史分支中備用。
開源代碼庫一般也可以允許感興趣的開發者對這個代碼庫做出自己的貢獻。一般的流程是這樣的，社區中的第三方開發者複製了代碼以後，做了一些修改，如果覺得自己的修改是對當前代碼庫的一種提升或者糾錯，則可以把這個修改提交給這個代碼庫，要求加入該修改。這個請求一般叫做pull request。在pull request上面可以看到開發者具體做了些什麼樣的修改。核心開發者在審閱了pull request的內容以後，可能會在提出修改意見修改以後把pull request的修改合併入development分支，也可能直接拒絕改修改。
在開源代碼庫的開發者團隊內工作，當項目還在快速演進中時，第三方的開發者的修改很難被融入當前項目中。這一方面是因為快速演進的代碼庫一般文檔只有在發布時才會變完善，因而讓人比較難以理解當前的開發進度。另一方面是因為第三方開發者的修改很有可能已經在開發者團隊的計劃之中了，他們的修改提議很可能會被一個更加底層的修改所取代。
當然隨著開源代碼庫的逐漸成熟，必然會有一些並非核心，但是有也很不錯的功能，暫時核心開發者團隊還沒有時間開發。如果說核心開發者能把這些需求列出來，然後作為project掛在代碼庫上讓第三方開發者貢獻，那麼將會讓第三方開發者的貢獻變得容易很多。
另外一方面，開源代碼庫本身也需要一些指導性的文檔，來說明幾個事情。 一是貢獻的代碼需要符合怎麼樣的代碼風格，什麼樣的變數要用什麼樣的格式來標註，命名。二是什麼樣的代碼可以接受，什麼樣的代碼不會被接受。因為有些代碼可能跟代碼庫的目標以及功能不吻合，將會打亂代碼庫的結構，不適合被合併入當前代碼庫中。
總之，一個成功的開源項目需要大量精心的維護，才可能最終成為一個成功的項目。這個過程中一方面需要項目足夠有價值，使得有大量的第三方開發者願意使用該項目，為該項目提出改進意見。另一方面也需要核心團隊帶領項目走向一個好的大方向，使得項目始終易於使用，易於拓展，清晰易懂。
TAG:高小貓 |