222    所以，如果公测人员和核心开发者都对代码心中有数，那么沟通和协作就很容易展开。

223    这就意味着节省核心开发者的时间，即使协作者众多。

224    另一个节约开发者时间的方法源自典型的开源通讯结构。

225    我在文中使用了´核心开发者”一词，这有别于 ´项目核心”和´项目外延”。

226    （´项目核心”一般很小；通常包括一到三个核心开发者，当然如果只有一人也不足为怪；´项目外延”则通常包括数以百计的´公测人员”和´贡献者”）

227    正如布鲁克斯定律所言传统软件开发结构下的根本问题是：´为已经延期的项目增添人手会让它拖的更久。”

228    通俗的讲，布鲁克斯定律昭示了：项目的复杂度和通讯成本会以开发人数为基础，呈现平方指数的增长态势，而绩效则仅能直线上升。

229    经验证实，错误大多集中在（不同人编写的）代码的接口处，而沟通/协调成本则会随着人员交流渠道的增加而增加，这就是布鲁克斯定律建立的基础。

230    然而问题也会随着开发者沟通渠道的增多而增加，后者恰好等于开发人数的平方。

231    （更确切地说，是遵循N*(N-1)/2公式，其中N代表开发者人数）

232    布鲁克斯定律（对于开发团队过大所导致的令人担忧的结果）的分析是基于一个潜在假设的：即项目必须采用全向连通的通讯结构，也就是说每个人都能与其他任何人取得联系。

233    然而在开源项目中，外延开发是可以分离的平行子环节，彼此关联甚少。

234    代码变动和错误报告都流经项目的核心团队，只有在那里我们才需要担负´布鲁克斯式”的管理成本。

235    代码层的错误报告对开发大有助益的原因还有很多，然而它们都围绕着一个事实。

236    那就是：同一个错误在不同的操作习惯和环境下会表现出不同的症状。