开发模式

　　现有的成功的开放源码开发模式有很多种，其中最常用的有两种:

　　1. 小型开源软件开发模式

　　其特点为核心开发人员很少，一般为1～2 名，核心开发人员承担主要的开发工作和维护相应的网站，用户会提出错误报告和提供少量的错误修正。一般很少采用CVS 来进行代码管理，而是定期发布新版本。一般没有明确的开发计划和日程安排，其软件更新速度和质量取决于核心开发人员的投入程度和水平。

　　2. 中型开源软件开发模式

　　其特点为拥有3～5 名核心维护人员，参与开发的人员10到40 人之间，采用CVS 进行代码管理，通过Maillist/IRC进行开发交流，有明确的开发计划和日程。用户提出的错误报告和修正数量很多，并且有一些分支产生。

　　除此之外，还有其他一些开发模式，比如完全封闭的商业开源软件、比较封闭的大型开源软件的开发、由商业软件转化过来的大型开源软件开发、“独裁”式的大型开源软件的开发、“民主”式的大型开源软件的开发。一般说来，根据项目的规模，我们很容易确定一种开发模式。我们这次实践采用的是“中型开源软件开发模式”，并根据我们自己的特征做了适当的调整。

　　不过，如果项目规模在中型以上的话，可以考虑同时采用多种不同的开发模式。最初我们曾经考虑全部严格遵循软件工程，并借鉴小组软件开发过程的思想。整个开发周期计划为16个星期。项目采用迭代式开发，分为两个阶段。但很快发现一个现实: 面对一个松散的开源团队，单纯的较严格开发方式有时反而并不高效，于是我们调整了开发方式。我们在项目中根据功能的需要，在某些独立模块的开发上采用下面两种开发方式。

　　首先，对于需求非常明确、有相当的把握开发成功的、成熟的独立模块，可以交付给熟练的开发人员独立开发，开发人员可以按照自己喜爱的开发方式，只要在规定的时间内完成即可，不必严格遵循团队的整体开发流程，但要保证开发模块的质量。

　　其次，对于无把握的或需要探索的新功能、新模块的开发，由于风险很大，所以也独立进行。要求本模块的开发人员在较短的时间内完成原型系统的开发。因为只是对新功能的示意，对其代码质量不进行要求，但需要能够快速完成、并明确结构的总体设计，便于真实系统的应用。

　　这样，整个开源团队就存在三条并行前进的线路：遵循软件工程进行迭代开发的主团队、进行成熟模块开发的小分队，以及进行新功能尝试、探索的探险队。项目的最终成功开发证明我们的这种开发方式确实是一种成功的开发模式。

　　人员交流

　　在这里把交流单独列为一节，足以表明交流在开发中的重要性，尤其是在开源项目中，由于各个开发人员不在同一间办公室中，因此往往缺乏最直接的交流。网络的出现，虽然在一定程度上缓解了交流的困难，但也在一定程度上掩盖了交流问题的严重性。

　　在交流上最大的误解就是很多人误以为“开源开发只要通过电子邮件进行交流就足够了”。在我们这次开发中，我们发现其实这是远远不够的。如果可能的话，面对面的交流依然是最有效的交流方式，尽可能找到你的同伴，当面说清你的问题，进行面对面的谈话。

　　即时通信工具，如QQ、MSN等，已经成为第二高效的交流方法了。其他交流方式，如网络语音聊天工具、论坛、手机短信息、邮件列表、网络会议、电子邮件等几乎全部能够想到的方式几乎都被我们采用了。而且事实证明这依然毫不过分，交流是最重要的，而且是最容易欠缺的。

　　时间风险

　　由于是开源项目，很多时候成员的工作时间得不到保障。通过我们这次实践，建议项目管理者把实际开发时间定为预期开发时间的1.5倍甚至2倍左右。图2是我们这次开发中成员的工作时间统计情况，横轴是从项目启动到结束的时间，小格代表一天，大格是一个开发周; 纵轴表示各个成员，图中深色的部分表示成员完全不能参与工作的时间段。

图2 开发成员的工作时间统计

　　从图中可以看出，在整个开发过程中，存在着大量的成员不能参与工作的时间段，具体的原因主要有“五一”长假、期末复习、假期回家、外出等。虽然看上去都只是一些偶然因素，但其实已经是开源项目中不可避免的一些影响因素了，在做计划时需要特别注意。