Subject: a model of competition between free and proprietary software
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Tue, 22 May 2001 19:08:57 +0900

>>>>> "Seth" == Seth Gordon <sethg@ropine.com> writes:

    Seth> The number of developer-hours that F can attract is roughly
    Seth> proportional to F's quality,

Hardly.  I can't imagine that qmail gets anywhere near the number of
contrib hours that Enlightenment gets.  This could be a measurement
issue, too (what is quality?) I guess.

    Seth> and if F's maintainer is competent, F's quality is roughly
    Seth> proportional to the number of developer-hours spent on it.

Not likely.  First, competent maintainers for large scale projects are
hard to come by in free software.  Cf Fred Brooks on teams; suffice it
to say that as the number of developer hours rises, what matters are
the management skills of the maintainer, not the programming skills.
Management is a thoroughly unpleasant task; nobody in their right mind
would do for free (says the unpaid XEmacs Release Manager) if they can
get paid to program (maybe that explains me? :)  But who's going to
pay the manager?

What seems more plausible is developer-managers, who operate in a
partnership.  But as the project expands, you need more dev-mgrs, and
they start to discuss among themselves.  This is why Linux distros are
"easy" to scale: you just split up the packages -- little coordination
needed.  This is harder to do with big apps (Emacs, Apache), even if
you modularize drastically.  Coordination is much easier if you
delegate to a single "boss" (literally in the P firm, a so-called
"benevolent despot" model in the F project).  But in the F world, some
of your best developers are likely to think of it as the "malevolent
despot" model.  It's hard to scale that, without paying the developers
to subordinate their creativity to the coordination.

Second, a technical comment: as the product grows, its complexity
grows exponentially (at any rate, it's much worse than the N^2 for
possible arcs in a graph of N nodes).  More plausibly Quality ~
Features * Dev Hours / Complexity.

Third, volunteer developers are not generally interested in working on
quality.  They're interested in working on features, which are
sometimes positively and sometimes negatively correlated with quality
as perceived by the user base.

    Seth> investors who supplied the original capital must be
    Seth> rewarded, and they must be rewarded at an attractive rate of
    Seth> interest, so P's sponsor has one *cost* that grows
    Seth> exponentially.

This is not true.  First order approx: If it was a loan, the cost is
fixed (per period).  If it is equity, no cost unless you can more than
afford to pay it.

    Seth> At a certain point, F's level of quality is so close to P's
    Seth> that if a customer needs one feature from F that P does not
    Seth> have, it will be cheaper for the customer to hire someone to
    Seth> extend F than to buy P,

This is a "suppose this happens" or "I have reason to believe it
_will_ happen" assumption?  The former is reasonable (Linux, gcc, GNU
tools in general, Apache), but begs the real question (which projects
will it happen to happen to?)  The latter I don't think a professional
economist would accept (this one doesn't, anyway).

My feeling is that a model that would allow you to discuss _which_
projects are likely to "take off" in this sense would be very similar
to a model in which you can discuss "why software patents are bad".
That is, it needs to account for related innovations.  But this will
be rather complicated.

    Seth> I know that the above scenario is missing a lot of details.
    Seth> (For example, I'm treating a product's "quality" as an
    Seth> attribute independent of its market share, and assuming that
    Seth> a customer's decision on which product to purchase is based
    Seth> only on "quality" and price.  This is certainly
    Seth> oversimplifying things.

These aren't objectionable for a first cut.  The productivity and
supply of devel effort assumptions above are much harder to swallow.
Even they would be acceptable as a first cut at a subset of free
software projects if you could say which projects the assumptions
apply to a priori.

This is one of the big advantages that P has over F.  There's an
operational definition of quality: "what the customers will pay for".
Another is that where quality and features compete for attention from
the same developer, as they often do, P can pay the developer to work
on quality.  This was mentioned by somebody else, but it's worth
noting that to extent that customer perception of "quality" depends on
a "coherent vision" of "what the product _is_", a single architect is
more likely to supply coherence, and money is the most effective tool
known for getting other people to implement one's vision.  Another win
for P.

    Seth> If one of the business or economics gurus on this list could
    Seth> give me a list of background reading,

You'll probably find technical economics pretty useless at this stage.
You might start with Charles Jones, "Introduction to Economic Growth,"
which gives a background in the kind of dynamic techniques economists
use.  (Don't be confused by the term "technology" as used in the book,
though; it doesn't have any relation to what you want to do.  Instead,
it simply means "any improvement in productivity we don't know how to
explain.")

Then I'd suggest the development management gurus, starting with Fred
Brooks (Mythical Man-Month, etc).  The SEI stuff on process maturity
is interesting from a descriptive social science viewpoint even if you
don't it as prescriptive for "good management."  You don't need their
technical tomes; stick with the sales brochures their consulting firms
distribute ;-)  Focus on stuff about teams, not technology (ie,
Brooks's "No Silver Bullet" is probably not relevant in your first cut,
not even the "reusable software" part).

All that said, I think at this point you've got something well enough
elaborated to write it down as a set of equations and solve it.  Or
you might prefer to write a simulation.  So it won't get you a PhD
from MIT, or even much notice from those who have them right off the
bat.  Who cares?  It's new.  You'll learn something, you'll have more
questions, some of which you'll answer for yourself.

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."