开发者和用户

后记：写得似乎语无伦次，诸位将就吧。

说起来，翻译amarok那篇开发者写的关于mysql的内容其实是因为感同身受。

用户的要求和开发者的要求有时候是冲突的。比如对我来说，我希望的是代码容易维护，易于扩展，而不是像贴补丁一样的东贴一份西贴一下，用户最终只关注功能，如果一个程序好用，谁管你用的什么方法。

从今年一月开始为fcitx做了第一次提交以来，我做的很多修改其实对于最终用户来说，没有太大的意义。比如配置文件的格式为什么要变化，比如为什么要用utf8。有一些理由其实很有意思的。在4.0终于要发布正式版的时候，有点想把这些写下来，当然各位也可以拍砖，也可以表达不同的意见。

第一件大事，采用utf8，这其实出于很多理由，但是最直接的理由其实仅仅是“啊有个编码转换的bug调试不出来”这样而已。当然这个bug的结果其实是我对于32位和64位编程的不了解造成的。utf8当然也会带来很多的好处，比如gb18030的编码其实是变长的（四字节），原来很多地方都是按照两字节来取的，这样其实甚至无法采用gb18030字符集里面的一些文字。当然utf8也是汹汹主流，于是还是用了utf8，当然出于一时偷懒没用unicode，算是一个折中的办法。

其次是t3swing兄开发的皮肤功能，我和他邮件讨论了很多次，包括究竟采用哪个库做绘制。考虑到gtk和qt是使用什么库进行的绘制问题，其实就是用png比较方便，于是就用了cairo。

这里列出两封我的邮件：

“现在我觉得字体有两个解决方案，一个是再用上pango（囧，离gtk越来越近了），一个是得手动指定locale，pango比较好的一点是对于非zh_CN的locale也可以比较正常的把字体显示出来，但是也多了个依赖，以前我用过pango的python绑定，还蛮简单的……我觉得先上pango好了，看看大家的反应…cairo应该说没做什么国际化的工作，另外中英文字体不用分开指定了……用一个字体好了，剩下让fontconfig去解决…”

“不行……我纠结了……pango依赖上glib了……还是算了= =b，洁癖了”

那会其实我已经在纠结字体问题了。

还有就是调整代码的问题，一口气把代码分了目录，这样其实也方便我找一些代码，也方便将来独立出去，其实是换汤不换药的行为而已……

比较重要的就是改配置文件的时候，那会还用上了uthash这个开源的hash表的头文件（BSD License），其实改了很久很久，一方面效率不高，中间也有各种事情，于是最后在8月中旬才提交上去，其实之前不少代码是在github的fcitx-clone里面放着的。当时也是想赶快改出来，起点作用，然后慢慢把所有配置文件都迁移过来。那会皮肤的配置其实还是后来迁移过来的。这有一个非常大的好处。fcitx配置变化了，增加了选项，那么fcitx-config完全不用重新编译，直接就可以用了。这在老的fcitx是难以实现的。并且这部分变成了动态库独立出去之后，其他程序（例如fcitx-sunpinyin）也完全可以使用这个库作为配置文件的读写，并且反过来用fcitx-config支持它的配置文件编辑。配置文件变成英文主要是考虑到不同locale实在是难以协调，于是就这样了。当然后来想起，可以按照当前locale输出下注释，这其实是后来的功能了。

再后来就是写fcitx-sunpinyin，差不多同时发了beta1。其实我非常想优化拼音的算法，甚至准备了论文打算读，不过后来还是作罢了。做的事情太多什么都做不好。既然sunpinyin有一个完整的团队在做这么优秀的输入法，何必分散自己的力量呢？

beta1之后的修改就很少了，比如说改掉灰了吧唧的菜单和皮肤的集成，一个拼音的小功能（ng/gn）。

最后就是采用了pango。还记得我前面对pango的纠结了吗，其实我一直在纠结……比如fcitx只用cairo画字体，那么只能画一个字体。多国输入法的字符无法显示怎么办？引入pango主要是出于字体的考虑。引入pango其实只修改了极少量的代码，这就是抽象的力量。所有fcitx里面的文字绘制都统一到了一个函数上面，因此对这一个函数进行修改的话，其实只要修改这一个函数就够了，这次我还是使用了git帮助我分支。

讲了这么多，还没讲到用户身上，似乎有点跑题。现在就来说一说我的一些个人感受，其实google code里面还有很多issue，为什么我只是加了邮件列表中的，其实还有很多需求，比如拆字输入什么的，当然一方面是暂时手头没有类似的数据，另外一方面主要是ng/gn可以很快的利用当前的模糊音的架构扩展进去，所以才实现了这个功能。

其实我主要想表达的是我在进行一些修改时考虑的问题，我全身心的投入想要为用户着想了吗？似乎并没有，很多时候其实仅仅是想到了这个很有意思，这个代码应该这么改才好。这就是开发者的偏心吗？尤其是开源软件，并没有一个明确的需求的前提下，开发者其实都是自己确定需求，自己实现的。比如ibus-cloud-pinyin，老实说我并没用过，但是使用说明让我觉得它带有着浓浓的开发者的特色。开源软件有趣的地方在于开发者会很乐意采用自己的方式来实现功能，这和用户的要求在某些情况下总是会有冲突。因为多半开发者也是一名自己开发的软件的忠实用户，他觉得最重要的问题可能他会优先考虑。

这都是都避免不了的，但也并非是一个缺点。用户和开发者之间的关系并不那么紧张，开源软件的问题反馈其实说起来要比其他商业软件要快得多，也许你今天汇报了一个bug，开发者觉得顺手就把它改了，这都是很正常的事情，开发者并不是和用户对立的，相反他们也乐于接受用户的意见。

“编程为什么有趣？作为回报，它的从业者期望得到什么样的快乐？ 首先，这种快乐是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到的快乐一样，成年人喜欢创建事物，特别是自己进行设计。我想这种快乐是上帝创造世界的折射，一种呈现在每片独特、崭新的树叶和雪花 上的喜悦。其次，这种快乐来自于开发对他人有用的东西。内心深处，我们期望我们的劳动成果能够被他人使用，并能对 他们有所帮助。从这一角度而言，这同小孩粘土为“爸爸的办公室”捏制铅笔盒没有任何本质的区别 。第三，快乐来自于整个过程体现出的一股强大的魅力――将相互啮合的零部件组装在一起，看到它们以精妙的 方式运行着，并收到了预先所希望的效果。比起弹球游戏机或自动电唱机所具有的迷人魅力，程序化的计算机毫不 逊色。第四，这种快乐是持续学习的快乐，它来自这项工作的非重复特性。人们所面临的问题总有这样那样的不同， 因而解决问题的人可以从中学习新的事物：有时是实践上的，有时是理论上的，或者兼而有之。 最后，这种快乐还来自于在易于驾驭的介质上工作。程序员，就像诗人一样，几乎是仅仅工作在单纯的思考中 。程序员凭空地运用自己的想像，来建造自己的“城堡”。”——《人月神话》

对于开源软件来说，用户对他们应该更加宽容，他们也许仅仅是想从自己的工作中获得他们认为应得的乐趣。