Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're forking Flutter

flutterfoundation.dev

Post reply on HN
Print view View original

171–180 of 748 posts

Re: We're forking Flutter

#171

Post by gman83 »

ignoramous wrote: post #146
eseidel wrote: post #51

Earlier quoted context omitted.

Flutter Founder here. If you ever have any concerns re: Flutter, please don't ever hesitate to reach out. eric@shorebird.dev

> Flutter Founder here. Flutter was a company acquired ala Firebase? Always thought it was a project (like Golang) incubated by/for/at Google.

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.

Re: We're forking Flutter

#172

Post by ibero »

| How many Flutter developers exist in the world, today? My guess is that it's on the order of 1,000,000 developers. The real number is probably higher, but one million should be reasonably conservative.

one million flutter developers? that does not make sense to me at all (by orders of magnitude). does anyone know any metric to validate this? i am shocked if it's true.

Re: We're forking Flutter

#173

Post by [deleted] »

plorkyeran wrote: post #21

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

[deleted]

Re: We're forking Flutter

#174

Post by munchler »

> The team can't fix the bug without information from me, and it's been too long for me to provide information to the team.

Ugh. I feel like developers should already know this, but I guess not: If at all possible, please, please, please include a solid reproduction case when reporting bugs. That way you don’t have to remember anything about it. (This is also pretty much the only way you can be certain that the problem isn't actually due to your own error/misunderstanding.)

Re: We're forking Flutter

#175

Post by divan »

1propionyl wrote: post #144
divan wrote: post #141

Earlier quoted context omitted.

> Just build native UIs Do you see any reasons why many companies/teams/devs don't want to "just build native UIs" and instead are looking for cross-platform solutions designed from ground apps for modern UI development needs?

Yeah I do see why they don't want to do it and I see it as a critical failure of risk management. If you think pinning your entire product on a cross platform UI kit when every single one (except maybe QT) had proven a failure... then yeah I think maybe you should consider actually just eating the cost of building native UIs. The risk analysis of building against supposed cross platform "solutions" just doesn't work…

> and I see it as a critical failure of risk management.

I also want to live in the world where risk management is the only variable that determines how CTOs and devs choose the stack for the software.

Re: We're forking Flutter

#176

Post by mdhb »

LauraMedia wrote: post #163
plorkyeran wrote: post #21

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

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.

Re: We're forking Flutter

#177

Post by pzo »

xster wrote: post #166
pzo wrote: post #66

> How large is the Flutter team, today? Google doesn't publish this information, but my guess is that the team is about 50 people strong. I doubt google have even 50 flutter devs in their team. You can easily estimate by checking github pulse: https://github.com/flutter/flutter/pulse/monthly https://github.com/flutter/engine/pulse/monthly Also take into account inflated commits by CI bots: engine-flutter-autoroll, sk…

https://ln.hixie.ch/?start=1714717681&count=1 is a sensible estimation

Actions (commits) speak better than words for me - flutter managers like (kevmoo) that are responsible for PR what gonna say? Probably you not gonna hear form them "Sorry we had layoffs and unfortunately our team is to small to handle all issues for now" Same with previous google employees that are still invested in flutter ecosystems by launching commercial products around it even if not at google anymore.

Re: We're forking Flutter

#178

Post by baueric »

mvac wrote: post #4

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…

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.

Re: We're forking Flutter

#179

Post by maxrmk »

com2kid wrote: post #154
maxrmk wrote: post #30

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

> 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 w…

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.

Re: We're forking Flutter

#180

Post by briandear »

Really not a fan of the flutter concept. “One codebase?” Ok, so how does that make a great iOS app that takes advantage of the full device? Basically coding to the least common denominator.

Hire a Swift person. Hire an Android person, and build things in a way that gets the most of of the device. Otherwise, what’s the point of an “app” in the first place. Can use a website if “one codebase” is a goal.

Post reply on HN