| Russell Nelson, President, | | nelson@crynwr.com |
| Crynwr Software | http://www.crynwr.com | |
| 323 W Clinton St. | +1-315-600-8815 | |
| Elmira NY 14901 |
Are you a hardware vendor who includes a proprietary Windows driver with your product? If so, I intend to convince you that documenting your hardware, and providing OSI Certified(tm) open source drivers, generates enough value to overcome the risk that your trade secrets will be stolen.
You're in business to make money. You engage in activities that advance you towards that goal, and refrain from activities that don't. Therefore, the only sensible reason for holding information (drivers, and hardware documentation) proprietary is to protect your business from activities which would reduce its profit.
One reason is simply because you can -- because the law allows you to. Another is because you believe it is traditional and expected. Another reason is because someone told you to -- perhaps an investor or other trusted party. But these reasons aren't rational unless they advance the goal of making money.
A bit about myself: I have been developing Ethernet drivers for almost fifteen years now. Ethernet adapter companies have rarely held back information on how to program their products. This is largely because they had to seek market share wherever they could get it. They had to work with the authors of various driver suites to make the full profit available from their products. Open documentation has always been standard in that market.
The big fear of any company is competition. Every good capitalist wants a monopoly on their own products. Any hook that keeps out the competition has been used, and holding information proprietary is one of them. However, there is no such thing as a free lunch, and keeping information proprietary has its cost.
One of these costs might be that your competition has started to benefit from Open Source. There's an anti-competitive effect of a cartel when all the manufacturers keep all information about their hardware proprietary. No customer gets a benefit from choosing Open Source because that's not one of the choices. The first product with an Open Source solution has an advantage over the competitors, and avoids problems due to partial solutions.
Another cost is not telling people how to use your product in the manner *they* wish. You are requiring them to abandon their chosen method of using your product, and pick up your method. This has a learning curve associated with it, so they will not buy your product as quickly as they might. It may make their use less efficient, so that they cannot afford to buy as much of your product. It may drive them to your competition, who might also be holding information proprietary, but whose approved method is more in line with the customer's chosen method.
Many companies are proud of their engineering, and rightfully so. It is a mistake, however, to presume that you know the customer's business as well as that customer. Some customers may have innovative and profitable uses of your hardware that you haven't anticipated. If you hold information about the product proprietary, you will never know about these customers, because they will simply not exist.
Yes, you can use a nondisclosure, but there are costs and risks to using them. The kinds of synergies that open up new markets are novel and unexpected. A nondisclosure interferes with this discovery process -- and the markets it creates.
If you execute a nondisclosure with everyone, then what are you not disclosing if everyone can find out about it? In the world of science, many discoveries have been casual accidents. Nondisclosures get in the way of those accidents.
One way to discover the possibilities of your products is to look at how your engineers (who don't need nondisclosures) use your products outside of company time. Are they doing interesting things? If so, think of the interesting and profitable things your customers will dream up.
Other times a customer needs to make your product work in their environment, and alas, your engineering has a flaw. The less you tell that customer about your product, the less likely they are to be able to fix the flaw for you. Many, many times I have had packet driver bugs fixed, not just by amateur hackers, but by paying customers. The value of even a single fixed problem is inestimable. It is extremely difficult to decide which customers are able to fix bugs. Only universal nondisclosure can solve that problem. And you'd be surprised by who fixes some problems. Someone in MIS at (a national automotive repair chain) whom I had never heard from before, sent me a bug fix for the token ring packet driver which allowed it to run under Netware as well as TCP/IP.
So far, I have assumed that not voluntarily disclosing information actually succeeds in keeping customers (aka potential competitors) from learning anything they need to know about your product. This is not the case. I can assure you that "no reverse engineering" shrink-wrap license terms are universally ignored by everyone concerned. The first thing an engineer does is whip out the reverse compiler to see how the code operates. This is not hearsay. When I was consulting for (a silicon valley fabless design shop), I actually saw a reverse-compiled listing of the 3C509 driver less than a week after 3Com started distributing it, with notes as to how the product worked. I produced my own source of MS-DOS which could be modified and assembled. I know someone else who did the same thing.
Customers have been known to reverse-engineer products also, but they usually have less economic incentive. For a while, Diamond held back their variable VGA clock interface as proprietary. The information itself was widely available anyway. Connectix didn't want to release programming information for their Quickcam, but users reverse-engineered it. Eventually they released programming information after the horses had left the barn.
The benefits, then, of not disclosing programming information are slim compared to the costs. A company that wishes to compete with you must make substantial investments in mechanical and electrical engineering, plastic molds, certification, prototyping, production, sales, and marketing. Another few thousand spent on the due diligence of reverse-engineering the competitor's products is a trivial expense.
There are some costs involved in releasing documentation and driver source. The documentation has to be good enough that people can actually use it. You have to develop a policy on answering questions about the documentation (charging a fee is not unreasonable). The driver source may not be in a state that you want to expose to the public. It might be poorly written. It might have profanity, or might have derogatory comments about the competition.
Another cost is that of maintaining a documented hardware interface. You might wish to keep the freedom to change the hardware interface, to lower costs or add functionality. You don't lose that freedom if you disclose programming information. All you need do is tell people that you are keeping that freedom. Give them a way to identify the hardware that matches the documentation. When the hardware interface changes, change the identification.
There is a conern in some quarters that Open Source projects will diminish the perceived quality of the product. People will see the product perform at a level below your target. This is a legitimate concern, but there are mechanisms to address it. For one, you can explicitly refuse to license your trademarks to Open Source projects. You can also alert your customers to the fact that you only support your own software. You can let them know that their warranty expires if they run non-certified software. You can establish a certification mark for use by third party software, which you only let them use if it meets your quality targets.
Many products follow industry standards because customers perceive value in compliance with standards. If your products qualify for Open Source certification marks your products are more attractive to some customers.
There is no evidence that proprietary documentation and drivers causes greater success in the marketplace. Instead, there are counter-examples that show that open documentation doesn't hurt. 3Com gives away information on how to program their network adapters. So does SMC. So does Intel. If proprietary documentation was truly a help, then how to explain these company's success?
Hardware manufacturers, please document your hardware, and put that documentation up on your web site. Please use an OSI Certified(tm) open source license on your drivers, and put them up on your web site.