Hacker News Reader

Comment by dm2 | Hacker News Reader

The fact is that Google tries to make their devices as open as possible. That philosophy is beneficial to the community, for the software, for their brand, and for the tech industry. If legal issues or unforeseen problems appear while they are launching a product that prevent stock images on a particular device, then oh well, shit happens.

There will be a dozen other Nexus devices within the next year and hopefully Google will learn from their mistakes, and will partner with suppliers who won't prevent source code from being published.

Does Google benefit monetarily from not releasing source code? Nope, it likely decreases their profit and tarnishes their reputation, so I would like to believe that they are doing everything in their power to keep Android and the Nexus brand as open as possible.

http://androidandme.com/2013/08/devices/new-nexus-7-may-not-...

View on HN

If Google was "doing everything in their power to keep Android and the Nexus brand as open as possible", they would have gave a shit about qualcomm's ridiculous conditions on source and redistribution before release.

Clearly they did not.

Especially considering that they managed it with the old Nexus 7. This is clearly not impossible, though I can buy that there are difficulties and tradeoffs.

The old Nexus 7 wasn't Qualcomm.

Yes, but nobody was forcing them to choose Qualcomm, if it didn't meet their requirements.

> The fact is that Google tries to make their devices as open as possible.

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.

I work for a GPU vendor so my viewpoint might be clouded, but there is a lot of competitive information to be gleaned from the source code of modern drivers.

I am praying for the emergence of a graphics vendor who can design decent hardware and have a liberal open source policy.

What is wrong with Intel ?

Opengl drivers. Have not played with the haswell generation yet.

Maybe the market is predicated on imperfect/occluded information. Therefore, ripe for disruption and collapse.

Strangely, you're describing (sort of) Intel!

I am cautiously optimistic about Intel providing some renewed competition in the graphics space.

What about the binaries? Isn't it possible to them off the device? Since you can't stop reverse-engineering, is there any sensible motivation for not officially releasing them?

Yeah, but most of it is encumbered so it'd be really hard for a competitor to go and read your driver code and then do the same thing without ending up in trouble later on.

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

If you wanted to find that information about one of your competitors, what would it cost you to hire a consultant to reverse engineer their driver and tell you all its secrets?

I used to write graphics device drivers so I'm going to bite. Usually most vendors think that their 'solutions', details about their hardware designs exposed in the drivers and optimizations are extremely valuable. Personally in my experience I found that most of what vendors considered secret was well known and not that novel and the majority of what was being done was application of the same or similar techniques in their hardware and drivers. Sure there are some novel things, but enough people have moved between the graphics card companies that the drivers really have very little truly unique information about the designs that would help a competitor.

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.

You might have been right at one point in time, but respectfully you're not right today. Today's modern GPU implementations -- especially on mobile because the APIs we support are so (intentionally) vague and encode a system with a wide spectrum of possible implementations -- are so complex and hide a lot of implementation specific secrets that other vendors would love to freely discover in source code.

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.

Licencing of components is done before you, well, put those components inside a million phones.

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.

> Does Google benefit monetarily from not releasing source code?

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

I think their options were either to delay the launch of the new Nexus 7 and possibly break a contract with Qualcomm or release it, let some non-devs enjoy the nice new hardware, and focus on the next new products. Makes sense to me, but I don't think Google benefited as much as they would have if Qualcomm would have allowed the source code to be published.

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

there was also the choice not to commit to this SoC unless Qualcomm agrees in writing that Google is allowed to publish factory images and binaries

Oh of course they would have been better off in a world where Qualcomm was friendlier, but that's not the question. Let's look at the cost/benefit to Google's decision if we assume there isn't a huge outcry.

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.

I personally see the lack of a Factory Image for a single device as being very minor. An overwhelming majority of Nexus users still choose to use stock Android and have no use for the source code. So what if there are a couple of devices missing from https://developers.google.com/android/nexus/images , it's really not that big of a deal in the grand scheme of things, especially considering how rapidly Google is pushing out new devices.

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

> I personally see the lack of a Factory Image for a single device as being very minor.

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.

This sounds like an apology. Openness is just not a high enough priority for them. It's just not their goal to release an open device otherwise they wouldn't have released this.

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.

Reply on news.ycombinator.com