开源软件开发几乎不用考虑人的因素，这并不代表个人因素不重要，而是因为人们的想法简单而统一。开源软件的开发人员，常常以一种松散的形式组合在一起，兴趣爱好是他们最主要的驱动力。对于这样的组织来说，过程可以最简化，只需要保留减少混乱、提升效率的活动，而剔除在缺乏主动性的情况下进行约束的所有内容。有哪些有价值的想法呢？首先，CMM对于软件开发过程的关注是系统性的。在CMM中，定义了质量保证、配置管理、需求管理、项目管理、软件开发管理、同行评审、项目资源协调、人员培训等概念，涉及软件开发过程中方方面面的活动。

其次，CMM推荐了大量被证明有效的活动，并把它们纳入一个模型中。CMM定义了这些活动的类型，以及先后次序和依赖关系。最后，CMM鼓励软件开发组织基于模型和推荐的活动来定义自己的开源软件开发过程。CMM会依据规范来评估自定义的软件开发过程，换句话说，CMM是一个参考模型，它不要求软件开发组织严格遵守。CMM只是建议，在软件开发组织自定义的活动和CMM规范推荐的活动之间做一些映射。这些映射可以非常灵活。 我很少看到有人提及最后这一点。这也许是很多人对CMM产生错误印象的原因之一。在我看来，CMM所倡导的灵活实践，使它的老学究形象平添了一份可爱。

我认识一位SEI认证的CMM评估师。他是做协同办公软件开发的，在与他的交流中，我深刻地体会到，CMM其实是一个非常灵活的模型。事实上，只要有想象力和创造力，你定义的软件开发过程，将会完全适合你的组织现状和企业文化。你可以为不同类型的项目定制不同的过程，从而最大限度地提升工作效率。有兴趣的读者可以去阅读相关的参考书。为了进一步了解CMM的灵活性，我们不妨来谈谈CMM中的同行评审活动。同行评审的目的是为了及早地、高效率地从软件工作产品中消除缺陷。一个重要的伴随结果是，对软件工作产品及可防止的缺陷得到更好的了解。

同行评审包括生产者的同行对开源软件开发工作产品进行系统地考察，以便识别缺陷和需作更改的区域。将经受同行评审的具体产品，在项目定义软件过程中加以标识，并作为开源软件开发项目策划活动的一部分来安排进度，正如在集成软件管理中所描述的。——CMM1.0同行评审是我非常推崇的一项活动。通过同行评审可以及早发现软件开发工作中的一些失误，可以及早为一些问题找到解决方案。CMM建议，同行评审应该执行这样一些活动：计划同行评审，并将计划写成文档。按照已文档化的规程进行同行评审。