> How large is the Flutter team, today? Google doesn't publish this information, but my guess is that the team is about 50 people strong.
> 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! That ratio is clearly unworkable for any semblance of customer support.
This is a weird exercise. Python, for example, is a #1/#2 language in the world and there's only 50 active core devs, 90% of which don't even work on Python full time. Somehow we make that work.
This is significantly undercounting in at least several cases I know of. e.g. I was employed by Elastic and Kong and in both cases, the number of developers employed by the company to work on these projects was several multiples the size reported here
Ah, I now see why: I hadn't really looked at the query, but now that I have, here are some of the problems:
1. Using median is a problem for many projects because many often start off (sometimes for years) with only a few developers before they really take off. The median() number for Elasticsearch was 28, but the max() is 49, which I suspect is closer to the current number.
2. Not everybody uses a pull request flow, and not everyone working on a project is a developer. You could have product managers, technical writers, engineering managers, etc, all working on a project and not opening PRs and you can have users just directly adding commits, especially when a project is young. The original query here for the kong/kong project shows a team size of 6, but if you remove event_type = 'PullRequestEvent' and switch to max(), you get 33.
3. Sometimes, parts of the project are kind of "elsewhere." e.g. Elastic employed a number of Lucene committers to help move Lucene along, Kong employed a number of folks that would e.g. commit/maintain OpenResty plugins which got incorporated in the build system, the docs live in separate repos in both cases, etc.
Every project is different. Claiming it needs more developers because "it needs to emulate UI of six platforms" as if that justifies a larger team is also fallacious.
I wanted to see the evidence that the community is lacking support and/or flutter is lagging behind competition. That would justify Flock's goal... Otherwise, it sounds a lot like both naivette and a unpublished agenda.
Very rarely do the people working full time on a framework/tool also use that framework/tool in a non-toy setting. They aren't working two full time jobs after all.
I think there should be a distinction here. E.g. if you work on a browser, possibly implementing parts of image loading, or javascript parser, etc.
Are you consider a dogfooder if you use the browser? or do you need to lots of write Javascript yourself, etc. to be considered "a user of your product"?
Typically, these are two different sets of people.
I suppose this problem is timeless, back when I was active in the PHP community it was a long-running joke that people who "graduated" to committing to the actual php source (in C) were not doing web development work anymore. And I suppose it was actually true for the majority. On the other hand, designing language features wasn't really related to using it for web work.
Dogfooding doesn't mean you know how to build it. Take for example the graphics engineers on Unreal Engine. They almost certainly know how to fly around test zones or make stress scenarios, but they aren't going to be building large, detailed, open world maps like will be seen in the next Cyberpunk or whatever. And it's not reasonable to expect that of them, either.
Nor are the people doing UI work in Blender going to be able to make Big Bunny.
Nor are the people working on fusion360's parametric system going to build complex mechanical-fluid simulation scenarios.
Flutter is simpler than those, sure, but even in that world you have people that do nothing but fonts & text for their entire careers. They'll know how to do text stuff in flutter, but they'd be lost if you demanded they make a tiktok clone.
Only if you're oblivious to the day-to-day activities of a software project. They work on building a framework, not on using said said framework to build something entirely different that has no bearing in how to build a framework.
> I think the experience of building something atop a framework should absolutely have bearing on how to build the underlying framework.
You'd be wrong. If your job is maintaining a framework then your focus is on internal details, and how the framework is used would be limited to your concerns in putting up test sets.
Believing that working on a framework gives you equivalent or even similar experience to using said framework in professional settings is a kin to believing that all mechanics are excellent drivers just because they work on cars.
It does, however, have bearing. Despite how common the practice may be in the corporate world, developing a framework without any regard to the user experience thereof is pretty suboptimal
Not sure this is a good comparison because the PHP Foundation is "relatively" new and afaik there's no strong correlation to "the php development team" besides these people being paid and also work on it. PHP had a 20y history before this foundation, and the main difference is that it was never steered directly by one big company. Zend, yeah, but they had influence, they had neither started the project, nor ever had a long-stretching majority of people in the important positions. (Disclaimer: have not been an active part of the project for a couple years)
Flutter has much bigger scope than PHP Foundation. It's more fair to compare PHP Foundation scope to Dart Lang and Dart SDK. Flutter scope on top of that is Flutter Engine, Flutter Widgets, Flutter Framework, Flutter Packages, Dev Tools (IntelliJ + VSCode). PHP also support desktops/server environments instead of Flutter 6 platform (iOS, Android, Windows, Linux, MacOS, Web). Making crossplatform UI toolkit is the most labor intensive - PHP Foundation is not developing that. PHP had also 2 decades ahead of development.
In general in PLs this is not true—the standard library is usually very carefully designed and all of its interactions are well-considered—but Python's libraries do seem to be more independently-updated than most.
Even so, isn't that an argument for a smaller, integrated team for the framework, rather than a large one made of ~1000 volunteers? A tightly-knit framework is much more likely to suffer from too many chefs than a disparate collection of library functions.
Between the parallelization problems inherent in a tight framework and the fact that its total surface area is also smaller than a PL that's maintained by about the same number of people, it sure doesn't sound like Flutter's problem lies in developer headcount.
I doubt that complexity of a language is comparable to that of a widget library. After the text input cell and scrolling window it’s basically dumb geometry/drawing code all along.
It's much harder to to implement a language in a proper way than writing a widget library.
But that hardness comes from the level of knowledge one must have in different fields such as compiler theory, cathegory theory, hardware, beside classical computer science and coding.
To write a widget library you just have to know how to code and have some experience.
That being said, the amount of work for implementing a widget library might be higher, but is less qualified work being done.
I dabbled in computer language theory and compilers and it's hard. I have no issues reading source code for widget and GUI libraries.
The Dart team is separate from the Flutter team, though they do interact as Flutter is now the primary use of Dart and as such, influences what is worked on in the Dart team.
> Even whatsapp had about 50 members when they were handling billion users
I would add that running a service deployed to N regions is considerably more demanding and work-intensive than working on a releasable software package.
No one working on Flutter is woken up in the middle of the night by a pager because a user was not able to install a package, to then create a call to pull in half a dozen of Flutter engineers.
Python doesn't have a narrow scope. At least compared to Flutter. It's in so many places, from Linux installers, to medical, aerospace, math,... and finally the web (which is probably what we hear about the most).
I did not meant to start a pissing contest, I thought the biggest idea was that Flutter isn't 35yo and because of it, it's more likely to drastically change, and in a fast way too.
> This is a weird exercise. Python, for example, is a #1/#2 language in the world and there's only 50 active core devs, 90% of which don't even work on Python full time. Somehow we make that work.
I think author put incorrect words into the statement you are quoting. Flutter has much less mature environment, UI packages look good, but most are hot garbage without even unit tests. You can't trust even a single one if it doesn't have at least 5 active developers. They are drying like flies, no one maintains them, updates on time and Dart package manager doesn't help at all, makes things worse by having that system of requirements, versions. I used to work on a side project in Dart and Flutter and quickly fall in love, because i was able to write UI and backend code super quickly, but about 18 months later, I was spending more time maintaining packages that were dropped by original authors, updating, fixing conflicts between versions, and this was the reason I simply rewrote everything back to Java, even frontend to PrimeFaces (: Nothing broke by itself since early 2021.
Even Google dropped 3 packages I used in my projects. Including Dart Angular, they archived it 7 months after promising in AMA they will maintain it for a decade ahead (: They also abandoned their flutter charts library, it stopped working in newer versions of Dart and community had to fork it, they made like 80 forks in a week.
I think this is the problem author is trying to say, not Flutter as the framework, but as the general ecosystem that's consistent and provides at least somewhat positive experience using it. Google is neglecting it.
> 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! That ratio is clearly unworkable for any semblance of customer support.
This is a weird exercise. Python, for example, is a #1/#2 language in the world and there's only 50 active core devs, 90% of which don't even work on Python full time. Somehow we make that work.