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

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

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

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

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

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

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

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

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

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

687    将李纳斯定律和哈斯勒定律结合起来，我们不难找到三种软件工程的对应模式：对于开发者不超过三人的小工程，无需领导和预设管理结构。

688    对于中型工程，采用传统的管理模式成本则相对较低。

689    并且可以有效的防止重复劳动，错误追踪，并且能很快的发现详细资料是否有遗漏，从而确保万无一失。

690    在此之上，李纳斯定律和哈斯勒定律共同说明了：对于大型工程，传统管理模式带来的问题和成本增幅，远超过预期的重复劳动的开销。

691    而这种调动大家参与所带来的微小开销并不是一个结构上的缺陷，相反（我们看到）这能比传统方法更有力的保证错误和细节无一遗漏。