And? I mean, ok, we get it, the most recently committed code is not open yet, probably because Google would prefer its flagship phones not be spoiled. So what? My phone runs an OS whose code is on github, and I install new versions when I choose to do so, from nightly builds.
And all the drawbacks I cited in the original post, ie, nobody outside the Android team bothers contributing anything, and the project has less developers and less features than it would if it were truly open.
Why would new phones be 'spoiled' if their source code was released?
> nobody outside the Android team bothers contributing anything
Do you have any figures to back this claim? Somewhere above or below a guy said he did send a patch.
> less developers and less features than it would if it were truly open
Very unlikely. Were it fully open (say, the Linux-way), it would not be pushed forward so steadily by Google, it would not have so many high-end apps (many written by Google), it would not have such a big piece of the market, it would not be the solution of choice for manufacturers, etc.
I also wish Android to be more open, and I hope we will see soon emerge a "Landroid" that will be to Android what Linux is to Unix, and probably Cyanogenmod is paving its path, but this is no reason to spit in the soup: Android is a giant step forward and without it we would be all sandwiched in a MS-Apple cross-fight.
> Why would new phones be 'spoiled' if their source code was released?
Suppose the most recent feature developed by Google on Android reveals that their next phone will have two-faced screens, wouldn't you think Google might prefer to decide when and how this new phone will be announced? As a result, we have a slightly lagging opening of the source code. It is sad, but better than nothing.
It is definitely incorrect to say "nobody outside the Android team bothers contributing anything": you can check the Android AOSP patch review website to see otherwise. However, I think it is a fair assessment to say that doing so is incredibly discouraging; while I don't have "numbers" to back it up, I definitely have tons of anecdotes on this.
On my own side, I can say this: I actually have code right now in Android; however, there is probably no chance that I will ever bother submitting another patch again.
What, in my experience, happens is that you submit a patch, and one person looks at it, thinks it is great, and gives it a +1. However, he can't merge it until someone agrees. Only, there isn't enough involvement on Google's end to get two people to agree. It isn't like someone else disagrees: you just don't get two peoples' opinions on the patch.
That is a patch that I submitted in January of 2009. Apparently, in May of 2010, a second person agreed, and the patch was merged. Yes: 16 months later. (There were three other patches I submitted in November of 2008 that were merged in August of 2009, but that was a "much more reasonable" 9 month gap, so... yeah ;P.)
With this patch, that same second guy had "disagreed"; well,
he wanted justification for why I wanted the feature. Two months later, the patch died, as I had long moved on. Now, had that question come, I dunno, a year earlier? (So, a mere 4 months after I submitted it), maybe I'd have remembered whether or not it was required for my use case. ;P
This patch wasn't even mine, but somehow I ended up in the system as "maybe he'll be second reviewer this time!" (and no, I have no clue how or why or what the rules are).
Only, this was the most depressing of all: when I reviewed the patch, I determined that the original code actually had a buffer overflow in it... this was an important patch.
The patch, of course, had already been in the system for a while: it was submitted in April, but it wasn't until nearly two months later that I got poked to review it. But, I don't think I actually could be "second reviewer", so there just ended up being a bunch of +1s from random people until yet another month went by; it finally got merged.
Another half of the problem is the same thing people here are complaining about: that AOSP is really just "an occasionally merged external branch" to "the real code".
The result is that when you are working on a patch, you actually can't know whether you are working on code that even exists anymore in the upstream branch. Maybe the code exists, but doesn't have the bug anymore; or maybe it does, but the implementation is sufficiently different that your code no longer merges against it.
What this means is that even if someone reviewed your patch instantly, it already might not apply anymore, and if it doesn't it isn't like they can even ask you to fix it.
It used to be that Google was promising that they'd merge the internal and AOSP branches, so they'd be working in public on nearly the same codebase (closer to Chromium). However, that promise at some point dissolved so greatly that they simply closed the source for something like eight months, not even attempting to merge it.
Why? As far as I can tell (and I've stared at this a lot), it was to hobble Amazon slightly, who had just announced that they were working on a tablet based on Android. Not just "an Android tablet", but "we are going to use all of that valuable work you did, but not pay you anything for it because we don't need your first-party Google apps".
The code didn't become open again until Amazon started shipping their tablets to users. At which point, the story with the open source codebase changed a lot. Now, the promise is more "we will make certain our preferred partners get access to the codebase quickly", but otherwise the code doesn't get dropped until the product ships.
Due to this, when we received our Android 4.0 test devices at Google I/O, and I soon there-after found a bug in libdl (broken shared object initializers), I was largely screwed. I seriously wasted a week (successfully!) figuring out what caused the bug and reverse-engineering what they changed using a disassembler, so I could file a bug.
When I managed to get the bug filed to the mailing list was about when the code finally dropped, so maybe that week was just wasted, but maybe I needed that time to find it anyway. Of course, Android 4.0 shipped with that bug. The issue was fixed in Android 4.0.1, and "luckily" almost no one upgraded to Android 4.0 until Android 4.0.2, but... frowny. :(
