有点杞人忧天？同学们，总会有让人无法忍受的家伙出现，真的。

这篇常见问题摘自Stack Exchange（免费且由社区支持的常见问题网站联盟，其成员超过一百家）上广受关注的每周系列博文，其中技术爱好者负责提出常见问题、其他用户则帮助作出解答。

Nathan2055提问称:

我为某个特定网站编写了一套开源脚本，并与其他几位开发人员一同将其搬上了GitHub（在这里我会隐去真实姓名）。在开始采用这套新系统之后，又有几位新人开发者加入了进来，其中有一位还非常活跃。不过，这位活跃的成员开始给项目带来诸多改变。

首先，这家伙删除了我们的版本管理系统（我们用的这套系统与Git不同，但作用类似——目前的版本被称为v4.1.16）并声称只要项目组成员认为代码已经准备就绪、将其直接发布到网站上即可。这样一来，现在我们就没有一个能够集中提供发行说明的空间了，这给我们的心情带来了极大影响。

真正让我感到出离愤怒、甚至一气之下直接走人的状况来自推送脚本。项目组中的其他几位开发人员编写了一套简单的Python推送脚本。由于我们在多个网站上保存着数个脚本版本，因此我开始编写一个规模更大的Java程序，希望利用其中的地理接口对原本代理中的Python脚本加以替代。我利用即时通讯工具向各位合作伙伴知会了这一消息，但这家伙跳出来给了我泼了一大盆冷水——他认为原本的Python脚本能够实现我这套新脚本的所有功能，而且更具轻量化特性（他还大肆鼓吹Python与Java相比的优越性等）。我曾认真审查对原本的推送脚本，而且可以负责任地告诉大家——他所提到的功能这里一项都没有。

所以现在我希望弄清楚自己该怎么办。我在这个项目上花了很多时间，因此让我直接甩手不管肯定是做不到的；但我发现自己也确实很难跟这位新人开发者合作。另外，他目前已经成为项目当中贡献量***的代码提交者，甚至比主要开发人员表现得更为积极。我不知道自己该如何处理这种情况。各位朋友有没有经历过这样的难题？如果有的话，大家是怎样处理的？

坚持自己的方式还是正确的方式？

gbjbaanb的回答(得到45票赞成):

1.你可以退出。这也许算不上是***建设性的选择，但有时候这却是惟一的选择。如果你决定这样做，请千万别再纠结不已、与伙伴们谈论自己不得不离开的种种理由。省下这些精力，把它直接用在其它有意义的事情上——换句话说，“换个方向继续前进”。

2.不理会他人，fork到底。其实你并没有必须与其他人共同工作的理由。坚持fork，改进代码并且允许其他人继续活在以自我为中心的小世界里。你的新项目必将与旧方案进行正面竞争，而到底谁能胜出完全取决于你自己。事实能够说明一切，如果旧方案依靠用户基础与功能压倒了新项目，那么也许你真的判断错了。

3.表达自己的意见。你可以与开发团队的其他成员沟通并表达自己的忧虑，让对方了解你的想法与感受。请不要把这些归结成个人问题，记得坚持将重点放在你对于代码改动的观点、缺乏确切的质量流程或者新决策并未得到每一位成员认可方面。也许大家认为旧方案还没差到必须更换的程度，也有可能会有几位团队成员认同你的判断、支持团队着手修改旧有代码。这样一来，这位希望颠覆一切的活跃新人有可能失去自己的代码提交权。当然，最终的结果也可能是你意识到了自己的失误，并愿意与大家一道将项目恢复到原先的状态。（后者的可能性是***的，除非大家真的发现项目从根本上出现了偏差。）

我们往往很难接受自己打理了很久的项目被刚刚进入的新人说三道四，保持自己熟悉的方向当然更安全也更让人放心。不过换句话来说，新人对于旧有习惯性作法的改动本身其实是件好事——至少从宏观意义上来看是这样。

你的立场何在？

Ben McCormick的回答(得到33票赞成):

我觉得还有很多情况没有表述清楚，特别是你自己在项目团队中的角色定位。而最终答案的选择恰恰与这一情况密切相关。

如果你是项目中的***并控制着git库：

夺回自己的控制权。如果这家伙在没有得到项目***同意的情况下就提交令人不满的代码，那么直接消除他的提交权即可。这才是开源项目的运作方式——除非某位用户真正在团队中赢得信任。你不需要也没必要将权限彻底下放。

如果代码库由其他人掌控：

与项目团队的***交流并表达自己的担忧，并鼓励对方采用更为严格的规划与审批机制以掌控项目变动。如果***不认同你的建议，那我们可以选择接受现实并继续为项目作出贡献，当然也可以选择fork路线以根据自己的观点来推动项目发展（记得带上与你自己观点一致的开发伙伴）。再有，你也可以选择离开并转而打理其它工作。无论如何，既然当前的状况让你感到很不舒服，那实在没必要继续忍耐下去。

接受现实

Deer Hunter的回答(得到15票赞成):

请原谅我的直率，但你的文章读起来更像是纯粹的咆哮与抱怨。

你说其他人喜欢盲目作出改变，但旋即抛出了自己认为合理的新方案——Java。

请先冷静一下：思考问题不应该非此即彼，我们不妨找到一种折衷的处理办法（如果你还想继续参与到这个项目当中，fork确实是最简单的办法——但这样除了满足你固执的自我坚持之外起不到任何有意义的作用）。

请首先认真思考该项目当中每一位参与者的明确职权划分，如果没有清晰的划分、这类职权之争将是不可避免的状况。没错，有时候我们必须信任其他成员作出的判断。

尝试谷歌给出的建议

Kurtosis的回答(得到4票赞成):

谷歌几年之前就这一问题开展过技术讨论，下面我来概括讲讲由此带来的结论性意见：

1.理解:了解你的社区成员参与当前项目的工作动力，再将其与其它机会成本进行比较——一定要用心保护好这些动力，它们是项目继续生存并前进的根本因素。

2.强化:建立起一个健康的社区环境，礼貌、尊重、信任与谦卑是其中必不可少的社会化组成部分。

3.识别:找到害群之马们搬弄是非的标志性征兆（这类例子不胜枚举，但既然你已经提出了这类问题，说明你之前可能已经见识过不少相似的情况）。

4.监控:冷静地坚持自己的立场，不要对侮辱、轻视、挑战以及不尊重等行为作出反应，同时不断强化前面提到的社区规范。

原文链接：http://arstechnica.com/information-technology/2014/01/how-to-deal-with-a-difficult-programmer-on-an-open-source-project/