开放源代码工程组织

-- ZoomQuiet [2004-12-22 11:44:35]

1. 资料收集

1.1. 项目管理系统

1.2. 开源开发模式

[WWW] OpenSource的开发模式探讨 <转载>

1.2.1. 现有成功的Open Source 开发模式介绍和分类以及优缺点

1.2.1.1. 现有的单个软件的 Open Source开发模式

  1. 小型OpenSource软件开发模式

    • 典型实例：Linux Virtual Server Project（www.linuxvirtualserver.org）其特点为项目的核心开发人员很少，一般为1-2 名，核心开发人员承担主要的开发工作和维护相应的网站，用户会提出错误报告和提供少量的错误修正。

      一般很少采用CVS 来进行代码管理，而是定期发布新版本。一般没有明确的开发计划和日程安排，其软件更新速度和质量取决于核心开发人员的投入程度和水平。目前采用这种开发模式的GNU 软件最多。而SourceForge.net 的出现又简化了这部分开发人员的重复工作。

  2. 中型Open Source软件开发模式

    • 典型实例：GTK （www.gtk.org ）

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

  3. 完全封闭的商业Open Source软件

    • 典型实例：QT（www.trolltech.com ）

      其特点为软件完全由商业公司内部开发，用户一般只能提供错误报告，不提供修复补丁，公司定期发布新版本的源代码。其好处是软件质量水平较高，其缺点是如果公司开发力量不足，软件发展容易停滞不前。

  4. 比较封闭的大型Open Source软件的开发

    • 典型实例：XFree86 （www.xfree86.org ）

      其特点为拥有数十名核心开发人员（一般不超过100 名），其中包括3-5 位核心开发人员，只有这些核心开发人员有权提交代码，代码使用CVS 管理，但是对外界不开放只有在发布新版本时外界才可以得到，开发计划和日程明确，发布日期一般准确，但是软件版本升级速度一般比较缓慢。这样开发的好处是代码质量比较平均，所受干扰小，缺点是由于用户不能积极参与开发过程中的测试工作，增加新功能后稳定期较长。

  5. 由商业软件转化过来的大型Open Source软件开发.

    • 典型实例：OpenOffice（www.openoffice.org）Mozilla （www.mozilla.org ）

      其特点为其软件计划开始时是基于一个被 Open Source的商业软件，一般都受到原商业公司的控制，一般都不采用GPL/BSD 形式的License ，一般都采用类似于MPL （Mozilla Public License）的版权，其特点是公司可以享有使用这些源代码的权利，他们的开发工作一般由公司的员工为核心开发人员和领导者，通过CVS 和Bugzilla进行代码和错误管理。拥有正式的QA体系，这种模式一般都进展不是很快，例如mozilla 三年多仍然不能发布1.0 版。主要原因是这种由于这些大型软件开发的起点比较高，因此自由软件程序员加入的数量都不是很多，还有就是由于商业软件公司的背景，使得部分自由程序员不太愿意加入。但是参与测试的最终用户比较多。 Mozilla的下载量一般都在数十万左右。而修复的错误数目也同比增长

  6. "独裁"式的大型Open Source软件的开发.

    • 典型实例：Kernel（www.kernel.org）

      其特点为软件开发人员非常多，一般都在百人以上，任何自由程序员都可以提交自己的修改工作，但是只有领导者（在Linux 核心上是Linus 和Alan Cox）才能够合并这些工作到正式的核心发布版本中。而且他们一般不采用CVS ，只是通过maillist来进行项目管理，交流，错误报告。经常发布新的版本，其好处是软件更新速度和发展速度很快，计划的开放性好，由于最终裁决人只有少数非常有经验的程序员，正式发布的代码质量非常优秀，由于用户数目非常庞大，最终发布版的错误一般都非常稀少。这种方式的缺点是计划的发展方向主要由核心开发人员决定，体现他们的设计思想。不过这个缺点从另外一个角度来说这些核心领导者的远见决定了工程的技术领先性。

  7. "民主"式的大型Open Source 软件的开发.

    • 典型实例：Gnome （www.gnome.org ）KDE （www.kde.org ）

