光速社区:开源新纪元的最佳实践

还没有读者喜欢这篇文章。
bees in a hive with words intelligent swarming over them

Opensource.com

Ansible 团队页面 的联合创始人兼首席技术官 Michael DeHaan 共同撰写。

你们中的许多人可能听说过 Ansible。 对于那些没有听说过的人来说,它是一个开源软件项目,可以从根本上简化系统自动化的艺术。

在过去的一年中,Ansible 在 DevOps 社区中非常受欢迎。 它目前是 GitHub 上最受欢迎的 Python 项目之一。 在 GitHub 上大约 86,000 个公共 Python 存储库中,Ansible 在 星标数量 中排名第 6,在 分支数量 中排名第 3,这使得 Ansible 在受欢迎程度和潜在贡献者方面都名列 Python 项目的前 0.01%。 Ansible 目前是 GitHub 上分支数量排名第 99 位的项目,每天都会创建数千个新的存储库。 根据 GitHub 的数据,Ansible 的终身贡献者人数(878)已经超过了 Chef(345)、Puppet(324)和 CFEngine(64)的总和。

对于一个只有两年的项目来说,这还不错。

Ansible 目前所享有的成功并没有简单的路线图; 在某种程度上,成功的项目之所以成功,是因为它们在正确的时间、正确的地点提出了正确的想法。 然而,现在有一些关键的开源原则可以被认为是“久经考验的”; 曾经在开源世界中的理论已经成为明确且可重复的实践。 在 Ansible,我们从一开始就尽力遵循这些实践。

因此,以下是一些开源实践,这些实践帮助 Ansible 在相对较短的时间内成功地吸引了参与者。

使用 GitHub

……但这不仅仅是关于 GitHub。

在开源的早期,大多数项目都围绕邮件列表进行。 大多数讨论都在列表上进行,因为它是保证所有人都能看到的存档,并且自我记录的讨论有助于明确决策过程。 但是,一旦做出这些决定,并且到了提交实际代码的时候,贡献者就必须学习将其贡献给所选项目的特定机制。 因此,如果贡献者跨多个项目工作,他们需要学习几种不同的做事方式。

现在有了 GitHub,有 600 万人在使用它。 如果您的项目在 GitHub 上,这意味着没有人需要学习特殊的魔术技巧来为您的项目做贡献,因为 GitHub 上的每个项目的工作方式基本相同。 在过去用户仅仅需要弄清楚项目的贡献机制的时间里,用户现在可以 fork 一个 repo,进行修复并提交一个 pull request。 新开发人员的默认本能不再是“建议更改”——现在的本能是“修复问题”。

仅仅因为存在使 fork 更容易的基础设施,并不意味着这些 fork 都会产生贡献。 在 Ansible,我们用来评估项目健康状况的一个关键指标是 贡献者占 fork 的百分比。 以下是 GitHub 上五个最受欢迎的项目的贡献者占 fork 的百分比,以及 Ansible

twbs/bootstrap:71,079 个星标 / 26,488 个 fork / 573 个贡献者 (2%)
jquery/jquery:31,528 个星标 / 7,234 个 fork / 196 个贡献者 (3%)
joyent/node:31,499 个星标 / 7,023 个 fork / 544 个贡献者 (8%)
mbostock/d3:29,377 个星标 / 6,729 个 fork / 77 个贡献者 (1%)
angular/angular.js:27,566 个星标 / 10,040 个 fork / 936 个贡献者 (9%)
ansible/ansible:7,251 个星标 / 2,227 个 fork / 846 个贡献者 (38%)

(所有统计数据截至 2014 年 8 月 18 日)

如果仅仅是为 pull requests 铺开欢迎地毯那么容易,所有这些更大的项目都会有数千个贡献者。 相反,大多数项目,即使是成功的项目,也清楚地看到了贡献者的上限。 拥有支持贡献的基础设施至关重要,但构建一个用于大规模贡献的项目不仅仅是基础设施的选择。

围绕模块化和选项价值构建架构

2005 年,哈佛商学院的 Carliss Baldwin 和 Kim Clark 写了一篇题为“参与架构:代码架构是否缓解了开源开发模型中的免费搭便车行为?”的论文。 在这篇论文中,他们观察到具有两个特定属性的开源项目更有可能获得并保留贡献者。 这两个属性是高 模块化 和高 选项价值

模块化很简单。 具有高模块化的代码库提供了一个简单的平台和模块框架。 该平台支持模块,并为模块开发提供明确定义的规则; 然后可以根据这些规则独立地开发或修改模块,从而允许贡献者以最小的投入在项目的各个角落增加价值。

选项价值有点复杂,但可以在模块化的上下文中轻松理解。 在高度模块化的框架中,某些模块显然比其他模块更好。 甚至可能有旨在执行类似职责的竞争模块。 具有高选项价值的高度模块化项目允许用户选择某些模块但不选择其他模块,甚至可以重写特定模块。 不必采用整个工具集,而是从各种选项中进行选择,这增强了这种价值。 更多选项意味着随着时间的推移,容忍不确定性的能力更强。

因此,具有高选项价值的模块化设计允许用户立即识别贡献方式,并快速看到该贡献的价值。 没有任何事情能像成功的贡献那样推动成功的贡献——这正是 Ansible 发生的事情。 在浏览 Ansible 的库时,人们可以找到 230 多个不同的模块,其中绝大多数是由多个社区开发人员共同开发和共同维护的。 Ansible 的“电池已包含”理念有助于确保随着新模块的开发,它们在 Ansible 的核心中进行测试和集成,以便最大数量的用户以最小的集体努力获得最大的选项价值。 回馈共享 commons 的价值也得到了加强,从而创造了贡献的不朽,而不是自定义开发解决方案中常见的最终位腐烂和替换。

