[[162258]]

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

　　1.與誰相關(guān)?

　　2.我們是否仍在使用?

　　3.我們是否做出承諾?

　　4.其在公共樹結(jié)構(gòu)下是否能夠順利進(jìn)行開發(fā)?

　　今天的文章將著眼于這四個問題，并探討它們?yōu)楹稳绱酥匾?/p>

　　1.與誰相關(guān)?

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

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

　　2.我們是否仍在使用?

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

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

　　3.我們是否做出承諾?

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

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

　　4.其在公共樹結(jié)構(gòu)下是否能夠順利進(jìn)行開發(fā)?

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

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

　　總結(jié)

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

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

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