多年来，Flutter 吸引了数百万开发者，在各个平台上构建用户界面。Flutter 最初只是一个移动端（iOS 和 Android）的 UI 工具包，随后又支持了 Web，最后扩展到了 Mac、Windows 和 Linux。在这种大规模扩展的过程中，Flutter 团队的规模却几乎没有增加。为了扩充 Flutter 的开发力量并加速开发进程，我们决定创建一个 Flutter 的分叉项目，称为 Flock。

我们先做个简单的估算，看看 Flutter 团队究竟面临多大的人力短缺。

目前全球大概有多少 Flutter 开发者？我估计约有 100 万人。实际数字可能更高，但保守估计是一百万。

那 Flutter 团队有多大呢？谷歌并未公布这一信息，但我猜大约有 50 人。

这意味着 50 人要满足 100 万人的需求。简单算一下，每个 Flutter 团队成员就要服务 2 万名开发者！显然，这样的比例无法提供任何有效的支持。

通常人力短缺可以通过招聘来解决，但由于谷歌内部的公司层面问题，Flutter 团队的人员编制在 2023 年左右被冻结，2024 年初我们还听说团队出现了少量裁员。现在看起来团队可能会通过外包来扩充人手，但短期内不太可能看到 Flutter 团队翻倍或大幅扩展。

更糟的是，由于谷歌将重心转移到 AI 上，Flutter 团队对桌面平台的优先级下降。如今 Flutter 支持的 6 个平台中有 3 个都处于维护状态。桌面端或许是 Flutter 最具潜力的市场，但它目前几乎停滞不前。

随着用户群体和需求的急剧增长，有限的人力对 Flutter 工具包而言代价高昂。

由于开发人员有限，很多问题积压在工单中，可能会延迟多年，甚至永远无法解决。

等到 Flutter 团队成员着手调查某个工单时，可能已经过去好几年了。这时候团队通常会要求提交工单的人提供更多信息。就我个人经验来说，当这个过程发生在我身上时，我早已不再为最初有问题的客户工作。我在此期间已经写了几十万行代码，甚至不记得曾提交过这个问题，更不用说相关细节了。团队在没有我的帮助下无法修复问题，而时间太久导致我也无法提供有效信息。因此，问题只能被埋到未来的开发者重新发现。

时效性不仅是修复 bug 的问题，它还是一个重要的产品问题。想象一下，假如你是某家公司的技术总监或 CTO，而下一个发布版本因为某个 Flutter bug 被阻挡了。如果团队两年内都不会处理这个 bug，你该怎么办？如果这个 bug 对你的公司很重要，那你就只能停止使用 Flutter。你别无选择，只能继续前进。你的团队不知道如何解决 Flutter 框架的问题，而 Flutter 团队对修复这一问题要么不予理会，要么完全没有任何承诺。这样的情况一旦普遍出现，Flutter 将难以为继。

Flutter 有两个非常宝贵的特质。首先，它是开源的，任何开发者都可以查看 Flutter 的任何部分如何实现，甚至可以更改它。其次，Flutter 框架和 Flutter 应用使用同一种编程语言。这两个特质使得经验丰富的 Flutter 应用和包开发者也能为 Flutter 框架做出贡献。

那么全球大概有多少开发者能够有效地为 Flutter 框架贡献代码？保守估计应该有 1000 人。换句话说，假如团队希望招聘大量开发人员的话，这些人都可以加入 Flutter 团队。

还记得刚才提到的 1:20000 的支持比例吗？如果全球所有有能力的 Flutter 框架贡献者都能定期为 Flutter 贡献，比例就会从 1:20000 降到 1:1000。虽然比例依然不小，但相较之下，已经 大大 改善了。

此外，随着更多外部贡献者熟悉提交修复和新特性，他们会帮助培训其他人来做同样的事。这样，支持比例将不断朝着更好的方向发展。

既然增加外部贡献是改进 Flutter 的方式，为什么不直接与 Flutter 团队合作，而是选择分叉？

直接为 Flutter 做出贡献的想法很诱人。毕竟，Flutter 团队经常宣传每次发布中包含了多少外部贡献。据 Flutter 的公关宣传来看，他们非常欢迎所有外部贡献！

但可惜的是，试图与 Flutter 团队合作的现实并不如宣传般顺利。虽然有些开发者确实与 Flutter 团队合作得不错，但很多开发者发现过程既令人沮丧，甚至几乎无法顺利进行。造成这种情况的因素有很多，不同开发者遇到的问题可能不尽相同，但这里列举了一些常见问题：

有限的审查人力：

没有足够时间编写代码的开发者同样要负责审查贡献，因此审查或更新可能需要很长时间。

时间压力也导致审查对话往往颇具争议。

流程冗长，往往纠结于不重要的细节。

沟通的单一文化 - 团队中的大多数人似乎期望某种特定的沟通方式，这种方式并不适合所有个性，因此一些人难以在原本简单快捷的对话中顺利沟通。

