There actually are relatively few closed pieces necessary to make something like Nexus S go. For the most part they're firmware, not actual "drivers", though the opengl libraries fall into a middle ground -- the SGX kernel driver is GPLv2, the userspace opengl libraries are closed. We've been working with vendors to make the closed pieces available under a license that allows them to be included in builds and distributed non-commercially (commercial distributors tend to be OEMs which have direct relationships and licenses with these vendors already):
http://code.google.com/android/nexus/drivers.html

I'd use the term "proprietary components" rather than "drivers" (the above URL is unfortunately named), personally, since at least for lead devices that Google works on, all the kernel drivers are GPLv2 and readily available:
http://android.git.kernel.org/?p=kernel/common.git;a=shortlog;h=refs/heads/android-3.0
(kernel/common is code common to all variants, SoC-specific work is under kernel/omap, kernel/msm, etc)

Keep in mind that the *any* device that supports USB Host mode can be an Accessory. There's a full open source reference implementation for Arduino, but the protocols are documented and open and you can implement it on any hardware you like.

Docs and Specs: http://accessories.android.com/

Google IO Talk: http://www.youtube.com/watch?v=s7szcpXf2rE

I have often thought we would have avoided a lot of headaches if we started with NetBSD instead of Linux....

The reality is that in 2005, Linux had the most momentum with the silicon vendors, the largest base of developers (if you're looking to hire systems folks with experience with the kernel), and was easier to explain to carriers, OEMs, silicon vendors, investors, etc. The hardware platform was no longer highly constrained: at Danger in 2000, we started with a 24MHz ARM7, with no MMU, 8K unified cache, 16MB ram, 4MB flash -- at Android in 2005, a 200MHz 64MB ARM9 based system was the baseline -- we had a MMU! luxury! -- Linux no longer seemed like overkill for the hardware at hand.

Linux also draws a bright line between kernel and userspace with the explicit carve-out in the COPYING file declaring that userspace code need to be GPL to interface with the kernel. Explaining that "kernel is GPLv2, userspace is Apache2/BSD/MIT" is pretty straightforward. Explaining that everyone benefits from having a better kernel but the kernel is seldom what makes one product win or lose in the market is also pretty straightforward (seriously -- users only know the kernel exists if it's not working, otherwise it's not what they care about at all).

Realistically, it should be under a week's work for somebody to use the NDK (native development kit) to throw together an Xserver that runs inside a SurfaceFlinger (Android's compositor) Surface and then you could run whatever existing X-compatible thing under that. You could build a wrapper/adapter app that would allow "native linux apps" to trivially run this way (basically app xserver/clientlibrary window compositor/windowmanager).

It's not hard to build open source software to run on Android and there are plenty of tools to help you do it, especially on Gingerbread were the NDK provides support for native (C/C++) apps.

Yes, Android is not natively X11/Gtk/whatever, but that certainly didn't stop people from getting this stuff to run on Win32 or OSX...

https://market.android.com/details?id=com.google.android.apps.authenticator

https://market.android.com/details?id=com.google.android.apps.authenticator

I'd argue that having an open platform that Google can ship their apps on is extremely important in the huge and quickly growing mobile space.

It would be unfortunate if the only game in town for mobile OSes were a closed platform where only software approved by the platform owner could be installed. How could one defend against such an eventuality? Perhaps one might invest in building a competitive open mobile platform and make it widely available, no strings attached.

The "collecting data" thing is a bit tinfoil hat-ish for me. I see it much more simply as "if it's impossible for users to use your apps because the dominant platforms are controlled by folks who shut the door on you, you're going to have trouble obtaining (or keeping) users."

Android has a HAL for GPU integration (we call it gralloc), Gingerbread brings incremental and concurrent GC in Dalvik, and the Gingerbread NDK provides for all-native development options, among other improvements. You're welcome.

http://android-developers.blogspot.com/2010/12/android-23-platform-and-updated-sdk.html

Nexus S will ship with support for "fastboot oem unlock", allowing for reflashing of the system software "out of the box", like Nexus One.

Something that may interest this community is that the NDK (native development kit) for Gingerbread now supports native apps (intended to simplify mobile gaming ports, etc) -- providing: libc, libm, libz, opengl|ES, opensl|ES, input/events/sensors, app lifecycle management, etc. JNI is available to access various higher level Android APIs as necessary.

2.3 (platform 9) SDK: http://developer.android.com/sdk/android-2.3.html
2.3 (revision 5) NDK: http://developer.android.com/sdk/ndk/index.html

Platform sources should ship at or shortly after commercial launch of Nexus S.
Kernel git repository (2.6.35 + android + s5pc111/nexus-s) will be available at or shortly before launch.

Enjoy!

Use adb install to install apps via usb (including third party app stores).

If it were possible to ship the N1 with the necessary collection of power amps and suitable antenna design *without* impacting the form factor (making the device thicker) to support both AT&T and TMO and the standard european/world GSM/UMTS bands all in one device, we would have shipped it that way.