另外 Adium 其实是个非常好的开发群体，非常 active & helpful，只是项目庞大到了这样，bug tracker 里的 ticket 一多，开发者自己也很难保证代码结构足够好了。

因为最近开始使用 MSN 群 (1, 2)，但我使用的 MSN 客户端 Adium 并不能将群内发言人的身份显示出来，只能全部统一显示为群本身的名称。

其实这是 Adium 所使用的 IM 协议支持库 libpurple 在支持 MSN 协议上固有的缺陷 — 不过也不算特别严重的缺陷，因为 Windows 版本的 MSN 也只在 Windows Live Messenger 8 以上才支持，而 Mac OS X 下的 Microsoft Messenger 干脆到现在也不支持。

所以，要修复这个问题，必须从 libpurple 上打主意，然而，因为 libpurple 编译不便 (后面我会解释为什么这么说)，Adium 本身的代码仓库中只提供了编译好的 libpurple framework，编译这个 framework 的步骤则是分离出来的，要单独用 Utilities/dep-build-scripts 下面的脚本来完成。

可是问题变得越来越 tricky 了：为了编译 libpurple 的代码，必须下载整个 pidgin 的代码，但 pidgin 的代码又是用臭名卓著的 Monotone 来管理的，这直接导致下载当前代码的步骤就变得复杂无比，更不用说后面的编译了。

这还没有完，崩溃的是，Adium 虽然其他协议的支持都是直接从 libpurple 来的，但偏偏 MSN 协议最近改用了从 libpurple 中 fork 出来的 msn-pecan 项目，而 msn-pecan 又是用 git 来管理代码的……

这么一来，为了修改 MSN 协议支持并编译出 Adium，我们必须至少涉及三套版本管理系统 (Subversion, Monotone 和 git)，把 Adium 提供的一堆错综复杂的脚本找出来，让它先给 libpurple 打上 Adium 自己的 patch，然后分 ARCH 来生成 configure 并分别配置编译，最后合并成 Universal Binary 再 copy 回 Adium 的 Frameworks 目录去… 到这里我还没开始改一行代码呢！

虽然这个问题最终得到了解决，我提交的 patch 也将合并到 msn-pecan 官方的代码中去，可是这个经历仍然让我觉得颇有体会：

从 F/OSS 项目的贡献者来讲，要成功的参与项目，就必须掌握好常用的版本管理工具并了解基本的编译手段，才有机会参与到真正的代码修改中去。

而从 F/OSS 项目的发起和维护者来讲，要创造一个成功的项目，应该：

1. 避免使用怪异的版本管理工具
2. 编译步骤简单再简单，尽可能分解为可以单独执行调试的步骤，尽可能减少会在编译时出现的问题