> What do you do if the team won't work on that bug for 2 years? Well, if it's a serious bug for your company, then you stop using Flutter. You don't have a choice. You need to keep moving forward. Your team doesn't know how to work on the Flutter framework, and the Flutter framework team is either unresponsive, or at least completely non-committal towards a fix.
Xplat FWs are just technical debt to prove a concept. Once you find critical mass the first order of business should be converting to native so you can remove that entire layer of additional complexity. Similar to paying down student debt to minimize how much interest you wind up paying on them after getting a good job.
IMO this should be the natural order if you size use it at all, not the emergency case.
There are different ways to think about complexity. In terms of the code that's being executed, certainly using a cross-platform framework is likely to result in more complex code as the final output. However, for apps that do not need to use a lot of native features, cross-platform frameworks can significantly reduce the amount of code that needs to be written.
It also means that the entire mobile team can become experts in one framework rather than needing iOS and Android folks. That said, it's certainly still helpful to have deep platform knowledge to debug/optimize in certain situations. But I think the point where using a cross-platform framework stops making sense is going to be very different for different applications.
Very sad article to read. I just expect the original Flutter will now die a slow death. I applaud the effort and hope they will be able to find a monetization model that works to support the development. There have been similar projects based on technologies that Microsoft has killed (Silverlight -> OpenSilver and various .NET-based cross-platform technologies) that serve their customers well. Unfortunately, none of them are in any way "mainstream" like Flutter is today.
No, it transitioned it to others after signaling it would for well over a year, so i don't think you could call it sudden:
"In 2011 with the introduction of the Dart programming language, Google stated that GWT would continue to be supported for the foreseeable future while also hinting at a possible rapprochement between the two Google approaches to structured web programming. However, they also mentioned that several of the engineers previously working on GWT are now working on Dart.[6]
In 2012 at their annual I/O conference, Google announced that GWT would be transformed from a Google project to a fully open-sourced project.[7]
In July 2013, Google posted on its GWT blog that the transformation to an open-source project was completed.[8]"
Google funded/helped for some number of years after that.
It still is going, afaik, with gwt 2.11 being released in january, 2024.
That might be the wrong way to interpret this. It actually validates interest in the framework. This change personally excited me and injects some change into the ecosystem that could result in a better future.
> What do you do if the team won't work on that bug for 2 years? Well, if it's a serious bug for your company, then you stop using Flutter. You don't have a choice. You need to keep moving forward. Your team doesn't know how to work on the Flutter framework, and the Flutter framework team is either unresponsive, or at least completely non-committal towards a fix.
Yeah this isn’t drive-by contributions where you shit out a PR that works for you but makes the test infra fail and you get upset. Ppl need to think big picture.
One big problem, I think, it may not be visible all of the test infrastructure if your outside google. Don’t know. Gerritt is its own world and googlers live there not in GH (it appears).
they're just too close to the problem and overestimating their relevance.
just because someone cloned a repo once or an NPM package was downloaded doesn't mean someone is a flutter dev. I don't know what the best metric would be, but its relevance is definitely overstated
Yeah, people like to count their "downloads" and call that their "users", but it's at least an order of magnitude difference in my experience. Sometimes a 100x difference.
Yes. Realistically off by at least a magnitude. There is literally zero chance there's 1 million active developers working on this experimental Google Tech out there.
while I'd agree with you that 1 million is too high, Flutter certainly is not experimental Google tech. It's widely used in particular internationally. I talked to a ByteDance guy two or three years ago and I think they alone had about 1k Flutter engineers. Nubank, Alibaba, BMW, Ebay use it extensively.
Flawed metric but eyeballing VScode Extension installs, Python 140m, c# 30 mil, Go 15 mil, Flutter 10 mil. It is very, very popular.
Just looked via google, and while no one really knows, common estimates of the number of web developers seem higher than that, on the order of 27 million.
Your point may still be valid, but... is 3-5% really that high?
(No dog in this, I'm not doing web development at the moment, although I have and probably will again.)
There's 200k weekly downloads of node on npm. A million flutter devs means that there's a comparable amount of node devs to flutter. I'm not sure how else to estimate it, but there's 170k github stars of flutter compared to 100k node, and a roughly equal amount of forks.
Github shows 98% of code is "Shell" on top of that there are also many different package managers that people use: fnm, volta that are build with rust. You can also install nodejs using homebrew.
No. It downloads binaries from nodejs.org. There is no "official" canonical means of managing Node versions. It's just a grab bag of community tools like NVM.
When I led the Google team we had pretty good analytics. `flutter` was for a long time opt-out with analytics and would phone home to Google and report usage. We filtered out docker containers and things that looked like CI and saw usage near 1M monthly actives when I left Google a couple years ago. I'm sure it's up since then.
There are 10s of millions of web developers in the world. Doesn't shock me that Flutter could be over 1M monthly (and probably several million annually).
There are just a lot of apps and app devs out there.
If there would be 1M flutter devs per year and on average team had 10 devs (rather rare most mobile teams would be smaller except really big apps) and development of app would take ~1 year you would expect minimum 100k new flutter apps in app store every year. That seems highly unlikely.
I suspect there's a lot of larger apps out there which use Flutter for one feature or set of screens but the majority of the app isn't written in Flutter. You could have a team of 100 working on a app where only three of them actually touch flutter on a regular basis, but depending on how exactly you capture analytics all 100 of them may get counted.
I‘ve worked for over a year, almost full time, on an internal Flutter app that never saw the light of day (maybe later, if the stars align). Many apps just get their support section revamped with Flutter because there’s no need for that to look fancy; but they‘ll still count against that quota. Many devs prototype their side projects with Flutter, but never release them. Etc
I'm pretty sure many/most professional app developers are in long-term projects, working on the same app(s) year after year. So for those devs the app count never goes up. That's at least my experience -- development work only stops when the app is pulled off the stores for business reasons.
https://flutter.dev/showcase has a few examples. Flutter is everywhere at this point. TikTok in China (Douyin), PUBG Mobile, MGM Resorts, eBay Motors, Kijiji.com, Grab are a few off the top of my head. And of course a whole bunch of Google apps (GPay, Earth, Classroom, etc.), Toyota cars, LG TVs, Google's own hardware devices, etc. Tonal is probably the app I used most often that's Flutter. Caribou Coffee, Betterment, Norwegian Cruise Lines, NuBank, Realtor.com are other random apps I've used that are Flutter.
Do you have a source for that claim? I'm pretty sure that is incorrect. Bytedance has said they use Flutter but for other projects.[0] Douyin is not mentioned anywhere.
I don't have access to any devices with Douyin on it, so I cannot confirm current usage.
My knowledge of their usage is from discussions with ByteDance some many years ago when I was in charge of the Flutter project at Google. At the time they were using Flutter in 50+ applications (probably most of them internal), including Douyin (TikTok for China) as well as physical hardware kiosks on their campus, web apps, etc.
I just tested Douyin 23.5 from 2022[0] and it does not have the two finger scroll bug.[1] It is of course possible they were carrying their own patch for it all this time but that seems unlikely. I doubt they are using Flutter or if they did it must have been a long time ago.
[1] https://github.com/flutter/flutter/issues/11884 - click on the search button in Douyin on the main page and search for something to get to a regular ScrollView. You don't need an account for this.
I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally.
I refuse to sideload arbitrary APKs, especially from bytedance. I feel bad because that is irrational, you did, and it'd be really helpful if I did and just did this myself, but, you should install FlutterShark and check: https://play.google.com/store/apps/details?id=com.fluttersha...
Why is "bug" in scare quotes here? It was most definitely a bug.
>I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally.
The actual fix was pretty involved. I doubt a large company like Bytedance would want to carry around extra patches at the gesture level that make the dev cycle more difficult. Having one person carry a patch on their local machine is a different story.
Anyway, the Bytedance blogpost says only 200 devs are using Flutter which would make no sense if it was used in Douyin, and LibChecker[0] returns no results for libflutter.so.
> Why is "bug" in scare quotes here? It was most definitely a bug.
Is it? I thought it was cool, I can't think of why its disruptive to scroll a list faster if you scroll with more fingers.
> I doubt a large company like Bytedance would want to carry around extra patches at the gesture level
I'm a solo endeavour, and I spent ~30 minutes to do exactly this (patch gesture behavior) two days ago. I was stunned how easy it is. But I grew up on versioned closed source dependencies on Apple iOS frameworks that you had to patch the runtime at runtime to fix, so I'm easily wowed.
> 200 devs are using Flutter which would make no sense if it was used in Douyin
Seems reductive: "Only" 200 fulltime, 800 in the company...and we're in a discussion about how 50 maintain _the entire framework_. :)
If you have an Android phone, get FlutterShark and check which of your installed apps use Flutter. It's a surprising amount actually. For example, I just recently discovered that Supercell uses Flutter for their Supercell-ID flow.
It was 8 out of 86 apps for me (9% of my apps). Including Hacki, the HN client. It's a good variety of apps too, from big billion dollar companies to tiny games I downloaded from F-Droid.
Since the beginning of Android apps could see what other apps were installed on your phone without asking for special permission.
They finally added a permission for it - QUERY_ALL_PACKAGES - in Android 11 (2020). Unfortunately it's one of those stupid permissions like filesystem access where you have to apply for it via a form, and only whitelisted use cases are allowed:
> Permitted uses involve apps that must discover any and all installed apps on the device, for awareness or interoperability purposes may have eligibility for the permission. Permitted uses include device search, antivirus apps, file managers and browsers.
I suppose that situation is slightly better than "anyone can do it for any reason".
That said, I literally only use Flutter as a hobbyist.
I made a basic web game for a friend, and a small web app that helps me manage my music lyric videos. I ultimately picked Flutter because I find it easier than actually building websites.
Dart is amazing.
But I'm not deploying to millions of users. At most 10 people have seen my Flutter apps.
It's VERY good for creating quick crud apps with Firebase.
Just counting the number of us who have it installed and might of spun up hello world says nothing about it's actual market share.
To be clear, I absolutely love Flutter, but it's still not something I really see job listings for.
on behalf of one of the Flutter founders, thank you for the thank yous.
I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for.
If you think its not popular until that increases past one of: JS, Python, Java, C#, PHP, C/C++, Ruby, Go, or SQL...I don't really know what to say. :)
Flutter in Kotlin instead of Dart would have killed! Alas. Hopefully, Kotlin Multi-Platform holds up as good as Flutter has (the rendering architecture based on Skia seems similar between the two frameworks).
Yes, I agree, trying to use Kotlin instead of Dart would have killed Flutter.
I've been hearing about Kotlin multiplatform just as long as flutter, and writing Kotlin since 2019.
Kotlin is a horrible daily driver.
I worked on Android for Google at 7 years, and maybe it'd have a better chance if it didn't win internally. As it stands, there's too many organizational boundaries created, and each organization holds itself accountable only within itself, so it's sort of the worst of all worlds, impedance mismatches everywhere, and nobodys fault they exist
I'm always stunned to read wish casting about Kotlin because there's ~0 path to even basic things that change productivity dramatically, like hot reload.
Only for the crowd, I need point out that no one's arguing there's more Dart jobs than C#.
Re: multiple frameworks, I worked at Google and would argue I know as much as anyone does exactly what happened there, so I can't agree it's weird, per se. Handwaving, I'd say that's because the situation seems more 'certain' or 'settled' to me, for good reasons, but ones not worth getting into.
There's absolutely tons of threads to unpack in your comment, I wish we were in person.
Speaking generally, based on observation you gravitated most towards discussing qualities of a job one might or might not get:
I essentially left my job at Google for no paycheck, partially because Google x Koyaanisqatsi, partially because I just couldn't imagine having to go back to write Kotlin and/or Java day to day and being criticized either way. That being said, it's deflating seeing Flutter job listings after getting into this whole industry from iOS dev. Thing with Flutter jobs is there's tons of low priced job seeking competition that are smart as hell.
That's because it is unusually effective in environments where people can't afford a Macbook only for iOS dev, and at this point in its lifecycle, it self selects for people who get experience with new frameworks
(On a serious note), inside Google you tend to get more easily promoted if you launch new products than if you maintain existing products, so it could be tempting for the employees themselves to follow in that direction.
> I don't hate Kotlin, it feels like Google's answer to Swift
You have the wrong order: JetBrains created Kotlin[1], and anything Google had to do with it was just adopting their language. Same story for Gradle choosing it over Groovy
> Can we at least agree it's weird Google is trying to promote 2 different languages for multiplatform development?
Google doesn’t promote anything. There are two competing teams with their own agendas. Flutter’s bills are mostly paid by internal usage, as far as I know. Android is mainly focused on Android part of Compose.
Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter’s lunch and promote Kotlin usage to drive their IDE sales.
> Let me compare Unity to Flutter for a bit. When Unity jobs are hard to come by, I'm still an OK C# dev.
Flutter/Dart doesn't offer they same freedom. Say what you want about Microsoft, but C# can essentially do anything. Including keeping me employed.
I might be wrong, as I’ve worked with .Net professionally, but I doubt you can jump from Senior Unity C# developer to Senior Asp.Net developer. Language is a small part in modern development.
>I might be wrong, as I’ve worked with .Net professionally, but I doubt you can jump from Senior Unity C# developer to Senior Asp.Net developer. Language is a small part in modern development.
I'm not exactly senior to senior, but I hopped from mid level hobbyist Unity dev to professional Unity dev , to mid level .net dev. I have a very specific niche though.
I'm very comfortable with my career.
>Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter’s lunch and promote Kotlin usage to drive their IDE sales.
Android Studio is free ? Are they really making that much money off users using Kotlin outside of Android Studio ?
Android Studio is subsidized by Google and works pretty much only Android. The moment you have to work something more, e.g. some Web stuff you need to pay for IntelliJ Ultimate as it’s only IDE that supports Kotlin.
They even have Ktor (Kotlin web framework) plugin available only in Ultimate. For any non-trivial Kotlin development you need to have Ultimate.
yeah, it fascinates me - both Apple and Google started these new UI framework things after Flutter, and both didn't land it, but instead, landed some half-baked thing where individual components can render live in the IDE.
That may sound more useful than it is: think "oh I can specify a dummy title and subtitle for a list view cell in code, then open a special pane in the ide to preview a source file, and then resize the window to imitate different screen sizes!", not, oh there's a bug, fix, save, insta-reload, verified fix. No holistic screens, or loading info from a database, or mutating data.
I assume this is an extremely hard problem. I remember trying to get Obj-C hot reload working 15 years ago and it kinda half-worked some of the time. And its not like I can edit the C++ my Flutter app is linking against and get instareload.
But still, it's one of the things thats easy to point out and drives home that these once-a-decade-or-two frameworks started in response to React Native/Flutter aren't addressing the fundamentals of what made them a sea change. Industry is risk averse and we make too many decisions similar to staying on track to launch MacOS 9.110 in 2024, instead of biting the bullet to get OS X done.
> both Apple and Google started these new UI framework things after Flutter, and both didn't land it
For Flutter to have fully landed it, it would take more than just hot reload. I'm not familiar with the latest but what are the chances of the Flutter rendering stack "going native" (as in not drawing to a Skia canvas or similar) on at least Chrome or Android? Or, is that the wrong question?
Yeah hot reload's just a one-off example that I think is the simplest way to relate the experience of SwiftUI vs. Compose vs. Flutter, though, the first two are long in the rear view mirror, I've been Flutter only for about a year.
Good question -- I don't think its the wrong question? Maybe? :P Tough to phrase on my end too.
I only feel native speaking in iOS or Flutter, even with the Android experience, forgive me: I guess I'd summarize it as "yeah, you're right. if you're wondering if they're ex. calling CoreGraphics on iOS, no" (well, they do, but for text rendering. Not for a red rectangle)
Generally, Flutter Web is rendering into a WebGL surface using Skia -> WASM (2.2 MB download! modern miracle). macOS, iOS, (done) Android (soon) are switching from Skia to Impeller. I think the thrust of your question is "are they still bundling the render engine?" and the answer is yes.
I find the way you phrased it intriguing, in that, before reading your post I'd say drawing to a Skia canvas is as native as you can get. But I realize now that means I was overindexing on "close to the metal", and its apex not-native to say "gimme the framebuffer and i'll take it from there"
I'm a bit picky with design stuff and I loooooove that Skia's bundled and I can rely on it cross platform
Just seems like personal preferences. I've used languages with extensive pattern matching and don't feel like I'm missing out without them. Don't really see the problem with Gradle or Static Delegation either.
Then you won’t understand what made Flutter “click”. I work with Kotlin, Gradle and Compose on a day to day job and it is absolutely dreadful experience. Sure, it beats working with Java… Java 8.
> I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for.
Did you really just thank the guy for saying thanks, but give him a big fuck you in the same breath for not being a 100% kool-aid drinker?
My point was you just can't count SDK downloads as developers. Is every CI/CD pipeline a developer ? The founder of Flutter who posted that stat has a startup which is heavily invested in the perception of Flutter being popular.
In the Unity community we aren't afraid to critique Unity and even suggest trying other engines. Of course Unity isn't open source so you don't get articles like this where someone claims it's time to fork.
At the same time, Unity uses C#, so you can take your skills, and even some nuget packages( with a bit of work) elsewhere if you want to switch.
Flutter requires a higher time commitment since I have to learn a language that's exclusive to Flutter. If this ship goes down I can't use Dart with anything else.
Anyway, I think job postings are a much better metric of adoption. I like Flutter, I've used it for 4 years and I want it to succeed. I don't want to go back to react native!
No, I sarcastically thanked him for free-association about the # of job listings he sees for job listings he's not looking for and what that means about the language.
I'm guess I'm capable of being curious and engaging in conversation, beyond sitting in the bleachers grading everyone on my scale that at 100% is "koolaid drinker.", depending on if I feel like the things they're talking about are on Team A or Team B I've identified.
Then again, that perspective would sort of come naturally if I were reading hysterics into every comment I read. "Big fuck you" is textbook catastrophizing.
It's possible that they also count students and amateurs such as me, who only used it in a small project never published. There could be a million I guess, but professional developers are probably a lot less.
I think this is a strong possibility. For example, I don't work in programing and don't intend to ever work in the field. I do it as a hobby. I downloaded flutter, played around with it for a few weekends and decided it wasn't for me. If you go solely by number of downloads I would be counted as a 'flutter developer'
I don’t sub him on YouTube - but I’m not lying when I say everyone I know IRL who does sub his channel has worked as a barista at some point in their lives (…and purchase actual chemical-lab supplies for their coffee brews).
My experience when I last looked into Flutter was that it was heavily used in India - at least based on who participates in the community online - and much less elsewhere. That's not a value judgement, just might be a factor in why you don't hear much about it if you're not in India.
Flutter is truly a piece of great tech with remarkable quality and value. I hope the right path will be found.
I think companies using it for commercial purposes (like what we're doing) should contribute something to the effort to help make sure Flutter not only survives, but flourishes.
Bug bounties, supporting individual developers, supporting efforts and initiatives, professional services, or any other way that helps the project move forward will be great.
Faster and better in almost every respect we've looked at vs React Native or Electron. We're super happy with this choice we made quite some time ago.
I'm not qualified to give an in depth review/comparison, however.
Edit: we use flutter to build an app which runs on iOS, Android, macOS, Windows and Linux -- the same code base with pretty minor adaptations to desktop vs mobile and different screen sizes.
The experience has so far been fantastic. It's fast, it's relatively light weight, it's performant, it's a pleasure and we couldn't imagine doing it any other way.
We have worked with flutter since 2019; having built internal apps for our staff, public apps for our customers, small utility apps etc- this has been our experience as well. Not only flutter has been rock solid, easy and fast to develop, it has a wide array of libraries. Long may it continue.
> Most of our apps use React. When we first adopted React, we were pleased with the development productivity it provided, but sadly its initial performance was subpar in terms of start-up time, memory consumption, and responsiveness. After significant and complicated optimizations we reached performance benchmarks that were good enough, and yet we desired a new technology that was both fast and simple.
> To our delight, our very first prototype with Flutter easily exceeded our target benchmarks! Without any optimization whatsoever, our Flutter rewrite launched twice as fast as our original app, consumed less runtime memory, and felt more responsive and playful to use
I wonder how it compares now with the latest version of RN that brings out a lot of performance gains induced by the removal of their native bridge, and also faster startup by making lazy loading of modules the default option
> But React Native is different , JS code compiled to native code using c/c++ compiler on target system. Flutter also do like this one.
Sure, but you're compiling two radically different languages. JavaScript is dynamically typed (even with TypeScript) and Dart has a sound static type system.
It's much easier to compile Dart to efficient native code than it is JavaScript.
I've been working with Flutter for a little over 2 years nonstop. Before I started this project, knowing enough react, I experimented with react native, Expo, also quasar, capacitor, nativescript, and other cross-platform mobile solutions. Flutter/Dart was just nicer to deal with than everything else. I needed to work with C code too, and Flutter made it straightforward with FFI.
The developer experience was great and the Flutter team was very responsive with questions I asked.
Exactly my thoughts. How anybody would take it seriously if the people behind are not known, is beyond me. Anyway I left flutter a long time ago exactly because the mentioned problems - ridiculously slow response time fixing bugs, like auto fill want working.
Honestly makes sense to me. If Google has proven one thing is that it generally maintains a very tight grip on anything open-source that they ship. Ie. it's extremely hard to contribute upstream. This is fine when it's a package that's critical to good, so they invest a lot into it (for example, Jax). But for stuff that's not quite there, it means fixes will meander for months if not years.
As someone reliant on Flutter, it is likely better to rip off the band-aid now than wait for a slow, prolonged decline. That being said, whilst I am at least somewhat comforted that the person taking charge is someone who was involved with the Flutter team at Google in the past, rather than a random, overenthusiastic person, I have a few crucial criticisms on this post that make me skeptical.
For one, I'd recommend adding a newsletter field to the website/blog, simply so those who may not want to test or participate right away can stay in the loop. More importantly though, the two links asking for reviewers and leads just link to a private Eggs account, which, even before someone decided it was a good idea to just make content appear in an unsorted manner (random post from 2023, then 2021, then 2024, then 2020, ...), has never been an ideal approach for such projects in my opinion. I honestly thought I had clicked on the wrong links when two eggs profiles appeared in new tabs.
Forcing potential devs to create a third-party account on a social media site, then send in DMs is likely not the best way to get such a major project of the ground and having public repos or at least a contact form set up would go a long way, especially since that also makes it easier to enforce some ruleset for applications.
Additionally, consider listing what changes have been implemented in Flock at this stage. As it stands, it appears impossible to easily tell what one can expect without diving into the changes [0] one-by-one.
Still, wishing you the best as Flutters development and approach to both what goes into which branch, as well as keeping up-to-date with UI elements in target OSs has been leaving a lot to be desired to say the least. I still feel that, despite all shortcomings, for certain applications and workflows, Flutter/Dart remains the best, and it would be a shame to see it unmaintained.
No Eric founded Flutter at Google. However, Google had previously acquired another company called Flutter, and they had that domain lying around, and decided to use it. That's what I understood, at least.
Guess you're right. Establishing a "Flutter org" counts. Though, I've never seen folks in this space (Bjarne Stroustrup or Anders Heljsberg for example) say they're the "Founder" of XYZ language / framework.
I've nothing to add to the conversation, but I jump on this oportinity to tell you that i like the content you've made with Adam Barth on yt very much, have a great day :)
> 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.
If "only" 50 people working on a project used by one million people was unworkably low then every single successful project out there would be doomed. I've certainly worked on things with much worse ratios than that.
> one has to critically assess why a team that loves external contributions has only managed to merge contributions from 1,500 developers over a span of nearly a decade.
External contributions from 1500 developers over a decade is a lot. That is an unusually high number, not a low one, and backs up Flutter's claim to love external contributions.
The fact that this person thinks that they can just magically conjure up dozens of volunteer PR reviewers is wild. Everything about this post makes it pretty clear that they don't have the slightest clue of the scope of what they're trying to do. This feels like one of the standard examples of an ex-bigco person setting off on their own with no understanding how just how much the bigco did in the background to facilitate their job.
Our user base is of a similar order of magnitude, with around 70 developers. It doesn’t seem like a large number, indeed! A small minority frequently contacts support, suggests features, etc., while the majority simply uses the product.
these are also 50 google devs (that may or may not be at the company anymore) by this estimate. They could have just said there were critical tickets not addressed by Gooogle and their PR's ignored, and would have gotten a much more sympathetic response.
Process groups, some solid performance tweaks to ETS and Mnesia, etc. It all got upstreamed or became redundant eventually. Rick Reed gave a couple talks about it around a decade ago if you can track down recordings.
The whole point of running an opensource OS/vm/runtime/etc is that you can tweak things here and there when you need them.
Yeah, we had to make changes, some changes to FreeBSD too, but mostly little changes here and there. Erlang and FreeBSD were both lovely to work on.
Re the sibling's question about what was changed, I don't remember everything, Rick Reed's presentations at Erlang Factory / Elixir describe most of them though (although those ended in 2014, I think). Many or most of the changes got into upstream one way or another. But most of it were things because AFAIK, we had much larger Erlang clusters than the rest of the community; I remember seeing advice about large clusters of 50 when we were running 300 nodes in a cluster, and I'm pretty sure we had dist clusters above 1000 later when we also had separate cross cluster messaging. We also had huge mnesia tables, other people said don't use mnesia over 2GB, and we had nodes with more than 512GB of data in mnesia. I don't really remember much that we had to do with dist, although pg2 needed help and our replacement became pg in OTP, mnesia did need some help to scale. We changed the ETS hash kernel to avoid everything hashing the same way, I don't know if that made it out.
We also needed to do things like timer wheel improvements, but OTP also did timer wheel improvements and we dropped ours. Not so many people were running quite so many timers.
Then there were things that I don't think are upstreamable. Adding a way to drop a process's message queue. Adding a way to add a message to the front of a process's message queue. Those two are very not in line with OTP, but handy for operations if you use them carefully.
How is it bizarre to compare the impact of a low number of engineers affecting millions of people. In the case of WhatsApp it was 35 engineers affecting 350 million people.
The support needs of developers is generally higher than those of a messaging user. How often have you had to contact the support of a messaging app you use? Now think about how often you create a Github issue or PR for an open source repo.
Absolutely, yes! Then make it two or three people, maybe 10 and there are still n-times too many people working on flutter compared to cURL.
Which boils down to: Number of devs vs. people using something is a very bad metric. Even number of supported devices won't work good in this case (I assume cURL runs basically everywhere).
I think it's very difficult to estimate complexity, and then make a statement about "how many people are enough" is even more difficult. Some environments are harder and more complex, some are just very heterogen and some are both. Sometimes it's the organizational overhead, maybe even something else.
WhatsApp has a very narrow use case and feature set to support. Flutter is a multi-platform framework for developing apps like WhatsApp. It seems like a apples and oranges here.
Flappy Bird was taken off the store by its author, if you take WhatsApp off the app store, that would be a completely different reaction to Flappy Bird.
What about Python? They had 34 core developers in 2017 [0]. Python is used by millions of devs. They have to support a multitude of platforms as well.
Same goes for a lot of programming languages like Go: a pretty small core, the rest is external contributions. And they have to support all sorts of platforms/configurations as well (probably more than Flutter does).
to be fair, Python's performance has lagged far behind comparable languages (e.g. JS) for at least a decade. maybe more devs could give it the V8 treatment?
I’m not sure what you mean by this but Python can be very performant when you want it to be. That is to say, when you build computation heavy parts in C (or Zig), and remember to avoid the various performance pitfalls like not using generators when you didn’t want to load all those millions of elements into your memory.
What sets professional Python aside from most other programming languages is that everyone who uses it knows that it’s terrible and how to deal with that. Which will sometimes be replacing parts (or all) or it.
To say that it’s inherently less performant than JS is frankly silly though.
Yes. Is that so weird? JS is also performant when you don’t use JS considering you’re running it on C or Rust and are likely using the FFI if you’re doing any form of computation heavy work.
Yes, it's very weird. When I write JavaScript, I expect it to run reasonably fast because of the JIT - and it does. I've never felt the need to use FFI, and libraries that use it generally do so because they want to interact with pre-existing C or C++ code, not because it's the only way to get decent performance.
CPython really is inherently less performant than V8. CPython, until very recently, didn't have a JIT at all. It compiles scripts to bytecode, then runs the bytecode in a giant case statement. It doesn't have a tracing profiler-guided optimizer or an exotic garbage collector. CPython is way, way simpler than V8, but it's consequently slower. It's just the consequence of Google putting centuries of developer-years into an engine.
You can't just claim Python is fast because Python's C libraries are fast. Those libraries are fast despite Python. Torch is extremely fast, but it's fast from C and Lua too. There's valid reasons to want to compute in your programming language. Python is, ironically, probably popular because its slow speed encouraged users to write blazing fast C libraries rather than even try writing native Python, vs. settling for middling performance as in Java or .NET.
I shouldn't have to get out my hammer and tongs when NumPy doesn't implement the operator I need. Why can't Python be fast like Julia?
We got around 3m with seven guys, so yeah, and we don't even have on-call rotation / schedule, even though emergencies do happen from time to time. They think 1:1000 ratio is too big as well? That's crazy.
Are you comparing a developer platform to consumer software there? Dev platforms have radically different support costs to regular SaaS or mobile apps. Developers are really support intense.
Shouldn't developers be the most self-reliant users possible, especially when working with open-source tools? That is, shouldn't we expect that when a developer has a problem, they dive into the code and figure it out on their own?
no, if I'm using your platform, it's because I really don't want to deal with the stinking pile of abstraction below that. so on the contrary, I would see it as a negative if the abstraction was that leaky.
No, generally developers prefer to request help or work around an issue than dive in and fix it. The activation energy for contributing to an upstream project is high and very few do it.
Developers are support intense because dev tools and platforms get used in a bazillion ways and combinations you can't predict. It's not like a nice consumer app where the user can only press a limited combination of buttons, and test coverage can be quite exhaustive. GUI toolkits are especially a bottomless pit of edge cases and bugs because they have tens of thousands of API methods, enormous numbers of features, they can all be used in combination, they have to run on multiple platforms usually and those platforms also have bugs etc. The support costs of a GUI toolkit are basically unbounded.
Yeah, the person primarily behind this is a bit of an oddball in my experience who had a somewhat contentious relationship with the team which he himself was once a part of and it’s not clear if he left or was asked to leave.
But reading that post I couldn’t help but shake the feeling that there might be other non disclosed reasons for the fork because some of the ones he did give as you pointed out didn’t make a lot of sense to me either.
I mean we do actually have many years of real life experience at this point of how they perform in the real world.
I’ve never actually come across a better maintained project personally. It is incredibly thoughtfully developed with a high level of attention to detail who have successfully shipped a huge number of major improvements in ways that made sense.
There is a premise in the post that implies Flutter is poorly maintained and that’s just not a commonly held belief by the community at all.
As I hinted to in another comment the particular person behind this is a bit of an oddball and I think there may be other reasons that drove this decision in the first place in addition to the ones he gave in the post which for the record I’m sure there are some things he wishes were prioritised differently but this fork seems kind of very “him” rather than a popular position that people were begging for.
50 people is a pretty huge team at Google to start with, there’s teams of <5 that support weird bits of core infrastructure that serve billions of users an hour.
Push notifications need to connect to that many devices every hour easily
You may not get a notification every hour, but the phone still have to connect to Google APIs to check to know that.
You can say same thing about say location services, every phone if powered and connected to the internet would ping more than one an hour, more than billion devices are definitely online at any give time, not just Android phones, also every android TV, tablet, watch, and the hundreds if not thousands of other devices running GMS on top of AOSP .
There are probably few other APIs in GMS that would ping at least once an hour each device that is powered on, perhaps things like NTP for timing alerts or Emergency Alerts etc.
You may consider them "Background Services" , most of them however have some foreground UI if they need to, and users will notice if they don't work
There are roughly 5 billion smartphone users now, those devices are almost always on and sending background data somewhere. By volume, more of that data guess to Google than anybody else, on the order of hundreds of network requests per device, per hour.
I don't find it hard to believe. I am not at Google but I work on a product with 200 million MAU, in a core team that serves requests to every single one of those users and there are 6 of us.
I believe it. I've never worked at Google, but I was the engineer for SMS/Voice registration at WhatsApp, ocassionally with one other engineer (I believe the team was 3 when I left, not sure if it grew); I think there were two engineers doing my job for Facebook; although they had a little bit more scope, since there were more kinds of SMS they sent. That doesn't have a huge request rate, but it is super important.
Something like DNS or BGP is going to have a tiny team and a huge impact. Load balancers probably has a bigger team, maybe 10-20 engineers, and almost everything goes through load balancers. And that's just the things that are easy to enumerate. I can think of lots of small teams when I was at Yahoo that worked on bits of software that are hard to explain, but were critical.
Exactly, there’s really like three dozen or so people globally who really should never be in the same room at the same time as the risk is too great they get hit by the same asteroid.
I’d put “person who makes sure WhatsApp verification codes work” on that list.
> I’d put “person who makes sure WhatsApp verification codes work” on that list.
Thanks! That part of my job really wasn't too hard though, once I got things in order; but it was the easiest part of my job to describe. Just a lot of debugging from sparse data, and trying to get things to work a smidge better, because smidges here and there add up. It really helped to have a great customer service team that bubbled up usable information from users.
Debugging things from sparse data gets you involved in a lot of different systems though... That and I told people I worked at an ISP in the before times, so guess who got to fight with sendmail, and guess who got to own our Domain accounts and DNS accounts and guess who got to get x.509 certificates, and who had to fight with Google Apps to make mandatory 2fa usable, etc. Basically everything without a person and server adjacent got me. :P
Anyway, I've moved on (replaced by a team of three on the SMS stuff amyway, much better bus factor) and am semi-retired and no longer in any critical path, which is a lot less stress.
World population is 8.2 billion. Assume that 1/3 are asleep at any given time, leaving 5.5 billion awake. It’s not a huge stretch to imagine 20% of them (1.1 billion) using core Google services during peak times.
Common misconception is that you open source something and contributions will flock in.
Doesn't happen that way.
And even if happens - changes can't be merged without thorough and careful review. So who's do the reviews when supposedly there are too many contributors? Only someone who fully understands that particular subsystem.
Which means we're back to square one because as per post there are only three subject matter experts available for the new fork.
It absolutely reads this way, and this person is in for a rude awakening. I thought all the Flutter team was laid off from Google anyways, effectively making this project dead in the water. Looks like there is a someone left over that can't let it go and just move on from the past.
You’re most likely confusing Flutter with the Python team which was laid off but the work moved to a team in Germany. The Flutter team has not been laid off to my knowledge.
The main problem in projects like flutter is to always focus on the "new". If you focus on the new without stabilizing the existing basic features, you will accumulate thousands of problems. If the same path is followed in this new project, I think the result will be the same. There is still no clear update on issues opened years ago. and most are pretty basic needs.
I must be living under the rock. I thought Flutter is prosperous? I only dabbed into Android development as a learning experience so I probably missed something important.
If everything the article says is true, should I switch to Kotlin?
Key statement: "As Flock ships important bug fixes and features, the Flutter team can then choose to add those to Flutter, on their schedule. "
I see a lot of negative comments but I think this will be a net positive over time to the Flutter community and to the technology itself. I think it will also give Google a reality check on the needs of the community.
Flutter Founder here. I'm very pro open-source, and pro taking-action, so hopefully good things will come out of it. I think this particular author is mostly stirring up a bunch of noise and does not represent a significant chunk of the community, but we'll see. :shrug:
> ...the Flutter team is in maintenance mode for 3 of its 6 supported platforms. Desktop is quite possibly the greatest untapped value for Flutter, but it's now mostly stagnant.
I can no longer speak for the Google team (since I no longer lead it), but my understanding is that yes, Google is focusing their efforts on other platforms rather than Desktop (despite themselves using Flutter on Desktop for a variety of platforms). Canonical is contributing to the Desktop efforts substantially.
The constant question of big tech OSS is who is it for/why does it exist? Did they make this because they think it's a useful tool internally, or are they trying to build a platform for external developers? If they built it because it's internally useful, then it's probably open-sourced for cultural reasons (the people working on it are used to being in open source communities and want to share what they're working on).
Unless something is specifically being made as a platform for external developers (Android and Firebase come to mind), the level of support you'll get is at the whims of the team's current product leadership and budget. Both of those things change over time - a product manager can always say "let's focus on internal developers" and put the external community in maintenance mode. Based on the article's mention of desktop support being deprioritized, this might have happened on Flutter.
Big tech funds things that would be really hard to pull off with just volunteers, but big tech projects can also be victims to the capriciousness of corporate politics and budgeting.
Agree, if it pans out this way in reality of course. That'd be splendid!
NodeJS went through something similar. It was tightly controlled by a single company (Joyent) who were juggling too many balls, and progress went slowly. Community people did a fork (io.js) which shipped improvements faster, but they did so in a careful non-shitty way. This made lots of people switch to io.js, so that eventually NodeJS merged with io.js (iirc they just renamed the latest io.js "NodeJS").
I don't know of any other instances of community forks of company-controlled OSS that did something similar though. If this is just one guy who made a blog post, like a sibling comment suggests it might be, then it might not pan out this way.
> 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.
Back when I worked on .net we had fewer than 50 people maintaining a product that shipped to over a billion machines. If you opened an issue on github we'd usually reply that day.
It's getting a bit long in the tooth, but I feel like 'the mythical man month' should still be required reading for software devs. More devs != better.
That's still plenty of people if you got a few thousand people at AWS/Azure or in this case Meta's in-house cloud making sure your service is running and scaling as it should.
That ethos runs through everything the WA team does. I learned a bit about it when I was at fb and I was beyond impressed by how few servers WA used for its core infrastructure. It's a really well engineered product.
Mythical Man Month applies to new product development, when you have a product you're trying to rush out the door that doesn't exist yet.
Once the project already exists, is largely feature-complete, and is mostly in the "fixing bugs and small annoyances" phase, then Linus's Law [1] takes over. Debugging is very much parallelizable, because you can generally fix the bug without generating major impact elsewhere in the codebase, and if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
> Once the project already exists, is largely feature-complete
That may be a reachable state for a command-line oriented operating system itself a clone of an older operating system, but is likely unrealizable in any sort of system that is trying to be actively more innovative.
> mostly in the "fixing bugs and small annoyances" phase
I don't know of any UI framework that has had the luxury of ever reaching that phase.
> then Linus's Law [1] takes over.
If you maintain a widely used framework, I think the more meaningful eponymous law is Hyrum's: https://www.hyrumslaw.com/
This is probably the #1 source of friction for contributing to Flutter. It's not that the Flutter developers are overworked killjoys who don't value external contributors. It's that when, as the author of the blog post says, your codebase has a million users, it's really hard for a contribution to not end up breaking someone.
> if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
Sure, but the fix itself will still need tests. So now you've got to walk the contributor through the process of writing tests which is definitely not a skill that most software engineers have and is not particularly rewarding for an external contributor who already has a working fix and just wants their patch to be "done".
Fundamentally, coordinating thousands of people to make a single codebase used by millions of people is hard. There is no silver bullet. It's a miracle it works at all.
I thought linus had lost it for a second there, until I saw it's just named after him and not something he created. I generally disagree - I think that having many developers with a shallow understanding of the whole codebase scales less-than-linearly with the number of devs.
It's probably less actively harmful than new product development, but I'd still say a team of 50 is probably larger than is necessary for the amount of usage flutter gets.
Having a large number of devs spot fixing issues as they come up without a deep understanding of the codebase is how you turn a maintainable project into a mess.
> Back when I worked on .net we had fewer than 50 people maintaining a product that shipped to over a billion machines. If you opened an issue on github we'd usually reply that day.
It depends on an org's priorities and what gets put on someone's reviews.
During one of the years when I worked on Windows Mobile (before Windows Phone!) we had an objective handed down from on high that we were to spend so many hours a week on customer support forums helping people out.
Well, for that year, customers all around the web got great support right from engineers! I got to paste lots of positive feedback from end users in to my yearly review, and I felt great about it!
If Google cared about supporting Flutter as an Open Source project, they'd make the health of the open source project one of the measurements going into employee reviews at the end of the year.
Totally– This was in the early days of open source .net, when it was still called .net core. We had just moved onto GitHub and I don’t think microsoft had quite figured out how to manage that organizationally. There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
> There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
Historically when MS was filled with software nerds, the fastest way was to post on an online forum!
Sadly those days seem long gone. It doesn't feel like Microsoft empowers employees to really reach out and help customers anymore.
I do remember responding to those Tier One support contract requests. IMHO that was a better system than what the large tech companies do now, which is basically just ignore customers no matter what.
> There is a point of time there where the fastest way to reach an engineer was not to go through a tier one contract that you pay microsoft millions of dollars for, but instead to just open an issue on the GitHub. I doubt that’s the case anymore.
That’s still very much the case today, BUT you absolutely need to do your legwork beforehand (e.g. include a copypastable program that reproduces the problem and as thorough an analysis as you can do) otherwise your thread will go poorly… (and plenty of regulars in the dotnet repos aren’t exactly the forgiving type). Compare that to what you get with a Support contract: you can be a non-technical person in Sales or the C-Suite or whatever and they’ll hold-your-hand to guide you through the troubleshooting/diagnosis/repro process - and if the issue is an actual bug in MS’ code then at least you get your ticket’s fee/credits refunded.
———-
Unrelated-but-related: An LLM+multimodal “AI” would be fantastic for walking nontechnical users through the issue-reporting process. I’d wager the number-one problem in tech-support today is dealing with “It doesn’t work”-type tickets which necessitates having to interrogate the user/customer/victim to get the details out - but if an AI agent (with screen-reading abilities) handles that (without a single audible sigh or facepalm) then that’s a win for everyone.
The OP was talking about developers serving the needs of developers, and the ratio involved there. This is different than developers serving the needs of machines (fifty developers to some arbitrary number of machines is not automatically impressive) or developers serving the need of users. One would expect the ratios involved to be different for all three and highly context-specific.
It's such a shame mobile development with C# isn't more viable. I want to make some apps, and I hate JavaScript, but from everything I've read Maui just isn't practical.
The native approach is quite viable: my MvvmCross-based app has been on both stores since 2018 with almost zero MAUI/Xamarin-related issues, even with hundreds of thousands of installs.
Not gonna lie though: building the UI twice for both iOS and Android feels somewhat masochistic. But in the end, it "just works" with shared View/ViewModel logic on both platforms.
- guy wants to add PR more aggressively to a code base than Flutter currently is
- isn’t clear if they have a concept of handling compatibility between fork and original
- why not be a labor organizing entity and work with the flutter team?
Some of the PR that I am aware of that are stale and could be good candidates - are difficult design decisions and stakes need to be put in the group.
It seems ill advised. This is huge amount of work with limited upside and huge downside (adding uncertainty to outsiders looking in) and tons of effort (just in infrastructure maintenance).
Edit: if I were conspiracy oriented I would think it’s to harm community. I would pay this no mind.
Note that I know nothing of the Flutter team/culture and am only answering generally:
>why not be a labor organizing entity and work with the flutter team?
Depends on the maintainers/team. I've definitely seen many a bureaucracy that slows down FOSS to a crawl of bug fixes and feature progression. If you make enough PRs that are ignored for weeks or months, you'll realize this isn't really a team ready for nor interested in a proper FOSS environment and it's instead mostly "that teams code that happens to be readable".
Their official answer seems to suggest as much:
>But, sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.
I guess we'll see. I'm way more of the mentality of "actions speak louder" so I'm not really one to announce my plans until I get something worthwhile off the ground (in this case, a few stale PR's that feel like game changers to the customers). But that's not a mentality modern social media rewards.
There is a comment above that shows the founding former didn’t want to fix tests in his PR. Flutter is massive and it’s critical infrastructure. The tests are critical to up-keep. The tests are probably a majority of the work. Which makes sense for something that has such a large surface area.
I think this is an emotional reaction from someone has never managed a large project. Merging PRs and releasing them isn’t the problem. I hope they understand that.
Flutter is amazing. Web, desktop and mobile that actually work is nearly magical. Yes there are priorities. Yes the desktop isn’t as high priority of web. It does work. Hell. Collect money and fund Hixie or others to prioritize patches community feel should go in. That is constructive and methodical/reproducible.
Forking a massive code base, applying PR and not conforming to the source repo standards (tests whether that is golden or not) - just seems not well thought out.
I think community could fund a well known developer to fix desktop issues and have PR adhere to Flutter standards. It’s a ton of work. But seems like it’s a money/dev/process issue. Not a PR merging exercise.
>But, sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.
I'd love to see some examples. I've had my pull request merged in a fairly quick amount of time - less than one release cycle, which is what matters here.
Also frankly, nobody forking Flutter will be nearly skilled enough to work on the Flutter engine (Impeller). So it's hard to take this announcement seriously.
> Also frankly, nobody forking Flutter will be nearly skilled enough to work on the Flutter engine (Impeller).
For me its so weird they ditched google/skia to develop Impeller in Dart from scratch in the first place. If skia was not ready they could move just 1-2 developers to Skia team to collaborate with them. Now they want to even write their own 3d rendering lib based on Impeller (flutter_gpu, flutter_scene) even thought google has already mature 3d engine in C++ (google/filament). For me from the outside looks like "not envented in our team" syndrome. We are now in funny situation that react native has react-native-skia and react-native-filament and Flutter teams reinvents the wheels.
They been building it before and still building and releasing with flutter so it's not like they don't have pipeline for that. And it was distributed compiled so nothing to compile for 3rd party users.
As someone who has slowly been writing Dart/Flutter bindings for Filament[0] over the last couple of years, I agree the internal 3D engine was a bit of a strange choice of priorities.
I expect there will be some communication from Google at some point and the foundation will have to be renamed. It reminds me of OpenTF being renamed to OpenTofu.
745 comments
[ 4.3 ms ] story [ 372 ms ] threadWhich will be responded to swiftly with no lawsuits or damages exchanged.
Are there no escape hatches?
The only escape hatch I can think of is to either have the team learn how to work on Flutter itself or hire someone who can.
IMO this should be the natural order if you size use it at all, not the emergency case.
There are different ways to think about complexity. In terms of the code that's being executed, certainly using a cross-platform framework is likely to result in more complex code as the final output. However, for apps that do not need to use a lot of native features, cross-platform frameworks can significantly reduce the amount of code that needs to be written.
It also means that the entire mobile team can become experts in one framework rather than needing iOS and Android folks. That said, it's certainly still helpful to have deep platform knowledge to debug/optimize in certain situations. But I think the point where using a cross-platform framework stops making sense is going to be very different for different applications.
Isn't flutter from google?
"In 2011 with the introduction of the Dart programming language, Google stated that GWT would continue to be supported for the foreseeable future while also hinting at a possible rapprochement between the two Google approaches to structured web programming. However, they also mentioned that several of the engineers previously working on GWT are now working on Dart.[6]
In 2012 at their annual I/O conference, Google announced that GWT would be transformed from a Google project to a fully open-sourced project.[7]
In July 2013, Google posted on its GWT blog that the transformation to an open-source project was completed.[8]"
Google funded/helped for some number of years after that.
It still is going, afaik, with gwt 2.11 being released in january, 2024.
https://www.gwtproject.org/
I find it odd that you would think this fork would even have an impact on Flutter or its roadmap.
they could pay contributor or issue bug bounty..
One big problem, I think, it may not be visible all of the test infrastructure if your outside google. Don’t know. Gerritt is its own world and googlers live there not in GH (it appears).
just because someone cloned a repo once or an NPM package was downloaded doesn't mean someone is a flutter dev. I don't know what the best metric would be, but its relevance is definitely overstated
while I'd agree with you that 1 million is too high, Flutter certainly is not experimental Google tech. It's widely used in particular internationally. I talked to a ByteDance guy two or three years ago and I think they alone had about 1k Flutter engineers. Nubank, Alibaba, BMW, Ebay use it extensively.
Flawed metric but eyeballing VScode Extension installs, Python 140m, c# 30 mil, Go 15 mil, Flutter 10 mil. It is very, very popular.
Seeing as React Native has somewhere around 1 million active developers, Flutter almost certainly does as well.
Your point may still be valid, but... is 3-5% really that high?
(No dog in this, I'm not doing web development at the moment, although I have and probably will again.)
The 2024 SO dev survey https://survey.stackoverflow.co/2024/technology/ has flutter at 10% and nodejs at 40%. Github language stats has JS about 10-15x the popularity of dart, but seeing as JS is more than just node it might pan out. https://madnight.github.io/githut/#/pull_requests/2024/1
So I guess looking at the stats 1M flutter devs is not an implausible number on its face.
I’m pretty sure Node developers usually don’t install Node from npm.
No. It downloads binaries from nodejs.org. There is no "official" canonical means of managing Node versions. It's just a grab bag of community tools like NVM.
I'm not sure what conclusions we can draw from either number.
When I led the Google team we had pretty good analytics. `flutter` was for a long time opt-out with analytics and would phone home to Google and report usage. We filtered out docker containers and things that looked like CI and saw usage near 1M monthly actives when I left Google a couple years ago. I'm sure it's up since then.
There are 10s of millions of web developers in the world. Doesn't shock me that Flutter could be over 1M monthly (and probably several million annually).
There are just a lot of apps and app devs out there.
[0] https://flutter.dev/showcase/bytedance
My knowledge of their usage is from discussions with ByteDance some many years ago when I was in charge of the Flutter project at Google. At the time they were using Flutter in 50+ applications (probably most of them internal), including Douyin (TikTok for China) as well as physical hardware kiosks on their campus, web apps, etc.
https://flutter.dev/showcase/bytedance
[0] https://douyin.en.uptodown.com/android/download/87248716
[1] https://github.com/flutter/flutter/issues/11884 - click on the search button in Douyin on the main page and search for something to get to a regular ScrollView. You don't need an account for this.
I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally.
I refuse to sideload arbitrary APKs, especially from bytedance. I feel bad because that is irrational, you did, and it'd be really helpful if I did and just did this myself, but, you should install FlutterShark and check: https://play.google.com/store/apps/details?id=com.fluttersha...
Why is "bug" in scare quotes here? It was most definitely a bug.
>I wouldn't say its unlikely they carried a patch for it, I just wrote a framework patch that I apply at build time in CI and locally.
The actual fix was pretty involved. I doubt a large company like Bytedance would want to carry around extra patches at the gesture level that make the dev cycle more difficult. Having one person carry a patch on their local machine is a different story.
Anyway, the Bytedance blogpost says only 200 devs are using Flutter which would make no sense if it was used in Douyin, and LibChecker[0] returns no results for libflutter.so.
[0] https://github.com/LibChecker/LibChecker
Is it? I thought it was cool, I can't think of why its disruptive to scroll a list faster if you scroll with more fingers.
> I doubt a large company like Bytedance would want to carry around extra patches at the gesture level
I'm a solo endeavour, and I spent ~30 minutes to do exactly this (patch gesture behavior) two days ago. I was stunned how easy it is. But I grew up on versioned closed source dependencies on Apple iOS frameworks that you had to patch the runtime at runtime to fix, so I'm easily wowed.
> 200 devs are using Flutter which would make no sense if it was used in Douyin
Seems reductive: "Only" 200 fulltime, 800 in the company...and we're in a discussion about how 50 maintain _the entire framework_. :)
Hard to say it is "everywhere". It's probably more popular than any of the other cross platform alternatives though.
>android.permission.QUERY_ALL_PACKAGES
>com.google.android.gms.permission.AD_ID
>android.permission.ACCESS_NETWORK_STATE
>android.permission.WAKE_LOCK
>android.permission.FOREGROUND_SERVICE
seems like imo the type of thing you should be prompted for but what do I know
They finally added a permission for it - QUERY_ALL_PACKAGES - in Android 11 (2020). Unfortunately it's one of those stupid permissions like filesystem access where you have to apply for it via a form, and only whitelisted use cases are allowed:
> Permitted uses involve apps that must discover any and all installed apps on the device, for awareness or interoperability purposes may have eligibility for the permission. Permitted uses include device search, antivirus apps, file managers and browsers.
I suppose that situation is slightly better than "anyone can do it for any reason".
- 5 years using Flutter - 31 full-time devs - 3 platforms (iOS, Android, and Web) - 1.3 million monthly active users
Overall, we’re very happy with our decision to use Flutter
That said, I literally only use Flutter as a hobbyist.
I made a basic web game for a friend, and a small web app that helps me manage my music lyric videos. I ultimately picked Flutter because I find it easier than actually building websites.
Dart is amazing.
But I'm not deploying to millions of users. At most 10 people have seen my Flutter apps.
It's VERY good for creating quick crud apps with Firebase.
Just counting the number of us who have it installed and might of spun up hello world says nothing about it's actual market share.
To be clear, I absolutely love Flutter, but it's still not something I really see job listings for.
Dart is great too BTW.
I bet they'd mean a bit more if it wasn't coupled to a lengthy thinking-out-loud post that casts doubt on it, based on how many job listings you see, for something you don't look for job listings for.
Quick Google shows Dart 10th, right below SQL, right above Kotlin. https://www.devjobsscanner.com/blog/top-8-most-demanded-prog...
I've been hearing about Kotlin multiplatform just as long as flutter, and writing Kotlin since 2019.
Kotlin is a horrible daily driver.
I worked on Android for Google at 7 years, and maybe it'd have a better chance if it didn't win internally. As it stands, there's too many organizational boundaries created, and each organization holds itself accountable only within itself, so it's sort of the worst of all worlds, impedance mismatches everywhere, and nobodys fault they exist
I'm always stunned to read wish casting about Kotlin because there's ~0 path to even basic things that change productivity dramatically, like hot reload.
C# , NodeJS, Python and rarely Java( had a rough year), pay my bills.
Flutter/Dart doesn't. If you know someone hiring a Flutter developer I'm 100% down to interview.
I don't hate Kotlin, it feels like Google's answer to Swift( although Java was never as hard as Objective C). I even built a small project with it.
Can we at least agree it's weird Google is trying to promote 2 different languages for multiplatform development?
Let me compare Unity to Flutter for a bit. When Unity jobs are hard to come by, I'm still an OK C# dev.
Flutter/Dart doesn't offer they same freedom. Say what you want about Microsoft, but C# can essentially do anything. Including keeping me employed.
Re: multiple frameworks, I worked at Google and would argue I know as much as anyone does exactly what happened there, so I can't agree it's weird, per se. Handwaving, I'd say that's because the situation seems more 'certain' or 'settled' to me, for good reasons, but ones not worth getting into.
There's absolutely tons of threads to unpack in your comment, I wish we were in person.
Speaking generally, based on observation you gravitated most towards discussing qualities of a job one might or might not get:
I essentially left my job at Google for no paycheck, partially because Google x Koyaanisqatsi, partially because I just couldn't imagine having to go back to write Kotlin and/or Java day to day and being criticized either way. That being said, it's deflating seeing Flutter job listings after getting into this whole industry from iOS dev. Thing with Flutter jobs is there's tons of low priced job seeking competition that are smart as hell.
That's because it is unusually effective in environments where people can't afford a Macbook only for iOS dev, and at this point in its lifecycle, it self selects for people who get experience with new frameworks
Java just feels like a less refined C# to me, but I'd be fine with it if offered a FAANG job.
I've tried to learn C++ too since I think I'd open up some job opportunities, but it's just too hard for me.
So who won, Kotlin or Flutter ?
From your last paragraph, I take your prefer to work as a Flutter dev all else(pay) being equal?
You have the wrong order: JetBrains created Kotlin[1], and anything Google had to do with it was just adopting their language. Same story for Gradle choosing it over Groovy
1: https://github.com/JetBrains/kotlin
Google doesn’t promote anything. There are two competing teams with their own agendas. Flutter’s bills are mostly paid by internal usage, as far as I know. Android is mainly focused on Android part of Compose.
Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter’s lunch and promote Kotlin usage to drive their IDE sales.
> Let me compare Unity to Flutter for a bit. When Unity jobs are hard to come by, I'm still an OK C# dev. Flutter/Dart doesn't offer they same freedom. Say what you want about Microsoft, but C# can essentially do anything. Including keeping me employed.
I might be wrong, as I’ve worked with .Net professionally, but I doubt you can jump from Senior Unity C# developer to Senior Asp.Net developer. Language is a small part in modern development.
I'm not exactly senior to senior, but I hopped from mid level hobbyist Unity dev to professional Unity dev , to mid level .net dev. I have a very specific niche though.
I'm very comfortable with my career.
>Multiplatform Compose, on the other hand, is mostly pushed by JetBrains to eat some of Flutter’s lunch and promote Kotlin usage to drive their IDE sales.
Android Studio is free ? Are they really making that much money off users using Kotlin outside of Android Studio ?
They even have Ktor (Kotlin web framework) plugin available only in Ultimate. For any non-trivial Kotlin development you need to have Ultimate.
That is so stunningly false that I am pretty sure I'm feeding the trolls: https://github.com/JetBrains/intellij-community/blob/idea/24... (Apache 2)
That may sound more useful than it is: think "oh I can specify a dummy title and subtitle for a list view cell in code, then open a special pane in the ide to preview a source file, and then resize the window to imitate different screen sizes!", not, oh there's a bug, fix, save, insta-reload, verified fix. No holistic screens, or loading info from a database, or mutating data.
I assume this is an extremely hard problem. I remember trying to get Obj-C hot reload working 15 years ago and it kinda half-worked some of the time. And its not like I can edit the C++ my Flutter app is linking against and get instareload.
But still, it's one of the things thats easy to point out and drives home that these once-a-decade-or-two frameworks started in response to React Native/Flutter aren't addressing the fundamentals of what made them a sea change. Industry is risk averse and we make too many decisions similar to staying on track to launch MacOS 9.110 in 2024, instead of biting the bullet to get OS X done.
For Flutter to have fully landed it, it would take more than just hot reload. I'm not familiar with the latest but what are the chances of the Flutter rendering stack "going native" (as in not drawing to a Skia canvas or similar) on at least Chrome or Android? Or, is that the wrong question?
Good question -- I don't think its the wrong question? Maybe? :P Tough to phrase on my end too.
I only feel native speaking in iOS or Flutter, even with the Android experience, forgive me: I guess I'd summarize it as "yeah, you're right. if you're wondering if they're ex. calling CoreGraphics on iOS, no" (well, they do, but for text rendering. Not for a red rectangle)
Generally, Flutter Web is rendering into a WebGL surface using Skia -> WASM (2.2 MB download! modern miracle). macOS, iOS, (done) Android (soon) are switching from Skia to Impeller. I think the thrust of your question is "are they still bundling the render engine?" and the answer is yes.
I find the way you phrased it intriguing, in that, before reading your post I'd say drawing to a Skia canvas is as native as you can get. But I realize now that means I was overindexing on "close to the metal", and its apex not-native to say "gimme the framebuffer and i'll take it from there"
I'm a bit picky with design stuff and I loooooove that Skia's bundled and I can rely on it cross platform
Killed the framework for good, true. No pattern matching, joke destructuring, static delegation, reliance on Gradle (puke).
I don’t understand how Dart still has bad reputation when it leapfrogged this joke of a language long time ago.
I was genuinely interested in your thoughts, "you wouldn't understand it, but trust me" is deeply unhelpful.
Glad you found it useful.
Did you really just thank the guy for saying thanks, but give him a big fuck you in the same breath for not being a 100% kool-aid drinker?
Speechless.
My point was you just can't count SDK downloads as developers. Is every CI/CD pipeline a developer ? The founder of Flutter who posted that stat has a startup which is heavily invested in the perception of Flutter being popular.
In the Unity community we aren't afraid to critique Unity and even suggest trying other engines. Of course Unity isn't open source so you don't get articles like this where someone claims it's time to fork.
At the same time, Unity uses C#, so you can take your skills, and even some nuget packages( with a bit of work) elsewhere if you want to switch.
Flutter requires a higher time commitment since I have to learn a language that's exclusive to Flutter. If this ship goes down I can't use Dart with anything else.
Anyway, I think job postings are a much better metric of adoption. I like Flutter, I've used it for 4 years and I want it to succeed. I don't want to go back to react native!
I'm guess I'm capable of being curious and engaging in conversation, beyond sitting in the bleachers grading everyone on my scale that at 100% is "koolaid drinker.", depending on if I feel like the things they're talking about are on Team A or Team B I've identified.
Then again, that perspective would sort of come naturally if I were reading hysterics into every comment I read. "Big fuck you" is textbook catastrophizing.
Some relevant data:
- Over 165K GH stars
- Over 140K subredditers
- Over 500K YouTube subscribers
The 1M estimate is at least ballpark accurate.
https://pldb.io/concepts/flutter.html
I don’t sub him on YouTube - but I’m not lying when I say everyone I know IRL who does sub his channel has worked as a barista at some point in their lives (…and purchase actual chemical-lab supplies for their coffee brews).
I think companies using it for commercial purposes (like what we're doing) should contribute something to the effort to help make sure Flutter not only survives, but flourishes.
Bug bounties, supporting individual developers, supporting efforts and initiatives, professional services, or any other way that helps the project move forward will be great.
How does it compare to React Native from user and developer experience perspectives? Are there other competitors?
I'm not qualified to give an in depth review/comparison, however.
Edit: we use flutter to build an app which runs on iOS, Android, macOS, Windows and Linux -- the same code base with pretty minor adaptations to desktop vs mobile and different screen sizes.
The experience has so far been fantastic. It's fast, it's relatively light weight, it's performant, it's a pleasure and we couldn't imagine doing it any other way.
https://webostv.developer.lge.com/news/2024-07-15-new-and-su...
> Most of our apps use React. When we first adopted React, we were pleased with the development productivity it provided, but sadly its initial performance was subpar in terms of start-up time, memory consumption, and responsiveness. After significant and complicated optimizations we reached performance benchmarks that were good enough, and yet we desired a new technology that was both fast and simple.
> To our delight, our very first prototype with Flutter easily exceeded our target benchmarks! Without any optimization whatsoever, our Flutter rewrite launched twice as fast as our original app, consumed less runtime memory, and felt more responsive and playful to use
But React Native is different , JS code compiled to native code using c/c++ compiler on target system. Flutter also do like this one.
Embedded browser is slower than native app, because extra browser layer than native one.
Sure, but you're compiling two radically different languages. JavaScript is dynamically typed (even with TypeScript) and Dart has a sound static type system.
It's much easier to compile Dart to efficient native code than it is JavaScript.
NativeScript
The developer experience was great and the Flutter team was very responsive with questions I asked.
The other xplat framework same as Flutter:
- React Native
- Kotlin Multiplatform
- NET MAUI
- NativeScript
- Slint
For one, I'd recommend adding a newsletter field to the website/blog, simply so those who may not want to test or participate right away can stay in the loop. More importantly though, the two links asking for reviewers and leads just link to a private Eggs account, which, even before someone decided it was a good idea to just make content appear in an unsorted manner (random post from 2023, then 2021, then 2024, then 2020, ...), has never been an ideal approach for such projects in my opinion. I honestly thought I had clicked on the wrong links when two eggs profiles appeared in new tabs.
Forcing potential devs to create a third-party account on a social media site, then send in DMs is likely not the best way to get such a major project of the ground and having public repos or at least a contact form set up would go a long way, especially since that also makes it easier to enforce some ruleset for applications.
Additionally, consider listing what changes have been implemented in Flock at this stage. As it stands, it appears impossible to easily tell what one can expect without diving into the changes [0] one-by-one.
Still, wishing you the best as Flutters development and approach to both what goes into which branch, as well as keeping up-to-date with UI elements in target OSs has been leaving a lot to be desired to say the least. I still feel that, despite all shortcomings, for certain applications and workflows, Flutter/Dart remains the best, and it would be a shame to see it unmaintained.
[0] https://github.com/flutter/flutter/compare/master...Flutter-...
Flutter was a company acquired ala Firebase? Always thought it was a project (like Golang) incubated by/for/at Google.
https://dictionary.cambridge.org/dictionary/english/founder (n)
If "only" 50 people working on a project used by one million people was unworkably low then every single successful project out there would be doomed. I've certainly worked on things with much worse ratios than that.
> one has to critically assess why a team that loves external contributions has only managed to merge contributions from 1,500 developers over a span of nearly a decade.
External contributions from 1500 developers over a decade is a lot. That is an unusually high number, not a low one, and backs up Flutter's claim to love external contributions.
The fact that this person thinks that they can just magically conjure up dozens of volunteer PR reviewers is wild. Everything about this post makes it pretty clear that they don't have the slightest clue of the scope of what they're trying to do. This feels like one of the standard examples of an ex-bigco person setting off on their own with no understanding how just how much the bigco did in the background to facilitate their job.
They're slightly different things (as the post notes, the bigger number includes copy editors), but still…
Yeah, we had to make changes, some changes to FreeBSD too, but mostly little changes here and there. Erlang and FreeBSD were both lovely to work on.
Re the sibling's question about what was changed, I don't remember everything, Rick Reed's presentations at Erlang Factory / Elixir describe most of them though (although those ended in 2014, I think). Many or most of the changes got into upstream one way or another. But most of it were things because AFAIK, we had much larger Erlang clusters than the rest of the community; I remember seeing advice about large clusters of 50 when we were running 300 nodes in a cluster, and I'm pretty sure we had dist clusters above 1000 later when we also had separate cross cluster messaging. We also had huge mnesia tables, other people said don't use mnesia over 2GB, and we had nodes with more than 512GB of data in mnesia. I don't really remember much that we had to do with dist, although pg2 needed help and our replacement became pg in OTP, mnesia did need some help to scale. We changed the ETS hash kernel to avoid everything hashing the same way, I don't know if that made it out.
We also needed to do things like timer wheel improvements, but OTP also did timer wheel improvements and we dropped ours. Not so many people were running quite so many timers.
Then there were things that I don't think are upstreamable. Adding a way to drop a process's message queue. Adding a way to add a message to the front of a process's message queue. Those two are very not in line with OTP, but handy for operations if you use them carefully.
https://news.ycombinator.com/item?id=39447564
Suppose Flutter may be an order or two magnitude more complex than cURL.
Which boils down to: Number of devs vs. people using something is a very bad metric. Even number of supported devices won't work good in this case (I assume cURL runs basically everywhere).
I think it's very difficult to estimate complexity, and then make a statement about "how many people are enough" is even more difficult. Some environments are harder and more complex, some are just very heterogen and some are both. Sometimes it's the organizational overhead, maybe even something else.
plus they said an "order or two" which would be 10-100x so ...
Same goes for a lot of programming languages like Go: a pretty small core, the rest is external contributions. And they have to support all sorts of platforms/configurations as well (probably more than Flutter does).
[0] https://pythondev.readthedocs.io/core_devs.html
What sets professional Python aside from most other programming languages is that everyone who uses it knows that it’s terrible and how to deal with that. Which will sometimes be replacing parts (or all) or it.
To say that it’s inherently less performant than JS is frankly silly though.
CPython really is inherently less performant than V8. CPython, until very recently, didn't have a JIT at all. It compiles scripts to bytecode, then runs the bytecode in a giant case statement. It doesn't have a tracing profiler-guided optimizer or an exotic garbage collector. CPython is way, way simpler than V8, but it's consequently slower. It's just the consequence of Google putting centuries of developer-years into an engine.
You can't just claim Python is fast because Python's C libraries are fast. Those libraries are fast despite Python. Torch is extremely fast, but it's fast from C and Lua too. There's valid reasons to want to compute in your programming language. Python is, ironically, probably popular because its slow speed encouraged users to write blazing fast C libraries rather than even try writing native Python, vs. settling for middling performance as in Java or .NET.
I shouldn't have to get out my hammer and tongs when NumPy doesn't implement the operator I need. Why can't Python be fast like Julia?
Python 3.13.0: 799.6559143066406 ms
Node 18.20.4: 59.34080000221729 ms
Shouldn't developers be the most self-reliant users possible, especially when working with open-source tools? That is, shouldn't we expect that when a developer has a problem, they dive into the code and figure it out on their own?
Developers are support intense because dev tools and platforms get used in a bazillion ways and combinations you can't predict. It's not like a nice consumer app where the user can only press a limited combination of buttons, and test coverage can be quite exhaustive. GUI toolkits are especially a bottomless pit of edge cases and bugs because they have tens of thousands of API methods, enormous numbers of features, they can all be used in combination, they have to run on multiple platforms usually and those platforms also have bugs etc. The support costs of a GUI toolkit are basically unbounded.
But reading that post I couldn’t help but shake the feeling that there might be other non disclosed reasons for the fork because some of the ones he did give as you pointed out didn’t make a lot of sense to me either.
There is no guarantee these 50 devs can actually focus on Flutter, instead they might get looped in in the internal race to AI products.
I’ve never actually come across a better maintained project personally. It is incredibly thoughtfully developed with a high level of attention to detail who have successfully shipped a huge number of major improvements in ways that made sense.
There is a premise in the post that implies Flutter is poorly maintained and that’s just not a commonly held belief by the community at all.
As I hinted to in another comment the particular person behind this is a bit of an oddball and I think there may be other reasons that drove this decision in the first place in addition to the ones he gave in the post which for the record I’m sure there are some things he wishes were prioritised differently but this fork seems kind of very “him” rather than a popular position that people were begging for.
Billions per HOUR seems quite a stretch there..
Unless you're discussing background processes on google's side
You may not get a notification every hour, but the phone still have to connect to Google APIs to check to know that.
You can say same thing about say location services, every phone if powered and connected to the internet would ping more than one an hour, more than billion devices are definitely online at any give time, not just Android phones, also every android TV, tablet, watch, and the hundreds if not thousands of other devices running GMS on top of AOSP .
There are probably few other APIs in GMS that would ping at least once an hour each device that is powered on, perhaps things like NTP for timing alerts or Emergency Alerts etc.
You may consider them "Background Services" , most of them however have some foreground UI if they need to, and users will notice if they don't work
Something like DNS or BGP is going to have a tiny team and a huge impact. Load balancers probably has a bigger team, maybe 10-20 engineers, and almost everything goes through load balancers. And that's just the things that are easy to enumerate. I can think of lots of small teams when I was at Yahoo that worked on bits of software that are hard to explain, but were critical.
I’d put “person who makes sure WhatsApp verification codes work” on that list.
Thanks! That part of my job really wasn't too hard though, once I got things in order; but it was the easiest part of my job to describe. Just a lot of debugging from sparse data, and trying to get things to work a smidge better, because smidges here and there add up. It really helped to have a great customer service team that bubbled up usable information from users.
Debugging things from sparse data gets you involved in a lot of different systems though... That and I told people I worked at an ISP in the before times, so guess who got to fight with sendmail, and guess who got to own our Domain accounts and DNS accounts and guess who got to get x.509 certificates, and who had to fight with Google Apps to make mandatory 2fa usable, etc. Basically everything without a person and server adjacent got me. :P
Anyway, I've moved on (replaced by a team of three on the SMS stuff amyway, much better bus factor) and am semi-retired and no longer in any critical path, which is a lot less stress.
And even if happens - changes can't be merged without thorough and careful review. So who's do the reviews when supposedly there are too many contributors? Only someone who fully understands that particular subsystem.
Which means we're back to square one because as per post there are only three subject matter experts available for the new fork.
If everything the article says is true, should I switch to Kotlin?
I see a lot of negative comments but I think this will be a net positive over time to the Flutter community and to the technology itself. I think it will also give Google a reality check on the needs of the community.
Can you make any comment on this? Is it accurate?
Is it time for HN to finally support Slack-style emojis?
I'm almost positive you, personally, could implement support for those emoji short codes via Violentmonkey
The constant question of big tech OSS is who is it for/why does it exist? Did they make this because they think it's a useful tool internally, or are they trying to build a platform for external developers? If they built it because it's internally useful, then it's probably open-sourced for cultural reasons (the people working on it are used to being in open source communities and want to share what they're working on).
Unless something is specifically being made as a platform for external developers (Android and Firebase come to mind), the level of support you'll get is at the whims of the team's current product leadership and budget. Both of those things change over time - a product manager can always say "let's focus on internal developers" and put the external community in maintenance mode. Based on the article's mention of desktop support being deprioritized, this might have happened on Flutter.
Big tech funds things that would be really hard to pull off with just volunteers, but big tech projects can also be victims to the capriciousness of corporate politics and budgeting.
NodeJS went through something similar. It was tightly controlled by a single company (Joyent) who were juggling too many balls, and progress went slowly. Community people did a fork (io.js) which shipped improvements faster, but they did so in a careful non-shitty way. This made lots of people switch to io.js, so that eventually NodeJS merged with io.js (iirc they just renamed the latest io.js "NodeJS").
I don't know of any other instances of community forks of company-controlled OSS that did something similar though. If this is just one guy who made a blog post, like a sibling comment suggests it might be, then it might not pan out this way.
Back when I worked on .net we had fewer than 50 people maintaining a product that shipped to over a billion machines. If you opened an issue on github we'd usually reply that day.
It's getting a bit long in the tooth, but I feel like 'the mythical man month' should still be required reading for software devs. More devs != better.
The constant pressure to ship new features instead of only widely desired features overtaxes a team quickly.
That's still plenty of people if you got a few thousand people at AWS/Azure or in this case Meta's in-house cloud making sure your service is running and scaling as it should.
Once the project already exists, is largely feature-complete, and is mostly in the "fixing bugs and small annoyances" phase, then Linus's Law [1] takes over. Debugging is very much parallelizable, because you can generally fix the bug without generating major impact elsewhere in the codebase, and if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
[1] https://en.wikipedia.org/wiki/Linus%27s_law
That may be a reachable state for a command-line oriented operating system itself a clone of an older operating system, but is likely unrealizable in any sort of system that is trying to be actively more innovative.
> mostly in the "fixing bugs and small annoyances" phase
I don't know of any UI framework that has had the luxury of ever reaching that phase.
> then Linus's Law [1] takes over.
If you maintain a widely used framework, I think the more meaningful eponymous law is Hyrum's: https://www.hyrumslaw.com/
This is probably the #1 source of friction for contributing to Flutter. It's not that the Flutter developers are overworked killjoys who don't value external contributors. It's that when, as the author of the blog post says, your codebase has a million users, it's really hard for a contribution to not end up breaking someone.
> if you have a good test suite you'll know if your fix has broken other invariants elsewhere.
Sure, but the fix itself will still need tests. So now you've got to walk the contributor through the process of writing tests which is definitely not a skill that most software engineers have and is not particularly rewarding for an external contributor who already has a working fix and just wants their patch to be "done".
Fundamentally, coordinating thousands of people to make a single codebase used by millions of people is hard. There is no silver bullet. It's a miracle it works at all.
It's probably less actively harmful than new product development, but I'd still say a team of 50 is probably larger than is necessary for the amount of usage flutter gets.
It depends on an org's priorities and what gets put on someone's reviews.
During one of the years when I worked on Windows Mobile (before Windows Phone!) we had an objective handed down from on high that we were to spend so many hours a week on customer support forums helping people out.
Well, for that year, customers all around the web got great support right from engineers! I got to paste lots of positive feedback from end users in to my yearly review, and I felt great about it!
If Google cared about supporting Flutter as an Open Source project, they'd make the health of the open source project one of the measurements going into employee reviews at the end of the year.
Historically when MS was filled with software nerds, the fastest way was to post on an online forum!
Sadly those days seem long gone. It doesn't feel like Microsoft empowers employees to really reach out and help customers anymore.
I do remember responding to those Tier One support contract requests. IMHO that was a better system than what the large tech companies do now, which is basically just ignore customers no matter what.
That’s still very much the case today, BUT you absolutely need to do your legwork beforehand (e.g. include a copypastable program that reproduces the problem and as thorough an analysis as you can do) otherwise your thread will go poorly… (and plenty of regulars in the dotnet repos aren’t exactly the forgiving type). Compare that to what you get with a Support contract: you can be a non-technical person in Sales or the C-Suite or whatever and they’ll hold-your-hand to guide you through the troubleshooting/diagnosis/repro process - and if the issue is an actual bug in MS’ code then at least you get your ticket’s fee/credits refunded.
———-
Unrelated-but-related: An LLM+multimodal “AI” would be fantastic for walking nontechnical users through the issue-reporting process. I’d wager the number-one problem in tech-support today is dealing with “It doesn’t work”-type tickets which necessitates having to interrogate the user/customer/victim to get the details out - but if an AI agent (with screen-reading abilities) handles that (without a single audible sigh or facepalm) then that’s a win for everyone.
…now if only StackOverflow had that.
Was created for flock?
This seems less of a fork and more of an attempted annex
It’s going down the same path unfortunately as Flutter did.
Microsoft has de-staffed and deprioritized Xamarin/Maui to a point most of the folks are in Aspire-dotnet and related efforts?
https://twitter.com/migueldeicaza/status/1778759403451081159
Not gonna lie though: building the UI twice for both iOS and Android feels somewhat masochistic. But in the end, it "just works" with shared View/ViewModel logic on both platforms.
Seems like:
- guy wants to add PR more aggressively to a code base than Flutter currently is
- isn’t clear if they have a concept of handling compatibility between fork and original
- why not be a labor organizing entity and work with the flutter team?
Some of the PR that I am aware of that are stale and could be good candidates - are difficult design decisions and stakes need to be put in the group.
It seems ill advised. This is huge amount of work with limited upside and huge downside (adding uncertainty to outsiders looking in) and tons of effort (just in infrastructure maintenance).
Edit: if I were conspiracy oriented I would think it’s to harm community. I would pay this no mind.
>why not be a labor organizing entity and work with the flutter team?
Depends on the maintainers/team. I've definitely seen many a bureaucracy that slows down FOSS to a crawl of bug fixes and feature progression. If you make enough PRs that are ignored for weeks or months, you'll realize this isn't really a team ready for nor interested in a proper FOSS environment and it's instead mostly "that teams code that happens to be readable".
Their official answer seems to suggest as much:
>But, sadly, trying to work with the Flutter team delivers a different reality. While some developers have had success working with the Flutter team, many other developers have found it frustrating, if not unworkable.
I guess we'll see. I'm way more of the mentality of "actions speak louder" so I'm not really one to announce my plans until I get something worthwhile off the ground (in this case, a few stale PR's that feel like game changers to the customers). But that's not a mentality modern social media rewards.
I think this is an emotional reaction from someone has never managed a large project. Merging PRs and releasing them isn’t the problem. I hope they understand that.
Flutter is amazing. Web, desktop and mobile that actually work is nearly magical. Yes there are priorities. Yes the desktop isn’t as high priority of web. It does work. Hell. Collect money and fund Hixie or others to prioritize patches community feel should go in. That is constructive and methodical/reproducible.
Forking a massive code base, applying PR and not conforming to the source repo standards (tests whether that is golden or not) - just seems not well thought out.
I think community could fund a well known developer to fix desktop issues and have PR adhere to Flutter standards. It’s a ton of work. But seems like it’s a money/dev/process issue. Not a PR merging exercise.
I only see a single name?
Is this just some dude with a blog?
The SQLite developers must find this rationale hilarious.
I'd love to see some examples. I've had my pull request merged in a fairly quick amount of time - less than one release cycle, which is what matters here.
Also frankly, nobody forking Flutter will be nearly skilled enough to work on the Flutter engine (Impeller). So it's hard to take this announcement seriously.
For me its so weird they ditched google/skia to develop Impeller in Dart from scratch in the first place. If skia was not ready they could move just 1-2 developers to Skia team to collaborate with them. Now they want to even write their own 3d rendering lib based on Impeller (flutter_gpu, flutter_scene) even thought google has already mature 3d engine in C++ (google/filament). For me from the outside looks like "not envented in our team" syndrome. We are now in funny situation that react native has react-native-skia and react-native-filament and Flutter teams reinvents the wheels.
Some related iOS jank issues from that time: https://github.com/flutter/flutter/issues/32170 https://github.com/flutter/flutter/issues/61450
Seems like most issues could be solved with new Skia graphite backend
https://skia.org/docs/user/build/
https://gn.googlesource.com/gn
[0] https://github.com/nmfisher/thermion
I expect there will be some communication from Google at some point and the foundation will have to be renamed. It reminds me of OpenTF being renamed to OpenTofu.