Manufacturers of peripheral hardware (Ethernet cards, disk controllers, video board and the like) have historically been reluctant to open up. This is changing now, with players like Adaptec and Cyclades beginning to routinely disclose specifications and driver source code for their boards. Nevertheless, therere's still resistance out there. In this appendix we attempt to dispel several of the economic misconceptions that sustain it.
If you are a hardware vendor, you may fear open-sourcing may reveal important things about how your hardware operates that competitors could copy, thus gaining an unfair competitive advantage. Back in the days of three- to five-year product cycles this was a valid argument. Today, the time your competitors' engineers would need to spend copying and understanding the copy is a substantial portion of the product cycle, time they are not spending innovating or differentiating their own product. Plagiarism is a trap you want your competitors to fall into.)
In any case, these details don't stay hidden for long these days. Hardware drivers are not like operating systems or applications; they're small, easy to disassemble, and easy to clone. Even teenage novice programmers can do this -- and frequently do.
There are literally thousands of Linux and FreeBSD programmers out there with both the capability and the motivation to build drivers for a new board. For many classes of device that have relatively simple interfaces and well-known standards (such as disk controllers and network cards) these eager hackers can often prototype a driver as almost rapidly as your own shop could, even without documentation and without disassembling an existing driver.
Even for tricky devices like video cards, there is not much you can do to thwart a clever programmer armed with a disassembler. Costs are low and legal barriers are porous; Linux is an international effort and there is always a jurisdiction in which reverse-engineering will be legal.
For hard evidence that all these claims are true, examine the list of devices supported in the Linux kernel or in the driver subtrees of sites like Metalab, and notice the rate at which new ones are added.
The message? Keeping your driver secret looks attractive in the short run, but is probably bad strategy in the long run (certainly when you're competing with other vendors that are already open). But if you must do it, burn the code into an onboard ROM. Then publish the interface to it. Go open as much as possible, to build your market and demonstrate to potentional customers that you believe in your capacity to out-think and out-innovate competitors where it matters.
If you stay closed you will usually get the worst of all worlds -- your secrets will get exposed, you won't get free development help, and you won't have wasted your stupider competition's time on cloning. Most importantly, you miss an avenue to widespread early adoption. A large and influential market (the people who manage the servers that run effectively all of the Internet and more than 17% of business data centers) will correctly write your company off as clueless and defensive because you didn't realize these things. Then they'll buy their boards from someone who did.