如何组建开源社区

将编程看作是一种社交活动，这将改变我们围绕编程而构建社区的方式。我们应聚焦于如何去构建一个社区，而不是如何去构建一块代码。以上是 Ash Furrow 在 Craft 大会上提出的观点。他的建议还包括：应采用一种行为准则（Code of Conduct）；对持续时间长的或很激烈的讨论，应使用 Skype 电话或 Google Hangout 开展；避免亲历亲为去解决一些简单的问题；将权利和责任分发下去。

Ash Furrow 是 Artsy 的一名高级工程师，他在 Craft 2017 大会上就如何构建开源社区做了一个演讲。InfoQ 以问答、总结和文章对本次大会进行了全程报道。

InfoQ 采访了 Furrow，议题包括：编程为什么是一种社交活动、开源社区中提升同理心（Empathy）的做法、如何能尽早地识别或避免开源维护者产生厌倦情绪，以及企业如何从开源中受益。

InfoQ：您在报告中指出“编程是一种社交活动”，能再详细介绍一下吗？

Ash Furrow：让我们考虑一下编程的本质所在。编程并非仅仅是打字，而是读写文档、提出问题和读写代码。这是人与人之间而非机器间的多种交流（编写代码是为了人能理解，顺便也能让机器执行）。交流是一种十分社会化活动，我认为有时编程人员并没有认识到从事我们这一行时交流的重要性。

将编程看成是一种社交活动，这将改变我们围绕编程而构建社区的方式。我们应稍少去关注代码，更多地重视社区。这其中需要的是同理心。

InfoQ：您是如何做到提升开源社区中的同理心的？

Furrow：同理心非常难以在线上社区培育，这是因为我们线上交流的主要手段是文本。文本并不能体现出细微的变化，也不能提供语调。这也是为什么我要鼓励开源社区维护者将持续时间长的或激励的讨论尽早移到 Skype 电话或 Google Hangout 上进行。互相看得见听得到，才能谨记更好地实现项目是我们的共同追求。

要让人们知道社区是欢迎他们参与进来的，无需担心会受到欺负或骚扰，这其中所遵循的行为准则依然有很长的路要走。只有当软件是每个人都参与编写的，才会实现人人可用的软件。只有当我们明确地欢迎那些曾被编程社区排除在外的人，这样的事情才会发生。

InfoQ：要让人们更容易对开源做出贡献，维护者应该怎么做？

Furrow：聚焦于构建一个社区，而非构建一个代码库。避免亲历亲为地解决简单的问题，而是去新建一个 GitHub 议题（issue），并将议题标记为“适合新手”，这样其他人会在解决问题后感觉良好。如果有人已经创建了议题，表示出对他们的感谢。

有时你会与社区成员产生不一致的意见。如果发生这种情况，我喜欢使用的方法称为 LARA，即倾听（Listen）、证实（Affirm）、响应（Respond）和添加（Add）。

• 倾听：重读一下他们所写的内容，尽量把他们往好里想，正如这仿佛是你最好的朋友所写的评论。
• 证实：找出你同意的内容，并告诉他们。
• 响应：在交流中保持晓之以理、动之以情。
• 添加：加入事实、反例，以及对项目远景文档的引用。

InfoQ：你提及开源维护者存在产生厌倦情绪的风险。我们应如何尽早识别厌倦情绪并避免其发生？

Furrow：尽早将自身的权力和责任分配下去。这意味着授权人们可以归并 Pull 请求并审核新议题，也意味着将开源贡献者以所有者（Owner）添加到你的 Ruby Gem 或 CocoaPod 中，还意味着使你的 Master 分支免受强制 Push。

在理想情况下，无需你亲历亲为，一个议题就能被报告、诊断和修复。

InfoQ：企业能从开源中得到什么？

Furrow：企业将可从以下几个主要方面受益。首先是企业的声誉。一名雇员难以达到名闻遐迩，对开源的贡献有助于提升开发者的名气。声誉将吸引更多的开发者加入并驻留在你的企业。其次是免费的培训。如果你的开源代码广受欢迎，那么新雇员可能早以对其了然于胸。最后一点是可收获免费的贡献。有更多的人在看你的代码，有更多开发人员在生产中使用它，这样你无需对任何人支付费用，就会在特性、QA 测试、故障报告和 Pull 请求等方面产生新的理念，以改进你的代码。

题外话，我相信工作于开源环境将有助于求知及覆车之鉴文化的养成。这些特性是与企业内部的心理安全相关联的，心理安全会导致工作更开心的雇员，以及更具生产力的团队。因此，开源可以使你的团队更快更好地编写具有更少软件缺陷的代码。另一方面，员工也会感觉很好。这是双赢。

查看英文原文： How to Build Open Source Communities