Subject: www.opensource.org/secrets.html
From: Russell Nelson <nelson@crynwr.com>
Date: 1 Mar 1998 22:13:11 -0000

[ 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.