避免开源项目管理中的不良实践

图片来源：

Opensource.com

在奥斯汀 OpenStack 峰会期间，我有机会与一些人交流我在运行开源项目方面的经验。事实证明，在社区中混迹多年并为许多项目做出贡献后，我可能能够为许多刚接触开源的人提供一些事后诸葛亮般的见解和外部视角。

有很多资源解释了如何运行一个开源项目。今天，我想从不同的角度出发，强调你在项目中不应该做什么。这份清单来自我过去几年遇到的各种开源项目。我将以随机顺序回顾我发现的一些不良做法，并用一些具体的例子来说明。

将贡献者视为麻烦

当软件开发人员和维护人员忙碌时，他们最不需要的就是：更多的工作。对许多人来说，对外部贡献的本能反应是：“该死，更多的工作。” 事实上，确实如此。

因此，一些维护人员倾向于避免这种额外的工作：他们声明他们不想要贡献，或者让贡献者感到不受欢迎。这可以采取很多不同的形式，从忽略他们到不友善。这确实避免了立即处理添加到维护人员肩上的工作的需要。

这是开源中最大的错误和误解之一。如果人们向你发送更多的工作，你应该尽一切努力让他们感到受欢迎，以便他们继续与你合作。他们可能很快就会成为代替你完成工作的人。想想退休吧！

让我们来看看我的朋友 Gordon，我看到他在 2013 年开始成为 Ceilometer 的贡献者。他做了很棒的代码审查，但实际上他通过捕获我补丁中的错误并发送我必须审查的补丁，给了我更多的工作。我没有欺负他，让他停止重做我的代码和审查他的补丁，而是要求我们通过将他添加为核心审查员来更加信任他。

如果他们不做这一次贡献，他们就不会做两次。他们将什么也不做。这些项目可能刚刚失去了他们的新维护人员。

只让人们做苦力活

当新的贡献者到来并想为一个特定项目做出贡献时，他们可能有非常不同的动机。他们中的一些人是用户，但他们中的一些人只是想看看贡献是什么感觉。获得贡献的刺激，作为一种练习，或者作为一种学习并开始回馈他们使用的生态系统的意愿。

维护人员通常的反应是将人们推入苦力活。这意味着做那些没有兴趣、价值不高，并且可能对项目没有直接影响的工作。

有些人实际上对此没有问题，有些人则有。有些人会因为做低影响的工作而感到冒犯，有些人会因为你给予他们某种认可而喜欢它。意识到这一点，并确保与做这件事的人击掌。这是让他们留在身边的唯一方法。

不重视小的贡献

当来自新贡献者的第一个补丁是拼写错误修复时，开发人员会怎么想？他们不在乎，你用你的小贡献浪费他们宝贵的时间。而且没有人关心文档中的糟糕英语，不是吗？

这是错误的。看看我对 home-assistant 和 postmodern 的第一个贡献：我修复了文档中的拼写错误。

我为 Org mode 贡献了几年。我对 Org mode 的第一个补丁是关于修复文档字符串。然后，我发送了 56 个补丁，修复了错误并添加了花哨的功能，还编写了一些外部模块。直到今天，我仍然是 Org mode 的 top-committer 列表中的第 16 位，该列表包含 390 位贡献者。所以我不会称之为小贡献者。我相信社区很高兴他们没有鄙视我的文档修复。

为新手设置过高的门槛

当新的贡献者到来时，他们对项目、其背景和技术的了解可能会有很大差异。人们经常犯的一个错误是要求贡献者做他们无法实现的过于复杂的事情。这会吓跑他们（很多人会害羞或内向），他们可能会直接消失，觉得自己太笨无法提供帮助。

在发表任何评论之前，你不应该对他们的知识有任何假设。这应该避免这种情况。你在评估他们的技能时也应该非常小心，因为如果你的低估程度太高，有些人可能会感到恼火。

一旦正确评估了该水平（几次交流就足够了），你需要以正确的程度指导你的贡献者，以便他或她能够蓬勃发展。掌握这一点需要时间和经验，你可能会在此过程中失去他们中的一些人，但这是每个维护人员都必须采取的道路。

无论是哪个项目，指导对于欢迎新的贡献者加入你的项目都非常重要。我很确定这也适用于自由软件之外。

要求人们为生活做出牺牲

这方面的情况因项目和背景的不同而有很大差异，但它非常重要。作为一个自由软件项目，大多数人会出于自己的意愿，有时会利用业余时间做出贡献，因此你不能要求他们做出很大的牺牲。这行不通。

其中最糟糕的实施方式之一是要求人们飞行 5,000 公里到某个地方开会讨论项目。这使得贡献者处于不公平的地位，这取决于他们是否有能力离开家人一周，乘坐飞机/船/汽车/火车，租一家酒店等等。这不好，应该避免一切要求人们这样做才能参与并感受到被纳入项目的感觉，并融入你的社区。别误会我的意思：这并不意味着应该禁止社交活动，恰恰相反。只是避免在讨论任何项目时排除他人。

