全球开源社区通常面临着语音壁垒、文化差异以及其它的挑战。如何去解决它们呢？

今天的开源组织参与人员来自于全世界。你能预见到组建在线社区可能遇到哪些困难吗？有没有什么办法能够克服这些困难呢？

为开源社区贡献力量的人共同合作推动软件的开发和发展。在过去，人们是面对面或者通过邮件和电话来交流的。今天，科技孕育出了在线交流——人们只需要进入一个聊天室或消息渠道就能一起工作了。比如，你可以早上跟摩洛哥的人一起工作，到了晚上又跟夏威夷的人一起工作。

全球社区的三个挑战

任何一个团队合作过的人都知道意见分歧是很难被克服的。对于在线社区来说，语言障碍、不同的时区，以及文化差异也带来了新的挑战。

语言障碍

英语是开源社区中的主流语言，因此英语不好的人会很难看懂文档和修改意见。为了克服这个问题，吸引其他地区的社区成员，你需要邀请双语者参与到社区中来。问问周围的人——你会发现意想不到的精通其他语言的人。社区的双语成员可以帮助别人跨越语言障碍，并且可以通过翻译软件和文档来扩大项目的受众范围。

人们使用的编程语言也不一样。你可能喜欢用 Bash 而其他人则可能更喜欢 Python、Ruby、C 等其他语言。这意味着，人们可能由于编程语言的原因而难以为你的代码库做贡献。项目负责人为项目选择一门被软件社区广泛认可的语言至关重要。如果你选择了一门偏门的语言，则很少人能够参与其中。

不同的时区

时区为开源社区带来了另一个挑战。比如，若你在芝加哥，想与一个在伦敦的成员安排一次视频会议，你需要调整 8 小时的时差。根据合作者的地理位置，你可能要在深夜或者清晨工作。

肉身转移，可以让你的团队在同一个时区工作可以帮助克服这个挑战，但这种方法只有极少数社区才能够负担的起。我们还可以定期举行虚拟会议讨论项目，建立一个固定的时间和地点以供所有人来讨论未决的事项，即将发布的版本等其他主题。

不同的时区也可以成为你的优势，因为团队成员可以全天候的工作。若你拥有一个类似 IRC 这样的实时交流平台，用户可以在任意时间都能找到人来回答问题。

文化差异

文化差异是开源组织面临的最大挑战。世界各地的人都有不同的思考方式、计划以及解决问题的方法。政治环境也会影响工作环境并影响决策。

作为项目负责人，你应该努力构建一种能包容不同看法的环境。文化差异可以鼓励社区沟通。建设性的讨论总是对项目有益，因为它可以帮助社区成员从不同角度看待问题。不同意见也有助于解决问题。

要成功开源，团队必须学会拥抱差异。这不简单，但多样性最终会使社区收益。

加强在线沟通的其他方法

