开源社区，简化版 » 代码简洁性
管理同意
为了提供最佳体验，我们使用cookies等技术存储和/或访问设备信息。同意这些技术将允许我们处理数据，如浏览行为或本网站上的唯一ID。不同意或撤回同意可能会对某些特性和功能产生不利影响。
功能性
始终活跃。技术存储或访问对于使订阅者或用户明确请求的特定服务能够使用的合法目的是严格必要的，或者仅用于通过电子通信网络传输通信的唯一目的。
偏好
技术存储或访问对于存储订阅者或用户未请求的偏好的合法目的是必要的。
统计
技术存储或访问专门用于统计目的。专门用于匿名统计目的的技术存储或访问。在没有传票、互联网服务提供商的自愿合规或来自第三方的额外记录的情况下，仅为此目的存储或检索的信息通常无法用于识别您。
营销
技术存储或访问需要创建用户配置文件以发送广告，或在网站或跨多个网站上跟踪用户以用于类似的营销目的。
管理选项 管理服务 管理{vendor_count}供应商 阅读更多关于这些目的 接受 拒绝 查看偏好 保存偏好 查看偏好 Cookie政策 {title} 法律声明
代码简洁性
开源社区，简化版
2011年2月1日，作者：Max Kanat-Alexander
成长和维护一个开源社区基本上取决于三件事：
- 让人们有兴趣贡献
- 消除进入项目和贡献的障碍
- 保留贡献者，使他们持续贡献
如果你能让人们感兴趣，然后让他们实际贡献，并让他们留下来，你就有了一个社区。否则，你就没有。
如果你刚刚开始一个项目或需要改进现有项目的社区，你应该按相反的顺序处理这些点。如果你在完成后面两个步骤之前就让人们对项目感兴趣，那么人们将无法进入，并且在进入后也不会留下来。你实际上不会扩大你的社区。
所以首先，我们要确保能够保留现有和新贡献者。一旦我们做到了这一点，我们就想消除进入的障碍，以便感兴趣的人能够真正开始贡献。只有这样，我们才开始担心如何让人们感兴趣。
所以让我们谈谈如何按相反的顺序完成每个步骤：
保留贡献者
对于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
分享 点击在Facebook上分享（在新窗口中打开） Facebook 点击在LinkedIn上分享（在新窗口中打开） LinkedIn 点击在Hacker News上分享（在新窗口中打开） Hacker News 点击在Reddit上分享（在新窗口中打开） Reddit 点击在Threads上分享（在新窗口中打开） Threads 点击在X上分享（在新窗口中打开） X
46条评论 留下回复
ashughes说：2011年2月1日上午11:38 伟大的博客文章！我一直在尝试改进MozillaQA社区的方法。这给了我一些想法——谢谢！ 回复
Max Kanat-Alexander说：2011年2月1日下午2:21 谢谢！太棒了！-Max 回复
Dan Mosedale说：2011年2月1日下午2:34 这里有很多很多好的智慧；感谢发布！ 回复
Max Kanat-Alexander说：2011年2月1日下午2:35 谢谢Dan！-Max 回复
Tweets that mention Code Simplicity » Open Source Community, Simplified – Topsy.com说：2011年2月1日下午2:58 […]这篇帖子被提到在Twitter上由Planet Mozilla, Janet Swisher和afcowie, Max Kanat-Alexander。Max Kanat-Alexander说：创建和构建开源社区的秘诀：http://j.mp/i90nQt […] 回复
Jolie说：2011年2月1日下午6:49 哇。这很酷且有帮助。 回复
Jogai说：2011年2月2日上午6:06 Damien Katz关于选择编程语言说了一些有趣的事情。不太流行的语言吸引更高质量的开发人员阅读http://damienkatz.net/2010/07/getting_your_open_source_proje_1.html在“Paul Graham Was Right”下。 回复
Max Kanat-Alexander说：2011年2月2日下午3:20 哇，那是一篇优秀的帖子。绝对精彩。Damien经验的很酷的事情是他从另一端来处理——他启动了一个项目并将其提升到流行，而我进入一个现有项目并必须弄清楚如何让社区重新流行起来。
他关于开发人员质量与数量的观点很好接受。我认为最好的平衡可能是Python，语言本身倾向于吸引高质量的开发人员，但其中有相当多的数量。 -Max 回复
Alan Franzoni说：2011年2月2日下午2:27 那很有趣，我也有一些关于这个话题的想法： http://ollivander.franzoni.eu/2010/12/building-successful-community-driven.html
顺便说一句，我认为你关于“好的入门项目”的点值得提及——这是一个非常好的主意！ 回复
Max Kanat-Alexander说：2011年2月2日下午3:26 谢谢！那是一篇有趣的帖子——有一些事情我不同意你，但那里有一些有用的提示，适用于那些想要有一个项目的人。当然，人们应该总是使用自己的判断，什么适用于他们自己，什么不适用。 -Max 回复
Boris Bokowski说：2011年2月6日下午7:12 嗨Max， 非常感谢你对此进行研究并如此好地记录它。我在eclipse.org的几个项目中活跃，你的结论对我来说很有意义。我想在你的列表中添加一件事：根据我的经验，长期贡献者，或超出通常错误修复或增量功能的更大贡献，只有在项目的当前提交者留下“空白”并非常透明地沟通时才会发生。只有当你非常清楚地沟通你关注哪些领域和不关注哪些领域时，潜在贡献者才能确定一个他们可以填补的利基。这对你来说听起来合理吗？ 回复
Max Kanat-Alexander说：2011年2月7日下午9:01 嘿Boris。感谢精彩的评论和赞美。
你知道，我听过几次关于留下“空白”的说法——最著名的是Linus Torvalds说的，像“如果你发布的东西很糟糕，那么人们会想修复它们”（我不记得确切的措辞）。
所以这个问题是，我无法可靠地证明这是真的。Bugzilla有重要部分需要很多关爱，我们多次清楚地广告这些部分需要