因 Flutter 前景晦暗不明,前谷歌员工宣布为该 UI 工具包推出 Flock 分叉。
Flutter 是一套跨平台开发框架,基于同样由谷歌开发的 Dart 编程语言。Flutter 涵盖 Web、Android 与 iOS 移动操作系统,以及 Linux、Windows 及 macOS 三大主流桌面平台。目前 Flutter 在 GitHub 上拥有 166k 颗 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 的广泛使用,它们已经完全僵化,社区已经放弃对它们的贡献,而是创建了分支或对贡献友好的包装器。
截图来自:InfoQ 公众号读者评论
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://news.ycombinator.com/item?id=41975047
https://www.reddit.com/r/FlutterDev/comments/1gebnd1/were_forking_flutter_this_is_why/
评论