通过设计模块化和选项价值,Ansible 确保用户可以在短时间内做出对他们自己和他人具有永久价值的贡献。

优化首次体验

使 Ansible 能够非常快速地传播的原因之一是产品和文档都针对最快可能的成功首次体验进行了优化。 简单的安装体验和文档中的友好介绍有助于创建一个“浅水区”,新用户可以在这里涉水,而无需头朝下潜入深水区。 用户可以在午休时间尝试一下,理解它——然后了解还剩下什么需要学习——这个想法是开源软件成功的关键驱动因素。 太多项目不必要地失败了,因为他们没有投资于这个关键的想法。

如果一个 GitHub 项目仅仅是五行 README 和任意代码,它可能会在少数开发人员中幸存下来,但广泛的用户采用将遥不可及。 反过来,这限制了开发人员的范围,因为许多最佳贡献来自将用户转变为开发人员。

在开源中,成功是病毒式的。 发现一个新项目本质上是一个孵化期,在此期间用户会试用该项目。 如果体验良好,用户就会“发烧”并与朋友“传播”该项目,从而创造更多的用户,进而创造更多的开发人员。 Ansible 的许多病毒式成功都是我们的短孵化时间和高转化率的直接结果——以及 Ansible 几乎永远不会杀死其宿主的事实。

优化首次体验不仅仅是用户的首次体验; 它还扩展到开发人员的首次体验。 这需要有据可查的开发过程,以及为了让新贡献者更容易而做出的有意的努力。 代码必须针对可读性以及技术准确性进行审查,并且应避免使用巧妙的代码技巧,而应使用易于更改、编辑和理解的代码,这些代码可以被大量人员理解。

收集数据并根据数据做出决策

Ansible 的出现是因为我们认识到一种模式:用户抱怨需要学习多种自动化工具,尽管这些工具之间存在明显的共性。 当一种工具可以完成这项工作时,为什么需要单独的工具用于云配置、配置管理、编排和应用程序部署?

随着项目的增长,识别新兴模式并对其采取行动成为一项关键技能——并且这些模式只能通过不断收集和分析数据来浮现。 在 Ansible,我们有多种收集用户数据的方式,并且我们积极地收集和分析数据。 错误报告、IRC 交互、邮件列表线程、Twitter 评论和用户调查都提供了驱动关键决策的关键数据点。

仔细收集数据最重要的优势在于,它可以让您倾听正确的用户,而不仅仅是嘈杂的用户。 如果您只听嘈杂的用户,那么您构建错误的东西或为少数人而不是为多数人优化的风险就会增加。

沟通,沟通,沟通!

在管理任何大型项目时,沟通至关重要,而且没有办法回避——不幸的是,许多开发人员只是不喜欢以代码以外的任何方式进行沟通。 但是,回答问题和编写文档(无论是为用户还是为开发人员)都是必不可少的活动。 项目越简单,需要的文档就越少——但仍然需要文档。 文档越好,需要回答的问题就越少——但仍然需要回答的问题。 这就是为什么对文档进行反复重构和重写,以及在邮件列表和其他地方进行反复沟通,占据了 Ansible 早期项目时间的 50%。 这种时间投入对于 Ansible 的快速增长至关重要。

在任何试图整合多种不同观点的庞大项目中,对于做事的正确方式总会存在分歧。并非每一个 pull request 都是合适的,也并非每一个 bug 报告都是有用的。以正确的方式说“不”甚至比说“是”更重要。即使您拒绝了贡献者的贡献,也要花时间让他们感到自己的价值,这可能很难做到,尤其是当管道中还有数百个其他贡献时。我们最近标准化了对常见问题的回复,以确保即使我们达到史诗般的规模,我们也始终让我们的贡献者知道他们的贡献有多么重要。沟通可以很快,但不能简洁,并且至关重要的是,要快速而真诚地沟通 Ansible 对其贡献者的依赖程度,以及我们对拥有他们的感激之情。

我们还强烈地沟通我们的优先级。我们会明确我们现在正在做什么,以及我们稍后要做什么,以及我们做出决策的方式。随着时间的推移,沟通这些事情可以使社区以统一的愿景和声音前进,并且项目会发展出可预测的脉搏。通过观察过去事物如何运作,可以预测未来。

成功是一系列刻意的选择

开源开发的方法在过去二十年中取得了长足的进步。 Linux 内核团队花了 11 年的时间才在一个月内获得 100 位贡献者; Ansible 只花了两年时间。当然,Linux 社区必须在实践中创造方法; Ansible 团队受益于多年来对 Linux 和其他开源社区的研究和参与。

最大的教训,并且它远远超出了开源的范围:卓越是一种习惯。你习惯性地做的事情,你就会成为什么样的人。

在 Ansible,社区建设是我们最根深蒂固的习惯,它以多种方式表达。 代码库的架构,日常沟通,关注收集和处理数据,对新用户最初体验的持续关注:这些习惯导致了如此多的贡献者和拥护者团结在 Ansible 周围。 随着我们与社区合作迎接新的挑战和新的方向,这些习惯将继续推动我们前进。

User profile image.
Greg DeKoenigsberg 是 Ansible 的社区副总裁,负责领导公司与更广泛的开源社区的关系。 Greg 为 Ansible 带来了十多年的开源产品和社区领导经验,其中大部分时间都花在了为开源领导者 Red Hat 构建和领导社区上。

评论已关闭。

Creative Commons License本作品采用知识共享署名-相同方式共享 4.0 国际许可协议进行许可。
© . All rights reserved.