決定将代碼開源之前要确定的四個問題

在任何一家公司的開源部門中，最常見的任務之一是評估内部軟體，确定它是否可以作為回饋社群的開源項目。我們在 paypal 進行相關評估時發現回答下面四個問題對我們的審查潛在的開源軟體的過程非常有用：

誰關心這個項目？

我們還在使用這個項目嗎？

我們還在維護這個項目嗎？

這個項目能夠在一顆公共代碼樹上開發嗎？

在公司之外，誰會對這個軟體感興趣？開源軟體失去社群的支援将一事無成。如果外面沒有人對這個項目感興趣，圍繞你的成果構成一個有意義的社群的幾率就會變得渺茫。一旦維護這個項目的員工都離開了，就一定要有人接管這個項目，否則這個項目最終會被抛棄。

有很多可以獲得外部回報的方法。和其他公司的同僚說、寫部落格、參加社交聚會和發表會議演講都是不錯的方法。有些員工可能已經做好了這件事，有些需要 告訴他們可以說些什麼，并且要怎樣做，而有些則不希望談論他們的工作。其實很多人隻需要有人告訴說他們是允許與外面的的人談論他們的工作的。同時我們還發 現給需要的人提供演講教育訓練以及幫助開發者管理部落格内容是非常有效的。

如果我們不再使用該項目，那麼它總是能夠通過開源的審查。如果我們不再繼續開發這個軟體，我們不太可能完成維護項目的任務或者圍繞其建立一個社群。 而如果一個它依賴的元件(或者軟體本身)發現了一個漏洞，那麼一定會有一個人要花費時間處理這個問題。除此之外，将 bug 分類、指導新的貢獻者、合并代碼這些都需要時間，而一個公司是不太可能投入大量的時間維護一個它不再使用的軟體的。

然而，更大的問題在于，将失敗的項目開源是很差的企業行為。如果我們因為不符合我們的需求而抛棄一個項目，那麼其他人也不可能發現它是真正有用的項 目，開源并不是我們抛棄無用軟體的垃圾桶。如果一家公司隻是開源了一些它不再需要的一些軟體，那麼還不如它根本沒有開源過軟體。

正如上面提到的，維護一個開源項目需要時間。而其消耗的時間取決于項目的規模。一個編碼風格檢查程式耗費的時間不可能和一個強大的應用程式架構相 比，但是他們都需要一定的時間。另一點不能忽視的是，開發人員和他們的管理者要有一定程度的共識。如果管理者不願意開發者在維護項目上花費時間的話，我們 将會再次走将軟體抛棄的路。

當你在一個比較靈活的環境中工作時，你能用很多種方法處理這些問題。如果你選擇的工作是基于開發者能力的，那麼你應該适當的減少參與開發工作的每個 開發者的能力。如果你選擇的工作是将任務分發給多個人做的，那麼你需要明确每個人要處理哪個部分。否則這些項目很容易夭折。如果這一切對于管理者而言是不 合理或者不可行的，那麼這些項目需要額外的審查

代碼中存不存在不能讓我們将整個代碼樹公開的部分？如果這些代碼由于依賴内部系統而不能完全公開，那麼這些依賴關系将需要被分離、抽象或子產品化。如 果這樣做了之後軟體對外界的價值不大，那麼你需要考慮是否添加部分内部依賴來讓整個項目變得更加有價值。如果不能添加内部依賴的話，那就沒有理由再繼續下 去了。

更深入的講，你不能在内部開發你的軟體，将你項目的裡程碑版本配合合适的開源許可證釋出到 github 中，進而合理的參與到開源中。外部的開發人員必須能夠平等地參與到設計與開發相關的讨論中，這樣才不至于讓你的社群走向沒落。從另外一個角度來看，這也意味着你需要開放一些内部的資料給社群，并允許他們在公開的讨論相關的技術，而不是一味地由内部貢獻這些資料。

結語

這四個問題并不能代表所有情況，一家公司必須從項目開源後對公司和開源社群的意義等方面考慮，而這四個問題可以作為讨論的起點，相信明确了這幾個問題後，你會很快得到你的結論的。

====================================分割線================================