Subject: Re:
From: "Jonathan S. Shapiro" <>
Date: Sun, 1 Mar 1998 15:09:24 -0500


A couple of thoughts, amplifications and (perhaps) clarifications on
your note.  A general observation: it's always better to acknowledge
the issue and address it than tell the person they are an idiot --
even when it is true.

> Objection: Hacked Code... Why use a third party's losing code when
> you could stick with the vendor's code?

This argument cuts both ways, and I don't recommend it.  A better
response might go like this:

   1. Acknowledge the Issue:

   Customers who run Windows or similar operating systems go to the
   source for their drivers.  That's generally Microsoft, or sometimes
   the vendor.

   Hacked source *is* a potential issue for other operating system
   users, but it is not the *vendor's* issue -- those people elected
   to run a system the vendor doesn't support.  Period.

   2. Point out the upside:

   When you look at where the performance advances are coming from,
   they aren't coming from industry.  They are coming from private
   individuals and researchers.  As a recent example, look at what the
   'UNET' project was able to do by rewriting the board-level
   microcode.  They took relatively "conventional" designs and turned
   them into miraculously high-performance devices.

   The best way to get good numbers, and to leverage those smart
   people, is to provide access to low-level documentation.

> Objection: Getting stuck supporting a third-party product.... the
> customer actually bought your product, so they are a customer.

This argument won't wash.  The vendor isn't worried about hardware
problems here.  The vendor is worried about installation support,
which is why they only support selected platforms.  While the customer
bought the board, they are using it in an unsupported fashion, and the
concern about customer support is real, legitemate, and pressing.

I'ld propose a different response:

   1. Acknowledge the issue:

   Yes, you are going to receive phone calls from some Linux users
   [substitute appropriately for "linux"].  

   2. What to do:

   Support calls for Linux can be handled in two ways:

      a) Tell them that you don't support Linux, they are welcome to
      return the board to their vendor, and that's that.  The board
      will quickly become known in the Linux community as expert-only,
      and the problem will go away.
      b) Tell them that while the *vendor* doesn't support the board
      in that configuration, information is available from [insert URL
      here].  Because the vendor doesn't support the board, the vendor
      takes no responsibility for the results of using that
      information, but as a service to our customers...

   In exchange for the fairly small step of doing (b), their product
   will likely gain appeal in the free software world, which will
   encourage those smart software people (who I mentioned above) to
   wring superb performance out of them.

   Point out to them that the second approach actually offloads
   support cost that they would actually be *paying* for if the user
   was running Windows, so it's found money.

> Objection: Supporting third-party developers.

   1. Yes you will get calls.
   2. Be willing to ship out the documents at cost, and no more.  You
      have to build those documents for internal use anyway.

      If you choose to be more active to promote sales, identify one
      or two contacts in the free software community to work with
      actively, and let *them* be the relay point for support.

General comment:

The vendor is being asked to make a cost/benefit/risk decision.  What
they need to hear is that the cost of putting this information out
their is small, and that the benefit is a larger customer base *who
will make their product work better.*  The real benefit to the vendor
is that by learning from the techniques that third parties come up
with they become able to deliver better products in the future.