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.

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.

But is it reasonable to say that Google has "sacrificed any idea of openness" by delaying the release of source code for one iteration of its platform?

Yes. Eventually is not now. Right now, Honeycomb is a closed source OS. Allowing politicians to live in the eventually (so they can keep their pet issue alive to get re-elected and not solved) has done us no good. Allowing companies to pull the same trick is not acceptable either. Open should not be a marketing term.

As mellis said http://news.ycombinator.com/item?id=2369108 they shipped product so the source should be good enough to ship also.

Well, I'd say it was reasonable to say Google sacrificed openness when

* They made sure that many of the most compelling -- to end users -- built-in bits were proprietary (i.e., those sweet Google-branded apps that you can get C&D'd for distributing)

* They began imposing requirements above and beyond software license compliance if you wanted full access

* They made sure their default (and thus, to most users, only) marketplace had the same sort of remote kill switch people complained about in Apple's ecosystem

* etc., etc.

Android is a mobile platform that you can sometimes get source for, sometimes hack on, and sometimes do what you like with. Which, um, isn't any idea of "openness" I'm familiar with.

Yes, because Google's privileged partners like Motorola get to access the source before its official release in order to have it ready on their products immediately, while everyone else has to wait.

This smacks of black/white thinking of extremes to me. Perhaps what they're doing violates the principle of openness, but if Honeycomb is the one exception to Google's "openness", and they end up releasing the code soon, for pragmatic purposes who cares?