672    所以这当然不会源自Unix和因特网传统。

673    比如在1990年到92年初首先出现在DOS机上的info-Zip压缩工具就是一例，另外就是同样始于DOS的RBBS电子公告板系统。

674    从1983年发展起来的强大的RBBS社团，使其至今（1999年中）都充满活力无论其间网络邮件和文件共享技术发生了多么翻天覆地的变化。

675    如果说info-Zip社团还或多或少的使用了网络邮件的话，那么RBBS开发则纯粹的依托于一个以TCP/IP为基础形成的在线社团。

676    对于扫清操作系统开发的复杂障碍，公开平等的审视是大有助益的，其实，这算不上是个新观点。

677    在1965年考巴托和维萨斯基共同设计了一个名为Multics的早期分时操作系统。

678    他们希望当Multics运行良好并满足下面两个条件的时候能得以发布：首先，它要经受的起来自用户无偿地公开审视和批评。

679    其次，当自身越来越复杂的时候，其有责任对未来的开发者做出贡献，以便令他们可以尽己所能开发出内核明晰的操作系统。

680    换言之，就是有责任公开自己的最基础版本。

681    对于在开源开发中，为何重复劳动算不上个大问题的原因，约翰·哈斯勒（John Hasler）做过一个有趣的解释。

682    他建议我命名为哈斯勒定律：重复劳动开销的增长趋向低于由开发团队扩大带来的指数式成本增长。

683    也就是说，开发团队扩大所带来计划和管理成本增速要远高于重复做功的开销。

684    这与布鲁克斯定律并不冲突，总体而言，抚平复杂度和纠正错误的成本是与开发团队规模成平方正比增长的，然而重复做功带来的开销则是其中同比增速缓慢的一个独特环节。

685    我们不难为此找到一个看似可信的原因：以一个既定的目标开始工作比让一群自主的开发者达成一致要简单的多，而且可以预防重复做功。

686    但是却不能有效的阻止开发陷入无法预期的恶性循环，最终导致整个系统置身错误之中。