Subject: Re: Bug Bounties. Making $ from bugzilla.
From: "Stephen J. Turnbull" <stephen@xemacs.org>
Date: 26 Nov 2001 11:18:22 +0900

>>>>> "Kevin" == Kevin A Burton <burton@openprivacy.org> writes:

    Kevin> The system supports microscopic issues as opposed to
    Kevin> macroscopic issues.  SXC really tried to fix HUGE problems
    Kevin> (port XEmacs to GTK, etc).

But that wasn't a huge problem in an economic sense; it would have
been done anyway (within a year or two, which is "soon" by the
standards of Emacs release cycles).  That was a _business_ problem,
Bob Weiner needed that port yesterday, and perhaps paid with his
company for lack of timeliness.

I think the scale of sXc was forced not by the desire to fix big
problems, but by the fact that to generate enough revenue per contract
to be self-supporting, ie, cover the transaction costs, it needed to
generate big contracts.

I don't see how this system gets around that.

    Kevin> We fix bugs AND RFEs.

Getting bugs fixed, now that's a _huge_ problem.  "Herding cats,"
"pulling teeth."  As an XEmacs maintainer, I can confirm that I see
very few high-quality fixes as one-offs.  And I don't get paid for the
fixes; I'm not about to give a bad patch an easy time because somebody
else might get paid for it!  But it's hard to get good patches even
from the regulars if it's not on what _they_ perceive as the critical
path.

It seems that for a project like XEmacs, this would just result in (a)
beer money for some of the regulars and (b) even more scarcity of
talent willing to work to the long term plan.

This points to another real incentive problem, too.  I don't
deliberately introduce bugs into XEmacs.  I don't think that's a
problem in any OSS project.  But there's no need to.  There are enough
"bugs" (as perceived by the user base) that I can demote a few
thousand to "fix by 2100" status, even though I know how to fix them.
I think others are more important, important enough to spend time on
diagnosis and design etc rather than fixing what I know how to deal
with.

However, it would be easy to pull a few of those minor bugs off the
shelf in time for Christmas.  But this would not be good for the
project.  IMO, as maintainer, anyway.

    Kevin> ... etc.

Now that, I agree with wholeheartedly.

Your proposal _can_ work.  But only if somebody works _hard_ on
mediating between would-be fixers and overworked maintainers.  It's
not something that can be addressed with a pile of software and a few
rules of payment.  It's _people_ work.  And it's _technical_ too, so
the principal has to be multi-talented.  And it's _retail_, so I doubt
it will be very profitable.

Russ Nelson could do it with qmail I bet.  I think I can guess why he
hasn't.


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