也紀念我們永遠的朋友 李士傑先生（Shih-Chieh Ilya Li）。
將封閉式軟體遷移到開源的 10 個步驟
將封閉式軟體遷移到開源的 10 個步驟
◎本文翻譯自 opensource.com ，原作者為 Alexander Todorov： https://opensource.com/business/14/5/10-steps-migrate-closed-to-open-source
Difio 是一個 Django 的基本應用程式，其對軟體包 (packages) 保持追蹤，當軟體包產生改變時它會告訴你。它提供了多變化的分析，讓你在何時或如何升級上可以做出明智的決定。Difio 是個封閉的軟體，然而我決定將它遷移至開源，以便於在內部部署以及吸引更多的社群參與這個項目。
簡化：
任何一個已經存在好幾年的應用程式，將不再使用其累積的代碼和功能。為了得到一個更乾淨、更簡單的共享代碼，刪除掉可以安全刪除的一切。開源 Difio 從移除約 20％ 現有代碼庫開始進行。
移除的部份包括了：
- 未使用和過時的設置
- Django 的應用程式
- 靜態文件和模板
- 模型類別
- 傳統的 URL
- 不適用的功能
- 其它 Python 公用程式
對於額外的依據和一次性的代碼，例如，我曾在一些模板和純 HTML 中使用 markdown 。也有一些只使用在一兩個地方的自定義的模板標籤。而所有的這些都已經刪除，模板之間更為相容一致。
當做快速的原型設計時，確實的編碼路徑、價值觀、網址…等是照例必須要有的。在某些時候，一個封閉源碼的應用程式除了繼承其部署環境的物件也繼承了這些需要進行清理的事務。我已使用自定義的模板標籤以及將其設置在需要的地方。
創建自含式的模組：
換句話說，重新組織文件的結構，不只變得簡單也使事情更自然了一些。讓模塊自成一體並且各自獨立，將使它更容易在之後分離。Difio 的 Web 後端部署在 OpenShift，它對模板和靜態文件使用了不同的目錄佈局。為了使他們能夠正確加載，我必須移動文件和更新 Django 的設置。這也使我重新思考從原始的靜態文件移至 CDN 後台的方式。
來自外部的獨立內部：
在你的應用程式裡存在一些內部代碼來為你提供更多的訊息，這是很自然的事。例如，使用追蹤和其他度量標準及佈告排列次序等。在基於網路服務的情況下，這些通常與核心功能整合在一起，但需要獨立分開。
這也是一個很好的機會來決定什麼該捨棄而什麼該留下。例如，Difio 不出貨的測試案例，因為他們需要在 CI 環境裡做更多需要乾淨分離的工作，並同時運行整個 Web 服務和反對獨立的應用程序。
Difio包含五個不同的模塊：
- Difio ／（核心用戶體驗）
- 一個概況子系統 (a profile sub-system)
- 佈告排列次序的模塊
- 擴展管理界面
- 與部署相關的模塊（主要是設置）
將這些正確地分離並相互隔離，以去除外部和內部的依賴關係。而目前 Difio/ 依賴於幾個配置文件的 API，為其提供正確的默認值。這個步驟也可以幫助你從核心用戶體驗方面來分割操作物件（如定制的電子郵件模板）。
代碼的重構：
這不需要多說，重構和測試應該是一件要持續努力的事。然而，到現在為止，你可能已經對整個（或大部分）現有的資源代碼做了快速的審查，並已經注意到很多東西需要改進。而現在有機會這麼做。
這也是一個很好的機會來創建一個簡短的路線圖，並將錯誤修正預先加載到你的公共問題追蹤裡。當找不到新的貢獻者時，它會幫助你的新生項目展示活動並在創業初期做持續的改進。
隨著 Difio，我主要是在內部重構了一些方法，讓他們適應新的應用程式結構。而外部的方法在留下後修復它，因為它們還是不錯的，並不需要重構。
法律工作：
根據使用軟體的規模和複雜性以及你的組織，遷移到開源可能是相當耗時的。一切應該被考慮在這一步：從選擇合適的許可證、品牌、命名個別作者、做法律審查，以及尋找潛在的專利侵權代碼。
對於 Difio，這簡單得多。我選擇了 Apache 2.0 許可，所有資源文件的表頭許可證，並且妥善地將著作權和版權歸因，因此，我在互聯網上找到了外部代碼（它在大部分時間裡並沒有指定任何特定條款）。
更新列表和外部依賴：
作為一名軟體開發人員，你必須採取額外的步驟來升級到最新版本，並確保你的軟體能與他們正常運作（或至少要相當不錯）。沒有人想與舊的依存關係運行代碼，很多時候，甚至是不可能運行代碼。
也要提供一個依賴列表（例如 requirements.txt 文件），讓人們知道如何在運行軟體之前安裝它們。幸運的是，Difio 是一個基於 Django 的應用程序，只有一些升級上的小問題和中等的外部依賴。
提供文檔和範例：
對任何新人來說，如果在項目中有個文檔，將會是個很好的附加檔案。畢竟這是個開放的東西，也希望吸引到社群。所以，書面文檔和範例是必須要有的。
對於 Difio，我寫了一個關於設置 README 的詳細文件，因為應用程式有多個子系統（消息傳遞層、cron 的調度等），其可以在無數的方法中被構建。我建立的第二個文件，是一個內容管理指南，因為不是一切的應用程序都是自動的，有時也需要手動調整。這兩個文件總結了 Difio 最重要的設計和部署功能，但你可能需要為你的項目編寫更多的其他文件。
建立一個公共代碼庫：
時間會建立一個公共代碼庫並將軟體推至上游。
對於 Difio，我決定複製其先前位置的整個 Difio/ 目錄，並做一個初步的提交。雖然這有個缺點，所有以前的歷史紀錄都將不能再使用的，但我已經決定要走這條路，為了避免洩露秘密密鑰和密碼，那些在確實編碼的過程中，代碼的某個點。
在產生的過程中，Difio/ 目錄被 git 的子模塊所取代，以便發布／部署週期能更為快速，而這主要是因為我在雲端環境中使用 git 的部署機制。
從現在開始，你做的一切資源應公開地進行。
在一個新的環境測試單機部署：
直到最近，你可能一直在你現有的本機副本內努力著，並繼承所有來自專有版本應用程序裡的各種因素，像是依賴性、環境配置…等等。如果在一個（或多個）新的環境中，從外部用戶的觀點進行測試，將能幫助你進一步地細化你的文檔以及清理遺留的問題。
在測試 Difio 時，我發現了幾個缺失和過多的要求，例如缺少和不恰當的設置、一些錯誤和不完整的文檔。
將這些完成後，重新開始、再次重複，直到每個步驟都是正確的解釋並能在機箱中適用！這將確保未來的貢獻者和用戶至少能夠安裝你的軟體。
將它宣布：
這是最後一步！寫下你的新聞稿，並向世界公佈新的軟體。恭喜你，現在你已是開源的了！
專欄總覽
E-Mail：[email protected] Address：台北市南港區研究院路2段128號 中央研究院資訊科學研究所 . 隱私權條款. 使用條款
