Flock 登場を冷静に評価する
Flutter を fork した Flock というリポジトリができました。
これにより、なにやら Flutter が落ち目にあるような声が散見どころでなく挙がっているのですが、冷静にちゃんと一次情報を読みながら fork の意図を確認しよう、という記事です。
Flutter が抱える課題
冒頭の書き方的に「Flutter は落ち目じゃないよ」「何の問題もないよ」という印象を与えていそうな気がしますが、「何も問題がない」わけでもないことは書いておかねばフェアではありません。
Google の全社的な事情で Flutter チームも一部のメンバーもレイオフされたというニュースがあったことは記憶に新しいですが、その影響があってかどうか、「Flutter チームのマンパワーが足りていないのではないか」というのが Matt さんの主張です。
推定される Flutter ユーザーが 100 万人、同じく推測される Flutter チームのメンバーが 50 人、単純計算するとひとりあたり 2 万人の開発者をサポートしなければならず、「これでは少なすぎる！」という意見です。
That's 50 people serving the needs of 1,000,000. Doing a little bit of division, that means that every single member of the Flutter team is responsible for the needs of 20,000 Flutter developers!
Google 社内としてもリソースを AI 関連に集中し初めており、Flutter チームが補強される見込みは薄いようです。[1]
マンパワーが足りないためにデスクトップの対応は滞り、issue は 1 万件以上が open のまま取り残され、要望のある機能は入らず不具合修正もなかなか対応されないまま埋もれてしまう。このような状態が Flutter の大きな問題として挙げられています。[2]
コミュニティによるサポート
Flutter はオープンソースであり、さらにフレームワークの言語はアプリの言語と同じ Dart です。Flutter チームと同じ目線でフレームワークを開発できる開発者が 1,000 人はいるのではないかと Matt さんは見積もっています。
In other words, there are at least 1,000 Flutter developers in the world who could conceivably be hired to the Flutter team
しかし、Flutter チームを直接サポートし、Flutter のバージョンアップに参加する方法では Flutter チームの方針や進め方が制約になり「ミイラ取りがミイラ」になるリスクが懸念されます。
そこで Flock です。
Flock
Flock の紹介記事の冒頭をちゃんと読むと、Flock の目的は Flutter チームのメンバーをサポートし、Flutter の開発を加速させることであると明確に書かれています。
To help expand Flutter's available labor, and accelerate development, we're creating a fork of Flutter, called Flock.
Flock は Flutter から fork された別バージョンの Flutter ですが、それは「Flutter との分裂」を 意味しません。
Flock は Flutter から独立した体制で Flutter とは別のフレームワークを作るのではなく、Flutter リポジトリ上で滞っているプルリクを積極的に取り込み、そこで発生する問題を洗い出し、改善案を検討し、 Flutter リポジトリに還元する ことで Flutter に貢献することを目的としています。
Flock は fork されたリポジトリですので、独自のルールで変更をマージできます。
Flutter ユーザーの間で要望が強い、でも Flutter チームの方針と合わないために取り入れられない機能や変更も同じように積極的に取り込んで Flutter リポジトリにフィードバックするような役割も考えられます。
「Flutter は少し敷居が高いけど Flock ならチャレンジしてみようかな」という人もいるかもしれません。そこで揉まれたアイデアが Flutter に還元されるパターンなんかもあり得そうです。
Flock リポジトリは Flutter リポジトリの main ブランチへの変更を毎日マージして、Flutter と常に同期が取られた状態を維持するそうです。
Flutter から離れないようにしつつ、でも新たな変更は積極的に取り入れる、それによって Flutter の議論を前に進める、そんなアプローチが Flock というリポジトリです。
以上のことから、Flock は Flutter の派生を作ってコミュニティを分断するのが目的ではなく、Flutter が試しづらいコードの実験台となることで Flutter の開発を少しでもスムーズにする ことが目的であるとわかるでしょう。
Flock の課題
とはいえその目的を果たすためには解決しなければならない課題も少なくありません。
まず一つ目がレビュワーの問題です。
そもそも Flutter チームの課題としてレビュワーの不足が挙げられていましたが、同じ課題を Flock チームが抱えないとは限りません。
以下のポストを見る限り、Flock チームはまだコアメンバーが Matt さんを入れて 2 人、追加で何名かが興味を持って検討しているという状況です。
さらにマージ作業も大変になることが懸念されます。
詳しくは Alessio さんの以下のツリーに書かれていますが、Flutter の変更は取り入れつつ、独自の変更も入れつつ、競合があれば都度判断してマージする、そのコストはとてつもなく大きくなることが予想されます。
また、パッケージ開発者も Flutter と Flock、どちらに合わせて開発すればよいかが悩みどころです。Flutter では動くけど Flock では動かない、もしくは逆に Flock では動くけど Flutter では動かないような状況は容易に想像できます。このあたりについては Remi さんが言及しています。
このあたりは引き続き Flock の状況をウォッチする必要がありますが、うまく解決案が出て本来の目的である Flutter の開発効率アップが達成できることを願います。
まとめ
そもそも今回の話は Flutter の課題を少しでも解決したいコミュニティメンバーが、コミュニティメンバーという立場からサポートできることを考えた結果の fork であり、Flutter を衰退させようという意図がないどころかむしろ Flutter を盛り上げるためのチャレンジ であることが見えてきたと思います。
「Google の Flutter チームに課題がある」「そこでコミュニティが fork 版を作った」からといって、「だから Flutter が落ち目である」と結びつけるのは Matt さんの貢献を蔑ろにする行為とすら考えられます。
特に、Flutter 自体は今回の話で何も変わっていません。むしろ開発スピードが上がる可能性を得たと言えるのではないでしょうか。
Flutter チームが Flock とどのように連携するのか はこれからの注目ポイントかとは思いますが、現時点では特に悲観する要素はないと思う、というのがこの記事の趣旨です。
ちなみに
とても個人的な意見ですが、仮にこれが Flutter の落ち目を表すニュースだったとしても、自分はそれを深刻な問題とは感じません。Flutter は好きなので残念だとは感じるでしょうが、一方で未来永劫使い続けられるフレームワークはあり得ないと割り切って使っているので、そこで右往左往するようなことはないと思います。
Flutter があるから他の技術を学ばなくて良い、Flutter が落ち目だから今までの学習が無駄になる、と考えたことは今まで一度もなく、むしろ Flutter をとことん深掘ることによって次に他の技術に乗り移る時の効果的・効率的な学習方法を学んでいる認識です。
Flutter でアプリ開発をしているプロジェクトとしては Flutter が使えなくなったら別の技術で作り直すコストが発生するのは確かに無視できない問題ですが、とはいえ似たようなことはネイティブだったとしても発生します。
Java が Kotlin に、Objective-C が Swift に置き換わり、最近は SwiftUI や Jetpack Compose といった新しいフレームワークも登場し、その度に既存のコードを書き直す手間が発生しているのはネイティブも同じと言えるでしょう。
一度書いたら終わり、一度学んだらずっと食べていける、と言う考え方はソフトウェア開発においては（少なくともモバイルアプリ開発においては）あり得ないと言っても過言ではないでしょう。大事なのは、その時にいかに新しい技術に適応できるかだと思います。
Discussion