Subject: Re: funding indirect services
From: "Stephen J. Turnbull" <turnbull@sk.tsukuba.ac.jp>
Date: Sat, 29 Jul 2000 10:38:38 +0900 (JST)

>>>>> "Brian" == Brian Behlendorf <brian@collab.net> writes:

    Brian> The only point I'll throw in is that sometimes there are
    Brian> tasks that "need doing" on an open source project that are
    Brian> either too complex or too boring or too large for the
    Brian> available volunteer resources at the time - and it's not
    Brian> inappropriate to augment those volunteer resources with
    Brian> paid resources

I don't see this as responsive to Crispin's point that the primary
models of OSS development to date (volunteer/potlatch and funded
research) don't directly generate revenue to support "paid resources."

    Brian> so long as those paid resources follow the
    Brian> same meritocratic principles that cause open source
    Brian> projects to generate high-quality code.  That's the raison
    Brian> d'etre for both sXc and Cosource.

I see the code-quality point, now that you make it explicit.  The
refereeing process and the milestones are clearly intended to support
quality-oriented contracts.  But

    (1) writing quality into the contract seems to be left up to the
	needs of the parties (either _could_ demand quality, but both
	have some incentive to trade quality against other values)

    (2) neither sXc nor Cosource requires participants to construct
        tasks that can be integrated into the original OSS project.

I'll take the XEmacs/GTK+ sXc project as an example.  One of the
reasons it has not been done is that most of the XEmacs review board
felt that it would _hurt_ maintainability of XEmacs as a whole.

Current efforts are to try to integrate the main application loops as
much as possible.  This can't be done with the NT port, but requiring
NT users to run an X server or GTK would be unacceptable to most.  The
GTK main loop similary doesn't support some features many users desire
from XEmacs (in particular, multiple displays).  OTOH, on *nix
systems, would-be GTK users can run the Xt version, without requiring
extra software.

So unless either the contractor decides to support this port as a
volunteer, or the client decide to put continuing resources into the
project, it seems very likely to be orphaned, as a false start.  I
don't know how Bill feels about it today, but early comments suggested
he saw it as an interesting toy, but not his own preferred version.
So probably no volunteer support.

I suspect BeOpen.com will put more resources into the project, but
that's by no means certain.  For one thing, I suppose that one
motivation on BeOpen's part was to try and get people interested in it
once it was initially started, and so get maintenance for free.  I
have seen no traffic on the developer's list recently, so that doesn't
seem likely.

So it seems to me that rather than being driven by the mainline OSS
project's need for resources, this particular project is driven by the
patron's desire to create an expensive experimental branch without
forking the project.

I think this is undeniably an important class of task that the OSS
exchanges will be called on to facilitate.  I would go further and say
that I think that the exchanges are basically a way for patrons to
vote for tasks with money, rather than by persuading projects that
they need to be done.  That's very arguable, of course.

Some of my friends see a similar effect from the employment of
principal Linux developers by the distros, especially orphaning of
older Sparc hardware because Dave Miller's employer doesn't see much
use in supporting it.  Different mechanism, same of effect of
redirecting resources from the volunteer decided agenda to a more
commercial one.

Of course I don't see this as a bad thing, I'm an economist.  I see
some redirection of resources away from the community agenda, but the
main effect is redirect more resources into the OSS area as a whole.
But many people strongly dislike the influence of such economic
considerations on what had been a wholly political process.

-- 
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."