[[162258]]

對于任何一家企業中的開源部門來說，相當常見的一項任務就是對內部軟件進行評估以考量其是否適合以開源形式回饋社會。而在PayPal公司執行這項任務時，我們發現有必要利用Danese Cooper建立的一套審查流程對潛在開源項目加以審視，從而為以下四個問題找到答案：

　　1.與誰相關?

　　2.我們是否仍在使用?

　　3.我們是否做出承諾?

　　4.其在公共樹結構下是否能夠順利進行開發?

　　今天的文章將著眼于這四個問題，并探討它們為何如此重要。

　　1.與誰相關?

　　立足于企業之外，還有誰會對這款軟件感興趣?如果沒有活躍社區的積極參與，任何開源項目都不可能取得成功。如果吸引不到外界的興趣，那么以現有成果為基礎建立活躍社區的希望也會變得非常渺茫。一旦依靠勞資關系維系的項目開發者們逐步離去，必須要有其他人接手其開發及維護，否則我們只是給歷史的垃圾堆增添了一件廢品。

　　獲得外部反饋意見的方式可謂多種多樣。與來自其它企業的同行們交流、撰寫博客、在會議活動中進行溝通或者發表演講都是不錯的實現方式。有些人天生具備這種能力，有些人則需要一定程度的引導才能確切表達自己的意見，也有不少人不太擅長談論與自己工作相關的話題。但在大多數情況下，員工需要得到企業的明確授權，告訴他們能夠在外界發表怎樣的言論。我們發現對有此意向的員工進行表達培訓能夠很好地解決上述問題，當然也可以幫助開發人員充實其博客中的相關內容。

　　2.我們是否仍在使用?

　　如果我們已經不再使用這款軟件，那么在進行開源之前總是需要進行大量審查。如果我們不再積極開發這款軟件，那么我們幾乎不可能以該項目為核心執行進一步推動或者為其建立社區。軟件中的某個獨立組件中可能存在安全漏洞(或者存在于軟件本身中)，這意味著必須有人全程追蹤并加以解決。更不用提其它一些常見任務的處理工作，具體包括歸類錯誤請求、指導新晉貢獻者以及根據用戶實際需要調整任務處理方式等等。這些工作都需要投入時間，而作為企業我們不太可能花費大量時間維護一款已經不再使用的軟件。

　　不過***的問題在于，對失敗產品進行開源會給企業聲譽帶來影響。如果我們由于一套解決方案無法解決實際問題而轉向其他軟件成果，那么真的很難指望這東西能夠切實幫助其他人搞定運營任務。開源社區不是求助站或者垃圾桶，我們不可能隨便把自己不想要的東西往這里一丟了事。如果企業回饋給社會的都是其不想要的軟件，那還不如干脆別打開源的主意。

　　3.我們是否做出承諾?

　　正如之前所提到，維護開源項目需要投入大量時間，而具體時間周期則取決于項目的整體規模。一般來講，開源項目的維護時間一般要低于核心應用框架，但其時間投入仍然相當可觀。毫無疑問，開發人員及其管理者都會把時間視為一種極其寶貴的資源。如果管理者不愿意讓開發人員把時間耗費在項目維護工作身上，那么項目本身很可能陷入慢性死亡狀態。

　　而在敏捷背景之下，大家則可以采取多種不同處理方式。如果我們的流程依賴于功能組件與短期沖刺，那么我們可以通過一項組件配合一輪沖刺的方式實現項目維護。而如果大家選擇基于任務的開發人員精力調派方式，則應當適當減少開發人員投入到項目維護方面的產能消耗。如果大家打算把工作均攤給多位成員，自然會希望確保了解每個人具體負責流程中的哪些部分——否則任務將很可能陷入僵局。一部分項目還需要全職社區技術人員予以配合。如果這一切在管理者眼中是不合理或者不可行的，那么該項目需要迎接進一步審查以考量其是否適合走向開源。

　　4.其在公共樹結構下是否能夠順利進行開發?

　　是否還有其它與代碼相關的阻力限制著我們在公眾視野當中進行項目代碼編寫工作?如果這些代碼由于同內部系統的關聯性而無法進行公共開發，那么，我們必須對這種關聯性加以隔離、剝離或者模塊化處理。而且，如果相關流程并不影響該軟件對外界參與者及使用者的吸引力，那么，大家應當考慮解耦這種內部關聯關系，從而幫助項目本身實現實用性。另外，如果沒有更多項目內容需要發布，那么相關代碼編寫也基本可以叫停。

　　更重要的是，大家絕不能繼續以內部形式開發軟件——通過許可將各重要發行版本發布在GitHub之上，同時合理啟用良好的開源資源。外部與內部開發人員必須能夠參與其中，并圍繞設計與開發議案進行討論，否則整個社區將被徹底架空。這意味著我們需要為社區提供可供討論的素材，并把技術決議交給公眾評判——而不能繼續依靠企業內部的決策傾向。如果項目團隊不想做這些工作，我們可能需要為其行為提供一些重要指導，從而幫助其走上開源正軌。

　　總結

　　這四個問題當然還不足以涵蓋開源過程中可能出現的全部障礙。任何一家企業都需要對項目當中可能涉及的各類知識產權問題做出評估。另外，我們也必須對其它類似開源項目進行研究，確保自己的努力成果不會與既有方案相重復。與此同時，項目本身還必須對企業自身以及整個開源社區具備實際價值。但總體來講，這四個問題可以算是一個良好的對話起點，大家可以利用它們幫助自己過濾掉那些不適合作為首發開源對象的軟件方案。

　　原文標題：4 questions to ask before open sourcing a project，作者：Duane O'Brien

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】