Hello! I'd like to chime in with a few quick points.

First, comparing a source release for Android to a source release for a single component such as Linux or GTK+ is not an apples-to-apples comparison. Releasing the source for Android is more like simultaneously releasing the source for glibc, Mono, a full-multimedia library, X-Windows, a GLX driver, GTK+, and GNOME. Right now we are focused on delivering the software for the first devices. Preparing and vetting all the source for release would take time away from actually releasing a product. We've said previously that we'll turn our attention to releasing the source code once the first devices are available, and that has not changed.

Regarding the hypothetical scenario of incompatible/custom builds, licensing is a red herring. Google (and in this case also the Open Handset Alliance) tends to pick the Apache 2.0 license for its open source projects because it gives developers a lot of freedom and minimal restrictions. However, the entire point of all open source licenses is to permit custom builds. If you are open-source at all, you cannot prevent incompatible builds, regardless of your license. Even if you use a license that requires source disclosure, all it will do is help enthusiasts create "corrected" builds; it will have no benefit to the vast majority of end users who will never even know those builds exist. In other words, if you are concerned about the problem of incompatible builds, the particular open source license you choose is irrelevant, and you have to use some other means to address the issue.

Our approach is to use the "carrot" rather than the "stick". We believe that an open mobile platform will be as compelling to people as the open web has been. We are stepping up and putting that belief to the test. We are going to ship a platform that we believe will be extremely compelling to developers and end users. We believe the value of that platform will be obvious to carriers and manufacturers, who will have no incentive to deviate. The alternative is to adopt the contractual and bureaucratic solutions (such as certification, mandatory test compliance, and so on) that have not achieved the results we all want.

- Dan

2008/2/15 Stone Mirror <ston...@gmail.com>:

managed to get as good as they are with a whole community of people working on them from the outset, I wonder...

other Google. Since Android has nothing in common with any other Linux-based system ever seen before on the planet, why would the folks who've been working in the real open source community for years what they've been doing to take on the improvement and maintenance of a whole wad of "toss-it-over-the-wall-ware" when the OHA never took any steps to attempt to involve them...?

community should just sit down, be quiet, and wait patiently for the largesse to rain down on them, at which point they can (happily) grab their cups of Kool-Aid and join the big parade, is that it...?

the entire rest of the world is going to simply get on board behind their fragment. This seems unlikely, especially since the entire architecture and initial presentation of Android as much as said, "All you folks working on mobile open source out there right now haven't got a clue, we're the only ones who know how to do it right."

runs on Windows PCs because it's proprietary." That's the main reason that the WIndows APIs have "stayed the same". If underlying APIs have changed, eMule has had to change to keep up with them. Unless you think APIs should never be refactored...

produce a credible mobile operating system are the same thing. As it is, Google's gone out of their way to draw a line between Android and everything else that's going on in the open source community: once you get above the kernel, there's nothing in common, and no way for folks who do stuff other than write applications to participate.

completely cut out of any participation in developing the Android system (which, from the sheer number of unimplemented APIs and bugs could apparently use the help), why exactly would they suddenly develop an interest in the million lines of unseen code that Google will unveil a year from now when Android phones finally ship (and LiMo phones, based on well-known components and using well-understood APIs, etc., have been shipping for six months)...?

the market in a few months, it seems. And there are more device manufacturers making actual commitments to those than to Android devices: with the single exception of HTC, Android was only being displayed and demoed by silicon vendors at MWC, and they do it in the hopes of enticing device manufacturers to sign up... I'd expect the community to gravitate toward the LiMo platform much more readily than to Android...

combined with the disadvatages of proprietary code: once it's released, it will inevitably fork, and since it's under the Apache license, there's nothing to ensure that changes even get published, much less make their way back to the main project; as far as that goes, Google (and the OHA members...? Has a single one of them contributed anything concrete to this platform...?) will be doing about 100% of the heavy lifting on keeping the 'project" moving forward.

source isn't open), it's "Java" (but completely divorced from the Java Community Process), it's "complete" (except for all the stuff which is unimplemented or just not working), etc., etc...

anyway) an open source license. It's not as though Google's likely to gain much traction by releasing the sources in a year and standing around insisting, "Okay, you can become a community now, and start pitching in, darn you!" That's not the way it works...