Subject: Re: Bug Bounties. Making $ from bugzilla.
From: (Kevin A. Burton)
Date: 26 Nov 2001 14:17:35 -0800

Hash: SHA1

"Stephen J. Turnbull" <> writes:

>     Kevin> Second a decent and OPEN site that didn't require human
>     Kevin> intervention would really take off.
> You and I evidently have drastically different assessments of the degree of
> human intervention required.  Consider the issue of "realistic plans"
> mentioned above, and the dual issue of salving hurt bounty-hunter feelings,
> alluded to below.
> BTW, what was un-OPEN about sXc or

I hope that no one interpreted this as a slight against these two companies.

At least with sXc (I never used cosource) there was a high barrier to entry.
Projects needed to be approved, you needed to have a high amount of cash, etc,

Compare this with something like bugzilla or sourceforge where anyone can create
an entry by themselves in real-time without external interaction.

>     >> But it's hard to get good patches even from the regulars if
>     >> it's not on what _they_ perceive as the critical path.
>     Kevin> It might be the critical path to pay the bills...
> XEmacs itself has no bills,

But its developers do...

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

I don't understand the above...
> That "IMO" is _not_ just my personal agenda.  (Admittedly, as long as nobody
> else is publishing one, it's hard to tell "the good of XEmacs" from "Stephen's
> blind spots.")  The problem is that most of the current bugs I know about have
> pretty obvious fixes.  These obvious fixes regularly (0) are buggy in
> themselves, which means $10 of QA for each $1 of fix; (1) conflict with each
> other; (2) conflict with similar features in GNU Emacs; (3) add ugliness and
> unmaintainability to the code; or (4) gratuitously introduce APIs or UI
> elements which we will either have to support or remove to general
> disapproval.  I don't want that kind of work done at all, by regulars or
> bounty hunters.

I certainly hear what you are saying.  There is a significant portion of me
that agrees with you (especially from a project maintainers background).

The flipside is what happens in the proprietary software world.  Users want bugs
fixed, managers push them through, developers complain, they get incorporated
into a source release, QA make sure the whole system functions together and you
get a product that customers, for the most part, can actually uses.

Of course this is why IIS has tons of security holes...

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

> And how many more XEmacs bugs will you fix for a "maybe $100" after I once say
> "no", and you dislike my reasons?  Would you really spend $100 of your time
> and emotional energy on getting a $100 bounty patch past a maintainer who
> seems intent on making "Beavis and Butthead" into a threesome?
> To make this idea really work, you need to get the maintainers to buy in to
> the concept, and fast-track the bounty patches.  You can see I'm already
> disposed against it.  I'll listen to counter-arguments, but so far all of
> yours have addressed the issue of patch production, not the QA issues near and
> dear to this maintainer's heart.
> So, do you think my feelings are unlikely to be representative of maintainers


Actually... I think you brought up some good points.

I don't think they are breakers but I think they should be addressed.

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

This wouldn't be as good as getting it into the official distribution but it is
better for Alice and Bob that it exists.

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

- -- 
Kevin A. Burton (,, )
             Location - San Francisco, CA, Cell - 415.595.9965
        Jabber -,  Web -

If you play with fire, you might get burned.  If you eliminate fire, you will
never feel it's warmth and never enjoy it's illumination.
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Get my public key at: