RE: Open Source Developer (Economics)

"Chris Maeda" <[email protected]> wrote:
[...]
> >>>>> "Benjamin" == Benjamin J Tilly <" <[email protected]>> writes:
> 
>     Benjamin> One of the commonly cited factors is the question of who
>     Benjamin> you sue.  Decision makers often need to address the
>     Benjamin> potential fears of what they do if things do not work as
>     Benjamin> promised.  With OSS nobody wants to make legal promises,
>     Benjamin> our assurances work through community dynamics that are
>     Benjamin> unfamiliar to businesses.
> 
> I think this is a financial problem more than anything else.  When you
> need to recover damages (whether legally or via day-to-day procedures
> in the purchase contract) you know you can't get blood from a stone,
> and you can't recover damages that are many times the net worth of a
> company.  OSS by definition reduces the financial potential of
> vendors, both directly by foregoing a revenue stream, and indirectly
> by dissipating energy in inefficient directions (it's often the case
> that what is "fun to work on" or "profitable to provide support for"
> is not the highest-value product for the client).
> 
> If the finances were there, OSS vendors would be sue-able.  If current
> ones insist on GNU GPL-style "No warrantee, you're supposed to be
> giving alms to us, remember?" licensing, somebody would find a niche
> (and probably more than a niche) selling "insurance" in one form or
> another.  They probably would be better managers (hey, Mr. Steyn,
> maybe that's you!) than programmers, but that's called "division of
> labor" and it's a good thing.

If you think that you can make an insurance business
model work, feel free to do it.  As far as I can see it,
insurance needs a combination of good information on the
part of insurers and the ability to distribute risks.
The problem is that the act of giving out insurance
signals the information you possess to the world, and
many people will respond by saying, "This combination
gets insured, it must be safe."  The fact that someone
is willing to insure gives enough comfort that they don't
actually bother paying you for the information!  There is
also the threat that someone who figures out a way to
break the software will buy tons of insurance before
releasing the exploit.  Plus you will have endless
problems with finger-pointing.  You think that your
software is OK, it is a user problem, the user thinks
that they used it correctly, your software failed.  How
do you settle these?

Either way the would-be insurer has to do a lot of work
just to be in the business, and then has to set high
rates for their risks.  And setting high rates then
limits your potential market.

Furthermore you are not even protecting against the
correct business risk.  Most security exploits happen
because of mistakes in implementation and usage, not
because the products could not be used in a relatively
secure fashion.  Think "poor passwords", "social
engineering" and "disgruntled ex-employee".  Attempting
to insure the quality of the software while not
addressing these issues is silly.

A more feasible insurance approach would seem to be
something like:

http://www.computerworld.com/securitytopics/security/story/0,10801,46992,00.html

That is, an insurer is willing to consider your work as
a mitigating risk factor in a broader insurance policy
that solves a real business need.  The company that does
the work does not then need to have the financial
resources to be sued - they just have to convince some
company that does (ie the insurer) that the products of
their work really reduces risk.

Cheers,
Ben
-- 
____________________________________________
http://www.operamail.com
Get OperaMail Premium today - USD 29.99/year


Powered by Outblaze