自从去年 4 月 Google「大裁员」这波浪潮波及自家的 Python 团队以来，另一大团队 Flutter 在 Google 内部的地位也开始变得摇摇欲坠。虽然当时 Flutter 和 Dart 的产品经理 Kevin Moore 在社交平台出面安抚众人，称：“这次裁员是由我们团队之上几层决定的，影响了许多团队。很多优秀的同事收到了坏消息，很多好项目失去了人才。Flutter 和 Dart 所受影响和其他团队差不多。这是艰难的一天……艰难的一周……你们感到焦虑，我理解，我们都理解；你们把赌注押在了 Flutter 和 Dart 上，我也一样，谷歌也一样”，但是随着 Google 如今进一步加大对 AI 领域的投资而导致资源在内部偏向性非常明显，众人对 Flutter 未来发展的担忧逐渐从内部蔓延开来。
时下，甚至有一些外部开发者也感受到了像 Flutter 这样的跨平台移动应用开发框架受到了 Google 的冷落。为了表达对 Google 的不满，并试图保护和进一步发展 Flutter 生态系统，一些开发者选择了直接分叉 Flutter 项目，建立了自己的分支，Flock 便是最新出现的分支之一。
Matt Carroll 是谁？
值得一提的是，发起这次分叉项目的不是别人，也是与 Flutter 有着很深渊源的开发者 Matt Carroll。
Matt Carroll 曾是 Google Flutter 团队的成员，早在 2018 年便加入了该团队。
要知道，Flutter 能有今天的成就，也离不开这些团队成员的努力。最初，Google 于 2017 年 I/O 大会上首次推出移动 UI 框架 Flutter 的主要原因，是希望通过一套代码可支持 Android、iOS 双端运行，以此能够为开发者提供一个多平台、可移植的 UI 工具包来支持高效的应用开发。后来，Flutter 又增加了对 Web 的支持。最后，Flutter 扩展到了 Mac、Windows 和 Linux 平台。
现如今就国内 App 而言，无论是阿里的闲鱼、淘宝特价版，字节跳动的抖音、今日头条，还是滴滴出行、美团外卖，这些 App 中都不乏有 Flutter 的身影。
同时，据 GitHub Octoverse 最新年度报告显示，2024 年 GitHub 上最吸引初次贡献者的十大开源和公共项目中，Flutter 位列第六，也反映出了它当前的受欢迎程度和社区实力。
正是一路见证 Flutter 的成长，Caroll 对着 Flutter 也有着很深的情感，因此即使在 2020 年离开 Google 之后，还是投入到了 Flutter 生态建设中，成为一名 Flutter 顾问，同时还建立了一个名为 Flutter Bounty Hunters 的网站，为 Flutter 和 Dart 创建开源软件包。
不过，Matt Carroll 指出，多年来，Flutter 吸引了数百万开发人员，他们在每个平台上构建了用户界面。在范围和责任的大幅扩展中，Flutter 团队的规模仅略有增加。
在 Matt Carroll 看来，以 Google 目前的人员投入，不足以良好地支撑 Flutter 日后的发展。
为了详述这一点，Matt Carroll 特地发布了一篇《我们分叉了 Flutter。这是原因》的长文，细数了 Google 几宗罪，以及 Flutter 当前面临的困境。
Google 对 Flutter 的资源投入太少，造成劳动力短缺
在博文伊始，Matt Carroll 就带领众多开发者算了一笔账——计算 Flutter 团队的劳动力短缺问题。
论及目前世界上有多少 Flutter 开发者？
Matt Carroll 给出了一个预测，称大概有 1,000,000 名开发者。之所以有这个猜测，通过 GitHub 上 Flutter 的仓库来看，该 Fork 数达到了 27.4k，Star 数达到了 166k。同样据 GitHub Octoverse 最新年度报告显示，GitHub 上贡献者排名前十的公共项目榜单中，Flutter 排在第五位。基于这些维度综合考虑，Matt Carroll 做出 100 万 Flutter 开发者数量的预估也应该是比较保守的。
进一步剖析这一个庞大用户群体的项目背后，究竟有多少人来做支撑与维护？
截至目前，Google 并没有公布这些信息，但 Matt Carroll 结合自己曾经任职的经历猜测该团队大约只有 50 人。
也就是说，50 个人要满足 1,000,000 人的需求。稍微划分一下，就意味着 Flutter 团队的每一位成员都要负责满足 20,000 名 Flutter 开发人员的需求！对于任何形式的客户支持来说，这种比例显然是不可行的。
有人或许要说，劳动力短缺问题可以通过招聘来解决。然而，Matt Carroll 表示，“由于 Google 全公司范围内的问题，Flutter 团队的人数在 2023 年左右被冻结。在 2024 年初，我们了解到有少量裁员。看来，该团队现在可能通过外包再次扩张，但我们不太可能在短期内看到 Flutter 团队的规模翻一番或翻两番。”
更糟糕的是，Matt Carroll 吐槽称，Google 重新将重点放在 AI 上，导致 Flutter 团队降低了所有桌面平台的优先级。就在其发布这篇文章的时候，Flutter 团队支持的六个平台中，已有三个进入了维护模式。桌面平台可能是 Flutter 最大的未开发价值所在，但现在却几乎停滞不前。
只提供有限的劳动力，也需要付出代价
Matt Carroll 认为，对于一个用户基础迅速扩大、整体范围也在增加的工具包来说，只有有限的劳动力需要付出巨大的成本。
由于开发者太少了，导致许多工单（ticket）会积压在待办事项列表中。它们可能会滞留多年，甚至根本不会得到任何处理。
Matt Carroll 分析道，当 Flutter 团队成员开始着手处理一个工单时，这个工单可能已经有几年的历史了。这时，Flutter 团队的开发者通常会向提交工单的人请求更多信息。
然而，根据 Matt Carroll 此前在 Flutter 待过的经验，其坦言称：
“当这种情况发生在我身上时，我早就不再与最初提出该问题的用户沟通合作了。因为在此期间，我可能已经写了几十万行代码，甚至早已忘记自己提交过这个问题了，更不用说相关的具体细节了。没有我的信息，团队无法修复这个 Bug，而对我而言已经过去太久以至于无法提供这些信息。因此，这个 Bug 会被埋没，等待未来的开发者重新发现它。”
最终，这种情况不仅影响到 Bug 的根因分析和最终修复，还给产品带来了重大问题。
对此，也不难想象一下，如果你是某家公司的工程总监或 CTO，公司下一次发布受阻于某个 Flutter Bug，且官方维护团队在未来两年都不会处理这个问题，你会怎么做？
显然，如果这个问题对公司至关重要，你唯一的选择就是停止使用 Flutter。你必须继续前进，但你的团队无法处理 Flutter 框架的问题，而 Flutter 团队要么对修复无动于衷，要么完全不承诺修复这个 bug。这意味着 Flutter 已经不能再用了。如果这类体验变得普遍，Flutter 将难以生存。
借助 Flutter 社区能否修复众多遗留的 Bug？
那在有限的劳动力之下，是否有解决方案？
答案无疑是肯定的。
Matt Carroll 解释道，Flutter 有两个非常有价值的特点，一是它是开源的，任何开发者都可以查看 Flutter 的任何部分是如何实现的，甚至可以对其进行修改；二是 Flutter 框架是用与 Flutter 应用相同的语言编写的。因为这两个特点，有经验的 Flutter 应用开发者和包开发者可以为 Flutter 框架做出贡献。
回到上述的问题，要想解决 Flutter 遗留的众多 Bug，当然也可以借助 Flutter 开源社区的力量。
那么，当今世界有多少有能力以生产级别的效率为 Flutter 框架做贡献的 Flutter 开发者？
Matt Carroll 又做了一个保守估计，其认为大约有 1000 名这样的开发者。换句话说，世界上至少有 1000 名 Flutter 开发者有可能被雇佣到 Flutter 团队，如果 Google 想雇佣这么多开发者的话。
还记得那个每 1 名 Flutter 团队成员对应 2 万名开发者的比例吗？如果所有有能力的 Flutter 框架贡献者都定期为 Flutter 做贡献，那么这个 1:20000 的比例就会下降到 1:1000。这仍然是一个很大的比例，但它比现在要好得多。
此外，随着越来越多的外部贡献者习惯于提交对 Flutter 的修复和特性，他们也会倾向于帮助其他人也这样做。因此，支持比例将继续朝着更好的方向发展。
为什么不直接与 Flutter 团队合作？
这就带来了另外一个延伸问题，即如果增加外部贡献是通往更好 Flutter 世界的途径，那么为什么大家不直接与 Flutter 团队合作，而是要 Fork Flutter 呢？
同样作为过来人的 Matt Carroll，其道出了一个现实性的问题，日常外部开发者想要尝试与 Flutter 团队合作却并不都是那么容易的。其中，不同的开发者会遇到不同的问题，譬如：
审查劳动力有限：那些没有足够时间写代码的开发者们就是那些被选来审查贡献的人，因此，审查或更新可能会花费很长时间；时间的压力似乎也导致了争议性的审查对话。
每件事都需要很长时间，而且似乎总是关于非关键性的细节。
沟通文化单一：大多数团队成员似乎期待一种特定的沟通方式，这并不匹配世界上各种各样的个性。因此，有些人很难在本来快速简单的对话中找到自己的位置。
Matt Carroll 在博文中指出，上述问题以及其它未列出的问题导致的结果是——至今为止，为 Flutter 框架贡献过的人数少于 1500 人。这个数字包括那些只来过一次，修正了一个 Dart Doc 中的拼写错误然后再也没有贡献过的人。
在 Matt Carroll 看来，要想改变这种现状，唯有靠 Flutter 组织内的人员一起共同努力，积极地与外部沟通与交流。然而，这些人中的大多数实际上并不认为这是个问题。就在 Matt Carroll 在职期间，就有不少人直接向 Carroll 表达了这种观点。
造成这种认知偏差的主要原因是 Flutter 团队有很多盲点，Matt Carroll 吐槽称，存在这些盲点是因为 Flutter 团队成员实际上并不使用 Flutter。因此，很多问题的紧迫性没有得到重视，作为外部贡献者直接提交修复所需的时间成本也没有得到重视。
分叉 Flutter，Flock 诞生
种种因素趋势之下，Matt Carroll 决定和另一位开发者 Jesse Ezell 一起 Fork Flutter，并将最新的分叉版本称之为 Flock。
不过，Matt Carroll 也特别强调，Flock 的目标并不是直接取代 Google Flutter，而是将添加重要的 Bug 修复和受欢迎的社区特性，这些都是 Flutter 团队无法或不愿意实施的。
Matt Carroll 希望招募一名 Flutter 工具负责人以及每个支持平台的负责人，覆盖 Android、iOS、Mac、Linux 和 Windows（未提及 Web）平台。不过目前，Flock 只是 Flutter 的一个镜像。
地址：https://flutterfoundation.dev/
分叉 Flutter 项目所带来的影响？
事实上，分叉 Flutter 并非完全是一件坏事，这种方式也可以有效促进创新，为开发者提供更多的选择。对此，HN 上一位网友表示：
「我们把 Flock 描述为“Flutter+”。换句话说，我们并不希望也不打算分叉 Flutter 社区。Flock 将始终与 Flutter 保持同步更新。」
当我看到 Carroll 发布的内容时，第一个担心是社区分裂，出现两个不兼容的版本。很高兴在文中看到了对此的说明。
第二个担心是这会如何复杂化开发过程，但看起来它是一个即插即用的替代品（只需要配置 FVM —— Flutter 版本管理器）。
Flutter 是继 Qt 之后在 UI 开发领域发生的最棒的事情。大多数人没有意识到他们每天使用的许多应用都是用 Flutter 编写的，仅仅因为这根本看不出来。文中描述的那种挫败感是许多 CTO 和开发者所感受到的。尤其是那些使用 Flutter 开发桌面和 Web 应用的人。Flutter 为桌面应用提供了出色的体验，正因为如此，当你遇到一些已经开放了一两年但从不被优先处理的愚蠢 bug 时，感觉尤为沮丧。通常，这些问题并不严重，但仍然需要解决办法，并浪费时间。
Flock 的想法听起来不错，主要问题是能否吸引社区的参与。希望作者（他自己似乎是 Flutter 团队的前成员）对社区的状态有很好的把握。
祝愿该项目好运，并将持续关注其进展。
不过，因为在今年 5 月 Google I/O 大会上，Google 强调了 Kotlin 优于 Flutter，并正式支持 Kotlin 多平台。这或许暗示了 Google 的重心转移，使得部分开发者对未来产生了不确定感，从而催生了 Flock 这样的分叉项目。
整体而言，Flock 初起步，未来究竟该如何发展，也需要交给时间来验证，但是分叉可能会导致社区精力分散，以及随着时间推移与主线版本产生差异，间接在工具链、插件生态系统等方面带来兼容性等问题，都是值得 Flutter 社区需要思考以及解决的问题。
参考：
https://devclass.com/2024/10/30/flutter-forked-as-flock-developer-cites-company-wide-issues-at-google/
https://flutterfoundation.dev/blog/posts/we-are-forking-flutter-this-is-why/