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

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

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

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

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

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

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

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

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

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

611    或许吧。

612    如果这样做了，我们就必须有充分的理由相信这些管理委员会和社团有能力制定出更具远见卓识的目标，而且要做的比开源世界中同司此职的项目领导和´部族长老”们更加成功。

613    这从表面上就很难说得通。

614    并非开源一方的发难（Emacs的长寿？李纳斯以´统治世界”的说辞集结´游牧部落”的能力？）打破了平衡。

615    相反，是传统模式对目标的制定令自己处境尴尬。