Ansible - 2023 年社区现状
欢迎！在本系列文章中，我将阐述我对未来一两年内 Ansible 社区需要做些什么的愿景 - 我希望到最后，您能同意我的观点（并参与讨论主题）。
简而言之；我将尝试说服您
- 我们是一个大型项目，但趋势并不乐观。
- 社区拥有许多部分，但正在变得支离破碎。
- 社区没有有效的代言人（没有单一的网站、博客或讨论场所）。
- 我们需要建立一个独立于Ansible.com 的社区网站。
- 我们需要建立一个论坛，将讨论/支持集中在一起。
在这篇文章中，我将阐述我们现在的现状 - 如果您已经观看过我在 2023 年 CfgMgmtCamp 上关于此主题的演讲，那么您可能可以跳过这篇文章，因为它涵盖了相同的内容。在第二篇文章中，我将说明网站和论坛的必要性。
如今社区的现状
毫无疑问，Ansible 规模庞大。无论是用户群还是贡献者，它都是一个大型项目，拥有（可能）数百万用户和数千名贡献者。干得好，我们！但 Ansible 世界并非一片祥和，为了说明这一点，让我们看一些图表。
用户群图表
首先，让我们谈谈用户。这些指标在开源软件中很难衡量，因为没有人需要告诉你他们正在使用你的项目。下载来源很多（PyPI、操作系统软件包、源代码等），而且经常被缓存。讨论空间也多种多样。社交媒体订阅量永远不会减少（人们不会取消订阅，他们只是停止阅读）。大多数用户永远不会提出问题或问问题（至少不会公开）。
因此，绝对数字在很大程度上毫无用处 - 但我们可以关注趋势。对于恰当地变化的趋势（例如，并非网站粉丝，网站粉丝数量永远不会减少），如果我们在多个指标中看到类似的趋势，我们可以相信这种趋势是真实的。
因此，让我们看看四个这样的指标
访问 docs.ansible.com
在 reddit.com/r/ansible 上的评论
StackOverflow 上标记为 ansible 的问题
发往 ansible-project 邮件列表的帖子
这些图表让我担忧。当然，每月有五十万次访问文档很棒，但这些指标都没有显示积极趋势 - 文档访问量持平，其他三个指标都在下降。我们的工具现在如此优秀，以至于用户不再需要问问题了吗？所有可能与 Ansible 相关的问题都已被问过了？在我看来，这不太可能。但让我们继续看看，看看我们还能关注什么...
贡献者群图表
我们在 GitHub 上的存在感很强 - 曾经（在 2020 年，当时一切都集中在 ansible/ansible 中），我们是 GitHub 上第八大项目。但如今情况如何呢？
为了回答这个问题，我将使用更严格的 活跃 GitHub 贡献者 定义。我不会在这里深入数学原理，但这基本上涉及统计用户创建的所有问题、PR 和评论，并为其赋予权重，然后应用基于时间的衰减。换句话说，这需要要么近期活动显著增加，要么至少持续参与几周/几个月。换句话说，我不符合这个标准，因为我目前的大部分工作都在其他领域。
那么，我们有多少 活跃贡献者 呢？我索引了大约 500 个与 Ansible 相关的存储库，结果如下
我无法过分强调 850 名高度活跃的贡献者是多么巨大！每次看到这个数据集时，我都感到震惊。但同样，它低于一年前的水平。我们也可以看看一些其他子集... 这里我们只关注所有包含在完整 ansible 包中的 Collections 存储库
同样的故事。这里只有 ansible/ansible
再次相同。我可以向您展示更多，但在大多数项目中，这种模式会重复出现 - 在我检查的所有部分中，只有 DevTools 在 2023 年 1 月有所增长。
贡献并不仅仅局限于 GitHub。其他地方的讨论呢？我们已经展示了邮件列表的图表，但聊天呢？
每天的 Matrix 用户数，经过平滑处理以反映每周变化
这个图表有一个好消息（至少对我来说是好消息！）- Matrix 使用量正在增长，而且一直在增长（事实上，我们聊天中 60% 的每日用户来自 Matrix）。这对我的上一个重大提案来说是一个胜利。但 IRC 正在下降，而且下降速度快于 Matrix 的增长速度，因此总趋势（最上面那条红色线）再次下降。
最后一个 - 聚会。鉴于疫情的影响，这一点不足为奇，但它也显示出相同的趋势
总结
那么，到底发生了什么？这些图表中的任何一个都有多种解释，但我只能想到两种解释可以解释所有这些图表。
首先，我认为这并非真实情况，但我们还是把它说出来。项目真的在消亡吗？所有项目（就像所有产品一样）都遵循一个增长/成熟/衰退曲线 - 随着项目的成熟，您会期望早期贡献者让位于用户，最终用户也会离开，特别是如果项目的目标不再具有相关性。
这符合实际情况吗？如果我们处于“增长”阶段，我会期望贡献者指标上升。如果我们处于“成熟”阶段，那么用户的趋势应该是上升的。那么，只剩下“衰退”了吗？对吧？
我不相信。Ansible 的目标（根据 PyPI 的说法是“极其简单的自动化”）仍然像以往一样具有相关性。在会议和与业内朋友的交流中，表明仍然有很多东西可以自动化。确实存在竞争对手，但还没有出现任何让我知道的新事物，这些事物能够吸引大量现有用户离开。
这就只剩下选项 2。如果没有任何东西在吸引用户离开，那么我们在推开他们，或者至少没有吸引他们的注意力，也没有让他们轻松参与。让我们看看是什么导致了这种情况...
强大社区的原则
我们假设对我们目标的兴趣是理所当然的 - 如果你不想自动化，Ansible 就不是你的项目。但是，如果这个项目符合你的目标，那么人们在社区中寻找什么？哪些因素可以确保社区继续发展？这些因素对所有社区（甚至我认为包括线下社区）来说都是通用的
- 强大的目标：没有它，凝聚力就会丧失。
- 透明度：公开决策和规则制定。
- 意见的多样性：从集体的智慧中学习。
- 去中心化：自我组织而不是强加结构。
- 公平的权威：所有人都必须遵守相同的规则。
- 自由加入：易于查找，参与门槛低。
（感谢 社会架构，Pieter Hintjens）
我可以写一页来详细说明每个原则（Pieter 也写过，如果你想阅读的话）。相反，让我们通过观察它们如何应用于今天的 Ansible 来进行说明。我将根据我的想法以及我们在根特举行的 Ansible 贡献者峰会上进行的举手表决，为每个原则评分。
强大的目标：没有它，凝聚力就会丧失（4/10）
目标是基石 - 如果我们不同意我们要解决的问题，那么我们就无法在其他几乎所有问题上达成一致。当差异很大时（你想构建软件，我想烘焙）这一点很明显，但当差距很小时，会导致一些尴尬的争论。
我认为我们在这一点上做得还不错。我们很清楚我们关注的是自动化，这很好，我们也经常提到“简单”。但是，我们在不同地方有很多不同的版本。我们可以反思一下我们的目标，重新措辞，并在所有地方使用它。
透明度：公开决策和规则制定（6/10）
亚里士多德首先谈到了集体的智慧，后来其他人也谈到了这一点。开源软件通常是很好的例子。我们知道，当非专家参与时，群体可以进行更好的讨论，充满活力的社区可以比小型团队更快地探索问题空间。
但这只有在我们将要采纳的智慧、如何共享它以及如何在发展过程中更新自己方面保持透明的情况下才能实现。如果我们没有透明地讨论和总结事情，我们就无法从智慧中获益。
总的来说，我们在这一点上做得还不错 - 鉴于项目的规模，大多数项目都在 GitHub 上，大多数讨论都有公开辩论的成分，而且这些讨论的记录也存在。
然而，我们（Red Hat）被指责没有根据社区的意见采取行动（有时不公正，有时并非如此），一些决策是在内部做出的，工作记录在内部跟踪器上，而且会议/决策记录通常难以找到。我们可以做得更好，如果社区有更好的工具来支持它，这将更容易。
意见的多样性：从集体的智慧中学习（8/10）
“集体的智慧”的问题之一是，它无法纠正群体本身的偏差。解决此问题的唯一方法是确保群体尽可能多样化 - 人员、背景、用例，都应该受到欢迎并被倾听。即使（特别是！）我们的批评者也拥有应该参与的有效观点，我们应该以包容和包容为关键原则来对待人们。
在这方面我们做得很好 - 有礼貌的辩论通常受到欢迎，我们有一个可靠的行为准则来处理任何问题（我们确实在执行它）。多样性长期以来一直是 FOSS 的整体问题，但我希望人们在我们社区中感到宾至如归，无论他们是谁 - 如果我错了，请告诉我，这对我很重要。
我之所以没有给出 9 或 10 的原因是（从最后一点来看），一些事情仍然是 Red Hat 的内部事宜。在这样的情况下，我们无法包容更广泛的群体，因此我们无法获得满分。
去中心化：自我组织优于外部结构（8/10）
为了探索问题空间，社区需要尽可能轻松地尝试事物。自我组织取决于这一点，否则将出现一组守门人来决定什么对项目是一个“好主意”。
毫无疑问，这是我们最强大的优势，我们在这方面做得很好。Matrix 房间和 GitHub 仓库可以免费启动，为一群人提供试验场所。热门项目会引起关注，并被更多人使用。ARA 和 VScode 插件就是这方面的良好示例。
如果说有什么不足的话，那就是我们在这方面做得几乎太过出色了。凭借 30 多个聊天室和近 500 个 GitHub 仓库，我们开始出现碎片化 - 用户难以找到有趣的解决方案，或如何为其做出贡献。
公平的权力：所有人必须遵守相同的规则（3/10）
有人必须在社区内制定规则。但至关重要的是，所有人都遵守这些规则，并且改变这些规则的流程对所有人都是透明的，包括谁有权改变这些规则以及人们如何加入该群体。如果某个子群体有不同的规则，就会变成有毒的局面（例如，看看Rust 在 2021 年发生了什么）
当我问 CfgMgmtCamp 的与会者我们在这方面做得如何时，没有人说我们做得很好。我之前提到的碎片化在这里也给我们带来了伤害 - 在许多情况下，我们没有一致地了解“谁拥有什么”，也不知道责任归属何处。在某些情况下，制定规则的人必须受雇于 Red Hat，这在长远来看显然是不健康的。
改变这一点将是所有工作中最难的部分，但我们必须这样做。
自由加入：易于查找，参与门槛低（4/10）
让参与变得容易是任何社区的基石，因为许多人都会感兴趣，但时间不多。每一步都让寻找你想要的东西变得更加困难，这意味着另一批潜在用户/贡献者将无法找到它。
Red Hat 没有其他产品没有为上游项目提供单独的网站。找到参与Ansible 的地方很难 - ansible.com/community 不够充分，在那之后，你就会陷入 GitHub 仓库、聊天室、邮件列表等等的混乱之中。如今，如果你想为特定事物做出贡献（或获得帮助），那么这并不容易 - 尤其是对于不熟悉 GitHub 的人来说。
最明显的证据是用户迁移到 Reddit 和 StackOverflow 来讨论和提问。我们未能提供一种适合现代用户的方式，因此他们离开了。
我之所以没有给它更低的评分，是因为如果你能找到一个好地方，那么我们非常欢迎你。但这有一个很大的前提。
Ansible 社区的结构性主题
让我们重新审视上述数据背后的两种可能解释
- 社区正处于增长/成熟/衰退阶段的“衰退”阶段
- 社区正在离开，因为存在结构性问题
如果我错了，而原因是 (1)，那么我们也无法真正解决它。因此，我选择相信是 (2)，并用上述理由来支持这一观点。
从上面提到的 6 条原则来看，我可以看出两个主要主题
碎片化
Ansible（截至撰写本文时）至少有 20 个项目（根据生态系统页面），这很棒 - 但它也伴随着代价。
当我们回顾我们的原则并提出“我们如何讨论我们的使命或规则？”、“我们如何确保参与变得容易？”，甚至“人们在 Ansible 中谈论什么？”等问题时，并不清楚应该在哪里查看或在哪里讨论。沟通不畅很常见 - 例如，在架构讨论中，不同组件之间没有及时沟通，导致无法避免冲突。
用户也出现了碎片化 - 他们应该在哪里获得帮助？许多人并不熟悉 GitHub。在 StackOverflow 上提供帮助的人（可能）不是在 Reddit 或 Discord 上提供帮助的人。这些是宝贵的知识，人们没有看到，因为用户群分散在多个地方。如果你无法重复使用答案，或者问题问错了地方，那么支持将更加繁重。
缺乏声音
当整个社区想要交谈时，它应该在哪里交谈？ansible.com/community 页面是静态的，并且受到严格的监管。ansible.com/blog 也是如此。我们有一个名为 Bullhorn 的通讯，但作为网络档案，它并不容易找到，而且根本没有社区博客。
当用户想要迈出下一步时，他们应该如何找到它？如果他们刚看完 YouTube 视频，或者从朋友那里看到了现场演示，他们应该去哪里？那一个社区页面 的范围有限，文档的重点不同，然后（再次）我们会进入聊天室和 GitHub 仓库的泥潭。
如果没有人可以讨论 Ansible 生态系统，那么就很难为整个生态系统构建一个基础。如果没有人可以放置地图，就很难为用户指明他们需要的东西。
未来的计划
这篇文章已经很长了。我希望我已经说服你，我们存在着一系列结构性问题，并且它们值得解决。
在下一篇文章中，我将介绍我关于如何解决这些问题的愿景。但这不是由我决定 - 如果你同意我的观点，你需要去投票。投票链接如下：这里 和 这里
