embedded devices and open source

[Ben Scott]

On 2/24/07, Jeffry Smith <jsmith at alum.mit.edu> wrote:
>>> And some don't understand what their product is.  ... Ask the
>>> company how many drivers they sell.  No hardware, just the
>>> drivers.  I'll lay you odds it's zero.
>>
>>  Of course, hardware without drivers tends to be zero, too.  Hardware
>> and software need to go together.  Most companies are developing and
>> selling the package.
>
> But the key is what is the motivation?  People buy the HW, and get the
> drivers because they're needed.  They want a video card/printer/modem,
> the software is something that's needed to make it work.

  No.  No.  No.  Not at all.

  People -- and businesses and organizations -- don't buy hardware.
They don't buy software.  They're willing to trade some of their hard
earned money for something that makes their lives easier or solves
some problem they have.  They don't care if it's hardware, software,
or a guy from India turning a crank.  Or some combination of all of
that.

  Likewise, businesses don't sell hardware.  They don't sell software.
 They sell products.  The revenue generated by said sales has to
exceed the cost of turning that product over to the buyer.  Those
costs include *everything*.  Raw materials.  Manufactured goods from
suppliers.  Capital investments (land, buildings, equipment, etc.).
Utilities (water, electricity, etc.).  Health insurance.  Training.
Research and development.  Manufacturing labor.  Marketing.  Legal.
And so on.

  Somewhere in that huge lists of costs, software development may or
may not show up.  If it does, then something *must* cover that cost.
Generally speaking, for the "embed ed market", software development is
mostly an NRE (non-reoccurring expense).  Or at least, it's treated
that way.  NREs are spread out over unit sales of the product, but
they are very much paid for.

  Say I buy a coffee pot.  Say it has a microcontroller that has 512
bytes of ROM that decides when to turn the heat on and off.  I didn't
set out to buy a microcontroller (hardware) any more than I did the
software.  I bought something to make coffee.  But I'm paying for that
software's development.    You can draw a line from me handing my
credit card to some Wal-Mart cashier all the way back to some code
grinder in Taiwan or India or whatever.

  A possibly more interesting argument (instead of "I'm not buying
software") is that, since I *am* paying for the software's
development, why shouldn't I get the right to see the source and
modify it as I see fit?  Maybe I shouldn't have the right to share it
with others, but shouldn't I at least be able to touch what I bought
and paid for?  Of course, that would bring in a whole 'nother tangled
ball of yarn.

> Right - fundamentally they are hardware companies.  the software is
> only to support the HW - they need it to sell the HW, but it's a cost
> of business, not a source of profit.

  *Everything* in business is a cost of business (see above for the
list).  There's one only source of profit in business: The customer.

> 1.  See previous answer - if they're doing the stuff in the driver,
> they're in the software (WInModem) business.

  Then I guess most companies are in the software business, because
that's the way computer products actually work these days.  Which
pretty much destroys your entire argument, then, right?

> If it's SW getting loaded on the card (firmware) - that's what FPGAs & ROMs are fore

  Or load it from a hard drive which the customer already has, thereby
lowering prices and saving the customer money.  (Or fattening the
bottom line (or both) of course.)

> 2.  Reverse Engineering - you're right, they need to be afraid of the
> poor FOSS guys who can't afford to build cards.  The competitors
> would never use debuggers, oscilliscopes, digital tracers, x-ray
> machines, and all those other tools they themselves use to
> reverse engineer the product :)

  Right, so why don't they publish all the design documents,
blueprints, and manufacturing procedures, too?  Oh, right, because
that would make it easier for their competition to steal their
business from them.

  Likewise, the possibility exists in some situations that their
competition will bypass the costs of software development by taking
the code the original company paid for and released as FOSS, thereby
enabling the competitor to sell their product at a lower price, and
steal away business.

  That's the risk that has to be weighed against the potential reward.

> Especially as complex as modern video cards are, knowing the
> input/output specs will not provide insight into the inner workings of
> those complex GPUs.

  Well, I don't know much about modern video cards, but I know enough
to see you obviously do not understand how they work.  It's not a
simple set of inputs and outputs like a 16550 serial controller.
Remember, these days, most video cards are sold as something more than
a really fast frame buffer.  They're extremely specialized devices,
with a lot of complex capabilities in the hardware, and they need
equally complex software to drive them.  NVidia and ATI both pour huge
amounts of money into software development.  Differences in driver
quality have made huge differences in performance (speed, visual
quality, reliability).  This isn't speculation; it's documented fact.
I can cite references if you like.

  Moving beyond fact into theory: Good source code is not just program
instructions.  It contains insight into flow, intent, and mindset,
just in the structure of the control statements.  And maybe -- just
maybe -- there are comments in there that explain the why and how of
what the code does, and thus explain how the hardware works.

  Now, exactly how much of a risk NVidia would take on by releasing
their code, I cannot speak to.  I've been told (by real people -- not
just corporate fronts, but people who have actually programmed these
things) that it's not just hypothetical.

> How well does knowing the x86 pinouts and assembly help someone know how
> the latest Intel processor work?

  Given that the x86's external interface is basically fixed in time
circa 1979, that's not a terribly good analogy.

>> What's the ROI likely to be?
>
> That's a key question - and if it's open source you get free labor -

  There's no such thing as "free".  They may get some labor they don't
have to pay for.  But it's not like software just appears on their
doorstep ready to run.  Indeed, a company that successfully leverages
FOSS ("leverages", ack, I sound like a suit) will often end up still
having a substantial software development budget.  But they multiply
the effectiveness of that money by opening the code.  In military
terms, FOSS can act as force-multiplier.

> ... which is probably why IBM & HP have been supporting Linux.

  If they're smart, IBM and HP have been supporting Linux because they
make more money in increased sales then it costs them to give that
support.  (If it's the other way around, it's a losing proposition,
and we in the Linux community are in trouble.)

-- Ben