posted by Thom Holwerda on Wed 11th May 2011 20:35 UTC
IconIt was inevitable, of course, and rightfully so: Google is having its big I/O conference, so we have to talk about the lack of Honeycomb's source code. While not violating any licenses, the lack of source code doesn't sit well with many - including myself - so it only makes sense people are asking Google about it. Andy Rubin confirmed we're never going to see Honeycomb's sources as a standalone release. He also explained what 'open' means for Android.

First of all, we're not going to see a separate code drop for Honeycomb. According to Andy Rubin, the phone functionality in Honeycomb is very broken because Google took a number of shortcuts to get the code out the door as soon as possible, and they don't want to dilute the Android experience by having people trying to cram Honeycomb onto smartphones. As such, the code for Icecream Sandwich, when it has been cleaned up, will be released.

So far, nothing new. As I said in my earlier story about this, while I understand Google's reasoning, I see this is a massive cop-out. Sure, they're not violating any licenses, and it doesn't come close to the structural (L)GPL license violations by Apple, but I personally believe that you shouldn't lock away BSD/Apache/MIT-licensed code just because you took shortcuts or because you're afraid of what cheapo OEMs might do with it.

The above isn't new, but what follows is. Andy Rubin detailed how, exactly, the Android team sees open, and they're basically echoing the notion that I (and many others) have detailed: open source does not have to mean open development or even open community. "Open source is different than a community-driven project. Android is light on the community-driven side and heavy on the open source. Everything we do ends up in the open source repository," Rubin said.

Well, except for Honeycomb, that is.

"We're building a platform, not an app. Developers evolve APIs and deprecate APIs, they are always adding new functionality," Rubin continued, "When we add new APIs, typically in my opinion community processes don't work. It's really hard to tell when you're done, it's really hard to tell what's a release and what's a beta. Developers have to have an expectation that all the APIs are done and complete at certain date."

"If it was a community process, an OEM could start building devices, then those devices would be incompatible from a third-party developer's perspective," Rubin added, "We have to make sure those APIs are on all those devices that adopt those platforms. Going forward, that becomes part of our job, our responsibility. A community process harder to manage. We take submissions form community, but it's a much more controlled way in how it comes out."

This I can agree with. Android is so popular it's very important that someone - Google - takes on a more governing and controlling role, to ensure Android moves in a specific direction that best ensures its long-term survival. Compatibility is important for developers and end-users alike, and if Google needs to exert some form of pressure to ensure this compatibility exists, than go team Google.

e p (3)    64 Comment(s)

Technology White Papers

See More