• 本地化： 在线社区成员可能会发现位于附近的贡献者——去见个面并组织一个本地社区。只需要两个人就能组建一个社区了。可以邀请其他当地用户或雇员参与其中；他们甚至还能为以后的聚会提供场所呢。
• 组织活动： 组织活动是构建本地社区的好方法，而且费用也不高。你可以在当地的咖啡屋或者啤酒厂聚会，庆祝最新版本的发布或者某个核心功能的实现。组织的活动越多，人们参与的热情就越高（即使只是因为单纯的好奇心）。最终，可能会找到一家公司为你提供聚会的场地，或者为你提供赞助。
• 保持联系： 每次活动后，联系本地社区成员。收起电子邮箱地址或者其他联系方式并邀请他们参与到你的交流平台中。邀请他们为其他社区做贡献。你很可能会发现很多当地的人才，运气好的话，甚至可能发现新的核心开发人员！
• 分享经验： 本地社区是一种非常有价值的资源，对你，对其他社区来说都是。与可能受益的人分享你的发现和经验。如果你不清楚（LCTT 译注：这里原文是说 sure，但是根据上下文，这里应该是 not sure）如何策划一场活动或会议，可以咨询其他人的意见。也许能找到一些有经验的人帮你走到正轨。
• 关注文化差异： 记住，文化规范因地点和人而异，因此在清晨安排某项活动可能适用于一个地方的人，但是不合适另一个地方的人。当然，你可以（也应该）利用其他社区的参考资料来更好地理解这种差异性，但有时你也需要通过试错的方式来学习。不要忘了分享你所学到的东西，让别人也从中获益。
• 检查个人观点： 避免在工作场合提出带有很强主观色彩的观点（尤其是与政治相关的观点）。这会抑制开放式的沟通和问题的解决。相反，应该专注于鼓励与团队成员展开建设性讨论。如果你发现陷入了激烈的争论中，那么后退一步，冷静一下，然后再从更加积极的角度出发重新进行讨论。讨论必须是有建设性的，从多个角度讨论问题对社区有益。永远不要把自己的主观观念放在社区的总体利益之前。
• 尝试异步沟通： 这些天，实时通讯平台已经引起了大家的关注，但除此之外还别忘了电子邮件。如果没有在网络平台上找到人的话，可以给他们发送一封电子邮件。有可能你很快就能得到回复。考虑使用那些专注于异步沟通的平台，比如 Twist，也不要忘了查看并更新论坛和维基。
• 使用不同的解决方案： 并不存在一个单一的完美的解决方法，学习最有效的方法还是通过经验来学习。从反复试验中你可以学到很多东西。不要害怕失败；你会从失败中学到很多东西从而不停地进步。

社区需要营养

将社区想象成是一颗植物的幼苗。你需要每天给它浇水，提供阳光和氧气。社区也是一样：倾听贡献者的声音，记住你在与活生生的人进行互动，他们需要以合适的方式进行持续的交流。如果社区缺少了人情味，人们会停止对它的贡献。

最后，请记住，每个社区都是不同的，没有一种单一的解决方法能够适用于所有社区。坚持不断地从社区中学习并适应这个社区。

via: https://opensource.com/article/17/12/working-worldwide-communities

作者：José Antonio Rey 译者：lujun9972 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

Red Hat 已经学会了跟随开源社区，并将其商业化。你也可以。

开源中最强大但最困难的事情之一就是社区。红帽首席执行官 Jim Whitehurst 在与 Slashdot 的最近一次采访中宣称：“有强大社区的存在，开源总是赢得胜利”。但是建设这个社区很难。真的，真的很难。尽管预测开源社区蓬勃发展的必要组成部分很简单，但是预测这些部分在何时何地将会组成像 Linux 或 Kubernetes 这样的社区则极其困难。

这就是为什么聪明的资金似乎在随社区而动，而不是试图创建它们。

可爱的开源寄生虫

在阅读 Whitehurst 的 Slashdot 采访时，这个想法让我感到震惊。虽然他谈及了从 Linux 桌面到 systemd 的很多内容，但 Whitehurst 关于社区的评论对我来说是最有说服力的：

建立一个新社区是困难的。我们在红帽开始做一点，但大部分时间我们都在寻找已经拥有强大社区的现有项目。在强大的社区存在的情况下，开源始终是胜利的。

虽然这种方法 —— 加强现有的、不断发展的社区，似乎是一种逃避，它实际上是最明智的做法。早期，开源几乎总是支离破碎的，因为每个项目都试图获得足够的成员。在某些时候，人们开始聚集两到三名获胜者身边（例如 KDE vs. Gnome，或者 Kubernetes vs. Docker Swarm 与 Apache Mesos）。但最终，很难维持不同的社区“标准”，每个人都最终围拢到一个赢家身边（例如 Kubernetes）。

参见：混合云和开源：红帽数字化转型的秘诀（Tech Pro Research）

这不是投降 —— 这是培养资源和推动标准化的更好方式。例如，Linux 已经成为如此强大的力量的一个原因是，它鼓励在一个地方进行操作系统创新，即使存在不同的分支社区（以及贡献代码的大量的各个公司和个人）不断为它做贡献。红帽的发展很快，部分原因是它在早期就做出了聪明的社区选择，选择了一个赢家（比如 Kubernetes），并帮助它取得更大的成功。

