After reading the Linux 2.6.37-rc3 release announcement
on the Linux kernel mailing list, another interesting thread was found and it's about getting hardware vendors to do their initial hardware bring-up under Linux prior to any Microsoft Windows or Apple Mac OS X support. A number of reasons are provided why hardware vendors should support their hardware first under Linux and also why they should foster open-source drivers along with its challenges.
Luis R. Rodriguez, a contributor to the wireless Linux kernel stack along with MadWiFi and Prism54 projects, among others, wrote Challenges with doing hardware bring up with Linux first
. Luis has worked on bringing up hardware support in Linux for Atheros wireless hardware. In this mailing list message, Luis expresses his wishes for hardware vendors to target upstream Linux drivers first prior to any other OS rather than the common situation where Linux support only comes after the hardware's been released, or if you're lucky as a customer at the same time as the Windows / Mac OS X drivers.
Luis believe that proprietary drivers exist so companies can continue producing quick, sloppy drivers with little oversight and quality assurance. Besides doing hardware bring-up in Linux first going to please Linux users with better and/or more prompt hardware support, Luis believes that vendors will begin caring more about driver architecture design in general and this could lead to better quality drivers for all platforms. Ultimately this message talks about creating a possible common driver architecture for other non-Linux operating systems within the Linux kernel's staging area for an OS agnostic solution to help hardware drivers in supporting Linux as well as other operating systems.
A discussion has already ensued with thoughts ranging from focusing instead on providing shim wrappers so that by developers targeting these agnostic wrappers on Linux, which in the case of the WiFi drivers would in turn communicate with the respective operating system's wireless stack, to relicensing parts of code under more permissive licenses.
As Alan Cox said, "It's a nice idea but the corporations exist to make money and adding proprietary custom stack add-ons is clearly a good move on their part to do that."
The discussion is still ongoing with many mixed messages already, but you can read this thread
to see what happens.