212    在提交错误报告的时候，习惯从自身环境出发，这样（一）会忽视重要的背景数据，（二）通常会遗漏重现错误的关键步骤。

213    更深层的问题是，开发者和测试者的思维模式不同。

214    测试者是由表及里的看问题，而开发者则是自内而外。

215    在封闭源代码的开发环境里，他们被各自的角色羁绊，往往各说各话而且认为对方很难沟通。

216    开源开发打破了这种束缚。

217    基于源代码，测试者和开发者可以很容易建立一个统一的模型，并借此有效沟通。

218    仅仅描述表面症状的问题报告和深入源代码基础抽象模型的报告，对于开发者而言作用是截然不同的。

219    在代码层，即使一个不完整的提示性错误描述，都可以让它们在大多数情况下得以修正。

220    比如当某个公测人员指出：“在某某行存在边界问题”，甚至只是说出´在某某条件下，变量溢出”的时候。

221    通常进行一次对于问题代码的快速扫描就足以锁定成因，加以修复了。

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

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

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

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

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