決定將代碼開源之前要確定的四個問題

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

• 誰關心這個項目？
• 我們還在使用這個項目嗎？
• 我們還在維護這個項目嗎？
• 這個項目能夠在一顆公共代碼樹上開發嗎？

誰關心這個項目？

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

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

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

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

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

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

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

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

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

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

更深入的講，你不能在內部開發你的軟體，將你項目的里程碑版本配合合適的開源許可證發布到 GitHub 中，從而合理的參與到開源中。外部的開發人員必須能夠平等地參與到設計與開發相關的討論中，這樣才不至於讓你的社區走向沒落。從另外一個角度來看，這也意味著你需要開放一些內部的資料給社區，並允許他們在公開的討論相關的技術，而不是一味地由內部貢獻這些資料。

結語

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

原文鏈接 : https://opensource.com/business/16/1/4-questions-ask-open-sourcing-project

本文鏈接： http://www.linuxstory.org/4-questions-before-open-source/  轉載請註明，否則將追究相關責任