【51CTO精选译文】Difio是一款基于Django的应用程序，旨在追踪软件包状态并在其发生变化时通知用户。它提供多种变更分析选项，因此大家可以根据当前掌握的情况决定何时或者如何实施软件包升级。Difio本身是一款标准的封闭软件，我决定把它转化为开源项目以实现家庭开发并为其吸引到更多技术社区参与者。
简化
任何一款已经面世数年的应用程序当中都必然积累下一些不会再被用到的代码以及功能。将这些无关紧要的部分加以清除能够保证需要共享的代码内容更纯粹也更简洁。Difio开源化工作的第一步正在于此--将现有代码库的规模降低约20%。
具体工作内容包括：
- 未使用或者已经过时的设置
- Django应用
- 静态文件与模板
- 模型类
- 遗留URL
- 不建议使用的功能
- 其它Python公用工具
举例来说，在处理额外的依赖关系以及一次性代码时，我过去一直习惯于将其记录在某些模板以及纯HTML当中。我也设置过一些只使用过一、两次的自定义模板标签。这一切都属于被删除的对象，最终保留下来的模板彼此之间都保持着较高的一致性。
对路径、值以及URL等要素进行硬编码无疑是快速原型设计工作中无法回避的组成部分。在某些情况下，闭源应用程序会继承其开发环境所遗留下来的某些特征，而这些也需要加以调整。我曾经在必要时使用过一部分自定义模板标签与设置。
创建自包含模块
换句话来说，对文件结构的重新构建也在实现简化的同时让应用本身显得更加自然。创建自包含与独立模块使我们今后能够更轻松地将它们彼此拆分开来。
Difio的web后端被部署在OpenShift之上，其中针对模板与状态文件使用了不同的目录层。我需要移动这些文件并更新Django设置，从而让它们能够更为恰当地进行载入。这也迫使我重新思考该如何将原始静态文件发送至CDN后端。
将内部与外部代码划分开来
在应用程序当中使用一部分内部代码以提供更多信息可谓理所当然。举例来说，我们在实现使用情况及其它指标追踪、计费乃至其它功能时，内部代码可谓不可或缺。在web服务方面，这些代码往往会被整合到核心功能当中，因此作为开源转化工作的重要部分、我们需要将其划分出来。
着手转化的过程也让我们得以判断哪些内容需要被划分出去、哪些最好继续保留其中。举例来说，Difio不会将测试实例划分出去，这是为了减少将其从CI环境中明确划分以及完全以web服务或者独立应用方式运行所带来的额外工作量。
Difio当中包含五大独立模块：
1. difio/ (核心用户体验所在)
2. 配置文件子系统
3. 计费模块
4. 扩展管理员界面
5. 相关模块部署（大部分设置来源于此）
以上模块彼此之间被明确区分开来且保持相互隔离，所有输入与内部依赖关系都被移除。目前difio/依赖于多个配置文件API以提供正确的缺省值。
这一步骤还能帮助大家将操作组件（例如定制化电子邮件模板）从核心用户体验当中拆分出来。
代码重构
无需赘言，代码重构与测试也应当作为一项需要持续关注的工作内容。不过到现在为止，大家可能已经对全套现有源代码（或者其中的大部分）进行了快速审查，而且初步明确了其中哪些部分需要加以改进。开源转移也是提升软件水准的好机会，我们应当好好把握。
此外，我们也可以借此机会构建起一套短期路线图，其中包含需要修复的漏洞等之前收集到的公共问题信息。这套路线图能帮助大家的新生项目在诞生之初表现出更为旺盛的活力与改进态势，这些特性是吸引更多贡献者加入进来的关键所在。
在Difio当中，我对一部分方法以及大部分内部代码进行了重构，旨在使其更好地与新应用程序结构相吻合。外部方法则姑且放在一边、等待今后修复，毕竟这部分改进属于"锦上添花"而非"雪中送炭"。
法律工作
根据软件规模与复杂程度的不同，大家在对其进行开源化整理与迁移时所需要付出的时间周期也会出现巨大差异。从选择合适的开源许可、塑造品牌、在产品中注明作者、进行法律审查并寻找可能存在专利侵权可能性的风险代码等等，这一切都是我们需要提前考虑的问题。
不过在Difio方面，这部分工作就简单得多了。我选择的是Apache 2.0许可，将许可标题添加到全部源文件当中，并妥善解决了自己能在互联网上找到的全部与外部代码相关的著作权与版权问题（在大部分情况下，应用本身不会就此提出任何特定条款）。
更新并罗列外部依赖关系
作为一名软件开发人员，大家必须要采取额外的处理步骤来应对其它应用程序的最新版本升级，同时确保自己的软件能够与它们保持顺畅协作（或者至少要保持合理的协作效果）。没人愿意为了运行大家的代码而被迫使用旧有依赖关系，而且在大多数情况下这也是根本不可能的。
另外，大家还需要制订一份依赖关系列表（例如requirements.txt文件），用于帮助使用者了解如何在运行软件之前安装其它必要程序。幸运的是，Difio是一款基于Django的应用，因此升级问题很少、对外部方案的依赖关系也不是太强。
提供说明文档与示例
对于任何一位刚刚接触我们开源项目的新人来说，说明文档的意义都可谓至关重要。毕竟我们的目的是建立起一套极具吸引力的社区，因此保持其开放性是实现目标的必要前提。而在这方面，撰写说明文档与示例就成了重中之重。
在Difio这边，我编写了一份README文件，其中详细描述了与设置相关的各项内容--这是考虑到该应用拥有多套子系统（包括消息传递层以及计划任务调度等），而这些子系统可以通过多种方式实现配置。我编写的第二份文档则是《内容管理指南》，很明显并不是每项工作都能够以自动化方式完成、手动机制偶而也需要参与进来。这两份文档涵盖了Difio当中最为重要的全部设计与部署特性--不过除此之外，大家可能还需要为自己的项目准备更多说明文档。
创建一套公共代码库
现在是时候创建一套公共代码库并着手进行软件交付了。
在Difio开源项目中，我决定把整个difio/目录从原有位置复制出来作为最初的提交内容。这样做的弊端在于此前所有历史提交内容都将不再可用，但我选择这种作法是为了避免已经被以硬编码方式添加到代码片段中的密钥与密码遭到泄露。
在生产过程中，我利用git子模块取代了difio/目录;这一方面是为了加快发布/部署周期，另一方面则因为我的云环境选择了git作为部署机制。
从现在开始，大家对源代码进行的一切调试及修改都将以公开方式进行。
在全新环境下测试单机部署
截至目前，大家的注意力可能一直集中在对现有本地副本的调试以及对应用程序前续版本遗留下来的内容--例如依赖关系、环境配置等等--进行遍历上。不过接下来我们需要转换思路，从外部用户的视角出发在全新环境下着手测试--这能够帮助我们进一步完善说明文档并清理遗留问题。
在对Difio进行测试时，我发现了几项之前忽略掉的或者刚刚出现的运行要求、缺少或者未经恰当处理的设置方式外加一些存在错误或者内容不够完整的说明文档。
在这部分工作完成之后，别急着休息、从头开始再进行一次，直到每个步骤都拥有正确的解释并适用于作为运行基础的全新设备。这至少能够确保未来的项目贡献者及用户能够顺利地将软件安装在自己的计算机上。
发布
终于迎来了最后一项工作！写下属于自己的宣传稿件，并向全世界介绍自己的这款新软件。祝贺各位，从这一刻时你已经正式步入开源阵营！
原文链接：http://opensource.com/business/14/5/10-steps-migrate-closed-to-open-source
