Afterword: Why Closing a Driver Loses Its Vendor Money

Manufacturers of peripheral hardware (Ethernet cards, disk controllers, video boards 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, there is still resistance out there. In this appendix I attempt to dispel several of the economic misconceptions that sustain it.

If you are a hardware vendor, you may fear that 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 damagingly large portion of the product cycle, time they are not spending innovating or differentiating their own product.

This is not a new insight. Former KGB chief Oleg Kalugin puts the case well:

For instance, when we stole IBMs in our blueprints, or some other electronic areas which the West made great strides in and we were behind, it would take years to implement the results of our intelligence efforts. By that time, in five or seven years, the West would go forward, and we would have to steal again and again, and we'd fall behind more and more.

But Rudyard Kipling put it better in his poem The Mary Gloster, nearly a century ago. He wrote:

And they asked me how I did it, and I gave 'em the Scripture text, 
``You keep your light so shining a little in front o' the next!''
They copied all they could follow, but they couldn't copy my mind,
And I left 'em sweating and stealing a year and a half behind.

Acceleration to Internet time makes this effect bite harder. If you're really ahead of the game, 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 almost as rapidly as your own shop could, even without documentation and without disassembling an existing driver.

Even for tricky devices like video and sound 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 and notice the rate at which new ones are added to the kernel even without vendor support.

Another good reason to open your drivers is so that you can concentrate on innovation. Imagine no longer having to spend your internal staff's time and salaries on rewriting, testing and distributing new binaries for each new kernel as it comes out. You certainly have better things to do with all that skill.

Yet another good reason: nobody wants to wait six months for bug fixes. If you have any open-source competition at all, they are likely to bury you for this reason alone.

Of course, there's the future-proofing effect previously referred to. Customers want open source because they know it will extend the lifetime of the hardware beyond the point that it is cost-effective for you to support it.

The best reason, though, is because selling hardware is what makes money for you. There is no market demand for your secrecy; in fact, quite the reverse. If your drivers are hard to find, if they have to be updated frequently, if they (worst of all) run poorly, it reflects badly on your hardware and you will sell less of it. Open source can solve these problems and boost your revenues.

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 the ROM. Go open as much as possible to build your market and demonstrate to potential 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 world—your secrets will still 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 a plurality of all 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.