597    这个巨大差异总是引发一个尴尬的问题：无论对于单个项目还是整个行业，甩掉能力最差的50%会不会好些？

598    明智的经理早就明白，如果传统管理的惟一作用是为了将最差部分由净亏损转变为边际收益的话，未免太得不偿失了。

599    开源社区的成功把这个问题变得相当尖刻，因为我们提供了硬性的证据：与管理整栋楼´身在曹营心在汉”的人相比，通过因特网招募自主选择的志愿者算是相当的´物美价廉”了。

600    这恰好把我们转向了´动机”的问题，对于我朋友的观点，有另外一种等价的，也时常听到的描述：传统开发管理是对缺少动力的程序员的必要补偿，否则他们不会好好干活。

601    这个回答通常伴随着一个说法，那就只能指望开源社区做那种´迷人”的或者技术上有趣的工作，否则都会半途而废（或敷衍了事）除非能把他们变成那种经理鞭打下收入微薄的苦工。

602    我在《开拓智域》（Homesteading the Noosphere）一文中就心理学和社会学的角度阐述了对这一观点的质疑。

603    就目前而言，我们暂且假定这个推论正确会更有趣！

604    如果传统的、闭源的、管理臃肿的软件开发模式只能托庇于一种令问题愈发枯燥的马其诺防线的话，那他们就要祈祷了，祈祷在每个领域都没人能发现问题的真正趣味，祈祷没人发现绕过防线的路径。

605    因为对于´枯燥”的领域，一旦有开源软件加入战团，用户就会立刻明白终于有人发现了问题的迷人之处并着手解决了！对软件业，如同其他的创造性工作一样，这比单一的金钱激励要有效的多。

606    只是为了获取激励而采用传统的管理结构，也许是个好战术，但绝非优秀的战略短期的胜利换来长效的溃败。

607    说到这，传统开发管理和开源开发相比，在两点上（组织和资源监护）显然是不智之举，对于第三点（激励）则显得鼠目寸光。

608    被团团包围的可怜的传统经理人也不会等到´监督”的任何援兵了。

609    因为对于确保细节无一遗漏，开源社区强健的同行评议要胜过所有传统方法。

610    我们能把´确立目标”留下来作为接受传统管理开销的理由吗？

611    或许吧。