【編者按】Difio是一個基於Django的應用程式，它可以跟蹤你的程式包並在其發生改變時通知你。它提供多種變化分析，因此你可以及時判斷你何時以及如何升級。之前，Difio是一個閉源專案，但是作者決定把它開源，以便能夠內部部署以及吸引更多的社群開發者參與進來。以下是作者    Alexander Todorov撰寫的Difio開源過程中所經歷的10個步驟，編譯主要內容如下，以供各位參考。

1. 刪除不必要的程式碼

任何一個存在了好幾年的專案都會積累一些不再使用的程式碼和功能。刪掉所有可以刪除的程式碼，以保持專案的簡潔。開源Difio前大約刪除了約20%的現有程式碼，它們包括：

• 未使用的和過時的設定
• Django的應用
• 靜態檔案和模板
• 模型類（class）
• 舊的URL
• 棄用的功能
• 其它Python工具

刪除需要額外管理的內容和一次性程式碼。比如，我曾經在一些模板裡使用Markdown而在另一些地方使用了純HTML，還有一些模板tag只在一兩個地方使用。把這些都刪除，以保證模板間更加一致。硬編碼路徑、值、URL等在快速原型中是不可避免的。有時，一個封閉原始碼的應用程式及其部署環境的遺留都需要清理。我已經在需要的地方設定並使用了自定義模板標籤。   

2. 建立獨立的模組

重新組織檔案結構也使得一切更加簡潔和自然。讓模組彼此獨立，自成一體，這樣以後分離起來也更為容易。

Difio的Web後端部署在OpenShift，它使用了不同的目錄佈局模板和靜態檔案。我移動了檔案並更新Django的設定，以便它們能夠正確載入，這也讓我重新思考靜態原始檔被送達CDN後臺的方式。

3. 分離內部程式碼和外部程式碼

在應用程式中有一些內部程式碼來為你提供更多資訊是很正常的。這些程式碼如使用情況跟蹤、其他指標、計費資訊等。在基於網路服務的情況下，這些功能通常是與核心功能整合在一起的，但是它們需要被分離出來。

這也是一個決定到底該留下什麼的好機會。比如說，Difio就沒有傳送它的測試用例，因為從CI環境分離它們需要跟多的工作量。

Difio包含五個單獨的模組：   

• difio/ (核心使用者體驗)
• 一個配置檔案子系統
• 計費模組
• 擴充套件管理模組
• 部署相關的模組（主要是設定）

所有這些都進行了適當的分離和相互隔離，以消除內部依賴關係。目前difio/依賴於幾個配置檔案的API ，它提供了正常的預設值，這一步也幫助你從核心使用者體驗分離一些工作（如定製的電子郵件模板）。

4. 程式碼重構

重構和測試應該是一個持續的過程。不過，到現在為止你可能已經將全部的現有程式碼做了一個快速審查，發現很多東西需要改進。這也是建立一個簡短的路線圖和修正你的反饋（ISSUE）跟蹤系統的好機會。它可以在早期對你的新專案展示和持續改進有所幫助。

在Difio專案上，我主要重構了一些內部的方法，讓它適應新的應用程式結構。外部的方法被留到以後解決，因為它們不是必須的。   

5. 做好法務工作

根據軟體的不同和組織規模的複雜性，遷移到開源也許是相當耗時的，從選擇合適的許可證、品牌、作者命名以及法律審查、尋找潛在的侵權程式碼等等，都需要在這一步解決。

對於Difio來說，這倒是簡單的多。我選擇了Apache 2.0協議，在所有原始檔開頭增加了協議說明，並妥善處理了我在網際網路上可找到的外部程式碼的著作權和版權。   

6. 更新和列出外部資源列表

作為一名軟體開發人員，你必須及時將引用的外部軟體升級到最新版本，並確保軟體正常工作。沒有人希望執行舊的外部程式，舊的外部程式有時會無法正常執行。你還需要提供一個列表，來讓別人知道如何執行和安裝這些軟體。

幸運的是，Difio中只有有限的問題和程式依賴外部專案。

7. 提供文件和示例

對於每一個想加入你的專案的新人來說，文件是非常重要的。畢竟你開源是希望引起大家的參與，書面文件和範例是必須的。

對於Difio，我寫了一個詳細的README檔案，因為該程式有多個子系統（訊息傳遞、cron呼叫等），它有很多配置方式。我建立的第二個文件是一個內容管理指南，因為有些東西需要手動調整，這兩個檔案囊括了Difio最重要的設計和部署功能。不過，你可能需要為你的專案寫更多的其他文件。

8. 建立一個公共程式碼庫

你需要建立一個公共的程式碼倉並往上推送軟體程式碼。

對於Difio，我決定複製整個difio/目錄下的內容，進行初始化提交。這樣以來，以前的歷史就無法使用了，但我仍然決定這麼做，以避免洩露在硬編碼中的一些金鑰和密碼。在實際開發中，由於我的雲環境中使用了Git部署，Git子模組取代了difio/目錄，這縮短了釋出/部署週期。

從現在開始，你對原始碼的一切操作都應該公開進行。

9. 獨立部署一個新的測試環境

直到最近，你可能一直在本地副本里操作來自於特定版本的應用程式，比如繼承關係、環境配置等等，但在一個新的環境裡從外部使用者的角度測試將會幫你進一步完善文件，清理遺留問題。

在測試Difio的時候，我發現了幾個缺失的或過多的需求、缺少或不恰當的設定、錯誤和不完整的文件。

你需要不斷的重複修改、測試，直到每一步都是合理的、開箱即用的，這將確保你的使用者和未來的貢獻者可以順利安裝你的軟體。

10. 對外宣佈

這是最後一步了！寫一篇    文章，對外宣佈你的軟體開源的資訊。

祝賀你！現在你已經完成了從閉源到開源的轉換！