Rust 与开源 | Rust 并不是一家公司
译者：郭晓双 / 后期编辑：张汉东
原文： https://blog.m-ou.se/rust-is-not-a-company/
本文是 Mara(Rust Library Team Leader) 写的一篇关于 Rust 项目开源治理的文章。
不是公司
在大多数公司中，董事和股东等等都在层次结构的顶端，他们为公司设定目标。目标、里程碑、最后期限，以及有望推动公司朝着最终目标前进的事情；通常是钱。
然后在部门和团队上划分了几层管理来划分工作量。每个人都负责部分目标，确保他们的部分完成，最终将任务分配给层次结构底部的员工，所有人都以某种方式朝着主要目标努力。
虽然像 Rust 这样的大型开源项目背后的结构从远处看起来很相似，但它通常是完全颠倒的。在这样的项目中，目标和目标不是顶级团队的，而是贡献者的。
例如，作为库团队，我们可以尝试决定应该重写格式机制 (std::fmt) 以使其更小更高效。但是做出这个决定并不会让它发生。而且我们没有分配任务的员工。这不是它的工作原理。
相反，一个对格式化算法充满热情的贡献者可能会出现，并开始研究这些事情。作为图书馆团队，我们的工作是赋予这个人权力。确保他们的计划与标准库的其余部分一致，审查他们的更改并提供有用的建设性反馈，如果更多人出现在这方面工作，则成立一个工作组来帮助他们组织一切等等。
公司不会让新人随机出现来做某事。如果做得好，这就是开源的特别之处和如此美妙的地方。
个人目标
理想情况下，像 Rust 这样的开源项目的项目目标只是参与其中的每个人的个人目标的组合。这很棘手。因为当一个新人出现时，我们不会为他们分配符合我们目标的任务。相反，这个人有自己的目标和想法，增加了已经非常多样化的潜在冲突目标。
这就是为什么一个由志愿者运营的开源项目需要一个管理结构。你不能把一百个人都有自己的目标，然后希望一切顺利。
因此，管理层所做的就是从每个从事某个主题的人那里获取所有个人目标，并尝试以某种方式引导他们，使事情顺利进行。这可能涉及对不适合其他想法的想法说不，或者可能需要进行大量讨论以调整想法以使其适合。这与典型公司的工作方式完全相反，目标来自上层，管理层决定如何拆分并将其分配给从事技术工作的人员。
虽然包括 Rust 在内的许多开源项目确实有一个总体方向或路线图，但这些必须基于个人贡献者的目标才能成功。说“我们 2021 年的主要目标是改进标准库中的格式化机制”将赋予那些已经在致力于它的人，并吸引那些已经想从事类似工作的人。这会对他们有所帮助，因为我们现在会优先考虑他们需要的任何管理决策和代码审查。它可以让人们集中注意力，完成更多工作。但没有这些贡献者，设定这样的目标毫无意义。与公司不同，我们无法选择人们花时间做什么，我们也不会雇用人员分配任务。
这是一个很好的事情。
这就是人们想要在 Rust 上工作的原因。
我并不是说不能像公司那样“自上而下”管理编程语言。许多编程语言已经并且正在以这种方式非常有效地开发。然而，我要说的是，我个人不希望 Rust 项目以这种方式工作。
我不希望管理锈公司库部门。我想授权那些想要改进 Rust 语言库的人。
蓬勃的空间
不同的贡献者有着不同的目标，通过非常不同的方式工作，并且需要与管理结构完全不同的东西。
对他们中的一些人来说，我们有适当的流程让他们的工作更轻松。想要开发新的语言特性的人可以以RFC的形式提交他们的想法，并加入库团队的讨论，以获得建议和指导。想要改进编译器实现的某些重要部分的人可以提交一个MCP（majorchangeproval）并与编译器团队讨论。如果有人想修复标准库中的一个bug，可以提交一个PR并让了解上下文的人对其进行复查(review)。
换句话说，我们为贡献者提供了很多空间。工作的空间，反馈问题的空间，得到帮助的空间，赢得认可的空间, 每一种能帮助他们成功做成事情的空间。
然而我们没有为一些类型的、不幸的贡献者创造合适的空间。
理想情况下，Rust库团队直到最近的工作一直集中在在API设计上。编译器团队只会关注关键重要问题的开发。较小的变更由单个库审阅者审阅。但是并没有对更大领域的变更进行管理。这意味着没有合适的空间提供给那些想要彻底检查并且变更std : : fmt实现的人。没有一个团队他们可以去或参与这方面的工作，那么对于想去变更std : : fmt实现的人来讲，这个目标就是更难、或者完全不可能完成的了。
这就是我成立新库团队的原因。
为某个事情腾出空间通常会（意外地）导致其它事情的空间被夺走。 如果一个人不太理解事情的实现，但是他们想要应用标准库设计的实践经验，并且非常关心标准库的接口，但是周会上面主要讨论如何让bug少，在下一个版本之前如何解决现有的问题的事情，那么他是不会在一个这样的周会上面十分积极的。
我们现在已经有了库贡献者。这是一个空间，容纳管理比一般人更加多的参与项目，但是不参与整体团队的决策的人。例如那些只处理库的特定部分，或者帮助审核(review)的人，我们为这些人提供了空间。一年之前如果没有一个更加合适的团队的话，就没有合适的空间让一个人去审核(review)库的实现。
在核心团队和库团队成员的授权和帮助下，我能够做出这些团队结构的改变。反过来，这些变化有望使这些新团队的成员茁壮成长，并反过来使更多的贡献者受益，最终使语言的所有用户受益。
保持改变
我并不认为我们现在已经成功地为每个可能的贡献者创造了空间。但是一旦团队的重组尘埃落定，我确实认为结果会比我们之前的情况有所改善，更符合目前的项目。
“此时此刻” 在这里成为了一个重要的部分。这些团队是围绕着目前的成员和我认为在不久的将来可能成为成员的人而设计的。但是团队的成员的需求变化，有时会出奇地快。在一个完全由为其做出贡献的人定义的项目中，对于这个项目自身和结构发生变化的事情的时候， 它就会快速的改变。
2018年,库团队大量参与指导了流行crate的作者。该团队发布了一套指南，将会审查(review) crate 并且和crate的作者一起实施它。所有这些都是为了提高 Rust crate 生态系统的一致性和质量。
直到几天前，这在技术上仍然是我们团队明确目标的一部分，尽管这种事情已经不是很多了；尤其是因为 Ashley Mannix 离开了一段时间。如果没有人将事情作为他们的个人目标，那么这个事情就不会发生。
这是一个很好的事情。
每个人的 Rust 愿望清单上都有很多事情没有发生，因为没有人在做这件事。我们不是一家有我们需要达到的最后期限和里程碑的公司。我们是一群多元化且瞬息万变的人，他们热衷于让我们想要付出努力的事情发生。包括一群热衷于管理这一切的人，试图为所有这些努力的发生腾出空间。
有很多事情，我们应该有属于它的空间，但目前没有空间。但如果我们继续努力, 我们不断进行小的改进。继续适应。继续关注我们周围也想做出贡献的人；赋予他们以及彼此权力。然后每一步都将朝着正确的方向迈出一步，使 Rust 和所有为它做过贡献的人，与它一起茁壮成长。