Subject: Re: Exploring the limits of free software
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Wed, 26 May 1999 16:25:02 +0900 (JST)

>>>>> "g" == D V Henkel-Wallace <gumby@zembu.com> writes:

    g> That wasn't the point I was referring to:

    g> I put up an rfp on sXc: I need someone to add VBscript support
    g> to gdb.  I find someone to do it.  I get the work I paid for.

    g> The gdb maintainers later reject it, perhaps because it's
    g> poorly written (likely) or perhaps (as I suspect because the
    g> hypothetical me is paranoid) for ideological reasons.  So it
    g> stops working in the next release and I get pissed off.

Ah, I see.  But "silly you," I think.  "You" still have VBscript
support for a working gdb.  I don't see why "you" are pissed off.  You
have the following options:

(1) Suffer without the new features.
(2) Talk to the GDB maintainers in advance; if they agree that
    VBscript is ideologically acceptable, you have an arm to twist if
    they refuse it.  How well that works depends on how you and 
    they go about reporting your original communications to the
    'Net.  That's politics....
(3) Talk to the GDB maintainers ex post, find out what they need to
    accept the patch.  Hire somebody to do it right this time.  You're 
    in really good position to twist arms if they say no again.
(4) Hire somebody to port the necessary GDB features to your version
    (this should be fairly cheap if the original support was
    well-written; it's all open source).
(5) Hire somebody to port the VBscript support to a later version of
    GDB (same gloss as (4)).
(6) Make (partial) payment contingent on acceptance by the GDB
    maintainers.

None of these options should involve much additional expense, unless
you bought crummy work in the first place.

You're absolutely right that decision-making weight won't be
proportional to financial weight here.  I should have been more
careful about my phrasing; all I really meant was that finance will
change weights, possibly in ways we don't like a priori.

(6) is a perfect solution except for two problems.  The first is
probably what you've been thinking about all along: the people who can
most easily accept such a contract are the GDB maintainers themselves,
creating a "conflict of interest."  But that's really what I was
referring to when I wrote about "financial weights".  As long as the
source is still free, I don't think there's much loss here.  The
second is that if "you" are a big, risk-neutral corporation, and the
contractor is risk-averse, there is an efficiency loss.

I suspect that there will be some efficiency loss (in a certain
technical sense) and that it can be only partially offset by properly
designed contracts.  But such a market should be an improvement over
no market at all.

Oh, and by the way, (6) has an interesting incentive effect - only
competent programmers intending to do a good job will apply, since
they know their work will be peer-reviewed, and failing costs them
money.  Lack of peer review if the contractor is the maintainer is
the real cause of the "efficiency loss" due to conflict of interest
mentioned above.  But this is probably not a big problem: after all,
you chose gdb because it was the best available software, and if
patches were mostly getting in because they were written by the
maintainers for quick bucks, that would change, fast.

-- 
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 two straight lines for?  "Free software rules."