Subject: Re: Bug Bounties. Making $ from bugzilla.
From: "Stephen J. Turnbull" <>
Date: 27 Nov 2001 13:15:24 +0900

>>>>> "Kevin" == Kevin A Burton <> writes:

    Kevin> "Stephen J. Turnbull" <> writes:

    >> BTW, what was un-OPEN about sXc or

    Kevin> At least with sXc (I never used cosource) there was a high
    Kevin> barrier to entry.

OK, "barriers to entry" makes the point precisely.  Note that the
barriers to entry mostly have to do with QA costs, though.

    >> and I don't want the regulars on piece rate.  We've had enough
    >> problems when we've had people on salary.  The problem is not
    >> getting patches from the regulars.  It's getting good ones,
    >> when they don't expect to work on the subsystem being patched
    >> before somebody else does the next massive reengineering of it.

    Kevin> I don't understand the above...

OK, here's an example.  We have a maintainer whose motto is "We apply
no patch before its time", at least for his own subsystems.  But just
yesterday he admitted that in order to get some work done on his
subsystems which are common between XEmacs and GNU Emacs, he browbeat
me into applying a patch which synched an XEmacs API to GNU Emacs.
Unfortunately, the only thing he synched was the calling sequence, so
the documented functionality was not present, and in fact in
combination with a GCC optimizer bug (IMO) causes a crash.

This was an extreme case, practically fraud, but gray-area patches
cross my desk every day.  If bug bounties were involved, there would
be a lot more of them, and they would be harder to refuse than they
are now because the bug bounty is objective evidence of user needs.

That doesn't mean "apply" is the right thing to do.  The fact that the
maintainer's judgement about "badness" of a patch is subjective
doesn't justify discounting it.

    Kevin> It is a shame there isn't a happy medium.

But there is, at least between pure volunteer OSS and the proprietary
model you described.  It's just not generalized like your bug bounty
exchange.  It's called by various names: Aladdin, Altrasoft (defunct),
Apache, (defunct), Crynwr, Cygnus, Linuxcare (defunct?),
Lucid (defunct, hm, is there a pattern here?), Sleepycat, ....  The
FSB Honor Roll, each more or less specializing in extracting revenues
for making sure some particular software product works.

Unfortunately, it's a full-time job.  Part-timers get paid in personal
satisfaction, not in dollars.

    Kevin> A good example... say Bob produces a patch that is
    Kevin> terrible, can't be incorporated back into the project, but
    Kevin> fixes Alice's problem.  Maybe this is OK.  Bob could just
    Kevin> provide a binary of XEmacs (or whatever) and give it to
    Kevin> Alice.

This is definitely OK with me, as long as Bob points M-x
report-emacs-bug back at himself.  I know of at least one full-fledged
fork of XEmacs (the UTF-2000 project), and two projects that would be
forks if we didn't support DLLs.  But all this is just free software
in action, isn't it?, as far as I can tell, is/was a low-barriers-to-entry
system capable of providing infrastructure for this kind of exchange.
But when I visted there, I saw lots of badly formulated RFPs, some
hardly more than whines, and very few proposals.  Some of which looked
about as plausible as an MLM spam.  sXc, by contrast, was high-quality
on both, but unfortunately produced few matches.

    Kevin> This wouldn't be as good as getting it into the official

But you said the patch is "terrible."  Surely what you mean is getting
a related high-quality fix into the mainline distribution.  But that
will be expensive in terms of core developer time.

The problem is distribution of the fix and of the bounty.  What you
are trying to do is arrange that lots of users with small value for a
fix can aggregate to provide a bounty large enough to get someone to
do it.  But the only way to address the mass of users is a fix that
gets into the mainline, and faster than it would otherwise.  But this
involves lots of costs that fall on people who will not receive the
bounty, and may even resent it.

    Kevin> distribution but it is better for Alice and Bob that it
    Kevin> exists.

    Kevin> It would also be better for XEmacs since we now have one
    Kevin> more developer (Bob) which is more familiar with the code.

All true.  But we continue to have the issues that low-quality patches
won't get enough distribution to generate enough bounty to cover cost
of production, and high-quality patches are sufficiently costly that
their bounty doesn't cover costs, either.

Institute of Policy and Planning Sciences
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.