[vincheezel]

Why even have a deadline? Why not just release the firmware to the public? What does google gain from stopping people converting stadia controllers to Bluetooth in the future?

I can already see issues like people who bought new old stock who can no longer do anything with them.

The best case scenario is they release a toolkit to flash your own firmware so people can hack on the now completely otherwise useless controllers.

[kyrra]

Googler, opinions are my own.

Every thing deployed at Google has all kinds of frameworks and shared libraries and tooling. There are many policies in place to get insure they get newer versions of shared code, such as:

https://opensource.google/documentation/reference/thirdparty...

And to maintain these kinds of things, it isn't uncommon for unfunded mandates to be pushed on people that own various tools, such as this one.

Meaning, even to keep a website up at Google, there will be some maintenance burden. Also, I could imagine Chrome pushing some update that would make all of the usb pairing stuff that they do here break at some point, and they will have to do work to keep it working.

[vel0city]

I understand there's a forever maintenance thing to forever hosting a website, especially a web application, when its a big behemoth like Google. Lots of compliance reasons and all other organizational policies can make it hard to even just host a file at a URL forever much less an actual interactive application.

I think the real question is why bother doing it with this website? The controller has a USB port on it and I imagine can talk over USB. It would be far better to just have some application which can flash over USB instead of needing some Google-hosted website. Just give me an executable that people can toss on a torrent or whatever. I appreciate they did something to make these controllers useful to people, but it seems like they really didn't pick the best path to achieve that.

I imagine they probably painted themselves into a corner and the firmware update process is so locked down and will only talk to approved Google endpoints over an HTTPS request or something like that and that's the ultimate reason why they went that route. But really I feel that kind of shows a failure to imagine the hardware life after the service.

[nox100]

A website works on all platforms; Mac, Linux, Windows, ChromeOS, ... maybe even Android. An app works on a single platform.

To me, they could put it on github and serve it on github pages. I suspect though that there's a bunch of non-open source libraries being used and getting into a condition that could be open sourced is person power they don't want to spend when they have an infinite list of things to work on.

[vel0city]

So sure, release a webpage that you'll only host for a few of years. But then also release a basic executable we can run for the next hundred years after instead of making something that needs Google's blessing and continued effort to exist.

Everything being a website isn't necessarily a good thing.

[depressedpanda]

I think you're missing the point. In this case it being a website is an awesome thing.

The underlying tech is powered by the WebSerial protocol. We basically already have the executable you're asking for. As long as Google supplies the firmware blob (and js source, though this can probably just be ripped from the current web page), anyone will be able to put up a server, and anyone with a modern browser will be able to visit the site and update -- without having to install anything locally.

Given that a 'native' app would probably be some bloated Electron abomination, I was actually pleasantly surprised that Google chose to solve the firmware update problem the way they did; it worked flawlessly for me on Linux which is seldom the case when it comes to these things.

[vel0city]

It's hilarious to me you're glad it's not a bloated Electron abomination while also taking about the joys of it requiring a whole web browser to operate.

[d0lphin]

Yup even Android, Chrome on Android supports WebUSB so I usually use it to flash different firmware to my Nintendo Switch on the go.

[avianlyric]

Well according to the article the entire firmware flashing process does happen over USB. The website is just a JS executable that uses WebUSB API to perform the flashing process via a browser.

As is also mentioned in the article, the author reverse engineered the site, and create a python script capable to performing the flashing process via standard OS APIs.

Really the flashing site isn’t really “a site”. It’s a hosted executable written in JS that pretty much runs entirely locally, apart from the bit where it downloads the new firmware to be flashed. It should be possible to extract the JS itself, plus firmware blobs, and run that completely offline for as long as browsers support WebUSB. Or you do what the author did and create a Python equivalent.

[worewood]

> Also, I could imagine Chrome pushing some update that would make all of the usb pairing stuff that they do here break at some point, and they will have to do work to keep it working.

That can be solved by developing a flasher in a framework more stable than Javascript and web browsers, like OP did.

Companies been increasingly using the "we can't do X because Y" justification when they themselves are responsible for Y.

[lima]

> What does google gain from stopping people converting stadia controllers to Bluetooth in the future?

It means they can delete the code from the monorepo.

[kevincox]

The hardware isn't changing. If they aren't going to provide bugfixes and support they can just archive the built artifacts and publish a torrent or public Google Drive folder.

[Tyr42]

They do have that, and I think it'll be on GitHub indefinitely, but Google is hosting a live site which can reflash the controller.

Eventually the framework it's running will be deprecated and someone will clean it up.

[kevincox]

All of the flashing logic is client-side. As a bonus they could archive the whole site. But even if just the firmware blobs were available it would be a huge win as developing another flasher is probably pretty easy with the provided documentation. I suspect that it wouldn't be hard to identify and download most of the firmware that could be used (I don't think there are many controller revisions) but distributing those will be a legal grey area without a proper license from Google which presumably owns the copyright.

[urbandw311er]

Best guess - it’s about support and maintenance. For every tool out there that’s live you’re going to have a degree of overhead to deal with queries and keep it working on the latest OS, browsers etc.

[saurik]

Google already has a solution for this: they just ignore any and all customer support queries.

[fy20]

They also refunded everyone who bought the controller, so legally they don't have to provide any support.

[emodendroket]

Even if they hadn’t I’m not sure what legal right you’d have to demand service.

[asylteltine]

Google has customer support?

[deely3]

Unless you make it opensource?

[jezzamon]

Generally things at Google are built on a stack of private libraries and infrastructure, such that open sourcing something requires a complete rewrite. Unfortunately.

[arccy]

have you not seen the typical GitHub issue tracker full of entitled people?

[zwirbl]

Then archive the repo or close the issue tracker and let the people whine on some forked repo