同样适用于任何其他形式的讨论，这使得每个人都难以参与：IRC 会议（对某些人来说很难预定一个小时，尤其是取决于他们居住的时区）、视频会议（尤其是使用非自由软件）等等。

任何要求人们在一段时间内以同步方式与项目进行交互的事情都会对他们施加约束，这可能会让他们感到不舒服。

最好的媒体仍然是电子邮件和异步衍生物（错误跟踪器等），因为它们是异步的，允许人们按照自己的节奏在自己的时间工作。

没有（隐式）行为准则

行为准则似乎是一个热门话题（也是一个敏感话题），因为越来越多的社区向比以往任何时候都更广泛的受众开放，这很棒。

实际上，所有社区都有行为准则，无论是以黑色墨水书写，还是无意识地存在于每个人的脑海中。它的形式取决于社区规模和文化。

现在，根据你社区的规模以及你如何感到舒适地应用它，你可能希望将它组成一个文档，例如 Debian 所做的那样。

拥有行为准则并不能奇迹般地将你的整个项目社区转变为一群遵循其指导的关爱熊。但它提供了一个有趣的要点，你可以在需要时参考它。它可以帮助将其扔向某些人，以表明他们的行为在项目中不受欢迎，并在某种程度上，减轻他们可能被排除的风险，即使通常没有人想走那么远，而且它很少有用。

我不认为在较小的项目上必须有这样的文件。但是你必须记住，隐式行为准则将源于你自己的行为。你的领导者与他人沟通的方式将设定整个项目的社交氛围。不要低估这一点。

当我们启动 Ceilometer 项目时，我们在 OpenStack 行为准则甚至存在之前就隐式地遵循了它，并且可能设置了更高的标准。通过保持友善、热情和开放的态度，我们取得了不错的多样性分数，我们的核心团队中有多达 25% 的女性 - 远高于 OpenStack 和大多数开源项目中当前的比例！

让母语不是英语的人感到像局外人

重要的是要意识到，绝大多数自由软件项目都使用英语作为通用的沟通语言。这很有意义：它是一种常用的语言，而且似乎可以正确地完成这项工作。

但是绝大多数黑客的母语不是英语。许多人无法流利地说英语。这意味着他们进行沟通和对话的速度可能非常慢，这可能会使某些人感到沮丧，尤其是母语是英语的人。

这种现象的主要表现可以在社交活动（例如会议）中看到，人们正在辩论。人们可能很难用英语解释他们的想法并以适当的速度进行交流，从而使对话和思想的传递变慢。在这种情况下，人们可以看到的最糟糕的事情是，一位母语为英语的人打断人们并忽略他们，仅仅是因为他们说话太慢。我理解这可能会令人沮丧，但是这里的问题不是非母语英语，而是使用的媒介没有通过口头移动对话来使你的同伴与每个人处于同一水平。

在较小的程度上，同样的道理也适用于相对同步的 IRC 会议。完全异步的媒体没有这个缺陷，这就是为什么我也应该更喜欢它们。

没有愿景，没有授权

在开源项目中遇到的最常见的两个错误：看到维护人员在项目增长中挣扎，同时有人试图提供帮助。

事实上，当贡献者开始涌入，添加新功能，寻求反馈和指导时，一些维护人员会感到窒息，不知道该如何回应。最终会让贡献者感到沮丧，因此他们可能会直接消失。

重要的是对你的项目有一个愿景并传达它。让贡献者清楚你想要或不想要在你的项目中做什么。以清晰（且非侵略性，请）的方式转移这一点是降低贡献者之间摩擦的好方法。他们很快就会知道他们是否想加入你的船，以及期待什么。所以做一个好船长。

如果他们选择与你合作并做出贡献，你应该尽快信任他们，并将你的一些职责委派给他们。这可以是任何你曾经做过的事情：审查补丁、针对某个子系统、修复bug、编写文档。让人负责项目的整个一部分，这样他们就会感到责任感，并且像你一样关心它。相反的做法，也就是成为一个控制狂，是让你独自一人维护开源软件的最佳途径。

任何项目都不会以这种方式成长并取得成功。

2009年，当 Uli Schlachter 发送他的第一个补丁给 awesome 时，这对我来说是更多的工作。我必须审查这个补丁，而且我已经非常忙于设计 awesome 的新版本和做我的日常工作了！ Uli 的工作并不完美，我不得不自己修复它。更多的工作。然后我做了什么？几分钟后，我回复了他，明确说明了他应该做什么以及我对他的工作的看法。

作为回应，Uli 发送了补丁并改进了项目。你知道 Uli 今天在做什么吗？自 2010 年以来，他一直在管理 awesome 窗口管理器项目，而不是我。我成功地传递了我的愿景，进行了委派，然后退休了！