This week Google did the totally not surprising move of cancelling Stadia. In some chat rooms I’m in the topic turned to Google’s penchant for cancelling major projects in general. That fed into a discussion of how can one choose Flutter as a viable tech stack if that is always hinging over our heads. In 2021 I created a series of tools for assessing open source projects through their Git histories. I wrote up my methodology in this blog post . I had intentions of analyzing many of my favorite projects at the time but never got past finishing Elastic/Kibana and starting OpenJDK. I’ve decided to turn that towards Dart and Flutter. The results for those projects can be found in this GitLab repository .
How I Rationalize My Dart/Flutter Choice
I clearly made the choice to start using Flutter and Dart as my fulltime platforms before I did this analysis since I’m now well over a year into it. I absolutely love the stack. Going back to having to do some Kotlin coding to tweak the processors for this post I’m reminded of a few things I wish Dart had that Kotlin does (hello data classes) but I’m now mostly comfortable with Dart more than Kotlin even. Since the source of inspiration for this was basically, “how could you choose Flutter knowing Google could just take it away,” my response is that even though Google is most of the force behind it that it can be stood up on its own by the community if Google drops it. The premise behind all of these analyses was determining how much of these tools are monocultural contributions even if they are open source. Even smaller projects like Elastic and Kibana are. OpenJDK is essentially an Oracle developed project. As you will see below Dart and Flutter are even more so but by Google. So how could I choose it?
First, since the big 6-12 tech companies suck most of the oxygen out of the room they also put most of the effort into keeping these moving forward. Even a gold standard diverse project like the Linux kernel still is heavily dominated by contributions from big tech contributors, such as the latest from the 5.18 kernal . The whole reason for my starting that analysis project was seeing how diverse, or not, these platforms we all take for granted are. So making a decision based on development diversity can be problematic, especially for stacks that need to target mobile. With a monoculture the question is if the community and project can survive without it. Usually the answer is, “Survive? Yes. Thrive? Probably not.” Smaller projects have the same problem except with less inertia to keep it moving. I chose Avalonia with its small development team before Flutter when I tried to do .NET cross-platform UIs. I chose Kotlin/KMM too, although that too gets substantial boosts from Google. So Dart and Flutter are not in that much of a different boat than any of these others.
So what happens if Google pulls the plug on Dart/Flutter? If it was two years ago then the project would be totally dead and not usable. It was just not mature enough to be a mainstream development platform for anything. Now though it is ready for prime time. It isn’t done with a bow on it by any stretch but if it went into a low level maintenance mode with community having to step up to host the dependency repositories and project page it totally could. Many of the newer features of mobile platforms can be and are absorbed by 3rd party libraries already, not core project ones. It would therefore need to be a truly user experience breaking change on target devices that would cause the need for a major overhaul that would ultimately sink the project. I can’t see that happening in the next decade at least. So if Google decided to just ax the whole thing in the worst case scenario the platform would stagnate and become less relevant over a decade or longer time span. I’ve swapped entire platforms several times in shorter windows. Therefore that true worst case scenario doesn’t hinder me from making Dart/Flutter my primary platform.
With that said lets look at the stats though…
I went into the full methodology of how to use this toolset to do this analysis in the original blog post as well as the obvious limitations of this methodology . TL;DR is the tool traverses every git commit of the project, extracts identifying information about the committer, files changed, and lines changed. We can then put that together with external information linking specific users to contributing organizations. This last part is the hard part. Some projects have lists of contributors but they can be of varying degrees of accuracy. Dart’s list of authors/contributors is here . Flutter’s list of authors/contributors is here . I had hoped that would make my job easier, and it maybe did or didn’t. Without a list of contributors it is down to literally doing searches against people’s name and email addresses on social media, GitHub, and LinkedIn to determine where they were working at the time of their contributions, if those were done individually or for a company/org they were a member of, and then if any of that changes. With the list, hypothetically, if they weren’t listed as a separate contributor then they worked for Google. The problem is that some of the listed as separate contributors did and do work for Google. In the case of some of them not only did they work for Google but they worked for Google on these projects specifically. It’s one thing to “work for Google” say on some Big Data thing in your day job but on the side or your one day a week side project to contribute to Dart/Flutter.
When I don’t have that sort of primer list I usually try to hit 98% of top contributors identified with their respective associated organizations or as individual contributors. This list, especially with some of those artifacts, complicates that. I know other organizations are using and contributing to Flutter, such as Canonical, but I’m not seeing it. Could it be just in the third party heavily used library space not the core? Could it be misidentified? I try to get 98% of contributions properly correlated to organizations or positively identified as self-contributed. I did that but this conflicting data did add a wrinkle. So instead I went with two separate analyses, one that shows the potential minimum amount of Google contribution and one that shows the maximal amount.
The Dart Project results can be found at this link . The Flutter project results can be found at this link . In each there are the graphical breakdowns of contributions for the entire project and for specific major development time periods. For Flutter it is broken down by 1.x, 2.x, 3.x, versions. For Dart this was broken down in point release versions, since they don’t undergo as many major version updates. That means that the statistics are for commits made when primary development is towards those versions not that all commits made went into that particular version. There is often patch work, clean up work, etc. being done on older releases mixed in too. It just lets one see a per-version look at the stats. I will only discuss a subset here.
First, looking at Dart in both the minimum and maximum cases
As one can see even in the best case scenario Google is 98% of the non-BOT commits. Worst case scenario it is 99.97%. So essentially 100%. “Bot commits” in this case are the automated scripts that run and do maintenance on the code. When one looks at the best case scenario in terms of “line volume” (the net number of lines changed) it does seem like over time there maybe were more non-Google contributions:
Even in the maximal Google contribution estimate it does seem like there is more third party contributing happing in later years, especially with Danny Tuppeny’s contributions. But even then it is still >90% Google. In the maximal case it is again essentially all Google over the timeline.
Flutter has a bit more diversity in their contribution space, First lets look at the overall statistics:
Whil it is still mostly Google there is a substantial larger constituent of third party developers. It is also interesting to see how dominant the bot contributions have become in later builds. This I’m sure has a lot to do with the CI system that is pushing lots of updates out continuously to keep the main development branch fresh. In a best case scenario Google is about 80% of the non-BOT commits. Worst case they are again over 98% of the non-BOT commits, and nearly 100% of the line volume:
AS we can see there is a growth in potential third party commit line volume over time. Even in the maximal case there is more of it, even beyond the one stand out contributor, Alexandre Ardhuin. Even though the bot is a huge percentage of the number of commits it obviously isn’t a huge amount of line volume, although still more than all other third party contributions combined in the 2022 and beyond period.
So the not so surprising conclusion is that the Google team is essentially the entire development team of both Dart and Flutter. While over time there is some more third party contribution it is very much in the noise. Based on my own interactions with the development of Flutter, albeit not very intensive, I don’t get the impression this is coming from there being a problem with accepting third party contributions. I believe it is coming from the fact that Google is throwing disprortionately large resources at these projects compared to other potential contributors. I am surprised I don’t see Canonical contributions. Ken VanDine of Canonical does have contributions but neither he nor Canonical are broken out in the AUTHORS file. Perhaps that is where a lot of the third party line volume is potentially coming from in the minimal Google Contributor case.
While I do wish that there was more diversity in the contributor space it doesn’t deter me from using Flutter or Dart as my primary platform for the reasons I stated above.