而这反过来又为其商业模式提供动力。

从社区混乱中赚钱

对红帽而言一件很好的事是社区越多，项目就越成功。但是，开源的“成功”并不一定意味着企业会接受该项目，这仅仅意味着他们愿意这样做。红帽公司早期的直觉和不断地支付分红，就是理解那些枯燥、平庸的企业想要开源的活力，而不要，好吧，还是活力。他们需要把它驯服，变得枯燥而又平庸。Whitehurst 在采访中完美地表达了这一点：

红帽是成功的，因为我们沉迷于寻找方法来增加我们每个产品的代码价值。我们认为自己是帮助企业客户轻松消费开源创新的。

仅举一例：对于我们所有的产品，我们关注生命周期。开源是一个伟大的开发模式，但其“尽早发布、频繁发布”的风格使其在生产中难以实施。我们在 Linux 中发挥的一个重要价值是，我们在受支持的内核中支持 bug 修复和安全更新十多年，同时从不破坏 API 兼容性。这对于运行长期应用程序的企业具有巨大的价值。我们通过这种类型的流程来应对我们选择进行产品化的所有项目，以确定我们如何增加源代码之外的价值。

对于大多数想要开源的公司来说，挑战在于他们可能认识到社区的价值，但是不知道怎么不去销售代码。毕竟，销售软件几十年来一直是一个非常有利可图的商业模式，并产生了一些地球上最有价值的公司。

参看红帽如何使 Kubernetes 乏味并且成功

然而, 正如 Whitehurst 指出的那样，开源需要一种不同的方法。他在采访中断言：“你不能出售功能， 因为它是免费的”。相反, 你必须找到其他的价值，比如在很长一段周期内让开源得到支持。这是枯燥的工作，但对红帽而言每年值数十亿美元。

所有这一切都从社区开始。社区更有活力，更好的是它能使开源产品市场化，并能赚钱。为什么？嗯，因为更多的发展的部分等价于更大的价值，随之让自由发展的项目对企业消费而言更加稳定。这是一个成功的公式，并可以发挥所有开源的好处，而不会将它受制于二十世纪的商业模式。

via: https://www.techrepublic.com/article/most-companies-cant-buy-an-open-source-community-clue-heres-how-to-do-it-right/

作者：Matt Asay 译者：geekpi 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

千里之行，始于足下 （ The journey of a thousand miles begins with one step ） —— 老子

参与开源工作有很多好处，可以帮助你优化和加速技术生涯，包括但不仅限于提高现实中的技术经验和拓展你的专业人脉。有很多你能做贡献的开源项目，无论是小型、中型、大型，还是不知名或知名的项目。在这篇文章里我们将专注于如何为网上最大、最有名的开源项目之一 ，Mozilla ，做出贡献。

为什么要向 Mozilla 做贡献？

现实经验

Mozilla 是网络上最大的开源项目之一，其也托管了许多其他的开源项目。所以，当你为像 Mozilla 这样的大型开源项目做贡献时，你能真正接触到技术领域中的事物是如何工作的，能增长关于技术术语和复杂系统功能的知识。最重要的是，你能理解如何将代码从本地系统移动到实际的代码仓库里。你将会学习在管理大型项目时，贡献者们使用的许多工具和技术，如 Github 、Docker、Bugzilla 等。

社区联系

社区是任何开源项目的核心。向 Mozilla 做贡献将你与 Mozilla 的员工和顾问、资深 Mozilla 贡献者（又称 Mozillians）以及你当地的 Mozilla 社区相互联系在一起。社区里有着同样关注并致力于改善开源项目的志趣相投的人们。

你也能有个机会来建立在 Mozilla 社区里的专属身份，激励其他 Mozillians 同伴。如果你想的话，最后你也能指导其他人。

活动和酷物件

没有点充满乐趣的活动和小礼品的社区是不完整的。Mozilla 也不例外。

向 Mozilla 做贡献能给你机会参加 Mozilla 的内部活动。一旦你成为熟练的 Mozilla 贡献者，你将能主持你当地的 Mozilla 活动（Mozilla 或许会予以资金支持）。当然，会另外提供些小礼品 —— 贴纸，T恤，马克杯等。

