开源社区，简化版
社区构建的三个核心要素
构建和维护一个开源社区本质上取决于三件事：
- 让人们有兴趣贡献
- 消除进入项目和贡献的障碍
- 保留贡献者，使他们持续贡献
如果你能让人们感兴趣，然后让他们实际贡献，并让他们留下来，你就有了一个社区。否则，你就没有。
如果你刚刚开始一个项目，或者需要改进现有项目的社区，你应该按相反的顺序处理这些点。如果你在完成后面两个步骤之前就让人们对项目感兴趣，那么人们将无法进入，即使进入也不会留下来。你实际上不会扩展你的社区。
所以首先，我们要确保能够保留现有和新贡献者。一旦做到了这一点，我们就想消除进入的障碍，这样感兴趣的人才能真正开始贡献。只有到那时，我们才开始担心如何让人们感兴趣。
按相反顺序实现每个步骤
保留贡献者
对于Bugzilla项目，这是我们最大的挑战。一旦有人开始贡献，是什么让他们持续贡献？我们如何让人们留下来？
我们在回答这些问题时有一个有趣的优势，因为我们是现存较老的开源项目之一，自1998年底以来一直存在。所以我们有大量的实际数据可供使用。我们通过两种方式挖掘这些数据：
首先，我们对所有过去离开项目的开发人员进行了调查，询问他们离开的原因。这是一个自由形式的调查，允许人们以任何方式回答。
然后，我们创建了一个随时间变化的贡献者数量图表，涵盖了项目的整个十年，并将图表的起伏与我们随时间采取或未采取的各种行动相关联。
所有这些完成后，我向Bugzilla项目的开发人员发送了一封电子邮件，描述了研究结果。你可以阅读整封电子邮件，但我会在这里总结发现：
不要长时间冻结主干。
Bugzilla项目有一个相当标准的系统，有很少变化的稳定分支（例如，“3.4”分支，我们提交错误修复并进行次要发布，如3.4.1、3.4.2等），以及一个主线“主干”仓库，所有新功能都进入这里，最终成为我们的下一个主要发布。
在过去，在主要发布之前，我们会“冻结”主干。这意味着在几周或几个月内无法开发新功能，直到我们认为主干足够稳定可以称为“发布候选”。然后我们会从主干创建一个新的稳定分支，并重新开放主线主干以进行功能开发。然而，当主干被冻结时，Bugzilla项目中任何地方都没有功能开发。
图表分析非常清楚地显示，每次我们冻结时，社区都会急剧缩小，并且在我们解冻后需要几个月时间社区规模才能恢复。每次我们冻结时都会发生这种情况，多年来多次发布都是如此。
开源的传统智慧是，人们喜欢开发功能，不喜欢修复错误。我不会说这完全正确，但我会说，如果你只让人们修复错误，那么他们中的大多数人不会留下来。
我们通过从不冻结主干来解决这个问题。相反，在我们通常“冻结”主干的时候立即分支。主干始终保持开放以进行新功能开发。是的，这意味着有一段时间，我们的注意力会在主干和最新分支之间分配。我们将相同的错误修复提交到分支和主干。我们也在主干上进行功能开发，同时进行这些错误修复。然而，我们发现，不仅社区以这种方式更快地扩展，而且我们实际上比过去更快地发布版本。所以这是一个双赢的局面。
人员流动是不可避免的。
调查发现，贡献者离开的首要原因是他们不再有时间贡献，或者他们作为工作的一部分贡献，现在他们换了工作。本质上，大多数贡献者最终离开是不可避免的。
所以如果社区成员肯定会离开，那么持续扩展社区的唯一方法是弄清楚如何保留新贡献者。如果你不让新成员留下来，那么随着老贡献者离开，社区将不断缩小，无论你做什么。
所以，虽然保留现有贡献者很重要——毕竟，你希望人们尽可能长时间地留下来贡献——但最重要的是保留新贡献者。你怎么做？嗯，这很大程度上是其余这些点的内容。
立即回应贡献。
Bugzilla项目有一个代码审查系统，要求所有新贡献在成为Bugzilla的一部分之前必须由经验丰富的开发人员审查。多年来对这个系统有各种抱怨，但分析调查数据显示，人们离开项目是因为审查时间太长，而不是因为审查太难。事实上，只要审查在有人提交贡献后几乎立即进行，审查可以尽可能严格。
人们（通常）不介意必须修改贡献。他们甚至通常不介意多次修改。但他们介意的是，如果他们发布一个补丁，三个月没有得到审查，然后他们必须修改它，只是再等三个月才被告知必须再次修改。重要的是延迟，而不是质量控制的水平。
还有其他快速回应贡献的方法。例如，立即感谢某人发布补丁可以大大有助于保留新贡献者并将他们“转化”为长期开发人员。
极其友善并明显表示赞赏。
对于几乎每一个回应我们调查的人，除了“我的工作变了”或“我没有时间”之外，不留下来的因素出人意料地个人化。我知道我们都与计算机打交道，也许我们愿意认为工程应该是一个完全冰冷的科学职业，我们都根据机器的要求正确完成工作，而不担心我们的情感或个人参与。然而，没有比这更偏离事实的了——人们与社区成员的个人互动、他们感到被赞赏的程度以及他们感到被攻击的程度，实际上是保留社区成员最重要的方面。
当人们以志愿方式贡献时，他们没有得到金钱报酬，他们得到的是钦佩、赞赏、工作完成良好的感觉，以及他们正在帮助创建一个影响数百万人的产品的知识。当某人贡献了一个补丁时，你需要感谢他们。即使补丁完全糟糕且必须完全重写，你也需要感谢他们。他们为此付出了一些努力，如果你不欣赏这一点，他们甚至会在开始之前就离开。毕竟，大多数人在工作场所得到的赞赏很少——他们留在那里是因为他们得到金钱报酬！如果其他组织也不欣赏他们的工作，甚至更糟，在感谢他们之前攻击他们贡献的每一个方面，他们不需要免费为其工作。
当然，你仍然需要纠正人们贡献中的错误。“友善”不包括将糟糕的代码放入你的系统中。这对任何人都不友善，包括贡献者，他们的技能可能需要提高，并且可能继续相信他们做错的事情实际上是正确的。你仍然必须是细心的审查者和非常好的编码者。
这意味着，除了告诉人们他们的贡献有什么问题之外，欣赏他们贡献中的优点也很重要，即使仅仅是他们花时间贡献这一事实。你必须实际告诉贡献者你欣赏他们的贡献。你做得越频繁和真诚，就越有可能保留贡献者。
鼓励完全不存在个人负面情绪。
一件事以闪电般的速度将人们赶出项目，那就是当他们试图做一些积极的事情时受到个人攻击。“个人攻击”可以小到关于他们代码的不愉快笑话，而不是仅仅对错误进行直接的技术描述。说一些像“你怎么了？”而不是实际留下一些有帮助的评论。将个人批评伪装成“试图帮助他们更好地编码”或“帮助他们与他人相处”。无论这些行为看起来多么合理，它们都是个人攻击，对你的社区极其危险。
说实话，编码和与有不同观点的人合作项目有时会非常令人沮丧，我和任何人一样在这个领域犯过错误。但我们都必须学会，仅仅因为我们个人对他们感到沮丧就侮辱其他开发人员是不行的。
然而，解决方案不仅仅是说“大家现在把挫折憋在心里直到爆发”。有很多实际的解决方案。最好的之一是建立一些具体的系统来处理有问题的贡献者。如果有某个贡献者Bob无法忍受，社区中需要有人Bob可以去找帮助解决问题。我们称这个可以找的人为“社区调解员”。所以Bob告诉调解员问题，也许调解员看到那个贡献者确实是个可怕的人或糟糕的编码者，于是这个“社区调解员”温和地纠正那个贡献者。但也有可能Bob和另一个贡献者之间存在一些沟通问题，调解员只需要帮助解决。
这个“调解员”系统不是处理问题的唯一方式。你可以通过多种方式解决问题——最重要的是你确实解决了问题。如果没有处理个人挫折的渠道或方法，个别贡献者会将这些挫折发泄在彼此身上。你实际上会培养一个环境，其中一个贡献者可以个人攻击另一个贡献者是可以的，因为这是他们解决问题的唯一途径，而且没有人阻止他们。
基本上，最后两点可以总结为：非常、异常、非常、非常友善，不要刻薄。
我们在过去几个月中一直在Bugzilla项目中应用所有这些原则，并且在我们开始应用它们后几乎立即看到保留贡献者数量的增加。在由于违反所有上述点而自2005年以来几乎持续缩小之后，我终于开始感觉社区再次增长。
消除障碍
下一步是消除进入的障碍。什么阻止人们开始项目？
通常，最大的障碍是缺乏文档和方向。当人们已经想要贡献时，他们的下一步是弄清楚如何贡献。他们会去你的项目网站看看。他们会想，“我应该和谁谈这个？我如何开始贡献？你们想让我做什么？”
对于Bugzilla项目，我们通过几种方式解决了这个问题：
简单入门项目列表。
每当我们看到一个错误或功能请求看起来适合新手解决时，我们就在错误跟踪器中将其标记为“好的入门错误”。这给了我们一个良好的入门项目列表，任何人都可以来看，而不必问我们“我从哪里开始？”
创建并记录沟通渠道。
人们几乎立即想与其他人讨论项目。你应该有电子邮件列表，也有一些即时通信方法，如IRC频道。例如，我们有一个Bugzilla开发人员的电子邮件列表，还有一个IRC频道，我们几乎所有的贡献者都在那里闲逛。事实上，我们不仅有一个正常的IRC频道——我们还有一个网页，人们可以使用该网页在该IRC频道中聊天。这样，人们不必安装IRC客户端就可以来和我们交谈。设置那个网页大大增加了进入频道并与我们通信的新人数。（而且增加完全是积极的——我想不出有一个人使用网页网关给我们带来麻烦。）
然后一旦你有了这些渠道，它们需要被记录！人们必须知道如何进入它们，他们需要知道它们存在。我们有一个wiki页面，解释如果你想贡献如何与我们交谈。（注意，这与我们的支持页面是分开的，支持页面描述了如何获得项目支持。）
此外，作为最后但可能明显的点，现有社区必须使用沟通渠道。如果主要贡献者都在办公室完成所有工作，只与旁边的人交谈，你不使用邮件列表或IRC频道，那么社区成员也不会想使用那些通信系统。毕竟，新贡献者不是在那里互相交谈——他们是在那里与你交谈！
优秀、完整且简单的文档，准确描述贡献应如何完成。
完全记录你的开发过程的每一步，并将该文档放在公共网站上。不要发明新过程，只需记录现有的实际过程。人们如何获取代码？他们如何向你提交补丁或其他贡献？这些贡献如何成为系统的官方部分？
我们有一个非常简单的页面，描述了我们整个过程的基本步骤，并链接到更详细描述每个步骤的文档。它还特别鼓励人们与我们沟通，以便我们知道他们在那里并想帮助。
使所有这些文档易于找到。
这是一个简单的最后步骤，但有时项目会忘记它！你可以拥有世界上所有精彩的开发人员文档，但如果新贡献者不能超级容易地找到它，那么你实际上并没有消除任何进入障碍！我们网站上有一个大的“贡献！”按钮，描述了人们可以贡献的所有不同方式（不仅仅是代码！）并链接到关于每种方式的更多信息。
一旦我们完成了所有这些步骤，我们看到了贡献数量和质量的明显上升。此外，将所有内容记录并明确陈述在公共网站上意味着我们不再需要每次向每个新贡献者亲自解释所有内容。
方向和文档并不是你能做的唯一事情。问自己，“什么阻止人们贡献？”并合理消除那里的所有障碍。
让人们感兴趣
你如何让人们想，“哇，我想为这个项目贡献？”这是他们成为贡献者之前必须采取的第一步。嗯，传统智慧指出，人们为开源项目贡献是因为：
- 他们喜欢帮助。
- 他们喜欢成为社区的一部分。
- 他们想回馈。
- 他们认为有些事情错了，他们需要/想修复它。
所以你可能想明确表明需要帮助，有一个愉快的社区存在，回馈是合适和受赞赏的，并且有问题需要解决。
公平地说，这是我还没有为Bugzilla项目完全规划或弄清楚的领域。所以我没有很多个人经验可以借鉴。但如果我们分析其他项目，我们可以看到一些获得贡献者的好方法是：
成为一个超级流行的产品。
这可能看起来很明显，但这确实是获得新贡献者的主要方式。如果无数人使用你的产品，统计上很可能其中许多人会想贡献。Linux内核和WordPress就是很好的例子——它们有数百万用户，所以肯定会有很多贡献者，前提是项目的“进入障碍”和“保留贡献者”方面也得到了处理。
成为一个超级流行产品的一种方式——即使你刚刚起步——是被强烈需要。Linux内核在首次编写时非常被需要，这可能是它如此快流行的原因之一。它迫切需要存在而尚未存在。
用流行的编程语言编写。
通常，如果项目用他们已知的语言编写，人们更可能贡献。WordPress有一个巨大的贡献者社区，它是用PHP编写的。无论你对PHP有什么看法，它都非常流行。有大量的人已经知道这种语言，这增加了其中一些人开始为你的代码提供补丁的可能性。
这不是你应该选择特定编程语言的唯一原因，但如果你要有一个开源项目，这肯定是一个主要动机。我可能认为Eiffel是一种卓越的语言，但如果我用它写一个开源项目，我会很难获得贡献者。
除了这些点，还有很多聪明的方法让人们有兴趣为你的项目贡献，包括在会议上发言、发布博客、一对一鼓励人们，以及其他基本上归结为“联系和鼓励”的方法。
我很想听听你在这个领域的一些想法。你如何让新人有兴趣为你的项目贡献？有什么特别成功的吗？
总结
开源社区有点流动的东西——总是会有人因某种原因来来去去。重要的是进入并留下的人的比率大于离开的人的比率。所有这些点都有助于确保这一点，并希望它们也使我们的社区对每个人，甚至我们自己，成为富有成效和愉快的地方！
-Max