Google's recalcitrance appears to stem from two issues: one is that Honeycomb is specifically designed for large-screen devices and Google is concerned that, if released, it would find its way onto unsuitable form factors; the other, hinted at by Google employees in the past, is that much of the code is a kludge unsuitable for publication.
I'm not sure why Google caught so much slack for keeping 3.0 closed source. I found these to be great reasons and instead of dealing with a bunch of HoneyComb/Android SUCKS reviews when someone put honeycomb on a small screen device google just weathered it out and released something with some quality.
That goes against the principle of open-source. The principle is that by releasing code to the public you will get contributions from others (an extra set of eyes) that will make the project overall better.
But to accept this principle to have to also accept that some people will take your code and use it in ways that you don't approve. The hope/belief is that the good will float to the top. If you don't accept this premise then you don't really have an open-source project.
I can't figure out why Android open sources its code, ever. They don't seem to care about contributions from the community, and they obviously don't want people using their code in ways they disapprove of. It seems that the major reason for open sourcing their code must be something else. What I keep coming back to is that it somehow protects them (in most cases) of patent violations.
I've asked this in the past: what is Andy Rubin's open-source credentials? What open-source projects has he been involved in during his long and successful career?
> They don't seem to care about contributions from the community
Google accepts a lot of patches from the community. Many of the major custom ROMs regularly submit patches. Things aren't perfect at the moment since all this infrastructure was hosted at kernel.org and is still down, so I can't link you directly to examples of public patch submissions and code review, unfortunately. But I can tell you they used Gerrit for that code review.
FTA: There are a few limitations to be aware of:
- Our priority has been getting the main source code mirrors back online,
so for the moment gitweb source browsing and Gerrit Code Review are still
unavailable.
Because the name is "Android Open Source Project".
It's totally fine to develop closed source software! The problem is that if you market something that's actually closed as "open", you're being disingenuous.
Apple did the same thing with Darwin, but to their credit they started backing off on the "open source" marketing once it became clear that they were heading in that direction.
The Darwin source is still being released if you want it (following the periodic code dump model), it just doesn't get much attention. For most people, it doesn't really offer a compelling case over Linux or its *BSD cousins.
They got lambasted for not releasing Honeycomb because "open" is one of their largest marketing platforms and the reason many people use Android. I'm glad they're going to release ICS source at some point, but can anyone be sure they'll continue to publish code for future versions? That kind of uncertainty diminishes their claims of "open" greatly in my mind.
Also, a tiny nit about the headline - it's not open source until they actually release it. Who knows when that will be.
Fwiw, many is a very relative term there. Android phones are definitely mainstream. I'd say of all the people I know that have an android phone, less than 10% even know what "open source" means.
My girlfriend has an Android phone. Her reasons are threefold (in order of importance); 1) It's cheap. 2) It's relatively small (Wildfire S is smaller that the iPhone). 3) She uses only Google services (Gmail etc.) so it makes sense to use Android. She is what I believe to be a typical user and the fact that the OS is "open" is irrelevant to her. No-one else influenced her choice and I think this is true of the majority of the phone-buying public; the silent majority that actually matter (we "technically minded" [geeks and nerds!] really don't). Genuinely, the openness debate only has any relevance in places like this, and even then it's arguably not really relevant.
There are thousands of reasons to love or hate android. One thing i like is the development going on in Cyanogenmod and MIUI Android. It's relevant to me.
Those things wont help android 'win' against the iphone, but it will be relevant in other markets, like the MIUI phone, wasnt that around 200$?
The kind of open that they do is definitely less good than I would have hoped (I would love to be able to submit patches for the bugs I regularly encounter on my N1, say).
But trust me, of all the people I know who have android phones here in "Middle America" (off the top of my head without thinking too hard let's say more than 10), none of them bought them because of a techie brother in law raved about it being so cool because it was open. They all bought them because they wanted a smart phone and it was the one they were sold by the telco marketing. Period. (Okay, I'm up to more than twenty coming to mind just while thinking at the same time as typing, and still, none of them bought them because of the openness at all).
So yeah. While it's really marketing-speak to say that android is open in the sense that we all traditionally think of it, to google (and much more importantly to all the telco sales people) it means exactly squat as a selling point.
Which is why only people on HN (and Richard Stallman) get upset about it :)
This just isn't true. I know for a fact JBQ has reviewed patches (and gotten relevant engineers to review things) that have made it into AOSP. The Android team does pre-push code review using Gerrit, and they often lack the personnel to review every change that comes in. As a result, patches sometimes (perhaps often?) wither on the vine before anyone can code review them.
Also: many potential contributors are scared off by the contributor license agreement required by AOSP. Patch contributions without the CLA can't even be reviewed.
As for not releasing honeycomb, look at releasing the kludged code from their perspective. They probably didn't want phones released from HC that wasn't ready for phone use, thus giving them a bad name when awful "Android Honeycomb Phones" hit the market.
to be precise, contributing means giving your copyright away to Google.
It means all you're doing belongs to Google, not to the community, or yourself.
Oddly it puts people off from contributing patches. Oddly!
I'm all for freely contributing to projects, but I will never assign my copyright to a corporation.
A not-for-profit at least, but corporation, come on.
There's a HUGE difference between copyright assignment (required by FSF!) and a license agreement (Google, Apache, Mozilla, many others). The former means you are giving away ownership to your IP, which is what you describe. The latter only means that the project can relicense or similar (which is very important if there's a bug in a license, for example). You retain copyright to any contributions made under a CLA.
It's a big difference. I don't see anything wrong with CLAs, and there are (according to some more versed in IP than I) some really good reasons to never accept patches without CLAs, especially when you're a potential high-profile lawsuit target.
eg
"Except for the license granted herein to the Project Leads and recipients of software distributed by the Project Leads, You reserve all right, title, and interest in and to Your Contributions."
> I'm all for freely contributing to projects, but I will never assign my copyright to a corporation. A not-for-profit at least, but corporation, come on.
The Mozilla committer's agreement, for instance, isn't that different in practice. You agree to specific licenses for your contribution (various shades of copyleft, MPL, GPL and LGPL) -- which amounts to anyone using that code being granted an irrevocable license -- but you retain copyright.
>As for not releasing honeycomb, look at releasing the kludged code from their perspective. They probably didn't want phones released from HC that wasn't ready for phone use, thus giving them a bad name when awful "Android Honeycomb Phones" hit the market.
Wasn't Honeycomb supposed to be a tablet-only OS? In which case, Google could have removed all cellular voice functionality, stated in the readme and release notes that this is intended for non-cellular phone devices only, and released it to the wild. Heck, they also could have refused to grant any usage of the Android trademarks to any manufacturer that used 3.1 source in a phone.
They could have done that but chances are a few of the less reputable OEMs would have ported code from Froyo or GB to get the dialer working again. The open nature of it means there is no restriction that could not be unrestricted.
But in all honesty HC was a rush job (as was most of the hardware) to keep Android in the game against Apple. I'm really looking forward to it getting "there". With 2x the resources (CPU and RAM) of an iPad it should absolutely kill it, but when the applications hesitate for a split-second I really have to contemplate what the hell is going on?
>They could have done that but chances are a few of the less reputable OEMs would have ported code from Froyo or GB to get the dialer working again. The open nature of it means there is no restriction that could not be unrestricted.
Unfortunately, this is probably the biggest mistake that Google has made with Android. Google could have gone the route that the Mozilla foundation has with Firefox, where Mozilla does not allow modified Firefox source versions to use any of Mozilla's Firefox-related trademarks without their consent(http://www.mozilla.org/foundation/trademarks/policy.html). If one does wish to use the Firefox source in an official way, Mozilla has a "Powered by Mozilla" mark that they grant out for people that use the source.
Google did not put such a policy in place with Android, which really limits their power with respect to "rogue" OEMs. Since they aren't charging for use of the OS, it's It has also led to the current issue that a lot of people have with pre-installed crapware or UIs.
Ideally, I think that Google should have created a "Powered by Android" mark that they could grant to anyone that follows certain restrictions, like full comparability with the Android App store, the ability to root the phone, multitouch, etc. That would help them to protect their brand, especially in this case, because it would allow Google to enforce any potential issues like trying to shoehorn a 7" tablet UI/OS onto a 3.5" phone. Also, like Firefox, it would not stop guys like Cyanogen, because they could still use some other public mark.
They do have that, it's "with Google". Android phones that follow Google's platform guidelines can put a "with Google" logo on the device, otherwise they cannot.
The problem is that the marketing is all around "Android", but the enforcement is around "with Google". So vendors that ship garbage can still ride Android's marketing coattails (and dirty them).
>'with Google' phones have been optimised for use of Google Mobile Services, providing easy access to Search, Voice Search, Google Talk, Google Maps, Gmail, Sync, YouTube and Android Market (where available).
And normal, non-branded phones are defined as:
>All phones in the Google Phone Gallery come with Android Market and Google Mobile Services such as Search, Google Maps and Gmail pre-installed.
What's the difference? There do not appear to be any real UX-related requirements, because Android 2.2 and 2.3 phones have the branding, some phones that use HTC sense have the branding(and others don't). Also, the Droid Incredible has the branding, but the Incredible 2 does not!
I'd also point out that basically all tool development is done in the open in AOSP. As you pointed out, it's usually just a matter of finding the people necessary to do code reviews.
Exactly. Honeycomb was something of a stopgap to catch up to iPad while Google went for its unified phone/tab ICS OS. Considering all the 1.6/2.1 tablets that were released this year that were just horrible, I can see why google went this route. The industry was fucking up tablets pretty badly and I can't imagine AOpen or Archos or whomever having access to a half-cooked Honeycomb source and pushing out yet another shitty product.
Instead we have gems like the Transformer, Galaxy Tab, Xoom, etc. Seems to me that google made the right move. Soon they'll all have access to ICS anyway. Lets see how badly these other companies fuck that up with their crapware, questionable UI changes, and cheesy hardware (I believe Archos or some other company is still selling resistive screens). Even if they do, we already have an established set of decent tablet products.
It could also be that it takes a very large amount of time to check and verify what can be released as open source code. Reorganizing the code so that proprietary drivers and internal-only APIs are abstracted out can take a very very long time. Even if nothing has to change, the time spent checking for these things was probably better spent working on Ice Cream Sandwich.
According to this[1] data Honeycomb is <2% of used Android versions. With the versions that 98% of the devices run being open I'd say it's a bit more than just touting about it..
Why did they even bother, then? That info makes this whole thing less understandable to me, not more.
Edit: Actually, that's beside the point. I think the reason they made Honeycomb is because they thought a lot of people would buy Android tablets, because a lot of people were buying iPads. But they were wrong about that.
I'm just saying, if they did it this way one time, there's no guarantee they won't do it again. How "open" it is, is really subject to Google's whim.
I'm not sure why Google caught so much slack for keeping 3.0 closed source. I found these to be great reasons and instead of dealing with a bunch of HoneyComb/Android SUCKS reviews when someone put honeycomb on a small screen device google just weathered it out and released something with some quality.