因 Flutter 前景晦暗不明，前谷歌员工宣布为该 UI 工具包推出 Flock 分叉。
Flutter 是一套跨平台开发框架，基于同样由谷歌开发的 Dart 编程语言。Flutter 涵盖 Web、Android 与 iOS 移动操作系统，以及 Linux、Windows 及 macOS 三大主流桌面平台。目前 Flutter 在 GitHub 上拥有 16.6k 颗 star，有人称其为“自 Qt 以来对 UI 开发的最大革新”。
在 Flock 项目发布的博文中，该团队抱怨称 Flutter 的核心开发人员已经无法满足 Flutter 应用程序开发用户们的期待和愿景。负责 Flock 的团队在 GitHub 上自称为 Flutter 基金会，旨在保障并推动该框架的进一步发展。
面对开源，谷歌频频踩下刹车
早在 2024 年 5 月，谷歌 Flutter 团队就受到了全公司裁员浪潮的影响。对于那些投入无数时间和精力开发 Flutter 的开发人员们来说，这样的消息令人不安，种种焦虑和猜忌的情绪也随之而来。一位网名叫 xeladu 的 Flutter 与 Firebase 开发人员写道，“说实话，我宁愿劝大家干脆别学 Flutter。”
他告诫新手们不要把自己的长期职业生涯押注在 Flutter 身上，先观察谷歌的动作再行决定。“现在玩玩可以，但成为一名专业 Flutter 开发人员可能是在浪费时间。”
Flutter 项目的产品经理 Seth Ladd 则向社区保证，“谷歌本身也从 Flutter 当中获得了大量价值。”为了证明这一点，他列举了谷歌地球和 Classroom 等内部应用程序，称它们都受益于这套跨平台框架。平心而论，Flutter 确实取得了令人印象深刻的成绩：承载的应用程序超过百万个，涵盖从初创公司到 Geico、Virgin Money 等主流品牌。然而，尽管 Ladd 的话让人稍感安慰，但他也亲口承认谷歌更推荐使用 Kotlin、而非 Flutter 进行更深入的硬件集成——这无疑让本就紧张的社区氛围变得更加焦灼。
![]()
就在昨天，曾在 Flutter 团队工作的前谷歌员工 Carroll 发表了一篇长文，详细解释了他为何要推动对 Flock 的分叉。他认为 Flutter 团队一直存在“人手不足”的问题——目前全球保守估计有 100 万 Flutter 开发者，而 Flutter 团队的规模估计是 50 人，也就是说每 2 万名 Flutter 用户只对应一名开发人员。
另外，还有网友分析谷歌 Flutter 团队甚至不到 50 人：这可以通过 GitHub 的月活跃情况大致估算，还需考虑 CI 机器人带来的大量提交记录。
“劳动力短缺通常可以通过增加招聘来解决。然而，由于谷歌内部的整体问题，Flutter 团队的人员编制在 2023 年前后被冻结，而在 2024 年初还出现了少量裁员。似乎团队目前可能通过外包扩充人手，但 Flutter 团队的规模在短期内大幅扩大的可能性不大。”
在他看来，这一令人震惊的投入比例，直接导致越来越多的 bug 积压和愈发严重的功能发布延迟。
“由于开发人员不足，许多问题会长期停留在待办清单中，甚至可能多年无人问津，最终被搁置而得不到解决。”
对于这些积压的 bug，根据 Carroll 的介绍，部分关于 bug 修复和功能发布的请求多年来一直没有得到答复。他还报告了自己的亲身经历，称直到退出项目很久之后才收到关于申请的反馈意见。可这时候，他早已忘记关于 bug 修复的更多细节信息。
时间延误不仅影响故障修复，还会成为产品风险，“设想一下，如果你是某公司的工程总监或 CTO，而你们的下一个版本发布因 Flutter 的某个问题受阻。假如团队需要两年时间才处理这个问题，你会怎么做？如果这个问题对公司至关重要，你只能放弃 Flutter。你没有选择，因为你需要继续向前推进，而你的团队并不具备维护 Flutter 框架的能力，而 Flutter 团队要么没有响应，要么完全没有解决问题的承诺。于是，只能放弃 Flutter。如果这种情况普遍化，Flutter 的发展将会受到严重影响。”
人手不足的现状也给 Linux、macOS 以及 Windows 等桌面平台的开发工作造成严重影响。目前这几个方向基本处于仅维护、不发展的状态。总的来说，Flutter 社区足够庞大，完全可以协助项目开发。经验丰富的 Flutter 开发人员能够以外部贡献者的身份为该项目添砖加瓦，毕竟 Flutter 名义上仍然是个开源项目。
因此，他认为分叉将有助于加快开发速度，这一方面能够增加急需的人手，同时也有助于消除那些阻碍外部贡献的官僚风气。
根据他们的说法，这个所谓开源项目的自我描述与客观现实之间存在巨大分歧：虽然 Flutter 团队会定期宣传来自外部的贡献，但参与者与该团队的沟通其实相当困难。
Carroll 的博文指出，“虽然也有开发人员能够成功跟 Flutter 团队进行合作，但也有不少人发现合作过程令人沮丧、甚至根本无法推进。”先后只有 1500 名外部开发人员为 Flutter 项目做出过贡献，其中还包括“负责纠正 Dart 说明文档中拼写错误”的参与者。
而且，据 Google Web Toolkit 员工指出，他们确实很难接受外部贡献，因为“团队有义务支持 Google 员工。也就是说，与 Google 的其他库和工具一样，更改不能破坏 google3（Google 内部 monorepo）。”很明显，在一些开源的项目上，Google 内部的优先级设置太高，以至于伤害了社区。Bazel 在很多方面感觉非常相似。例如，由于资源分配不足以及 google3 内部对 rules_proto 和 bazel-skylib 的广泛使用，它们已经完全僵化，社区已经放弃对它们的贡献，而是创建了分支或对贡献友好的包装器。
Flock 应运而生
Flock 的出现正是为了扭转这种不利局面。Flock 背后的团队将该分叉称为 Flutter+，明确表示这不是要分裂 Flutter 社区。该分叉将始终与 Flutter 的最新版本保持同步，同时接收社区提出的关于一切重要 bug 修复及功能更新的诉求，代替 Flutter 团队履行他们无法或者不愿承担的责任。
![]()
作为行动的第一步，Flock 团队已经为 Flutter 制作了副本。GitHub 上的代码仓库与原始 Flutter 官方仓库直接对应，而且全面保留了 Flutter 这个名称。除了框架本体之外，Flutter 基金会还在 GitHub 上分叉了 Flutter 引擎，同时为其网站和相关工具建立了代码仓库。
该团队目前正邀请人们对其进行测试。Flutter 基金会官网上发布了简短的说明文档，指导贡献者如何完成 Flutter 版本管理器（FVM）工具的安装和分叉项目的初始配置。
![]()
“我们将 Flock 描述为‘Flutter+’。换句话说，我们无意且不打算分裂 Flutter 社区。Flock 将始终与 Flutter 保持同步更新。”当我看到标题时，首先担心的是社区可能会被分裂，出现两个不兼容的版本。很高兴在文章中看到这一点已得到回应。
第二个担忧是 Flock 会让开发流程变得复杂，但看来它只是一个即插即用的替代方案（只需配置 FVM - Flutter 版本管理器）：
Configure .fvmrc to use Flock:
{
"flutter": "master",
"flutterUrl": "https://github.com/Flutter-
Foundation/flutter.git"
}
我觉得 Flock 的构想不错，主要问题在于如何吸引社区参与。希望作者（看起来他也是 Flutter 团队的前成员）能很好地把握社区现状。
该团队还在寻求有意参与审查人员。最后，项目希望为各具体领域吸引相应的核心成员，包括各类工具以及 Android、iOS、macOS、Windows 和 Linux 等对应平台。
Flutter 与 Flock 的未来命运将走向何方？
跟大家预期的一样，Flock 的发布迅速在整个开发者社区引起反响。在各社交媒体平台上，部分开发者对 Flock 表达了欢迎，认为这是谷歌可能放弃该项目的情况下让 Flutter 得以延续的一种可行方式。X 上的一位用户评论称，“面对谷歌可能放弃 Flutter 的风险，至少这样一来社区仍然是安全的。”
![]()
好的一面是，面对谷歌可能放弃 Flutter 的风险，至少这样一来社区仍然是安全的。至于坏的一面，则是如果谷歌真的打算从项目中撤出，那还需要基金会为其提供支持。
但其他一些声音对此则没那么乐观。
一位用户在 Reddit 上写道，“这完全是在浪费时间。老实讲，我认为这只会令人们对 Flutter 的未来命运更加怀疑，最终成为压死骆驼的最后一根稻草。而且讽刺的是，这样做的唯一结果就是浪费 Flutter 团队的时间去跟高层磋商，讨论这套由谷歌推动的开源 UI 框架为什么会走向分叉。”
![]()
在他看来资源应该被用于支持 Flutter，而不是割裂其社区基础。另一位用户也半开玩笑地评论称，“没错，Flutter 不行了，大家快来我们这边看看吧！”
![]()
目前我看不出这个项目有什么吸引力，它只会让新人贡献者更加困惑，不知道自己应该参与哪个代码仓库，甚至有可能撕裂整个社区乃至原有贡献者。具体如何，未来半年左右应该就会见分晓。也许我是错的，但愿别让我说中。
总的来说，整个社区分为两派，一派认为 Flock 确实是必要的防卫性手段，而另一派则认为这是一种过度反应、只会给项目陡增混乱。
一部分开发者认为，谷歌只需要向 Flutter 投入更多资源并扩大团队规模，即可解决当前问题。他们经常会拿 WhatsApp 来类比，毕竟 WhatsApp 就是靠一支高效运营的小团队服务着数十亿用户的项目，但也有不少人觉得这种比较并不公平。简而言之，Flock 的批评者担心此番分叉可能会让本就人手有限的贡献群体再遭撕裂，导致 Flutter 和 Flock 都感到能够保持延续的临界规模。
那么，Flutter 的未来命运将走向何方？谷歌尚未就 Flock 一事发表任何公开声明，也没有透露关于放弃 Flutter 的消息。他们依然在继续强调 Flutter 的发展路线图，包括性能改进、增加平台集成，甚至还有用于实现商业收益的新广告格式。从这份路线图来看，谷歌似乎并不打算彻底砍掉 Flutter 项目。只是与鼎盛时期相比，未来的团队规模将有所收缩。
另一方面，Flock 仍在向前迈进，希望在增强灵活度的同时包容各项由社区推动的优先事项。Carroll 强调，Flock 与 Fluter 之间不会构成竞争关系，而是对后者加以补充，通过解决被忽视的问题并增强功能来弥补差距。如果成功，那么这套双生系统将带来两全其美的效果——该框架将既保持谷歌的官方支持，又拥有社区的额外贡献。当然，这一切假设的前提，都是 Flock 能够获得足够的吸引力并得到众多贡献者的接纳和参与。
那么问题来了：我们到底要不要放弃 Flutter？最简单的答案就是不要头脑发热，但同时也要保持警惕。就目前的情况看，谷歌的 Flutter 路线图表明他们仍致力于推动项目持续发展，但 Flock 的存在也的确暗示了 Flutter 在谷歌生态系统中也许出现了潜在的可持续性挑战。
Flock 可能只是又一个将逐渐消失的开源分叉。但如果谷歌在 Flutter 身上投入的资源继续减少，Flock 最终也没准会成为挽救 Flutter 于危亡的一线希望。
参考链接：
https://flutterfoundation.dev/blog/posts/we-are-forking-flutter-this-is-why/
https://www.heise.de/en/news/Software-development-Is-it-still-Flutter-or-already-Flock-It-s-a-fork-9997633.html
https://www.linkedin.com/posts/saezchristopher_i-talked-to-a-google-developer-expert-about-activity-7200929320368832512-aZjF
https://news.ycombinator.com/item?id=41975047
https://www.reddit.com/r/FlutterDev/comments/1gebnd1/were_forking_flutter_this_is_why/
