Reversing the trend
In the past many, if not most, Linux drivers were developed by reverse engineering binary code, by trial and error, and less frequently, from the technical specification. For the most part these drivers worked well. The problem from the Linux user's perspective is that there tends to be a time lag. If there is no native driver, one will come later. If there is no cooperation from the original manufacturer some features may not be supported. On occasion, the result may be superior, because the original bugs may be found and by-passed in reproducing what the device actually does, as opposed to what you might think it does.
Much has changed in the last decade. Linux is a mainstream operating system with a growing presence in a number of divergent markets. Historically, providing support for Linux has not been top of the priority list for many manufacturers. But the lesson of free software is that collaborative software development works and broadens the scope of the hardware. On the server side, the major manufacturers have long realised the importance of supporting Linux. Many willingly contribute open source drivers and development effort towards the Linux kernel. The rise of Linux in specialist and developing markets may force the hand of manufacturers who are becoming less competitive in these markets.
Blobs of binary code are unsatisfactory for many reasons, not least of which is the technical shortfall they represent.
If a vendor provides a binary only driver there is no guarantee that it can be deployed across the many different architectures that Linux supports. Binary drivers may have perceived advantages for the manufacturer, but are inconvenient, and do not always fit the billing. In some cases they have been deficient.
The adequate solution is to provide open source drivers that provide the opportunity for debugging and optimisation, and extend the usefulness of the hardware, not just on Linux but on all platforms. Freeing the specifications in the manner suggested by Kroah-Hartman can provide time-to-market, cost and performance advantages.
Some vendors remain resistant to releasing open source drivers for the components or devices they manufacture, but there are compelling reasons why this should not be the case.
You might think that the software component of a device is, or should be, secondary to the hardware component, but this is not the case with modern electronic devices in which software is often central to the functionality and smooth operation of the hardware, and the drivers are often as complex as the . Drivers are not developed in a vacuum, and in a polyglot world, there may be significant cultural and language reasons why specifications (and even code) are not so easily released into the outside world. Manufacturers also devote disproportionate resources to software development, and want to keep the methodologies secret, for fear of losing advantage over competitors or giving away trade secrets, the elements that make their hardware distinctive.
Secrets and lies
These arguments have some credence but ignore the reality that competitors will reverse engineer the hardware and the code at the first opportunity, and will attempt to utilise any development that produces a perceived advantage, irrespective of the wishes of the original manufacturer.
