6 ms·

> 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 th

> 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.

bsimpson 2y ago
It struck me that they estimate that the number of qualified contributors is 1000, but the number _so far_ is 1500. They're slightly different things (as the post notes, the bigger number includes copy editors), but still…
kgeist 2y ago
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.
johnnyanmac 2y ago
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.
- adamc 2y ago
  Even though they didn't say, that was my assumption. Why would they bother, otherwise? And that's not wrong.
giancarlostoro 2y ago
WhatsApp had less than 50 engineers (or was it employees total?) when Facebook bought them out, and they had millions of users.
- droideqa 2y ago
  The power of Erlang.
  - zerr 2y ago
    Modified Erlang. Genuine one didn't scale.
    - mg74 2y ago
      How so? Is there anything on what changes they made to Erlang/BEAM?
      - bhaney 2y ago
        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.
        mg74 2y ago
        Thank you
    - toast0 2y ago
      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.
igorguerrero 2y ago
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.
- mike_hearn 2y ago
  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.
  - mwcampbell 2y ago
    > 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?
    - exe34 2y ago
      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.
    - mike_hearn 2y ago
      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.
mdhb 2y ago
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.
LauraMedia 2y ago
I generally agree, the fact that the project relies on Google's internal steering is the much bigger factor in this to me. 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.
- mdhb 2y ago
  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.
deleted 2y ago
[deleted]
fhdsgbbcaA 2y ago
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.
- EGreg 2y ago
  Exaggeration? Billions per HOUR seems quite a stretch there..
  - fhdsgbbcaA 2y ago
    Nope.
    - EGreg 2y ago
      Link to proof?
      - fhdsgbbcaA 2y ago
        Can’t, but not sure why that’s hard to believe?
        EGreg 2y ago
        Because billions of people or their devices aren't even online every hour. Unless you're discussing background processes on google's side
        manquer 2y ago
        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
deleted 2y ago
[deleted]
wg0 2y ago
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.
iamleppert 2y ago
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.
- sulam 2y ago
  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.

bsimpson 2y ago

It struck me that they estimate that the number of qualified contributors is 1000, but the number _so far_ is 1500. They're slightly different things (as the post notes, the bigger number includes copy editors), but still…

kgeist 2y ago

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.

johnnyanmac 2y ago

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.

adamc 2y ago
Even though they didn't say, that was my assumption. Why would they bother, otherwise? And that's not wrong.

giancarlostoro 2y ago

WhatsApp had less than 50 engineers (or was it employees total?) when Facebook bought them out, and they had millions of users.

droideqa 2y ago
The power of Erlang.
- zerr 2y ago
  Modified Erlang. Genuine one didn't scale.
  - mg74 2y ago
    How so? Is there anything on what changes they made to Erlang/BEAM?
    - bhaney 2y ago
      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.
      - mg74 2y ago
        Thank you
  - toast0 2y ago
    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.

igorguerrero 2y ago

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.

mike_hearn 2y ago
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.
- mwcampbell 2y ago
  > 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?
  - exe34 2y ago
    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.
  - mike_hearn 2y ago
    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.

mdhb 2y ago

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.

LauraMedia 2y ago

I generally agree, the fact that the project relies on Google's internal steering is the much bigger factor in this to me. 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.

mdhb 2y ago
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.

deleted 2y ago

[deleted]

fhdsgbbcaA 2y ago

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.

EGreg 2y ago
Exaggeration? Billions per HOUR seems quite a stretch there..
- fhdsgbbcaA 2y ago
  Nope.
  - EGreg 2y ago
    Link to proof?
    - fhdsgbbcaA 2y ago
      Can’t, but not sure why that’s hard to believe?
      - EGreg 2y ago
        Because billions of people or their devices aren't even online every hour. Unless you're discussing background processes on google's side
        manquer 2y ago
        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

deleted 2y ago

[deleted]

wg0 2y ago

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.

iamleppert 2y ago

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.

sulam 2y ago
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.