Clearly they did not.

Well, sort of. Keeping GPU drivers closed is a charade. There is no secret sauce of any great value in these drivers. There might be embarrassing coding horrors. But there is no good reason to keep these drivers closed.

In this case, not even the binary blobs are available. That's gratuitous pig-headedness from the GPU licensor and SoC maker. Google could have extracted at least that concession. When someone with as much integrity as JBQ quits, it's not just the run of the mill SoC vendor crap that caused it.

One thing that I think does cause problems for opening up hardware though is that many graphics implementations use the same or similar chips (to save on asic costs) and the drivers enable options based on the product the customer bought, but the underlying chip will actually still implement the higher end functionality. This is a common enough technique and to avoid people getting 500 dollar parts for 99 they can't open up the drivers. I don't understand why they don't push this sort of thing exclusively to device microcode (many do this or at least partially) rather than having software components that do some of this logic.

Discovering the secret sauce is the very embodiment of my job for my employer, and I make a great and exciting living figuring out our competitors' myriad secrets, a lot of which is controlled entirely by the driver.

I could write an entire book about why there's potentially very valuable competitive data enshrined in GPU driver code. Some obvious examples: execution resources and scheduler details (including full software schedulers in many cases), register allocation strategies, optimising shader compilers, hardware bug workarounds, power management limitations, clocking schemes, API compliance workarounds; all highly valuable competitive data that would be plain as day if GPU driver source were available.

For example, NVIDIA vs SGI on Texture Mapping, or NVIDIA vs 3dfx on stochastic mipmapping. (NV lost both of these cases, but managed to get what they wanted in the settlement...).

Someone who "tries to make their devices as open as possible" chooses components that can be made open. Someone who intentionally chooses a component and does not ask/licence it's driver to be open - hasn't even tried.

Indirectly, yes — choice of Qualcomm as a supplier (under condition of not releasing source code) must have been beneficial for Google.

http://www.fudzilla.com/home/item/32057-why-google-went-qual...

If Google insisted on shipping stock images it would have cost them. Either by picking an inferior chip, or by upsetting Qualcomm, or by Qualcomm charging them a higher price. Therefore they chose a position of some benefit to them when they decided not to ship stock images.

The best way to counter this benefit is a public shaming, so that in the end it's costlier than the other options would have been. But Google's not stupid; they wouldn't have made such an anti-openness move if they expected it to cost them.

Android is still open-source and the AOSP is still very alive and will live on.

It's not the lack of a factory image for a single device. It's the lack of a factory image for Google's flagship device when they've made so much hay about it in the mists of time (oh, about three months ago).

I'm not particularly sympathetic to most "open" argumentation when it comes to devices, but Google should walk their talk.

It's their goal to do whatever it takes to compete aggressively and if openness can win them PR, they'll do it, but it isn't a goal in itself.