从一道作业题谈一点开源规范
在 William Stallings 的操作系统教材《操作系统——精髓与设计原理》中有一个编程实验题，开发一个简单的 shell 程序，在题目中，要求实现一个基本的 shell 功能，然后是下面的一些要求：
- 设计一个简单的命令行 shell，满足上面的要求并且在指定的 UNIX 平台下执行。
- 写一个关于如何使用 shell 的简单用户手册，用户手册应该包含足够的细节以方便 UNIX 初学者使用。例如，你应该解释 I/O 重定向、程序环境和后台程序执行。用户手册必须命名为 readme，必须是一个标准文本编辑器可以打开的简单文本文档。举一个描述的类型和深度的例子，你应该看一下 csh 和 tcsh 的在线帮助(man csh,man tcsh)。这两个 shell 显然比你的 shell 有更多的功能，你的用户手册没必要做的那么大。不要包括编译指示——文件列表和源码，我们可以从你提交的其它文件中找出来。这应该是操作手册而非程序员手册。
- 源码必须有很详细的注释，并且要有很好的组织结构以方便别人阅读和维护。结构和注释好的程序更加易于理解，并且可以保证批改你作业的人不用很费劲地去读你的代码。
- 提交内容为源代码文件，包括文件、makefile(全部小写)和 readme(全部小写)文件。批改者会重新编译源代码，如果编译不通过将没有办法打分。
先不论题目本身的难度，就这些要求来说，已经是非常严格了，比如必须包括一个用户手册，对于用户手册，应该包含足够的细节，大部分用户不是程序员，他们不想为了寻找某个功能的使用方法而去阅读源代码，他们更不会去读源代码以寻找更多你的手册中没有写出来的功能，他们唯一愿意做的就是 remove，然后搜索其它。如果开源从根本上的利益是获得成就感，那么你真的需要去重视你程序的使用指南，开源可不是扔一堆源代码出去就完了。
在 UNIX 系统下，对用户手册有比较严格的要求，比如必须是简单的文本文件，只要有文本编辑器就可以打开阅读，同时也可以使用 man 命令查看，请不要使用极具平台特色的文件，比如 doc 什么的。文本文件也因为简单而有一些弊端，比如在排版上很难，解决方法有很多，比如使用标记语言，比如 Markdown。对于复杂拥有庞大主题的文档，在线手册也很有必要，比如你可以使用 Github 的 Page 或者 Wiki，在线托管文档的 Read the Docs，在 Python 下，可以使用 Sphinx 制作排版生成文档。
对于开源软件，也要照顾一类特殊用户，他们想要通过你的源代码学习编程，或者想 hack 一下你的源代码，让它变得更好（也有可能变的更坏），所以你的源代码须要清晰简洁，注释适当，组织结构要好，以方便他人的阅读与维护，没有协作的开源是很难生存下去的开源，这就是 Github 会非常火的原因。对于 UNIX 或者类 UNIX 下的开源软件，只需要提供源代码文件，编译指示(通常一个 makefile 文件)就可以了，不用提供已经编译好的二进制文件，因为平台特性，可能会出现兼容问题，不过使用包管理也不错，在这方面不是很熟，所以也就不扯下去了。
开源这个词似乎还是在国外比较流行，从这个教材的这套题就可以看出，当然也免不了因为 Stallings 先生也是从当年的 UNIX 开源运动中过来的，对开源世界存在好感。而在国内大学，开源这个词还是比较遥远的，这不免我又得吐槽学校机房的那一台台 Windows XP和上面的 VC++ 6，数据库实验用的 SQL Server，连唯一在操作系统实验中使用的 Linux 系统都是装在虚拟机上的。这也可能是利益原因，因为使用 Windows 下的那堆东西可以申请经费，然后买个盗版盘，轻松装机，感觉还不错。
我得开始自我反思了，放在 Github 上的几个小玩意儿，极其混乱，文档不足，代码格式不规范。俨然已经将 Github 当成堆放代码的地方了，而不是展示作品和协作开发的地方，虽然水平还不是很高，至少要有模有样。