Google's reputation for not supporting things long term is finally starting to affect them in noticeable ways.
Developers didn't onboard because they were afraid it would get shut down. It got shut down because no one onboarded.
Developers didn't onboard because they were afraid it would get shut down. It got shut down because no one onboarded.
I seriously thought about it but ended up scoring an Xbox and game pass and my main reason was I have to buy the games at full price for Stadia and google will deffo shut it down sooner rather than later so too risky.
Game pass is amazing for someone who isn’t a hardcore call of duty type gamer! I’ve been away from gaming since playing tiger woods on the OG Xbox so being able to play so many different types of games is awesome.
I like forza horizons!
Even if some people are kind of used to this happening, stating it more obviously might have a negative effect just as well.
And then if you need to and don't want to refund, just keep the service limping along for 5 more years.
If the terms Google had were "we'll sell licenses for your games, but if we shoot down then you have to accept those users as native users", then uses would have been insured against shut-down. I can't see how those terms are worse than if Google were a retailer of those games?
A lot of AAA games are freemium with IAP, surely the acquisition is Cannondale enough that game companies would go for such a deal?
I suppose there wasn't enough upside for Google as people still bought Stadia without any such promise.
But they failed to adequately engage devs or their customers' desires in the first place, so such an arrangement would have been a comparatively impossible licensing and product goal for them.
But developers aren't getting their time back.
It's that endurance in the platform that has me coming back. I have faith that Valve as a company is in it for the long haul to act as a game store platform and honor my digital purchases. It's allowed me to put several thousand dollars into them.
However, on the flip side, there are also a good amount of games on Steam that are totally DRM free and Valve wouldn't have to do anything for those games in the event they shut down.
Maybe, just maybe they would release DRM-free Valve games, but that is as far as I could imagine they would go.
The hardware itself was cheap anyways – like $50 for a Chromecast + controller (and even cheaper with deals and bundles), and you can still use both after the service shuts down. It was the $60-80 per game that was the deal breaker.
When I buy pretty much any Microsoft product, I can go on their lifecycle policy page and see a date, often five to ten years out, when they commit to continue supporting/securing the product through. If I get more than that, great, but there's a commitment Microsoft is held to up front.
Google cannot make that commitment because Google cannot commit to anything. But it's a large enough company it could afford to do it and eat the cost when it was a bad call. The reason they won't is because Google doesn't view customers as people or partners they need to value.
But when I got the hardware I tried signing up and realized that apparently I had signed up for the Stadia free trial 6 months earlier. I vaguely remember trying for literally a few minutes on my laptop. This means that the $100 of promotional hardware they sent me is completely useless for its intended purpose.
It's genuinely sad that some manager or team went to all the trouble of getting the budget for this hardware promotion, but couldn't or didn't reset the free trial for the Google accounts of the recipients. But it might be a clear sign of the general level of competence with which the entire Stadia project was executed.
On the bright side, the Chromecast is still quite useful, although I'm not personally using it and haven't found someone to give mine to. Last I checked there wasn't any way to use the Stadia controller for anything, but I wouldn't be surprised if people could figure out how to "jailbreak" it and make it useful.
I got the same deal you did and use my Stadia controller with ROMs on my laptop when traveling. Works great. Excellent controller, too.
The wireless interface is actually WiFi and some form of Bluetooth and not easily jailbroken last time I checked.
I had a secondary Google account for app publishing, and I was able to switch to that and start another trial there. Not that this information is really any use to you now!
For what it's worth, my experience was pretty bad. Had tons of lag spikes on my 50/5 down/up internet.
I'm not a hardcore gamer and have a pretty weak desktop by gaming standards. If this was setup like an all-you-can-eat subscription, or an al-carte rental, I would have jumped on it in a heartbeat, and if it went away, oh well, I got what I paid for.
But the fact that that you had to "purchase" individual games made it a complete non-starter for me. If I purchase something, I want to actually own it, forever, not have temporary access to it at the whim of the publisher/service. I don't trust any online service to stay active indefinitely, and Google doubly so.
https://www.reddit.com/r/Stadia/comments/ceuy4w/comment/eu56...
(That said, props to them for refunding folks.)
1. we're committed to supporting this for years to come
2. you can download your game metadata (saved games)
LOL, what are people supposed to do with their game metadata now that Stadia is being shut down? Look at it in a hex editor?
Take your full price refund and rebuy the game at half price.
If you don't have the hardware for it, it's much cheaper now than it was three years ago, or you could use geforce now.
This was a doomed business model because it blurred subscription and purchase. If it was subscription, there should have been no purchases (hardware or software) necessary. There are millions of people - myself included - who would pay for a subscription game service. Stadia was not that service.
That's not the "Netflix for games" that it needed to be and stadia pro's limited selection was nowhere near adequate either. As a result, they set themselves up with the most unappealing business model possible for consumers.
I assume at this point that the license for the one game I bought was only good for Stadia, and I'm being refunded for it. That's good, cause Far Cry 5 got boring fast.
But it could have been different. They could have got $10M in revenue, then most users would have moved to competing platforms, while still playing previously purchased games on Stadia. This could have left them with a choice between $1M/year running costs to keep the lights on vs. $10M to purchase goodwill that is only worth $1M.
The goodwill is worth far more than $1M because it affects Google's entire reputation.
They already have a reputation of shutting things down.
How many people will look at this, and start considering whether or not they should move off GCP?
How many people will not sign up for their next big new product because of things like this? Which will ironically be likely for that product failing and being shut down (like Stadia).
It's a vicious cycle, and Google is going to have a hard time breaking it.
They deserved to fail on that point alone. Either promise refunds or promise none; either way you're signaling a form of confidence in your product and making the expectations clear to your users.
Refusing to answer on that point made it clear where their confidence was and how weasely they felt they needed to be to sell their product.
Note that Google Cloud Services lose money. "Google Cloud is now approaching a $16 billion annual revenue run rate, but Google's ad business is likely to subsidize it for the foreseeable future."[1] AWS makes money in that business, but Google does not.
So, don't depend on Google Cloud for anything critical. Only a few months ago, Google was saying they were not going to shut down Stadia. So, any PR statement about Cloud not shutting down can't be believed. Stadia, after all, was a cloud service.
And that was easy because we did not commit to any GCP exclusive services (because they tend to shut down all thr time). On AWS we prefer using things like DynamoDB and that further locks us into AWS.
GCP is a joke.
I’m confident AWS will exist in a decade, I’m not confident GCP will. I would never recommend a dependency on a Google service, especially not one that matters where there’s potentially millions of dollars on the line.
Google is starting with a handicap, in that they have a very strong reputation for killing products that don't meet unknown high standard of performance/revenue. I mean, the term "Google Graveyard" is popular, although I prefer Killed By Google[0]. To counter that handicap for GCP, they need something that stands out as much as Amazon's initial claim, and I haven't seen it. It seems clear that Google isn't running their own infrastructure on GCP. If anything, the hope seems to be that they've spent so much money on GCP, surely they wouldn't shut it down after all of that?
But of course, the bright sparks at Google are aware of the Sunk Cost Fallacy as well as anyone else, so... yeah. I have trouble trusting it.
I think even more important than the scalability, it implies AWS isn't going away as long as Amazon is in business.
> You can pretty accurately model what they will and won't do with this one unusual insight that they're a business... But "It's a Google product" is a weak signal about whether it's going to get killed, and there are many stronger signals. Let me know when they kill Ads and Cloud.
* 2018: -4.3B USD
* 2019: -4.6B USD
* 2020: -5.6B USD
* 2021: -3.1B USD
(https://www.theregister.com/2022/02/02/alphabet_q4_2021/)
I realize Google is making a bet on the long term of cloud, but... it's continuing to bleed money making that investment. Meanwhile, AWS is also seeing large growth numbers while remaining very profitable.
So, while I get the "investment for the long term" angle that Google is pitching for GCP, how long will they decide to continue making that investment while they lose money on it, chasing a profitable AWS
GCP is basically number four globally in cloud - with Alibaba being number three
This tells me it won't last much longer...Google can't afford to spend all that money to be number four
Yes, but also the market is much bigger now, and the cloud isn't something abstract people need to be convinced about. It's the de facto standard now.
> GCP is basically number four globally in cloud - with Alibaba being number three
Alibaba is niche in that few people outside of Asia would use it. It's still an enormous market, but GCP/AWS/Azure and Alibaba don't compete for the same workloads in the majority of cases. So there's plenty of place under the sun for GCP, if Google want it. Them killing it would be b2b suicide.
TAC (traffic acquisition costs) have exploded over this time frame. If you subtract TAC from Services revenue, the growth is merely good. Cloud revenue also seems a lot less sensitive to the recent economic downtown so far, but we'll really know after Q3.
The operating losses for Cloud are also shrinking quickly. Building data centers should be capex, but I'm guessing they count R&D as opex, which makes the losses higher now even though it will pay off later like an investment. They could probably start to have operating income any time in the next 3 years.
My opinion was "yeah, cool, but I just don't see it". It was very annoying when these coworkers judged me, thinking I am simply too stupid to realize how amazing this is...
Not that the economy really cares about wasteful consumption now of course, but there might be natural influences that may eventually force it to care about it.
We also never really explored what cloud-native games actually mean. Like what could we do with cloud games that we couldn't on a console? What does it mean to the compute budgets, to asset streaming, to multiplayer between cloud instances, if we could more efficiently use gpu resources if multiple players use the same gpu to play the same game, can we make multiplayer games in the cloud that are impossible any other way? etc. It feels like no game developer thought about what cloud gaming actually could mean, this could be a very exciting space in a few decades from now.
I think Stadia wasn't really a product developed by remotely competent people, they did so many mistakes that it feels like almost anybody could've told them. There even were detailed early reviews of the many issues with the platform, but they never addressed any of them. Its like they burned money it was weird.
Tying it to an expensive, mediocre controller instead of "runs on anything with a modern browser" was especially confusing to me, it seemed so incredibly foolish.
They might still of joined if there were any customers, but customers didn't join because of the prospect of needing to buy their existing games again, then pay for a subscription service to play them, on top of the already-not-so-big group of people with great internet but not so great hardware. Though they might of still joined if there were any games.
The primary thing Google got wrong was assuming everyone would flock to their service in droves for the promise of the other side of the service, thus forming it. They didn't anticipate that all the roadblocks they installed from the start would prevent any kind of flocking.
HN posters will talk about Google's graveyard, but it is not a factor for businesses; Google's history of shuttering perfectly good services doesn't extend to services you actually fork over cash for. And this won't affect that, as it was nowhere near a perfectly good service and was doomed before it was released.
While Sony, Microsoft, AMD, Intel, NVidia do cool tech sessions, Google is all about analytics and Play Store.
Then they expect developers used to devkits and Visual Studio plugins, to use classical UNIX like development experience to target Stadia, while hoping Stadia will stay around.
sucks to hear as someone who wants linux gaming to get more prominance, but I guess for now the current direction is to WINE it out.
https://twitter.com/taodong/status/1141603862740008960 (thread)
Canonical saying Flutter is the future of Ubuntu desktop apps is something too, but I'm not sure how much it's caught on since when it was announced in July 2020.
You lose that with OSS projects because you eventually end up with people screaming down your door and the visibility that brings. Also being assigned to work on these projects internally is career death. Both of these problems happened to Google Cloud's Terraform provider at some point and it was a headache for the company and the community.
Luckily Terraform adoption is out of Google's hands. They're just forced to play ball. OTOH, Google could easily kill off Flutter via other means.
If google drops support for flutter, the next design update by ios or android would kill it.
Projects that make it big from within Google need to find shelter from this perception by moving into community driven project governance, for better or worse.
Are there any major projects besides flutter built on dart? The fear is not that dart is hard to use, it's that it would not be maintained if flutter was not a mainstream success.
Seems to be enough buzz around it that I wouldn't be super worried.
For sure, anything that I could say along the lines of "we're not shutting Flutter down" might be taken as having overtones of the Baghdad Bob meme. And indeed, why should you trust my word?
The reason you should feel confident to use Flutter is because it's strongly in our business interest to invest in it. Over 600,000 apps in the Play Store alone are already written using Flutter, to say nothing of the countless apps for iOS, Windows, macOS, Linux and web. The list includes big brands like Alibaba, BMW, eBay, and SHEIN. Neither Google as a whole, nor Android in particular would be better off if Flutter didn't continue to flourish.
Aside from that, there are thousands of engineers at Google who use Dart and Flutter internally to build a wide variety of apps. There are many millions of lines of code written that power everything from Ads to our internal CRM system. Google wouldn't be better off if we had to throw all that code away and start over.
Lastly, Flutter is very successful. It has a developer base of several million, is growing quickly, and developers tell us it makes them more productive (https://medium.com/flutter/does-flutter-boost-developer-prod...). Happy developers are a prerequisite for a wide variety of other Google APIs and services, so we have a vested interest in continuing that.
Even if it weren't for Google, there are more contributors to Flutter from outside Google than there are Flutter team employees. Those contributors include big companies like Samsung, Canonical and Sony, as well as prolific individual developers like @a14n (https://github.com/a14n).
We're working hard on lots of fun new stuff right now, including a rewrite of our graphics rendering engine. If you haven't seen it, check out https://wonderous.app, which is using the new engine on iOS. We think it shows the potential of Flutter well!
How is Flutter funded? It was said a few years ago the budget came from internal projects like ads, fuchsia, pay, and stadia, does stadia being killed effect the Flutter budget? There was an implication at that time that if they all died or left Flutter then it would be killed via budget cuts, is that true? Why is Flutter not being adopted by Google for more outward facing apps? Is it seen internally as at risk of abandonment?
"600,000 apps in the Play Store alone", how many of these are commercial vs hobby projects, does Google really care about these if enterprise adoption is minimal? Delving into game dev when iOS is not polished seemed like a decision made because there was a need to show potential value via expansion upward in the org, I was concerned this was a hail mary when announced, and with Stadia now gone the timing seems more suspect.
"It has a developer base of several million", how many of these are again hobby users, how many use it weekly / monthly? Flutter has a large DevRel push, how many of these projects / users are students who just spin it up once and hit star on GH when asked and never touch it again? Your team was asked approximately this question by a MSFT employee looking at publishing info on cross platform framework adoption vs native and could not get a straight answer I was told.
Multiple Flutter related posts by agencies and evangelists point to a google trends page or GH stars saying Flutter is blowing up in popularity compared to other frameworks, but when you start looking at core packages searched for and starred for each framework the Flutter trend reverses, is this because the words Flutter and Dart are too common and in actuality the popularity is not what is being projected in trends? Is this because DevRels directly ask people to star the core project? I ask Flutter GDE's these questions and they come off like they can't be trusted to be honest on these topics for fear of losing status. I have also heard a certain outspoken Flutter GDE mention on stream other frameworks have much larger communities, how can this jive with these purported trends?
It seems as though the community size and growth of Flutter is projected to be greater than it is, that's subjectively how it feels as a dev as well I will note as someone who is using packages / repos, and that is worrisome. I worry that the first time we hear solid numbers will be in a blog post about the Flutter project ending with an explanation that low enterprise adoption and direct or indirect revenue could not support the scale of this ambitious a project. It would be great to hear some hard facts that give people confidence in adoption and that Flutter has long term backing higher in the company. If this is not the case, honesty would be nice as well.
@a14n seems to have tailed off on his work on Flutter quite a bit, which worries me if he is the core example of users who would pick this up in an OSS abandonment situation. Even now it feels as though if major OSS package maintainers like Remi Rousselet walked away the community would be hit hard. I can't imagine the project continuing without Google, especially with Dart needing the same treatment if Flutter was killed. Dart issues with notes saying the team lacks bandwidth exist now, I just can't see it working even with some other companies interested, Flutter/Dart need full enterprise backing at this stage.
"which is using the new engine on iOS" - An aside... I downloaded the app, it seems pretty smooth, not sure the FPS but I saw minimal jank which is great. BUT, it still has the biggest complaint I hear about Flutter apps on iOS, feel. On iOS is does not feel native, the scrolling and gestures feel off. This is part of what I was referring to regarding ignoring polish on iOS in favor of expansion earlier, iOS still feels second class on Flutter. I have watched a friend delete a flutter app from their phone right after installing with the reasoning "I hate when apps feel like that, it's so obnoxious", these people exist, they feel Flutter apps are second class, this sentiment will 100% drive away enterprise adoption imho. Even recently a user on the flutterdev subreddit said they were leaving Flutter behind just do to this persistent user feedback.
My final thought is the same as my first, be more transparent, show the community with tangible honest numbers and backing Flutter is not in jeopardy, otherwise the track record (and imho vague mushy pumped up stats) makes it appear it is.
Modulo a few minor redactions, this is the entire document. I don't know of many other projects of our scale that has shared something like this. It's reasonable to have divergent opinions on whether we're successful or popular, or what that means about our developer base. But I hope you'll see that we're trying to be pretty transparent about what we're focused on. We're just trying to build something valuable and useful, and that benefits Google as well as the broader community.
I don't give a fuck about flutter, but the link to the strategy document and the generic nod to transparency came across quite poorly as a response.
I guess he can't get a straight answer either. I would have loved to see a thoughtful reply.
Strategy:
> We primarily build for external-to-Google users, but Google adoption of Flutter remains of great value to us, as it helps us “pay our bills”
So grow or die as Google adoption is heading in a negative direction now and you are racing to grow enough to offset no one new eating the dog food?
> our primary strategic objective is the growth of monthly active users
> On the other hand, even a mediocre SDK will have a healthy and flourishing ecosystem if it is used by the plurality of developers.
Don't create something people love and use internally then share it with the world with mostly permanent internal funding, but instead get enough external buy-in that Google keeps it alive via inertia? My questions above were very much about this, does Flutter have that inertia in hard numbers or are you racing a clock now that internal buy-in is seemingly diminishing? Based on this you must have a MAU target, how far off is it, could you share even a percentage? If you don't hit it will the project be axed right away or is there a runway?
> Other characteristics (runtime performance, memory usage, etc.) will earn the respect of a developer: important, for sure. But developer experience will earn love.
This is only true until they realize the devils bargain you are mentioning above, I was complaining about expansion via game dev over polishing iOS in my previous post, this seems to be the planned strategy, which is very disheartening.
> In 2022 we will make good on this promise, and further raise our quality on web and desktop. We believe Flutter's growth will increasingly come from web and desktop: ecosystems that each have many millions of developers.
> Yet the web developer market is huge (10m+) and Flutter offers something distinctive for this audience
In a world where polish is not priority I think Flutter best fits on desktop, kudos there...web for flutter is very niche as noted, I guess if expansion is all that's important that's cool, but I would take iOS polish over web any day, I just don't see business apps using Flutter for web, it really only makes sense to me for apps that would be looking toward canvas, etc. anyway.
Roadmap:
> We will update the Material library to support Material 3.
iOS once again super low priority :(
> We plan to continue to evolve the language at a deliberately slow but steady pace.
This is how churn will happen, you have buy in from many people and they are clamoring for improvements, custom linting, sick of codegen, better inference, faster analysis in large repos, etc., but this is lower priority than gaming and material design updates.
> In 2021 we resolved a number of issues around jank ... As a result, we have been rewriting our graphics backend. In 2022
Out of everything I read only this last piece on jank felt like something I need as a current Flutter developer on mobile; thank you.
I have felt for a while the developer experience was too focused on easy entry / getting started and not professional work, this seemingly is the goal. The r/FlutterDev thread on the stadia shutdown has lots of users saying "Flutter is not Stadia", but it sounds like it is. Flutter is not an OSS framework like React that is supported by Meta because they use it heavily, this is a product, you need customers, Flutter has targets that can be missed just like Stadia. This is extremely worrisome. The same MSFT employee who asked you about MAU mentioned the large DevRel spend on Flutter vs the zero spend on the main competitor. I thought at the time this was to push more people toward Android first multi-platform (I would say the competitor is iOS first), turns out that was a misread. This also explains why MAU numbers are not shared, that's not a nice metric of an OSS community like other OSS frameworks have, that is a business metric.
Unless there is more hard number / metric / goal transparency I don't think you can really say there is no reason to be worried.
> your team needs to be more transparent.
Unfortunately most of the lack of transparency is not under the Flutter team's control, but I'll see what I can do.
> How is Flutter funded?
A number of companies (Google, Bytedance, and Canonical are three that I know have publicly stated so; there are others but it's up to them to make such statements) employ people to work on Flutter. Hardware costs (CI, source control, bug database, etc) are paid for by Google and Microsoft.
These companies don't typically share more detailed information about how they account for this funding or how much they pay exactly; it's considered proprietary, and often there are legal implications to making detailed statements about this kind of thing.
> It was said a few years ago the budget came from internal projects like ads, fuchsia, pay, and stadia
(I'm assuming you are referring to Google's portion of the funding.) That's not really how Google accounts for things internally. Broadly speaking, the more usage (internal and external) that a product gets, and the more revenue can be assigned to a product, the more Google is likely to fund it. In the case of Flutter, Google is apparently quite happy and has been increasing funding over time as a result, as have other companies (as you can tell by looking at the number of people employed to work on it).
> does stadia being killed effect the Flutter budget?
No, that's not how things work at Google. (I assume you mean Google's investment in Flutter when you say "Flutter budget". Flutter itself, as an open source project, doesn't have a budget currently. Maybe one day we'll have a foundation but right now the additional management overhead doesn't seem worth it.)
> There was an implication at that time that if they all died or left Flutter then it would be killed via budget cuts, is that true?
I think when there were far fewer apps using Flutter, and fewer other companies using and contributing to Flutter, that if Google had stopped using it internally, after a while, it would have become difficult to justify continued investment (since in that scenario, very few people are using it at all, so what's in it for Google? Google isn't a charity). However, at this point Flutter is used a great deal outside Google, as Tim discusses in his comment above, and even if Google itself were to stop using it (which seems highly unlikely) there would still be plenty of justification to continue funding it as a developer product (many of Google's APIs and developer products aren't used internally at all).
That said, this is not intended to be a forward-looking statement (https://en.wikipedia.org/wiki/Forward-looking_statement). If you want to ask Google about its future funding plans I suspect the best place to do so is a stockholders conference call.
> Why is Flutter not being adopted by Google for more outward facing apps?
With some exceptions that involve negotiations with the relevant teams, Google doesn't generally talk about what technologies it uses for its own applications. Tim listed quite a few apps whose teams have agreed to publicly state they use Flutter, though. I'm not sure what else to tell you. It's not like Google is making new apps all the time, and rewriting an app in Flutter only makes sense if the app's team benefits from the rewrite in some way.
> Is it seen internally as at risk of abandonment?
No. (But then, why would you take my word for it.)
> "600,000 apps in the Play Store alone", how many of these are commercial vs hobby projects
I don't think this is an axis along which apps are categorized, so I've no idea how to answer that. (What is a "hobby project"? Does it count as commercial if someone charges for their hobby?)
> does Google really care about these if enterprise adoption is minimal?
Yes? We care about all apps.
> Delving into game dev when iOS is not polished seemed like a decision made because there was a need to show potential value via expansion upward in the org, I was concerned this was a hail mary when announced, and with Stadia now gone the timing seems more suspect.
I'm not sure what you're suggesting here. Our work on iOS is entirely orthogonal to the work on the Casual Games Toolkit, it's not like the people who worked on one could work on the other. The Casual Games Toolkit is intended to help people who are interested in writing games with Flutter but don't know where to start; we regularly do surveys of our developer base and this was an area that people indicated an interest in. I'm not really sure what the supposed link to Stadia would even be. Work on iOS continues, and we have significantly grown the team there in the past year.
> "It has a developer base of several million", how many of these are again hobby users
We occasionally post the data from our quarterly surveys to our blog on Medium, the latest post I could find that separates the data by "what is your primary purpose" was the Q3 2021 survey's report and it had this graph: https://miro.medium.com/max/1400/0*_GNHkk5TLOI7wQYc
Looks like it's <50% are "hobby" users and the number is shrinking. That said, we explicitly want to be a project that people use to learn programming, providing a seamless path from "learning" to "hobby" to "professional" so I would hope this number never gets very low.
> how many use it weekly / monthly?
That's very hard to say for a variety of reasons (e.g. many people turn off analytics, analytics are extremely unreliable in general, many people use Flutter via means that wouldn't trigger our analytics in the first place, etc) but my understanding is that as best we can tell, Flutter has well over 500,000 MAUs. I don't think we track weekly numbers.
[continued below]
I've no idea how to measure that.
> Your team was asked approximately this question by a MSFT employee looking at publishing info on cross platform framework adoption vs native and could not get a straight answer I was told.
I mean, there's some questions we just don't have the answer to. I'm not sure what to tell you. We do share quite a lot of our data, e.g. from the quarterly surveys, as noted above; for most of your answers the numbers I just gave you can be found by Googling.
I would personally love to share more (e.g. I'd love for the analytics to be public) but there are significant privacy constraints around this. Even within the team, most people don't have access to the analytics data, and we're actually making an effort to limit that even more as part of our extensive efforts around tightening security.
I hope one day we can anonymize and aggregate the data to a level that satisfies Google's privacy team and then we'll be able to share the numbers in real time, but that won't be for some time (if ever, this stuff is hard).
> Multiple Flutter related posts by agencies and evangelists point to a google trends page or GH stars saying Flutter is blowing up in popularity compared to other frameworks
I would point to things like numbers of users or apps rather than vanity metrics like GitHub stars, but there we go.
> but when you start looking at core packages searched for and starred for each framework the Flutter trend reverses, is this because the words Flutter and Dart are too common and in actuality the popularity is not what is being projected in trends?
I would posit that it is because Google Trends data is a terrible way to measure popularity of an SDK.
> Is this because DevRels directly ask people to star the core project?
GitHub stars are purely a vanity metric. I would ignore them.
> I ask Flutter GDE's these questions and they come off like they can't be trusted to be honest on these topics for fear of losing status.
Feel free to tell them to reach out to me if they ever have a question about what they can or can't say.
> I have also heard a certain outspoken Flutter GDE mention on stream other frameworks have much larger communities, how can this jive with these purported trends?
Flutter is big and growing, but there are plenty of much bigger SDKs, certainly. I don't think that's a big secret. :-)
> It seems as though the community size and growth of Flutter is projected to be greater than it is, that's subjectively how it feels as a dev as well I will note as someone who is using packages / repos, and that is worrisome.
There are plenty of SDKs with much smaller communities that are very healthy and have been around for decades. I think it's reasonable to be concerned about ecosystem health, but I must say that personally I am quite happy with Flutter's ecosystem and community size and growth.
> I worry that the first time we hear solid numbers will be in a blog post about the Flutter project ending with an explanation that low enterprise adoption and direct or indirect revenue could not support the scale of this ambitious a project.
Well good news, the numbers you asked for have largely already been discussed publicly, so you need not have that specific worry.
> It would be great to hear some hard facts that give people confidence in adoption and that Flutter has long term backing higher in the company. If this is not the case, honesty would be nice as well.
I can't promise long-term backing from Google, because I'm not the CEO and ultimately it has to be his call. I can point to all the reasons Tim gave above for why there's no reason to expect Google to abandon Flutter any time soon, and I can point to the numbers I gave above as the "hard facts" you are looking for, or at least the closest things to them that one can have. Unfortunately with squishy things such as ecosystem size and how people use products and so on there is so much noise in the data, such big error bars, that anyone giving you precise numbers is selling you snake oil.
> @a14n seems to have tailed off on his work on Flutter quite a bit, which worries me if he is the core example of users who would pick this up in an OSS abandonment situation.
I think Tim just pointed to a14n because he's contributed so much over the years. No one person could take over the project and I certainly wouldn't put that on a14n's shoulders!! You can look at our GitHub and Discord activity to see how the project is doing in terms of non-Google contributors.
> Even now it feels as though if major OSS package maintainers like Remi Rousselet walked away the community would be hit hard.
We are a long way past there being any single person who is keeping the project afloat.
> I can't imagine the project continuing without Google, especially with Dart needing the same treatment if Flutter was killed. Dart issues with notes saying the team lacks bandwidth exist now, I just can't see it working even with some other companies interested, Flutter/Dart need full enterprise backing at this stage.
You never know. FreePascal is an example I love to point to; it's an open source project with minimal (if any) corporate/enterprise funding and yet they have been delivering reliably for decades now. I don't see why a dedicated team couldn't pick up Dart in the same way, if the interest was there.
> BUT, it still has the biggest complaint I hear about Flutter apps on iOS, feel.
The biggest complaint we hear is definitely jank, FWIW. :-)
> On iOS is does not feel native, the scrolling and gestures feel off.
If you have specific reproducible cases of this, please file bugs with test cases demonstrating it. The more concrete and specific you can be (e.g. high speed video showing the difference) the better.
We actually have built tools to verify that we are matching iOS physics to the pixel, so if there are cases where we're not, we would love to learn about them and fix them. (Unfortunately until recently we were mostly focused on lower-level issues on iOS, like performance and plugins, and have not had as much time to spend on widgets and physics. That's changing, though.)
> This is part of what I was referring to regarding ignoring polish on iOS in favor of expansion earlier, iOS still feels second class on Flutter.
We've made huge strides here in the past year, but yeah, we still have work to do.
> My final thought is the same as my first, be more transparent, show the community with tangible honest numbers and backing Flutter is not in jeopardy, otherwise the track record (and imho vague mushy pumped up stats) makes it appear it is.
As far as I can tell, we've been transparent, with most of the numbers you say you'd like us to share being numbers we have in fact shared already. The numbers are not made up, but yes, they are mushy. If you have any idea how to get less mushy numbers, join our Discord, help us out (the link to the Discord is in the contributor docs on GitHub).
On the budget / funding side I understand not all details can be shared, I think the general gist is just the broad question of what can effect flutter funding. It sounds like Stadia shut down won't, but I see that question was also raised on Reddit, so clarity on that was appreciated beyond myself I am sure, and any more would be appreciated as well.
On internal apps, I know Flutter is being used, this sort of leaks into PRs, comments, etc, but I think the question I was getting at is if that has enough value to google. On the outward facing apps this is definitely a matter of perception, I don't think I need to expand there.
The hobby projects, I think this is hard to define but is a classic you know it when you see it. The result of a single Udemy course, something that serves 0 to few users (most of whom are the devs friends), something not actively being developed, something where the code base is quite small, etc. Projects done and published for the sake of learning more than their use to others is likely where I would draw the line. I think there is another line at profitable / paid dev, but I would say the lesser line is appropriate. I think the wider question is how many people are getting enough value out of Flutter that it truly translates into value for Google that is worth sustaining, definitely not an easy question to answer.
> I'm not sure what you're suggesting here. Our work on iOS is entirely orthogonal to the work on the Casual Games Toolkit, it's not like the people who worked on one could work on the other.
This is still hard for me to swallow. Codegen for json deserialization, data types, general slowdown in the analysis server at scale, the list feels long, I would have to dive into the current issues to get them all. But coming from other languages / frameworks there is an incompleteness that feels more important to address than games no matter what a survey says. Saying they are orthogonal is denying resources/funds could be used differently for different goals. The Stadia link was simply it seems growing Flutter user base has a priority over polish, and with an internal app shutting down it seemed growth could itself grow in importance over polish.
> <50% are "hobby" > 500,000 MAUs
Thank you! This!! This gives some idea of how many devs are truly working on Flutter worldwide. These numbers make much more sense to me and what I see!"It has a developer base of several million", I felt like this was gaslighting me as I could not see where all these devs existed, how were stackoverflow issues that seemed like they should be semi-common with 0 to 1 replies!? This did not jive with millions of dev, even a small percent working at enterprise scale, and did not fit with my experience working on other frameworks that claim similar scales.
> I would point to things like numbers of users or apps rather than vanity metrics like GitHub stars, but there we go.
> I would posit that it is because Google Trends data is a terrible way to measure popularity of an SDK.
> Flutter is big and growing, but there are plenty of much bigger SDKs, certainly. I don't think that's a big secret. :-)
Combine the use of these two stats being heavily pushed in blogs etc with the, "It has a developer base of several million", quote, mix in first hand observations that they feel off, and the feeling the team is hiding something starts to manifest. Especially when blog posts turn these stats into proof through twisting that Flutter is for lack of a better term, "the biggest". Thank you for noting these are vanity numbers, imho pushing them does a disservice. I will also submit that at 5 years old continuing to push the narrative that Flutter is "new" and the nearest competitor only has any gains do that that gap starts to get some side eyes.
> We are a long way past there being any single person who is keeping the project afloat.
Agreed, but still it feels like there are a few big hitters, it does not go unnoticed where he works and I am guessing is sorta paid by proxy by Google.
> I don't see why a dedicated team couldn't pick up Dart in the same way, if the interest was there.
Agreed on Dart, I think Flutter is another matter though.
> The biggest complaint we hear is definitely jank, FWIW. :-)
>If you have specific reproducible cases of this, please file bugs with test cases demonstrating it. The more concrete and specific you can be (e.g. high speed video showing the difference) the better.
These feel tied together, I mean this in a honest way and not to offend the team, but does anyone on the team use iOS full time and run Flutter apps on device in prod regularly (just cruise ebay motors?)? I talk to other iOS users and this is a well known issue, scroll acceleration is off (scroll fast and it's WAY off), there is an issue already posted for Flutter with scroll being a full frame behind native so the location / perceptions feels off at first touch, and pull to refresh is a bit janky at times. "We actually have built tools to verify that we are matching iOS physics to the pixel" I mean no offense, but is something code wise wrong in the tooling? As a full time iOS user it's VERY obvious, you feel it and see it, my friend literally deleted an app due to it after using it for seconds, it's not just a vague complaint, it's highly perceivable.
> We've made huge strides here in the past year, but yeah, we still have work to do.
TY
> As far as I can tell, we've been transparent, with most of the numbers you say you'd like us to share being numbers we have in fact shared already.
I have gotten more info from this post than anything else I have read on the state of Flutter, appreciate it.
I mean, I hate to be flippant about it, but honestly the biggest factors in Google's funding of Flutter in the last 5 years have been COVID-19 and Russia attacking Ukraine, along with the subsequent market instability and inflation.
> The hobby projects, I think this is hard to define but is a classic you know it when you see it.
Well that's fine but I can't afford to have someone comb through 600,000 apps and make a call for each one on whether it's a hobby or not. :-)
> The result of a single Udemy course
We don't know how people wrote their apps. Also, someone can do a single Udemy course and then develop a killer app that makes millions of dollars. Is that a hobby?
> something that serves 0 to few users (most of whom are the devs friends)
I assure you plenty of commercial projects fail in exactly this way. ~90% of startups fail.
> something not actively being developed
Plenty of commercial projects have no active development. Probably most, frankly. For example my bank's app hasn't changed in years.
> something where the code base is quite small, etc.
Is Wordle commercial or hobby? Would a Wordle-style app written in Flutter count as a hobby app or a commercial app? What if it sells for millions of dollars the day after we decide it's a hobby app?
I just don't think this is a useful metric.
> I think the wider question is how many people are getting enough value out of Flutter that it truly translates into value for Google that is worth sustaining, definitely not an easy question to answer.
The value Google wants is ad dollars, Android users, and reduced internal development costs. Google isn't willing to report any of these numbers, and they are material so I would get in legal trouble for revealing them. My job is working on Flutter, and I am not concerned for my job. If that's not enough, there's not much more I can tell you.
> I would have to dive into the current issues to get them all.
I'm happy to discuss whatever issues you'd like if you're curious about current status on things. I recommend reaching out to me on our Discord (link in the contributing docs on GitHub, I'm @Hixie there). In general all our issues are public on GitHub and for Flutter I try to give regular updates on the top-voted issues (see also https://github.com/flutter/flutter/wiki/Popular-issues for a summary of the top 10).
> But coming from other languages / frameworks there is an incompleteness that feels more important to address than games no matter what a survey says.
I'm not sure what to say to that. Dart has one of the most comprehensive standard libraries out there. We have some holes, e.g. we don't yet have a good story for HTTP2, which we're working on. But compared to most languages, the core standard library is way more comprehensive than average, IMHO.
But again, the people who would work on, say, HTTP2, and the people who would work on the Game Toolkit, are entirely different people and the skills aren't interchangeable. Engineers aren't commodities you can just move around at will. People specialize, have interests, commitments are made, etc.
I would also say that "no matter what a survey says" is a very subjective way to run things. I actually strongly appreciate our data-driven approach. I think that's the right way to develop a product. You're never going to be able to address everyone's needs, but addressing the needs of the most people first seems like the better choice. We drive almost all our efforts from hard data collected in surveys, UX research, voting on issues, etc.
> Saying they are orthogonal is denying resources/funds could be used differently for different goals.
The paltry funds we spent on the Game Toolkit work literally could not have been used for iOS work. That's just not how things work.
> growing Flutter user base has a priority over polish
The two are not mutually exclusive. The Google team working on Flutter is currently focusing on growing the user base _by_ improving the polish (specifically around developer experience).
> Thank you! This!! This gives some idea of how many devs are truly working on Flutter worldwide. These numbers make much more sense to me and what I see!
These numbers have been public for some time, for what it's worth. We're pretty transparent, more or less as transparent as we can be about this stuff given constraints like privacy on analytics and given the very dubious nature of analytics in general. We tend to share these numbers on our blog and developer events regularly.
> "It has a developer base of several million", I felt like this was gaslighting me as I could not see where all these devs existed
The total Flutter developer base is much bigger than MAUs. As best we can tell from data collected by third parties, there are several million developers who use Flutter. They might not all do so within the same month, though. (For the same reason, if we had weekly active user numbers, they'd be smaller than the monthly active user numbers.)
I would be very careful about interpreting absolute numbers here. You cannot compare numbers from different sources because collection methodology is such a huge factor in determining the result (literally by orders of magnitude). In my experience the only way to use metrics like this is comparing them over time to metrics collected in the exact same manner.
> it does not go unnoticed where [Remy] works and I am guessing is sorta paid by proxy by Google.
I actually have no idea where Remy works, where is it?
> These feel tied together, I mean this in a honest way and not to offend the team, but does anyone on the team use iOS full time and run Flutter apps on device in prod regularly (just cruise ebay motors?)?
Yes, of course.
> I talk to other iOS users and this is a well known issue, scroll acceleration is off (scroll fast and it's WAY off), there is an issue already posted for Flutter with scroll being a full frame behind native so the location / perceptions feels off at first touch, and pull to refresh is a bit janky at times.
Do you have the issue #? I can see if we should be prioritizing it higher.
> "We actually have built tools to verify that we are matching iOS physics to the pixel" I mean no offense, but is something code wise wrong in the tooling?
Maybe? I don't know. My experience on iOS is that we do pretty well, but maybe I'm just not sensitive to the same issues, or maybe it affects different hardware, or maybe we have changed the settings, who knows. Concrete data filed in actual GitHub issues is the way to resolve this.
Very fair
> Well that's fine but I can't afford to have someone comb through 600,000 apps and make a call for each one on whether it's a hobby or not. :-)
> We don't know how people wrote their apps. Also, someone can do a single Udemy course and then develop a killer app that makes millions of dollars. Is that a hobby?
> I assure you plenty of commercial projects fail in exactly this way. ~90% of startups fail.
Here I what I was getting at was todo examples being submitted, or some single tutorial chat client, someone can come out and make flappy birds of course, I taught kids in the past and some went on to publish their apps as encouragement from their parent. Nothing wrong with it, just don't see it paying the bills was my point. That was the totality of my point I think....
> The value Google wants is ad dollars, Android users, and reduced internal development costs.
I was trying to get at if a billion "hobby" devs don't drive any of this it's all a zero, thus my interest in that number.
> My job is working on Flutter, and I am not concerned for my job. If that's not enough, there's not much more I can tell you.
This is the best answer yet
> But again, the people who would work on, say, HTTP2, and the people who would work on the Game Toolkit, are entirely different people and the skills aren't interchangeable. Engineers aren't commodities you can just move around at will. People specialize, have interests, commitments are made, etc.
Totally agree, it seemed more to me people were hired for this vs expanding elsewhere.
> The paltry funds we spent on the Game Toolkit work literally could not have been used for iOS work. That's just not how things work.
Seems like it didn't matter though so fair enough
> I would also say that "no matter what a survey says" is a very subjective way to run things.
> The two are not mutually exclusive. The Google team working on Flutter is currently focusing on growing the user base _by_ improving the polish (specifically around developer experience).
I could be 100% wrong but perception is real, after I wrote this I was sent links to other people on twitter lamenting the same growth into other sectors while mobile was not polished. I know in the yearly survey it asked about professional use, not sure if that gets more weight?
> These numbers have been public for some time, for what it's worth.
I tried googling this so many times, SEO of dev shops and blogs obscure whatever is out there on this subject.
> The total Flutter developer base is much bigger than MAUs
This is a deeper convo, if I have to update some wordpress php once every 6 months am I really part of the php/wordpress developer base? Idk, it's semantics I suppose, I have my opinion that the base is people who deal with the language / framework on a nearly weekly basis. My point in being interested in this number related to "Google wants is ad dollars", and the assumption they connect.
> I actually have no idea where Remy works, where is it?
Remmy works for Invertase who make all the Firebase packages, he and they do a great job imho.
The last pieces were on iOS, here is the issue that was filed: https://github.com/flutter/flutter/issues/110431 but honestly if you have full time iOS users ask them, they have to know, it's impossible to miss, this is not the only issue, but it requires more quantifying. To be totally frank as a dev with many iOS and Android test phones, Flutter scrolling feels like Android scrolling on an iPhone.
Oh I'm sure plenty of that happens, but that's true of all SDKs. Plenty of people do that with Android Views, plenty of people do that with Swift UI, etc. I have no reason to believe that Flutter is particularly different from the others in terms of the proportion of apps of this kind.
> Totally agree, it seemed more to me people were hired for this vs expanding elsewhere.
Ah, no. We've hired more engineers for iOS work in the past few months, but the games toolkit was mostly devrel and a contractor, if I recall correctly. Similarly for things like the pinball demo or the Wonderous app, those are primarily done by contracting an agency rather than people on the Flutter team, with the agency's feedback directly feeding into the engineering team's priorities. So for example, Wonderous was great because during its development it helped us find a whole bunch of issues we needed to fix.
> after I wrote this I was sent links to other people on twitter lamenting the same growth into other sectors while mobile was not polished
Again, the various areas aren't comparable or exchangeable. For example, Canonical is contributing to the Linux port, but it's not like Canonical would ever contribute to the iOS port, after all, their interest is in using Flutter on Ubuntu. Similarly, people Google hires to work on the iOS port are typically not the kind of people who want to work on Android or Windows, and so on. There's lots of areas of specialization, and if you task people to work on areas they're not experts on and not interested in, you're just going to burn them out and get low-quality work.
Even if people were commodities and interchangeable, though, I don't think it makes sense to focus on one area at the exclusion of another. There is more value in Flutter being able to target seven platforms (Android, iOS, Windows, macOS, Linux, web, and Fuchsia) well, than there would be in targeting just one platform completely perfectly. Especially because the effort to get from zero to excellent is much less than the effort required to get from excellent to perfect. Flutter is not unique in this. Kotlin isn't perfect on Android, but that doesn't mean JetBrains should avoid working on web support. C++ isn't perfect on AT&T Unix, but that doesn't mean people shouldn't implement it on other platforms. HTML isn't perfect for documents, but that doesn't mean we should not have extended it to applications. My house's kitchen isn't perfect, but I still want a bedroom.
> I have my opinion that the base is people who deal with the language / framework on a nearly weekly basis
By that definition, I am not a programmer, because there's literally no language that I use every week. Indeed, there are entire weeks where I don't write any code at all!
> https://github.com/flutter/flutter/issues/110431
Looks like Chris is working on that one. (By the way, that issue was filed by a Flutter team member, so presumably that answers your question about whether the Flutter team notices iOS issues.) (Also, that issue is a good example of the tools that we use to test this stuff.)
I was just trying to understand adoption rate which I believe correlates to longevity
> Again, the various areas aren't comparable or exchangeable. > My house's kitchen isn't perfect, but I still want a bedroom.
I totally get this viewpoint, I think perception can be different from the outside.
> By that definition, I am not a programmer, because there's literally no language that I use every week.
Head back to IC ;)
> By the way, that issue was filed by a Flutter team member, so presumably that answers your question about whether the Flutter team notices iOS issues.
Need to take issue here, this was talked exhaustively about in a thread on reddit where a dev was leaving Flutter because of user complaints on this issue, the thread was seen by a team member then and taken up.
>Codegen for json deserialization, data types, general slowdown in the analysis server at scale, the list feels long,
Those are clearly Dart critiques, sure Dart is not a perfect language, but I can tell you coming from Java and Kotlin that they have plenty of warts of their own, as does ObjC and Swift. On the other hand, Dart is still being very actively developed and improved so I have no doubt that in the future, it will be better than today, just as its sound null-safety now out classes Kotlin's NS implementation.
>but does anyone on the team use iOS full time
Not sure why you keep focusing on iOS and Flutters focus on Material. Sure you might feel the need to use iOS styled widgets but there are plenty of commercial apps built with Flutter that very happily base off of Material and you should note that the new rendering engine has been developed on iOS first to specifically address many of the valid perf issues that skia based engine has had on iOS and Metal.
>. On the outward facing apps this is definitely a matter of perception, I don't think I need to expand there.
After reading all your preceding posts and now this, you seem to want to imply something but not come out and say it. I know that Google have publicly announced Flutters use by Google Pay (https://flutter.dev/showcase/google-pay), if that's not a big enough app for you I'm not sure what would convince you.
>As a full time iOS user it's VERY obvious, you feel it and see it, my friend >literally deleted an app due to it after using it for seconds, it's not just a >vague complaint, it's highly perceivable.
This is my biggest pet peeve, anecdotally I hear a fair bit of this coming from mobile devs, especially with iOS devs who seem fixate on this, but guess who I've never heard this from in over decade in mobile dev: iOS users (and Android users) who are not devs. Literally never. Not a single non-dev person has ever mentioned it to me. Sure the complain about a million others things to do with phones, apps, you name it, it's amazing all the things people want to talk to you about when they find out you're a mobile app dev, but literally it's never about scroll physics being too fast or off.
Sure I'm very involved in the Flutter community and do it for my day job, so I can quite rightly be labelled as biased, but trying to be as objective as possible, on all measures I can think of, Flutter is a very successful open source project and simultaneously a very successful "commercial product" which is quite a rare feat to this day.
Finally on the topic of open source, I'd point out that unlike for instance AOSP (another huge Google project/product) Flutter is not developed in "throw it over the wall once a year" fashion but completely in the open, all work is done in the public repo, on public issue trackers, public design documents, roadmaps, etc. Its really quite exceptional in this regard and is really one of the big reasons why its really close to foundation/consortium style projects (think Apache, Eclipse, Linux, Rust) than a single-corp sponsored one.
Every language has spots of pain, of course, but the sticky points in Dart at scale don't feel like rough edges, they significantly effect workflow.
> you seem to want to imply something but not come out and say it
I have said multiple times not eating the dog food makes me weary, Google uses Angular a lot, why not Flutter? ...I think you need to read back I am well aware of Pay, this thread is about Stadia, the largest commercial Flutter project at google afaik, being killed. Pay is USA and India only.
> Not sure why you keep focusing on iOS and Flutters focus on Material > This is my biggest pet peeve, anecdotally I hear a fair bit of this coming from mobile devs > Not a single non-dev person has ever mentioned it to me.
I think you may be too deep in the Android space, I have heard this a ton. TBH I think many times the apps are wrapped webviews so scrolling works but other interactions feel off, but 100% non devs notice when iOS apps don't feel native.
Most of the anxiety and concern isn't from the Flutter project itself so I wholly empathize, but from Google's history in the dev space. Virtually anyone who had an AngularJS codebase knows what it means to depend on a Google OSS product that Google uses internally.
> There are many millions of lines of code written that power everything from Ads to our internal CRM system. Google wouldn't be better off if we had to throw all that code away and start over.
IIRC, when the AngularJS team came out with a brand new JS framework and called it "Angular", I believe the team explained how they automated migration of most of Google's "millions of lines" of complex internal codebase from AngularJS to Angular in a relatively short time, thanks to Google's internal infrastructure and tooling.
You could do dependency analysis, build ASTs across projects, at "Google scale", and have special tooling, transpilers, compilers to migrate code across Ads and verticals in a fortnight. Google has the talent, tools, cash to take such grand measures and come to conferences to showcase how they did it.
So the several million devs using Flutter are still undertaking a risk if Google deems targeting each new iOS version UX is too expensive, freezes contributions from internal devs, and starts internally migrating codebases to native with some shiny, new internal tooling.
EDIT: If such a scenario does come to pass internally, I think the Flutter community would very much appreciate project leaders being upfront about it.
But all the tooling we built for that multi-million LOC migration is open source, and available to everyone as part of the core SDK (https://dart.dev/null-safety/migration-guide#migration-tool). It's sophisticated, migrates much code automatically, and provides a visual editor to help make decisions about other code. That should be evidence at least that we care about migration.
Every ecosystem goes through migrations at some point (Objective-C to Swift, Java to Kotlin, Win32 to UWP, etc.) Flutter isn't immune to that risk, but I don't think it's particular to Flutter either.
At least some of your million dev userbase comprises of consultancy shops, contributing in part to your popularity by building products for their clients, but also making a buck with low effort on the underlying tech. They end up stitching codebases using unusual practices to meet deadlines that often blow up when a migration is upon them.
Angular had a migration tool called ngUpgrade that was painful in the wild.
All I'm saying is, these tradeoffs have now surfaced and crystallized.
Firebase is a google product (not an OS framework) that Google could kill off and no one could do anything about it. It they decided to shut it down every app depending on it would go down the day day they turned it off.I don't see people being equally concerned about using Firebase because Google could kill it. It makes sense to use it because it is cheaper and faster to get started than creating your own backend and all of the related services. If they did shut it down people expect to get enough lead time to transition to something else. Using Flutter is less risky than depending on any Google service. Additionally Flutter development is faster and requires fewer engineers for the same output. Flutter code is more testable and reliable than any other option that runs on the same platforms. Flutter does not require QA teams or additional quality engineers when you leverage its full testability. Flutter runs on everything, if suddenly Oracle won a lawsuit and manufacturers stopped making Android devices Flutter would run on the next mobile OS, or the next anything OS. Regardless of what Google does in the future Flutter is the safest bet a startup can make and it is the smartest bet a mature company can make. The gains you will make in the meantime using Flutter outweigh the risks.
I'm not even sure that Google has shut down more products than an equivalently sized company. But it's certainly shut those products down in such a way that it's generated far more backlash and ill will than anyone else.
Just brainstorming, but perhaps a large company, when launching a new product, could establish some kind of dedicated trust to provide credible assurances that e.g. the product would be supported for at least 10 years.
There are a few problems to Google's way of doing things, having witnessed it from the inside. In no particular order:
1) Google tends to be over-optimistic and under-skeptical when it comes to new products. This is largely driven by organizational dynamics: Google's corporate structure encourages fiefdoms that come up with the Next Big Thing(tm) - everyone involved is encouraged to be wildly over-optimistic about their products, and there is not a countering skepticism from upper management to impose the right amount of discipline re: these wild-eyed claims of TAM, growth, etc. The net effect is that Google launches products that aren't sufficiently baked, with vastly overestimated initial growth. This creates disappointment as the products bounce off the market and do not get anywhere near the (completely fictional) projections.
2) Google's go-to-market strategy tends to be under-baked as well. This is related to point #1 - heavily over-optimistic projections causes Google to accept woefully substandard GTM plans. Stadia launched with an incredibly poor lineup and burned a lot of the initial goodwill and press which stalled any kind of momentum they could've gotten.
3) Google organizationally isn't set up to reward individuals that turn around troubled products. Promotions heavily favor new product, not fixing existing broken product, especially once the product has lost executive favor. This causes team death spirals - failing products experience intense team attrition that further hampers any kind of turnaround plan.
4) Google has comparatively high executive turnover vs. similar companies. This results in rapidly shifting high-level strategy. Products and projects fall in/out of favor so quickly it causes whiplash. Other companies (see: Nvidia, Sony, MS, Apple) seem to be able to identify product areas of strategic importance to the company, executing against it, and having the executive support to continue resourcing these projects even if they initially fail/disappoint (see: Apple Maps, PSVR). Google constitutionally does not have this ability - they talk a lot about multi-year investments in strategic areas but in reality their commitments are fickle.
Other systems I'm aware of mostly piggyback on some other platform so your "ownership" extends to local usage also (like how Nvidia's system works with your Steam library), or are just Netflix-esque subscriptions that give you access to the available library as long as you're subscribed (like PlayStation Now, well, whatever it's now called under Plus, and Game Pass streaming).
Neither of those models has the same type of concern over losing your purchases. Google's track record is obviously a factor too, but the business model is as well.
Slow-roll invite-only launch to establish a core user base, work out the bugs, show staying power, and build from there. Exactly what Google did in 2004 with Gmail.
Unfortunately I don’t think Stadia fits that description well; you need to build hardware, network PoPs, license games, etc.
Maybe there is a private-beta approach that really iterates, initially uses off-the-shelf hardware, only launches in one state, has limited games, etc. but it’s hard to make a splash like that.
I think if Stadia had just been better (so everyone using it was raving about it) the Google reputation might not have mattered.
It just ended up not being a game-changer economically, people still want to buy consoles etc.
The model of thin-client gaming might win long-term but it’s just not a clear winner yet.
Hardware is literally scaled by customer demand, and was one of the reasons gmail went with the invite only launch.
Network PoPs are less an issue when you are already piggybacking off of Goog / GCP infrastructure, and you can mitigate the remaining costs by per country launches. And they did exactly that. It's still not supported in Hawaii. https://support.google.com/stadia/answer/9338852?hl=en
> I think if Stadia had just been better (so everyone using it was raving about it) the Google reputation might not have mattered.
Stadia was too late to market, in a field where content is rare enough relative to the number of competitors to have bargaining power. And they have no vertical integration to lean on. Nvidia has GPUs in house, MS/Sony/Nintendo have game devs in house for exclusives. Amazon _might_ be able to parley Twitch into a profitable Luna, but its a long shot.
Hardware manufacturing is, but design is most certainly not. It takes as much work to design a controller that you build one of as it does a controller you build a million of.
Obviously less viable for the set-top boxes, but still a valid strategy if you can do it.
They do have a client-side console/controller, and to be fair I had to look up why they did their own (https://en.wikipedia.org/wiki/Google_Stadia#Hardware).
> While Stadia can use any HID-class USB controller, Google developed its own controller which connects via Wi-Fi directly to the Google data center in which the game is running, to reduce input latency.[8] Google is also exploring further ways to reduce latency, using an idea called "negative latency" which involves prediction of user input through various means so that any apparent network lag between controller and game response is minimized.[12] During its GDC 2019 keynote reveal, Google confirmed that the controller would also feature Google Assistant, which will automatically search YouTube for relevant, helpful videos related to the game they are currently playing at the touch of a key.[13]
I don't think any of Google's manufacturing capex is recoupable here; it's specific to making that thing, and if you don't want to make any more of that thing it's trash. (I'm not a hardware guru though, so that's not a statement made with high certainty. There might be bits that are reusable.)
That's… kind of the problem? They have a reputation for abandoning products after making a huge splash. The only way around it is to stop looking for big splashes and start building products slowly instead. Pixel phones were notoriously only available in selected countries. Google Fibre is even more limited.
A coworker and I were chatting about it, what happens if/when Apple drops and Mx SoC in the AppleTV? There are the obvious apps, you create a camera add on and add FaceTime to the living room. Things like that but you also have a very serious machine that can go head to head with PS5 and Xbox, legitimately. I wouldn't be shocked if something like that were to happen.
It does mean any further support is non-existent. With PaaS and SaaS, this implicit contract between buyer and seller no longer holds.
There's typically a fight, though.
AWS has shut down I believe only one service in its entire existence (SDB). And only when they had a viable alternative (DynamoDB) and helped their biggest users make the move.
I can't recall any Apple service that has been shut down without an alternative. They've certainly cancelled hardware programs, but that doesn't break your existing hardware. And they give plenty of warning for iOs phase outs. They pissed some people off by dropping support for old apps, but only after most of the big ones had been converted.
And Microsoft is the king of long term support. How long did they keep supporting DOS in Windows? Or 32 bit programs. Or Windows 2000!
I can think of an esoteric one that no one misses: Ping (their music-based social media network)
The fear with Stadia wasn't that Google may just shut it down, it's that it could have been very successful, with millions of happy users, and Google still would have shut it down. That's what separates Google from other companies.
Now, it's a perfectly valid point that Stadia is a consumer service, like Drive - but in a thread where there are discussions about developer services (GCP, for instance), making the distinction is important.
The distinction is meaningless in that case because GCP hasn't sunset any services either.
Weeps in Google Play Music and Hangouts.
I feel like there's a whole generation of people who are now in senior decision-making roles who are still bitter about Reader. Killing that product, specifically, is likely costing billions per year in GCP revenue.
The difference is Google shuts down services people actually like and use simply because they aren't profitable enough
Silverlight may have a replacement, but that doesn't help the devs who sunk their time developing with it. Same for people writing extensions for and debugging compatibility with Edge.
It feels like you have a double standard at play here, and are giving both Microsoft and Amazon a free pass on their abattoirs of dead products by various excuses, and totally ignoring that those same excuses would apply to Google's.
> AWS has shut down I believe only one service in its entire existence (SDB).
Sure, but that's comparing a different branch of the company. Stadia is a consumer product, not a paid developer product. On the consumer side, Amazon has discontinued plenty of things (as every large corporation has):
According to this article[1], Amazon has canceled Haven, Amazon Spark, Amazon Restaurants, Amazon Storywriter, Amazon popup stores, Dash buttons, Amazon Tap, Instant Pickup, Amazon Tickets, Whole Foods 365, Amazon Fresh's Local Market Seller, Quidsi, Endless.com, MyHabit.com, Amazon Webstore, Amazon Destinations, Amazon Local, Amazon Wallet, Amazon Local, Fire Phone, Amazon WebPay, Amazon Askville, Amazon PayPhrase, and Amazon Auction.
Relevant to this thread, Amazon Games is technically still around, but they canceled Nova, Intensity, Breakaway, Crucible, and the Lord of the Rings MMO. Many top executives have left.
[1]: https://www.businessinsider.com/amazon-products-services-fai...
So they don't exactly have a spotless record.
And then there's any era of Apple and their habit of removing consumer choice and forcing customers more into their closed ecosystem.
Can you provide some examples? The years of supports for things like Carbon are hard to reconcile with that claim.
Not sure if it counts, but dropping 32-bit support on macOS may be counted.
To show great confidence in it and address the elephants in the room as directly and clearly as possible.
I think the main issue here is that the perception of Google being fickle and uncommitted means it's harder for third parties to want to commit resources to. Strong signaling from Google on long term commitments has to be made, but I think that Stadia is in a bit of a pickle because of its nature.
With a console, I assume there are some general timelines developers get on how long the console is going to be around, so it's a lot easier to develop a strategy for working with it because you know off the bat you likely have at least N years, your projects will take Y years, thus you understand how many projects you can put onto it before the console obsoletes.
With Stadia though, since it was just PC games and Android games being streamed, there are two ways you can try to understand it:
- It never obsoletes as Google just upgrades the hardware and OS to keep new fresh games coming in
- It obsoletes as soon as it's too costly for Google to refresh the hardware and they decide to cut their losses
My guess is a lot of people thought it would be the latter and just didn't want to invest time into it. I'm not sure how the process for getting a game on Stadia was, but based on a quick look at some articles, seems that Google was struggling with this aspect even as late as 2022 [0] with trying to help make the process more convenient and faster. That's 3 years into the platform already and they were still teaching developers how to get their games onto Stadia efficiently, and I have to imagine Google was already looking at the numbers for the datacenter costs and going "welp".
So how could Google have really changed it? My take is have this convenience and strategy for the porting from Day 1. I did not use Stadia or really follow it (just not interested in Cloud gaming in general), but looking at this article and the history of articles on porting games to Stadia, seems that it wasn't an attractive process from the beginning, for an already iffy platform for developers, with the looming fear that Stadia would not make the numbers to keep Google's interest.
Combine that with Players already unhappy with not actually owning a lot of their games and distrusting Stadia, I guess it seems like Google just couldn't quite sweeten the pot enough to convince them to pay full physical game price for a game they didn't really own and ran the risk of being removed due to obsolescence (a perception on players part perhaps, but this is again a communication issue for Google)
[0] - https://www.forbes.com/sites/krisholt/2022/03/15/google-stad...
On one hand, the distribution power makes it extremely easy for new products to get lots and lots of users really quickly. On the other hand, it can give a false sense of security when it comes to product-market fit.
The only real solution I can think of is deliberately launching new products without the Google branding and without relying on the built-in distribution channels, working towards product market fit the hard way, and only after that should they consider taking advantage of Google's distribution power to accelerate growth.
Google's reputation for canceling projects was bad, even back then. Never gave it serious thought. You could see the writing on the wall, even before they built the thing.
This would have given enthusiasts a lot less to hate about Stadia. It would have given customers a lot more confidence in the long-term viability of their purchases. It would have highlighted the flexibility offered by Google's streaming platform without making putting up with its drawbacks a requirement to enjoy your games. A player could start out only streaming their games, then upgrade to a real PC down the road to get an even better gameplay experience out of their existing library.
For many enthusiasts, the product Google actually launched felt like an existential threat to their hobby. They feared games could go streaming exclusive. Publishers could use it as a form of extra draconian DRM, or start designing their games around the limitations of streaming. As a result this turned many of the biggest gaming enthusiasts, the people casual players will often ask for advice on what to buy, into ant-Stadia evangelists.
Nvidia already has a product like that called Geforce Now. Instead of having it's own store it integrates with Steam and GOG.
There's still the problem that is a hypothetical customer wants to game enough to pay for Stadia but doesn't have the funds for a gaming PC... why don't they just buy the $300 dollar Xbox Series S?
One of the reasons why they launched and bought studios for exclusive content. Which they then shut down early, only a bit over a year after launch of Stadia (?).
Google is building a too strong reputation of an unreliable company. Doesn't help when an AI is in charge of banning people from accessing their critical stuff like emails and stored files.
> Google's reputation for not supporting things long term
I didn't know Google had such a reputation. I mostly use drive and gmail, so it was fine to me.
Does google really have such a reputation? Any place I can read more on this?
I miss Google Reader and Google Wave the most.
Youtube Music is a huge step back. Spotify is far too playlist and recommendation happy, I want to listen to albums not curated lists. Tidal is decent, but similar to Spotify. Apple Music is the one I haven't tried for more than a couple of days and I don't recall what I didn't like about it.
The point I was making about Spotify is that even if I solely listen to music as full albums, I only get recommendations for playlists. I rarely want to listen to a playlist. There are a number of other things I don't like about Spotify, but it works well enough.
I've concluded the price saving isn't enough to use a product who's UX I enjoy less, even if it works well for other users.
Spotify is okay and does have some nice features in the way that casting works and multiple devices joined to one account, but it's certainly not as enjoyable to use.
Not 0, but really not much, that is true.
I remember the shutdown of google reader. I tried it once, but let go of it before it was shut down.
But I really didn't know google had this kind of reputation.
Nobody wants to go to Walmart in VR and artificially grocery shop. That's a dystopian misery. But Facebook is happy to try!
Their counterparts at places like VRchat meanwhile realized that just making a sandbox environment for people to do whatever they wanted is far more enticing to users. Valve meanwhile is happy to chug along and putter out critically acclaimed games to go with their own bespoke hardware releases