根据 CC BY-SA 4.0 协议分享，印度 2016 Mozilla 聚会， Moin Shaikh 提供。

如何向 Mozilla 做贡献

不管您是编程人员、网页设计师、品质控制测试者、翻译，或者是介于之间的任何职业，都有许多不同的方式向 Mozilla 做贡献。让我们看看以下两个主要方面：技术贡献和非技术贡献。

根据 CC BY-SA 3.0 协议分享， Mozilla.org 供图。

技术贡献

技术贡献是给那些喜欢编程，想要用他们的代码来弄出点动静的人。有不同的用特定编程语言的项目可供施展能力。

• 如果喜欢 C++ ，你能向火狐的核心层和其他 Mozilla 产品做贡献。
• 如果喜欢 JavaScript、HTML 和 CSS ，你能向火狐的前端做贡献。
• 如果你懂得 Java ，你能向火狐移动端、火狐安卓版和 MozStumbler （LCTT 译注：MozStumbler 是 Mozilla 开源的无线网络扫描程序）做贡献。
• 如果你懂得 Python ，你能给网络服务，包括 火狐同步 （ Firefox Sync ） 或者 火狐账户 （ Firefox Accounts ） 做贡献。
• 如果你懂得 Shell、Make、Perl 或者 Python ，你能给 Mozilla 的编译系统和发布引擎和自动化做贡献。
• 如果你懂得 C 语言，你能给 NSS、Opus 和 Daala 做贡献。
• 如果你懂得 Rust 语言，你能给 RustC、Servo（一个为并行、安全而设计的网页浏览器引擎）或者 Quantum （一个将大量 Servo 转化为 Gecko 的项目）做贡献。
• 如果你懂得 Go 语言，你能给 Heka 做贡献，这是一个数据处理工具。

要获取更多信息，可以访问 Mozilla 开发者网络 Mozilla Developer Network （MDN）的开始部分来了解不同的贡献领域。

除了语言和代码，积极测试火狐浏览器的各个部分、火狐安卓浏览器和 Mozilla 的很多网络组件，例如火狐附加组件等，这样也能贡献你的品质保证（QA）和测试能力。

非技术贡献

你也可以给 Mozilla 提供非技术贡献，专注于以下领域：品质保证（QA）测试，文档翻译，用户体验/用户界面（UX/UI）设计， Web 识别 （ web literacy ） ， 开源宣讲 （ open source advocacy ） ，给 Mozilla 的火狐用户、雷鸟用户提供支持等。

品质保证（QA）测试： Mozilla 的 QA 团队遍及全世界，有着庞大且活跃的社区，他们深入参与到了火狐及 Mozilla 的其他项目中。QA 贡献者早期介入到各种产品，探索新的特性，记录漏洞，将已知漏洞分类，编写并执行测试用例，进行自动化测试，并从可用性角度提供有价值的反馈。想开始或者了解更多 Mozilla QA 社区资源，请访问 Mozilla QA 社区 网页。

用户体验设计： 如果你是个有创意的设计者或是个喜爱折腾色彩和图形的极客，Mozilla 在其社区里有很多位置提供给你，在那里你能设计好用易理解的、美妙的 Mozilla 项目。去看看 Mozilla GitHub page 上的 开放设计仓库 Open Design repository 页面。

用户支持（论坛和社交支持）： 这是成千上万像你我这样的火狐、雷鸟用户访问和发帖询问关于火狐、雷鸟问题的地方。这也是他们从像我们这样的 Mozilla 贡献者获取回答的地方。这不需要编程才华，不需要设计技能，不需要测试能力，作为火狐用户支持贡献者，你只需要有点儿火狐的知识即可上手。点击 SUMO 的“参与其中”的链接来加入用户支持。从做支持开始或许是你着手开始你的 Mozilla 旅程中最简单的部分。（注：三年前，我从社区支持论坛开始我的 Mozilla 旅程）

