开源项目应选好管理方式

　　开放源码这一开发模式是近几年在国际上非常流行的一种软件开发方式，相信很多人已经耳熟能详了，但其实在国内亲身参与过的人并不多，而且很多人认为这种在国际上很成功的开发模式，在中国有些“水土不服”。本文作者结合自己的亲身实践，对开源项目的管理方式提出了很多值得参考的建议。

　　在中国，成功的开放源码项目并不多，如果再去除那些以传统形式开发成功后再公开源码的项目，纯粹的开源项目就更是屈指可数了。笔者刚刚组织了一个历时近4个月的开源开发项目——天网千帆开放源码文件搜索引擎项目，该项目运作比较成功。通过这次尝试，笔者对开源开发这一模式有一些认识和感受，并总结了一些在实践中得到的经验，希望对其他想进行开源开发的读者有所帮助。

　　前期准备

　　一般说来，每个项目都会有一个项目的提出者。在实际中项目提出者往往也会成为整个项目的中心人物甚至负责人。在开始开源开发之前有必要进行一些前期的准备。主要包括对项目本身的评估和对开源开发的一些基本知识的了解。其中对项目本身的评估包括: 项目的规模、对开发者的技能和人数的要求、项目的预期开发时间，个人能够付出的时间和精力等。

　　在前期准备中，容易忽视的一点就是组织者对自己的把握。尽管开源项目有很多志愿者的协助，但实践中，组织者本人往往是项目中最重要的一个人物，往往也会花费较多的精力，因此有必要在项目开始前确认自己是否有足够的技能和精力来运作这个项目，不打无准备之仗。

　　在这个阶段最重要的一点就是明确自己提出的项目是否适合进行开源开发，因为并不是任何项目都适合进行开源开发的。其次就是明确需要的人力、物力和时间等因素。

　　人员招募

　　一般说来，开源项目的人员招募通常可以采用以下方法: 从身边入手，拉上几个志同道合者; 或者在开源项目网站上注册自己的项目计划，吸引开发者; 也可以通过自己的网站或其他活动进行宣传。

　　其中第一种方法比较常见，在小的开源项目中还是不错的方法。同身边的人一同开发在交流合作上都比较方便。但是如果项目较大、需要的开发人员较多的话，往往就不能满足要求了。如果采用第二种方法的话，最好考虑sourceforge等知名度较大的网站，在中国有“共创软件联盟”www.cosoft.org.cn) 等网站。不过采用这种方法一定要确保项目有足够的吸引力，在项目介绍上写清楚自己对整个项目的规划、对人员的要求，否则也许会发生过了一两个月还没有人报名的尴尬局面。如果项目不是从第一个版本开始开发，并且早期版本已经有一定的影响力的话，也可以采用第三种方法，自己撑起一面大旗，招兵买马。

　　国内做过志愿者的开发人员并不多，是不是因为大家都没有兴趣呢?笔者曾经做过一次调查，询问北大天网的用户是否愿意参与我们项目的开发，共485人参与了本次调查，结果如图1所示。可以看到，虽然目前国内有开源开发经历的人并不多，但有热情、想作为志愿者参与开发与运作的人还是相当多的。

　　在天网千帆开放源码文件搜索引擎项目中，我们采用了第三种招募方法。首先进行了一场类似“宣讲会”的报告，然后在我们的网站上发布了一个广告。由于我们的网站访问量较大，报名的人数也比较多，10天之后就有100余人报名。

　　如果报名人较多，有必要筛选一下。筛选时要注意，除了技术之外，开发人员的热情和时间也是非常重要的因素。另外，在很多时候，尽管有很多报名者，我们依然很难找到理想的技术人员。但其实完全不必为此担忧，技术都是很相近的，只要找到懂相关技术的人就可以。比如在我们这次开发项目中，多数人对要开发的系统都缺乏经验，但项目依然取得了成功。

　　下面谈谈在人员招募的过程应当注意的两个问题，主要针对初次涉足开源开发项目者。

　　首先，如果可能的话，应当确保团队里至少半数志愿者能够进行一周一次的面对面交流。虽然我们可以通过网络与远在地球另一端的开发者进行实时交流，但如果绝大多数开发人员彼此都不能见面的话，沟通的代价和难度都将远远超过我们的预期。

　　其次，在我们的印象中，国外的开源项目的开发者往往是一些技术精英，因此我们通常也希望招募一些技术高手。不过在实践中，一方面这样的高手很难找到，另一方面大家也大可不必如此在意技术水平。因为国内整体开发确实同国外还存在一定的差距，另外如果一个团队里有一半高手，一半水平中庸，技术水平相差过于悬殊的话，反而不利于开发。

　　开发模式

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

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

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

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

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

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

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

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

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

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

　　人员交流

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

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

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

　　时间风险

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

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

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

原文转自：http://www.ltesting.net