以上问题以及可能未提及的其他问题导致至今为止总共仅有不到 1500 人曾为 Flutter 框架做出过贡献。这个数字包含了曾经修正过 Dart Doc 中拼写错误、然后再也没有做出贡献的开发者。这 不是 经常贡献大量价值的常驻贡献者人数。

无论你在 Flutter 贡献中经历了什么，都不得不反思为什么一个欢迎外部贡献的团队在近十年间只合并了 1500 名开发者的贡献。我个人认为，这可能是因为公关团队的邀请信息与实际的贡献体验并不一致，难以推行的团队政策、开发者有限的时间以及技术文化让推动更改的过程异常艰难。

这个现实只能由 Flutter 团队内部的人来改变。然而，许多团队成员并不认为这是一个问题。我知道，因为他们中一些人曾直接告诉我。Flutter 团队存在许多盲点，主要在于他们并不需要定期交付基于 Flutter 的应用功能和修复。换句话说，我认为他们有盲点是因为团队成员本身并不真正使用 Flutter。因此，很多问题的紧迫性没有得到重视，外部贡献者提交修复的时效和成本也未被充分理解。

如果 Flutter 团队不认为贡献问题是个问题，因此也不会采取措施解决，那该怎么办？这也是我们撰写此文并付诸实践的原因。我们认为，唯一能帮助解决人力问题的方式就是分叉 Flutter。

我们分叉的 Flutter 称为 Flock。我们将 Flock 描述为“Flutter+”。换句话说，我们 并不 想，也不打算分裂 Flutter 社区。Flock 会始终与 Flutter 保持同步更新，增加重要的 bug 修复和受欢迎的社区特性，而这些是 Flutter 团队无法或不愿实现的。

通过分叉 Flutter，我们可以决定合并哪些内容。在不降低质量标准的前提下，控制合并决策将带来以下机会：

招募比 Flutter 团队更庞大的 PR 审查团队，加快审查速度。

招募愿意积极帮助贡献者的审查员，而不仅仅是勉强接受他们。这意味着支持更多样的贡献者。

优化政策。例如，不再盲目要求设计文档和会议，仅在真正有助于任务时才安排。

通过成功的贡献案例来鼓励更多的贡献。

我们都是 Flutter 用户 - 利用团队和公司关系来识别市场优先级。

当 Flock 提供重要的 bug 修复和新特性时，Flutter 团队可以选择何时将其添加到 Flutter 中。社区不再局限于 Flutter 团队的可用性，也不需要请求团队接受更改。Flutter 团队可以自由选择是否使用 Flock 的解决方案，但所有 Flock 用户都可以立即使用它们，从而消除公司和团队的紧迫感和焦虑。

Flock，正如其名，离不开社区的支持。我们非常欢迎你加入。

Flock 的第一步是镜像 Flutter。这意味着自动同步master、beta和stable分支，并复制所有发布标签。

此外，在框架被镜像后，Flock 还需要自动构建并上传引擎，并将这些引擎二进制文件提供给 Flock 用户。

在我们进行镜像过程时，如果你能尝试使用 Flock 构建你的应用，将会是极大的帮助。你不应察觉到 Flock 和 Flutter 之间的任何差异，只需进行一次简单的 Flutter 版本管理器 (FVM) 配置即可。

请查看我们的指南以了解如何开始。

Flock 需要招募数十名审查员。审查员的职责是确保代码质量标准与 Flutter 相似。这包括要求描述性的类、方法和属性名称，有效的 Dart 文档，以及适当的测试。

但我们希望审查员能更进一步。我们不仅要接受贡献，更要积极支持贡献。很多人都有过这样一种经历：当你完成 90% 的 PR 工作后，Flutter 团队的审查员会突然表示需要你完成一些你不知如何处理的事项，而这将决定合并与否。这种体验非常糟糕，而我们希望在 Flock 中避免这种情况。

我们希望 Flock 的审查员愿意在 PR 快要完成的情况下介入，帮助贡献者完成最后的 10%。这并不是让贡献者偷懒，而是当贡献者已经尽其所能，并且 PR 已接近完成时，审查员能提供方向来完成最后的 10%。通过这种方式，我们可以帮助教育贡献者，确保下一次 PR 能够 100% 完成。

如果你有意成为 Flock 的审查员，请联系我们。

维护并扩展一个长期存在的 Flutter 分叉需要一批专家来负责项目的具体领域。比如，我目前担任 Flock 的总负责人，同时也是框架负责人。Jesse Ezell 则担任引擎负责人。

我们希望找到一位 Flutter 工具（flutter CLI 工具）的负责人。

此外，我们还希望将引擎责任按平台分配，每个平台（如 Android、iOS、Mac、Windows 和 Linux）各有一位负责人。

如果你希望在 Flock 中领导某个领域的工作，请联系我们。

让我们加速 Flutter 的发展，使其成为理应如此的通用 UI 工具包。Flutter 有潜力超越市场上的每一个替代方案。但它需要社区的共同努力，才能达成这一目标。让我们一起努力吧！