编写知识库和帮助文章： 如果你喜欢写作和传授知识，知识库对你来说是个好地方。 Mozilla 总是在寻找能给火狐和其它产品用英文撰写、编辑、校对文章的志愿者。每周有成千上万的用户浏览这些知识库文章，通过分享你的智慧和编写帮助文章，你也能产生强大的影响力。访问 Mozilla 知识库 页面来参与其中。

本地化，又称 “L10N”： （LCTT 译注：L10N 是 localization 的缩写形式，意即在 l 和 n 之间有 10 个字母） Mozilla 的产品，例如火狐，被全世界数百万讲着不同语言的人们所使用着。人们需要这些产品以他们的语言显示。语言本地化是个非常需要志愿者的领域。需要你的翻译和本地化能力的项目包括：

• Mozilla 产品，例如火狐
• Mozilla 网页和服务
• Mozilla 市场活动
• SUMO 产品支持文档
• MDN 开发者文档

你可以访问 Mozilla 本地化页面来参与其中。

教授和 Web 识别 （ web literacy ） 能力： Mozilla 基本使命目标之一是使所有人都可访问网络。为了实现这个目标使命，Mozilla 通过提供 web 识别工具和技术来致力于教育和帮助 Web 用户。这是可以用你的教授技能来帮助他人的地方。如果你是一位喜欢分享知识、给民众展示关于互联网相关东西的热情的老师，来看一下 Mozilla 发起的 Web 教育活动。将互联网和 web 识别教给你当地社区、学校孩子、你的朋友和其他有关的人。

宣讲： 如果你对 Mozilla 的使命充满热情，你能通过倡导 Mozilla 的使命来传播使命内容。当倡导 Mozilla 的使命时，你能做出如下来贡献：

• 捍卫公共规则，为开放的互联网和用户隐私做斗争。
• 跟网站管理者在兼容性方面合作，提高网站的互操作性。
• 帮助网络作者提升在开放网络方面的文章写作。
• 成为 火狐朋友 （ Firefox Friends ） ，展示你作为 Mozilla 和火狐贡献者的自豪。

想要开始帮助宣传 Mozilla 使命，看一下 Mozilla 宣讲 页面。

如果你还有疑惑，我来帮你开始！

我知道，作为一个新来的贡献者，这篇文章或许给你太多的信息。如果你需要更深入的方向、更多的资源资料，你可以在下面的评论中问我，或者在 Twitter 里私信我，我很乐意帮助你开始向 Mozilla 做出第一次的贡献（或者更多！）

作者简介：

Moin Shaikh 是一个开源科技极客，职业是网页分析，有着 7 年多的 IT 工作经验。主要贡献领域：火狐网络 QA ，火狐技术支持，本地化和社区指导。除了开源贡献，还学习并身体力行于用户体验、物料设计和电子商务分析。

via: https://opensource.com/article/17/1/how-get-started-contributing-mozilla

作者：Moin Shaikh 译者：ypingcn 校对：jasminepeng

本文由 LCTT 原创编译，Linux中国 荣誉推出

如果你想要使用指标来追踪你的自由开源软件（FOSS）的社区。现在就面临着一个问题：我应该去追踪哪些指标呢？

要回答这个问题，你必须知道你需要什么信息。比如，你可能想要知道一个项目社区的可持续性。一个社区对问题的应对速度有多快。一个社区怎么吸引、维护或者流失贡献者。一旦你知道需要哪类信息，你就可以找出哪些社区活动可以提供你想要知道的内容。幸运的是，自由开源软件（FOSS）遵从开放式开发模型，在其软件开发仓库里留下了大量的公共数据，我们可以对这些数据进行分析，并从中收集到一些有用的数据。

在这篇文章中，我会介绍一些指标，从而为你的项目社区提供一个多方位的视角分析。

1. 社区活动（Activity）

一个社区的总体活动和这个社区怎样随着时间演变，是度量所有社区好坏的非常有用的指标。社区活动是评价一个社区工作量的第一印象，也可以用来追踪不同种类的活动。比如，提交次数，给人的第一印象就是跟开发工作量挂钩。通过 提出的问题 （ tickets opened ） 我们可以大概知道提交了多少 bug 或者又提出了多少新特性。邮件列表中的邮件数量或者论坛帖子的数量可以让我们了解到有过多少次公开讨论。

