Hacker News Reader

Comment by stuartjmoore | Hacker News Reader

"…once it’s available on devices"

Meaning: November. Basically, they won't hold it back like Honeycomb, this isn't a rush job.

Neither is it meaningfully an "open source project" any more, either. They do a lot of work and throw it over the wall. People are welcome to contribute fixes, but no meaningful architecture input flows inwards. I find that sad.

But it's far better than the disaster that was Honeycomb, or the fortess that Apple builds around its developers. But it's not where I personally would have hoped we would be at this point.

Android's never been "true" open source. I don't think they've ever done major development in the open; definitely not since 2.0 (IIRC, the Droid was on the market before even the SDK and emulator for Eclair, and not even sure if Eclair got a source release before 2.1)

I find the lack of "inflow" to be, as you put, very sad. I understand the need to develop in private and release at their discretion, but there are more than a few features in ICS that were implemented by the CM team already, as well as other things that have been "major" issues in the AOSP build tree that had been sorted out by the CM team and submitted as patches that were ignored. Seems a shame, really. That having been said, I'm sure I will install CM9 when it becomes available for whatever device I wind up with.

Yeah, it's a bit of a letdown in some ways, but... still. Liberally licensed project with tons of source code still isn't doing too bad.

To put a more constructive twist on things, I wonder how Google could achieve their goals and also make Android more 'real' Open Source?

Very interesting question, especially considering what strikes me as the newly singular vision behind ICS. Which also brings it to a new level of quality from what I can tell.

The MeeGo world had a bunch of discussions on this. What ultimately (IMHO) matters to people is simple visibility into the design process. With desktop linux, we get that. We can see Gnome 3 coming and talk about it before it arrives. We can try out a new driver from a development tree. When the occasion arrives, we can grab/test/fix/rework this stuff and know who to push the changes to.

But when these processes and priorities collide with "product strategy" they always lose. Google and its partners want to unveil ICS in a big press conference, not an email message. Samsung wants to show the first ICS phone, and not be one-upped by some geek running a CM9 nightly image on a phone she bought last year. So they delay the source drop and shutter the doors on the git archives. But in so doing they kill off the "project" part of AOSP.

And no, this didn't really work in MeeGo either. I don't know what the answer is, except to decouple the OS vendor from the hardware vendor (i.e. the Red Hat model). But that won't work because apparently no one wants to sell an open consumer electronics device.

Google also does not want device manufacturers to ship pre-release versions of Android just to be first to market. This was apparently a problem with Froyo or Gingerbread.

Google could hold back the sexy UI and application changes and just develop the kernel and foundation libraries in the open. But some of their hardware partners are very secretive and do not want any details leaked about the capabilities of their new hardware that may be revealed in device drivers.

Those are certainly some of the reasons, yes. But my point was more that Google is doing a poor job of managing the conflict between the business interests of its hardware partners and the health of the Android Open Source Project. Basically, AOSP isn't a "project" anymore (if it ever was), and that's sad.

And it's not like this is an impossibility. Red Hat manages to sell RHEL licenses without killing Fedora, for example.

Reply on news.ycombinator.com