其特点为核心开发人员数目较多，子软件计划非常多，利用CVS 进行代码管理，核心开发小组一般在百人以上，分成若干个小组，每个小组有1-2 个领导者，权限比较分明，有明确的开发进度管理和日程安排，有严密的Alpha ，Beta，RC1，RC2测试阶段。主要开发者定期召开开发者大会，讨论开发中的问题和新版本的设计。拥有自己的开发文档库和编码/ 测试标准。同商业软件公司一样，一般每隔半年左右推出一个正式版本。这种方式是目前效率最高的一种方式，也只有这种开发模式能够承担利用Internet 协作开发KDE/Gnome这种超大型套装软件的开发工作。

1.2.1.2. 现有的Linux 发行版本的开发模式

  1. 完全封闭式

    • 典型实例：Caldera （www.caldera.com ）

      其特点为完全由公司内部程序员封闭开发，在正式产品前不发布任何测试版本，其缺点式显而易见的，主要体现在产品开发周期长，用户参与不足。质量完全取决于公司内部的开发管理水平和实力。

  2. 半封闭式

    • 典型实例RedHat（www.redhat.com）

      其特点为产品在Beta阶段推出1-2 个测试版本，然后推出正式版本。 RedHat内部的开发制度是目前把Open Source 开发模式和传统软件的开发模式结合得比较好的一种，其特点是：公司将技术研发部门和生产部门交叉组合起来，技术研发部门的管理比较松散，其下拥有一批技术上非常领先的自由程序员，主要负责进行技术研发和前瞻性研究，而生产部门采用企业化的项目管理制度，这样的好处是既保持了产品的质量，又保持了技术上的领先地位。而且能够保守一部分技术秘密。缺点是没有强大的研发实力，是没有办法承担这种开发模式的。

  3. 全开放式.

    • 典型实例Mandrake（www.mandrake.com）Debian（www.debian.org）

      其特点是其开发阶段完全向用户开放，随时接受用户的错误报告，内部只维持一支相对较少的开发队伍进行管理和重点程序的攻关工作。其特点是开发速度快，质量稳定，能够最大限度地利用Open Source 社区的力量。缺点是不容易控制开发周期。

1.2.2. 如何将Open Source 开发模式同传统开发模式结合起来

1.2.3. 在中国Open Source 开发模式的现状和前景

  1. 没有形成一个自由程序员阶层.

    • 目前中国的程序员数量并不少，看看在www.csdn.net上的文章和大量涌现的共享软件的数目就可以估计出来，而自由程序员却寥寥无几，目前在国际上有影响的自由软件计划中由中国人带队的只有LVS （Linux Virtual Server，章文嵩）LIDS（Linux Intrusion Detection System谢华刚）还有 MiniGUI ( MiniGUI,蓝点公司魏永明),SBM(Smart Boot Manager,苏哲)四个，其原因可以归结为下面几条：

      • 中国程序员目前的经济情况还处于温饱状态，还必须为自己的生计奔波，因此不能投注更多精力在自由软件的开发。

      • 中国程序员不熟悉自由软件开发的通行模式。一般表现为受传统开发的手工作坊模式影响，不习惯合作开发，对管理一个项目的经验不足。

      • 基于Unix系统的程序员不多，由于自由软件大多数是基于Linux/Unix系统，而在中国由于种种原因，Windows 程序员占绝大多数。

  2. 没有形成完整的自由软件社区

    • 国外的自由软件社区包括slashdot.org这样的论坛，freshmeat.net 这样的软件下载基地，sourceforge.net 这样的软件计划基地，而且有自己的Linux 杂志，如Linux Journal 等等。而目前，在国内，已经有了freesof.cei.gov.cn，Linuxforum， Linuxaid 等论坛和下载基地，也有一些刚刚创办的Linux 杂志，但是总体而言，社区的力量和影响还是很小，表现在对媒体和大众的影响不大。

2. 最敏捷组织

last edited 2005-02-18 04:03:50 by ZoomQuiet