OpenStack 活动看板上面显示的项目代码提交次数和代码评审之后代码合并次数随时间变化的趋势图（周数据）

2. 社区规模（Size）

社区的规模指的是参与到这个社区的人数，但是，基于不同形式的参与人数也有很大的差别。好消息是，通常你只对积极活跃的贡献者比较感兴趣。活跃的贡献者会在项目的仓库留下一些线索。这意味着你可以通过查看 git 仓库存放的代码中 author字段来统计积极贡献代码的人数，或者通过看积极参与问题解决的人数来统计活跃人数。

所谓活动（某些人做了某些事）可以扩展到很多方面。一种常见的跟踪活动的方式是看有多少人做了工作量相当可观的任务。比如，通常一个项目代码的贡献者是来自这个项目社区的一小部分人。了解了这一小部分人，就对核心的工作组（比如，领导这个社区的人）有一个基本的认识了。

Xen 项目开发看板上展示的该项目邮件列表上作者人数和提交人数随时间的变化趋势（每月数据）

3. 社区表现（Performance）

到目前为止，关注点主要集中在活动数量和贡献者数量的统计上了。你也可以分析流程还有用户的表现如何。比如，你可以测量某流程需要多久才能执行完成。解决或者关闭问题的时间可以表明一个需要及时响应的项目对新信息的应对如何，比如修复一个报告过来的 bug 或者实现一个新需求。代码评审花费的时间，即从代码修改提交到被通过的时间，可以看出更新一个提出的改变要达到社区期望的标准需要多久。

其他的一些指标主要与项目处理挂起的工作表现如何有关，比如新的和被关闭问题的比例，或者仍然没有完成的代码评审的队列。这些参数能告诉我们像投入到解决这些问题的资源是否充足这样的一些信息。

在2015第三季度 OpenStack 开发报告上显示的，每季度关闭与打开状态的问题数之比，接受与放弃的改变提案与最新的改变提案之比

4. 社区人口特征（Demographics）

随着贡献者的参与或者退出，社区也在不断改变。随着人们加入和退出社区，社区成员的会龄（从社区成员加入时算起）也各异。社区会龄统计图表很直观的展现了这些改变随时间的变化。图表是由一系列的水平条组成，每两条水平条代表加入到社区的一代人。对于每一代， 吸引力 （ Attracted ） 水平条表示在相应的时间里有多少人加入到了社区。 活跃度 （ Retained ） 水平条表示有多少人目前仍然活跃在社区。

代表一代人的两个水平条的关系就是滞留比例：依然在这个项目中的那一代人的一部分。 吸引力 （ Attracted ） 水平条的完整集合表示这个项目在过去有多么受欢迎。 活跃度 （ Retained ） 水平条的完整集合则表示社区目前的会龄结构。

Eclipse 开发看板上显示的 Eclipse 社区的社区年龄表。每六个月定义一次

5. 社区多样性（Diversity）

多样性是一个社区保持弹性的很关键的因素。通常来说，一个社区越具有多样性（人或者组织参与的多元化），那么这个社区的弹性也就越大。比如，如果一个公司要决定离开一个自由开源社区，那么这个公司的员工贡献5%要远比贡献85%所可能引起的潜在问题要小很多。

小马因素 （ Pony Factor ） ，是 Daniel Gruno 为“最少的开发者贡献了50%的代码提交量”这一现象定义的术语。基于小马因素， 大象因素 （ Elephant Factor ） 则是指最少量的公司其员工贡献了50%的代码提交量。这两个数据提供了一种指示，即这个社区依赖多少人或者公司。

2015开发云数量状态统计显示的在云计算领域的几个自由开源社区项目的小马和大象因素。

还有许多其他的指标来衡量一个社区。在决定收集哪些指标时，可以考虑一下社区的目标，还有哪些指标能帮到你。

via: https://opensource.com/business/15/12/top-5-open-source-community-metrics-track

作者：Jesus M. Gonzalez-Barahona 译者：sonofelice 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出