因 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/