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