曾经有个叫做 Subversion 的开源项目需要一个数据解析器。一天，一个程序员毛遂自荐写了一个程序。但是，他坚持要在程序里保留他的名字 John Hancock 的标签，这一点违反了开发原则。 Subversion 的启动人说，保留署名标签会破坏整个项目的协作性。
Subversion 的启动人要求他去掉自己的名字，但是他拒绝了，并且威胁道要带着这个解析器的源程序离开项目。事实上，这的确是个非常好的解析器，而且十分符合整个项目的需求。但是，(Subversion 的)启动人仍然坚持自己的原则。于是，这个程序员带着解析器的源程序走了，过后也没有提交过任何补丁。六个星期后，另一个程序员来了，说他也可以写一个数据解析器。
Brian Fitzpatrick 和 Ben Collins-Sussman，两位 Subversion 的启动人，坚信开源项目一定是包含了大量公共要素的。在项目进行中就要控制好这些公共要素，以免像挤公交时人数过多而发生危险一样，导致开发进度崩溃。他们认为，一个简单的控制项目公共要素的方法就是，从开源程序里去除开发者的名字。
(译注：原文中 bus factor 即指公共要素，比喻了开发过程中的一些共同因素。如果挤上 bus 的 factor 越多，bus 就越不稳定，所以要控制好 bus factor ，以免问题发生。)
“你要制止开发人产生‘这是我负责的模块，我写了这些程序，每个改动都要通过我同意’的想法。” Collins-Sussman 如是说。“这种想法对程序的整体性来说是很危险的。”
这可能意味着错过一些十分有价值的代码提供者，同样也会错过那些源代码。但是当最终程序发布时，通常会有更多的提供者参与进来，同样这也意味着更多的优秀源代码的加入。“长痛不如短痛，决不能牺牲项目的健壮性来保留当下的瑕疵。”
这不过是 Fitzpatrick 和 Collins-Sussman 的教训之一，这两位长期从事开源项目的技术人现在正在 Google 交流他们的开发经验。(译注：原文写于会场进行时间。)这两位开发者在旧金山的 Google I/O developer conference ( Google I/O 开会者大会)上作了一个“怎样从害群之马手中拯救整个开源项目”的演讲。
恶意开发者(译注：原文是 poisonous person ，即对项目有害的人，本文译作害群之马)，可以是任何导致团队协作代码开发产生问题的人。从喜欢恶意地让项目走弯路的人，到把开发成果据为己有的篡位者，都是害群之马。“要提防任何扰乱你，排斥你的人。”Collins-Sussman 说。“有些人名不见经传，但是有些人却是优秀社区的名人。世界上最优秀的开发者往往是完美主义者，要么就是控制欲强的人：他们只会让你陷入无穷无尽的讨论之中。”
这两位 Googler 开发者说，成功的开源项目立足于“专注”，而且要不惜任何代价来保护开发成果。“如果有一群人都在捐钱，却来了个人开始从中抽取利润，这就是件十分令人头痛的事情。这时你就得叫警察了。”Fitzpatrick 说。“专注是开源项目的命脉。”
这些听起来有些老生常谈，但是 Fitzpatrick 和 Collins-Sussman 提出了更多的建议来减少这些害群之马的负作用。
1，启动项目之初，仔细定义项目的目标，并且发布到受关注程度较高的网站上。“发布在网上表明其官方性质。”Collins-Sussman 说。这句话引发了一些开发者的会心之笑，但是 Fitz 也被他们指出这不过是掺杂了一些实事的笑话罢了。“如果你通过 Email 发布了项目，开发者们会一直为此争议几个星期。但是如果你花些时间把它公布到网站上，他们就马上把它当回事了。”(这句可能是 Fitz 说的。)
2，更改目标说明：“为 CVS (版本控制系统)建立一个强制复位系统。”Collins-Sussman 说。正因为有了这个独立的系统，才能吸引合适的开源提供者来关注这个项目。
两位开发者提倡，要让讨论一直保持在最小但是最有利的状态。这包括一个完美的 Email 系统，和可伸展的项目历史文档。这个文档中应该包含所有开发过程中的讨论，代码修改，重要的修订及错误记录等等。“如果不把项目开发历史整理成文档，你就会陷入不断(向其他人)重复开发过程的无用循环。”
他们继续道，即使在讨论以前没有讨论过的问题时，也要得懂得适时制止讨论。“我们曾有个开发者一直不停地谈论着同一个细节问题，结果我们根本不知道该怎么处理。”Fitz 回忆道。“于是，最后我们告诉他，放下这问题去做下一步工作吧。这句话奏效了，他接受了我们的建议。”
他们说，开源文化精髓应该是自我选择。换句话说，就是要坚持目标。(即坚持开发初衷，让项目自己选择合适的开发者和及其他内容。)如果人们不喜欢这个项目，他们会主动离开——至少，大部分人是会离开的。不过仍然会有制造麻烦的家伙们留在开发组里，所以这时就得当心这些莽莽撞撞的家伙。也就是说，得主动让他们离开项目。这同时适用于项目的奠基人和那些天才们。
在 Collins-Sussman 的项目受到严重威胁，即将导致崩溃时，他踢走了一个知名的“天才”。他认为这是整个项目中最为关键的决定。他说，天才不如团队合作重要；而在现代社会，天才程序员反而是屡见不鲜的。(译注：寻找开发天才不如提高团队合作性。)