Hacker News Reader

Comment by bobz | Hacker News Reader

Your question is ambiguous, depending on how I read the word any... so I'll address both.

1. ...to compromise the idea of openness at all...

The point is not to be open. Openness is a tool that Google uses to create the product and ecosystem that it wants. In sacrificing a little openness, it loses a little bit of the perks of being "open," but probably gains other things, so I can respect that.

2. ...to compromise the idea of openness entirely...

I don't think we can say that they've done this, at least not yet. I'm just look at it as an experimental branch of the code that isn't yet ready to be merged into the trunk. It makes a lot of sense to me that, if they rushed this code out for strategic reasons, that they would want to keep it a little close to the chest until it was more stable. Remember, while to you this is an abstract principle of openness, to them this is a product they ship, and they WILL be judged on its performance.

View on HN

Honeycomb is a production branch of the code, shipping on hardware already available on store shelves. So the idea of it being withheld as 'not ready' doesn't pass the smell test.

Surely withholding Honeycomb is within Google's rights and likely its best interests. But I don't think you can argue that it fits within any reasonable definition of Open. If "Open" has but one inviolable property, what could it be if not "source code availability"?

Honeycomb may become an Open Source project in the future. Google may have every intention of making that happen. But until the source is released "Open" isn't a property of their project, it's an unrealized goal.

And when evaluating how likely they are to deliver on that, I note the trajectory of the Android project has been away from Open and toward Closed for some time now. This non-release is an acceleration of that trend, not a simple continuation or an aberrant change in direction.

The best-case scenario is that Google does release Honeycomb, merely putting us back to where we were already arguing about whether Android's "Open" was translating into real, practical benefits over the approaches of Microsoft, Apple, RIM and HP.

Whereas the likeliest scenario is that this "eventually-Open" lag between product release and code release becomes a regular fixture. So not only will the practical advantage of Android's Openness be debatable, but the applicability of those contributions will vary within the release cycle.

>I don't think we can say that they've done this, at least not yet. I'm just look at it as an experimental branch of the code that isn't yet ready to be merged into the trunk. It makes a lot of sense to me that, if they rushed this code out for strategic reasons, that they would want to keep it a little close to the chest until it was more stable.

Which would be an acceptable reason if Honeycomb tablets weren't available for purchase. Since the Xoom is running Honeycomb, I cannot see how anyone can say that it's "experimental" at this point. It isn't just a commit that Google isn't done with yet, it is released software.

My interpretation is that the OS development has been "spiked" to target certain platforms, as a proof and exploration of the tablet form factor. But, as with most fast, targeted code pushes, some sacrifices have been made in the generalizablility of the code base. They may want a chance to go back and smooth out their hacks before eager vendors get their hands on it and start building the first at large generation of tablets.

This is just one interpretation, but it's an example of a case where I'd be behind Google's actions.

I agree that this is a good reason why Google doesn't want the code released, but I do not believe that it is a good reason not to release the code. If your Open Source software is good enough to be shipped, the code should be good enough to be released. In this case, I think it's more an issue about how Google is managing expectations with the system.

I think it would have made more sense to release a one-off Android branch for the Xoom. In addition, I would have:

1. Made it clear that this code release is a targeted device code release, and will have major issues with other devices.

2. Released a somewhat detailed timeline for when the stable, generalized 3.0 code is expected to be done.

The first keeps the homebrew community happy, because they have something they can hack with on the Xoom. It might boost sales marginally, too.

The second keeps the tablet manufacturers happy, because they now have a timeline for when Google is going to get a generalized tablet OS out the door.

Reply on news.ycombinator.com