It sounds like there are two main pieces to me:
1. Removal of cloud dependency
2. Making usable the API (and providing documentation)
With a minor 3rd piece:
3. The official app will be updated to support the "offline" mode without losing as many features as possible now that the cloud service is going away.
All very laudable things IMHO. I'm actually going to buy one of these
Sanitizing an existing documentation for public release might take notable time and effort if there are 100s of endpoints. But I would assume that is not the case with an API for a speaker.
This is making them controllable.
The headline may be inaccurate, but I'm not clear on what source code you'd even want. To the firmware do you mean?
A documented API seems like the most useful option here.
I assumed they meant the firmware, and was quite surprised they would do that...
Secondly, these devices are basically one step above embedded. It's highly unlikely you can load and run anything custom on them.
Since they are opening up the API, you can keep using them for what they were made for, which is at least a solid basic liberty
Seeing that, I expected the ability to build and run a custom firmware, like with an Android device with its bootloader unlocked. But it is not that, and they didn't open source their app either.
What they did is that they removed dependence on their servers, and opened their device to be controlled by third party apps. That is, they let users use their device past its end of life, including when the first party app will stop being maintained, but not to the point of letting user add features.
In understand why they would do that, they don't want users to backport features only available on their latest models that are sold at a premium, therefore competing against themselves. After all, the value in smart speakers is not the sound producing device, which I think is a problem that has been solved more than a decade ago at the consumer level, it is all about software features.
Evolution v. Revolution. I'd prefer the latter, but realistically the former is the more likely to succeed short of people like us getting control of regulatory bodies and forcing it.
Unless you want to actually develop ON the device (and build binaries etc...), this completely allows you to use the device and connect it to whatever, so I don't know what more we should expect.
No one else is doing this, so yeay applause