iTranslated by AI
A Calm Assessment of the Emergence of Flock
A repository called Flock, which is a fork of Flutter, has been created.
Due to this, I've seen quite a few voices—more than just in passing—suggesting that Flutter is on the decline. This article is intended to confirm the intent of the fork by calmly reading the primary source information.
Challenges Facing Flutter
Based on my opening, I might be giving the impression that "Flutter isn't on the decline" or "there are no problems at all," but it wouldn't be fair if I didn't mention that it's not as if there are "no problems."
It's still fresh in our memory that there was news of layoffs in the Flutter team and among some members due to Google's company-wide circumstances. Whether it's an effect of that or not, Matt's argument is that "the Flutter team might be lacking manpower."
With an estimated 1 million Flutter users and 50 members of the Flutter team, a simple calculation means they have to support 20,000 developers per person, and his opinion is that "this is far too few!"
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 itself is starting to concentrate resources on AI-related areas, and the outlook for reinforcing the Flutter team seems slim.[1]
Because of the lack of manpower, desktop support is lagging, over 10,000 issues remain open, requested features are not being added, and bug fixes are buried without being addressed. Such a state is cited as a major problem for Flutter.[2]
Support by the Community
Flutter is open source, and the framework's language is Dart, the same as the app's language. Matt estimates that there are probably at least 1,000 developers in the world who could conceivably develop the framework at the same level as the Flutter team.
In other words, there are at least 1,000 Flutter developers in the world who could conceivably be hired to the Flutter team
However, in the approach of directly supporting the Flutter team and participating in Flutter version updates, there are concerns about the risk of "the seeker becoming the sought"—becoming restricted and bogged down by the Flutter team's policies and processes.
This is where Flock comes in.
Flock
If you read the beginning of the introduction article for Flock carefully, it clearly states that the purpose of Flock is to support the members of the Flutter team and accelerate the development of Flutter.
To help expand Flutter's available labor, and accelerate development, we're creating a fork of Flutter, called Flock.
Flock is a separate version of Flutter forked from Flutter, but that does not mean a "split from Flutter."
Flock's goal is not to create a separate framework independent of Flutter, but to contribute to Flutter by actively taking in pull requests that are stalled on the Flutter repository, identifying issues that arise there, considering improvement plans, and giving back to the Flutter repository.
Since Flock is a forked repository, it can merge changes according to its own rules.
It could also play a role in actively incorporating features or changes that are highly requested by Flutter users but cannot be adopted because they don't align with the Flutter team's policies, then providing feedback back to the Flutter repository.
Some people might think, "Flutter has a high barrier to entry, but maybe I'll give Flock a try." There could be patterns where ideas refined there are eventually contributed back to Flutter.
The Flock repository will reportedly merge changes from the Flutter repository's main branch daily, maintaining constant synchronization with Flutter.
Flock is a repository approach that stays close to Flutter while actively adopting new changes, thereby moving Flutter discussions forward.
From the above, it's clear that the purpose of Flock is not to divide the community by creating a derivative of Flutter, but rather to act as a testing ground for code that is difficult for Flutter to experiment with, making Flutter development as smooth as possible.
Challenges for Flock
However, there are quite a few challenges that must be solved to achieve those goals.
The first is the issue of reviewers.
The lack of reviewers was originally cited as a challenge for the Flutter team, and there's no guarantee the Flock team won't face the same problem.
Looking at the post below, the Flock team currently has only two core members including Matt, with a few others interested and considering joining.
Furthermore, there are concerns that the merging process itself will be demanding.
Alessio details this in the thread below, but the cost of incorporating Flutter's changes while applying unique ones and resolving conflicts as they arise is expected to be enormous.
Additionally, package developers will have to decide whether to align their development with Flutter or Flock. It's easy to imagine situations where something works in Flutter but not in Flock, or vice versa. Remi has mentioned this point.
We need to continue watching Flock's progress in these areas, but I hope successful solutions emerge and the original goal of improving Flutter's development efficiency is achieved.
Summary
First of all, this whole story is a fork resulting from a community member thinking about what they can do to support Flutter from their position as a community member to solve Flutter's challenges even just a little. It's clear that there is no intention to make Flutter decline; on the contrary, it is a challenge to revitalize Flutter.
Just because "Google's Flutter team has challenges" and "the community created a fork" does not mean "Flutter is on the decline." Connecting these two could even be seen as an act that disregards Matt's contribution.
In particular, Flutter itself has not changed at all in this story. Rather, it could be said that it has gained the possibility of increasing development speed.
How the Flutter team will collaborate with Flock will be a point of interest going forward, but the gist of this article is that there are no particular elements to be pessimistic about at this point.
By the way
On a very personal note, even if this were news indicating Flutter's decline, I wouldn't feel it's a serious problem. While I like Flutter and would feel disappointed, I use it with the understanding that no framework lasts forever, so I don't think I would be flustered by it.
I've never thought that I don't need to learn other technologies just because Flutter exists, or that my previous learning would be wasted if Flutter declined. Rather, I see it as learning effective and efficient ways to transition to the next technology by diving deep into Flutter.
For projects developing apps with Flutter, the cost of rebuilding with another technology if Flutter becomes unusable is certainly an issue that cannot be ignored. However, similar things happen even with native development.
Java was replaced by Kotlin, Objective-C by Swift, and recently new frameworks like SwiftUI and Jetpack Compose have appeared. Native development is the same in that it requires rewriting existing code every time such shifts occur.
It's no exaggeration to say that the idea of "write once and you're done" or "learn once and make a living forever" doesn't exist in software development—at least not in mobile app development. What matters is how well you can adapt to new technologies when the time comes.
Discussion