[ I was originally only going to send this to Reinoud and Eric, but it might be helpful for FSB developers trying to work with manufacturers. -russ ] I have a few suggestions for www.opensource.org/secrets.html. I've worked with a number of manufacturers to pry documentation out of their fingers, and I've heard every one of these objections before. 1) Objection: Documentation helps competitors. Trade secrets in shipping products aren't very secret. Consider the investment needed to create a competing product. Think R&D, inventory, plastic molds, production runs, the whole nine yards. A competitor need spend only a tiny fraction of that amount to reverse-engineer your product. I know of a manufacturer creating an Ethernet controller who did just that to 3Com's 3c509 product. Reverse-compiled the drivers and burned the plastic off a chip. So much for not documenting anything! 2) Objection: Poorly-performing products. Yes, it's possible to a third party to create a solution which does not function well with your product, and which reflects badly on your product. It's more likely that that will happen if they have to waste resources uncovering your secrets. They're likely to do a good job if you reveal how best to use your product. 3) Objection: Company X did well and they kept secrets. No one is saying that you can't keep secrets and do well. We're saying that companies that don't keep secrets don't do poorly. Companies keep secrets out of fear of doing poorly. Your anecdotal evidence is not about a company that didn't keep secrets. 4) Objection: Hacked code. Yes, a third party could modify your code so that they perform incorrectly, or badly. In practice, this doesn't happen much, because a vendor of open source products makes his code easy to get. Why use a third party's losing code when you could stick with the vendor's code? 5) Objection: Getting stuck supporting a third-party product. You are concerned that your tech support will be pestered by a user of a third-party product whose tech support is weak. The key here is to remember that the customer actually bought your product, so they are a customer. Be up-front about it. Tell them that it's a third-party product, and that you don't know much about it, but you'll help them as best you can. If the situation becomes chronic, it could be that everyone wants to use the third-party product, and it's driving sales of your product, in which case you really ought to support it. 6) Objection: Supporting third-party developers. If this is your concern, then do not provide any support. If a developer calls, tell them that they get no support. If this situation becomes chronic, it's probably because you've got a hot product, and sales are brisk. Relax -- this is a good problem to have. 7) Objection: the only sizeable market is Windows, and we support them, so nobody needs documentation. This is simply not true. Embedded systems are a very big market these days. The profit margins per product are often very large because one sales contact results in many sales of product. Embedded systems developers rarely use Windows. There are a number of operating systems suitable for embedded systems. 8) Objection: If you want documentation, sign an NDA. While this helps third parties who wish to create proprietary solutions, it doesn't really help the author of an Open Source solution. It's hard to write good software without creating documentation to go with it. That documentation is going to violate your NDA. -- -russ <nelson@crynwr.com> http://web.crynwr.com/~nelson Crynwr supports Open Source(tm) Software| PGPok | Freedom is the primary 521 Pleasant Valley Rd. | +1 315 268 1925 voice | cause of Peace, Love, Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | Truth and Justice.