Re: Open Source Developer (Economics)

>>>>> "Julius" == Julius Steyn <[email protected]> writes:

    Julius> Hi gentlemen,

I wish my wife were so polite. :-)

Ian Taylor, as usual, has a well-focused take.  Robin's suggestion was
intriguing, too.

    Julius> During the latter part of 2002 I became involved in
    Julius> co-sponsoring an OSS project which initially from a
    Julius> financial and business sense just did not make sense to me
    Julius> - but the concept of a sound sustainable business that
    Julius> could add value to the lives of several thousand like
    Julius> minded individuals intrigued me sufficiently to take on
    Julius> the project.

OSS/free software makes generic business sense only as an heuristic.
The underlying concept of free software (Richard Stallman, The GNU
Manifesto) is that intellectual assets, and particularly software, are
morally no person's property.  Therefore, you may not make any
contracts on software -- everything is reduced to spot exchange.  So
once you transfer the software, you may not place any restrictions on
its use.  This is just too extreme (and even the GNU GPL violates that
principle).

There are a couple of general principles, though.  First, if something
is not your core competence, open source it.  The option value of it
"turning into a killer app" is low, and you probably wouldn't be the
one to exploit it anyway.  Making it open source, especially copyleft,
allows you to share in the benefit of any community development, plus
the warm glow of being "socially conscious" that attaches.

Second, where the network benefits of a shared platform are high, you
may want to open source the platform then develop apps on top of it.
This has its problems -- famously, X11 and Unix are too "policy free"
and lots of the benefits of standardization were supposedly lost, as
compared with say Apple or Microsoft.  But TCP/IP has literally
achieved world domination, and Apache has as good a chance as any to
do the same in its field.

However, in most business applications, there are two problems.
First, since you basically concede control of distribution, revenue
becomes problematic.  (That's what most FSBers are most concerned
with, of course.)  For some business models, this doesn't matter.  For
example, suppose you're in the business of teaching use of software
packages.  Then the wider the distribution, the better---that's more
customers for you, and you love free software (as long as somebody
else is putting it out there!)  Then there's the Aladdin Ghostscript
model: identify a few high-revenue customers, charge _them_, and
otherwise allow open access to source and use.[1]  This is _not_ OSS,
but if this were the dominant proprietary model it would be very hard
to get most people interested in "True OSS", I think.

For this reason, OSS can lead to extreme market failure, if

       Proprietary Revenue > Cost of Development > OSS Revenue

since the product may not be developed at all.  This is _certain_ to
happen in many cases because development cost has a large proportion
of specification/design/market research.  You just never get to the
point where even a feasibility study makes sense.

The second problem is more subtle.  That is that from the point of
view of social benefit, OSS hackers are likely to often misdirect
their efforts to the less valuable products.  Let PR1, PR2 be the
proprietary revenue to products 1 and 2 respectively, FR1, FR2 the OSS
revenues, and C the (common) cost of development.  Then

                     PR2 >> PR1 >> FR1 > FR2 > C

(where >> means "much bigger than") is all too likely a scenario.
It's not universal, but it's likely to be fairly common.  While PR !=
gross social benefit as free software, it's likely to be highly
correlated.  So there is market failure: the OSS developers will
work on project 1, and the net value PR2 - PR1 gets dropped on the
floor.  (Yes, this aggregates to a world with more than one OSS dev
team in it: so many projects, so few of us, no?)

Now let's consider a mixed economy with both free software and
proprietary software in it.

    Julius> The discussion I wish to initiate is based on various
    Julius> published reports that indicate the lack of OSS with
    Julius> respect to "business critical" or "Mission Critical"
    Julius> software that can effectively compete with SAP, ORACLE
    Julius> finance, ORACLE HR, SIEBEL, to name a few examples.

("Mission critical" is not the right term here.  TCP/IP is mission-
critical to the Internet, it was originally OSS and still is, although
there are proprietary variants---mostly based on the original OSS.)

These products are specification-intensive.  You need to know a lot
about business to produce them.  It's not surprising that OSS didn't
get there first.  Developers by and large dislike management; you
really don't think they're gonna lose sleep trying to develop large
scale management apps?  :-)  However, I agree with those who have said
OSS will produce similar apps in the near future.  These products
are themselves the specification, now.  (This is disparagingly called
"taillight-chasing", but it will still produce huge amounts of social
value as the price of OSS "vanilla" versions drops and the
functionality becomes universally available.)

Note that they don't come close to either of the general principles
above, either.  The software _is_ the core competence at this stage of
the industry.  Nor are there currently large network externalities, in
the sense that these packages mostly stop at the boundary of the
organization.

That suggests an indirect approach where OSS targets "distributed supply
chain management", and tries to encroach on SAP's territory by working
"from the walls in".  HR and finance would be hard to do that way, though.

    Julius> Why is it that OSS seems to focus mainly on server
    Julius> environments, web applications and firewalls?

They're easier to specify without a large non-technical research
effort.  Nor do they require adaptation to, and conformance from,
whole organizations.

    Julius> Could possible reasons be related to; Licensing, OSS
    Julius> Legacy environment, lack of appropriate skills, or an
    Julius> industry "norm" to avoid these market segments?

I think the main barriers facing OSS in this area are lack of skills
to _specify_ the new product and so establish a leading position, lack
of resources to finance development to compete on features and quality
when coming from behind, and lack of resources to finance the
consulting support.

    Julius> Are we aware of any such initiatives (real quality) that
    Julius> are currently active that require assistance albeit
    Julius> financial, marketing, strategy or other

I don't know of any such, but what I would look for is to get bought
out by a large "solutions provider" who wants to get into that market
but does not currently have a competitive product.  Say, IBM on the
technical side, or BCG on the consulting side.  From their point of
view an OSS solution is attractive because it makes the proprietary
products cost-ineffective from a basic functionality standpoint.
(Like the frequently discussed strategies of IBM and Sun
w.r.t. OS/webserver, supporting Linux and Apache.)  Then they can
focus on the value-added consulting parts, while the incumbents will
be psychologically and organizationally committed to the rapidly
devaluing base software, and may not be nimble enough to change
strategies in mid-stream.

I think you really need a tie-up with somebody with consulting muscle.


Footnotes: 
[1]  You can quibble that the license actually prohibits all
commercial use, and it has been enforced, eg against book publishers.
But economically speaking, most of the value is in the printer/fax
manufacturers on the one hand, and the direct use in document
processing.  "Printer mfrs pay, otherwise just like open source" is
close enough in those terms that the simplification justifies the
slight incorrectness.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.