User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030611 Mozilla Firebird/0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030611 Mozilla Firebird/0.6 We could have a donationa link on each bug page that allows ppl to commit to contributing a certain dollar amount if the bug is fixed by a certain date. This will help raise funds, and though likely will not be enough to cover the cost of the bugfix, might encourage both giving and focus on important bugs to users. We could also set aside say $5 of each "reward" and give the coders/QAs little gifts. This might be done in a round-robin fashion of some sort that will alleviate the problem of ppl not getting their dues for fixing important but less-noticed bugs. Reproducible: Always Steps to Reproduce: 1. 2. 3.

Sorry for the bugspam but I forgot to mention that ppl can start donating now for bugfixes, and this will prove to mozilla.org that it's a feasible way to increase revenues and interests.

The folks at ghostscript post reward amounts for top issues and enhancements, so obviously somebody else has some success with this approach.

If this was to happen, it would need to be handled very carefully though. What happens if two people come up with fixes for a bug? What happens if someone has a try at fixing something and their patch is rejected for some reason? and if someone posts a work-in-progress and someone else adds a couple of lines to finish it off? When is something "fixed" - when there is a working patch? when there is a patch that's acceptable to be checked in? when the patch is checked in and not backed out for a Think of the MNG situation, or the splash screen saga, and then imagine that the outcome of the argument is worth a thousand dollars to someone... One also has to be careful about influence on the project - suppose some Microsoft supporter comes along and offers $10,000 for implementing some IE-compatible feature which has been rejected in favour of standards. You would need a bunch of carefully drafted rules of how the scheme works, some procedure for some independent adjudicating of disputes, and to ensure that Mozilla.org sticks to its goals, even if it means turning down some patch that someone is offering a load of money for...

Competing, Dividing Reward: There's some risk of duplicated work, but that's probably a small risk for small bugfixes. 'Many-eyes/brains' competing on speed & quality is good. If the result combines several contributions, the sponsor could divide the small fee among the contributors. Or if the problem is a complex project, it might be better for the sponsor to pick a qualified consultant, either to do the project, or to manage the competition. Bid: for larger projects, the sponsor may have little idea if a change is easy or hard, and may be reluctant to set a price. An auction lets 'many-eyes/brains' compete to justify a reasonable price for their proposed work. Sponsor picks best fit, which will often not be the cheapest. Escrow: This being the internet, there's also a good chance of getting jilted by some poser who promises but never pays. Better to work through any expertise marketplace that provides an escrow account. and advertise it on the mozilla consultants list at mozdev. Delivery: A sponsor could specify for which stages/milestones they will pay. o Patch: demonstrates functionality is possible o Extension (xpi): delivers functionality separately (for distribution) o Custom branch/app: delivers private integration (e.g., for company intranet) o Accepted into trunk: demonstrates public integration is possible o Accepted into a final release: delivers public integration A sponsor might try to pay higher to attract developers that are qualified to integrate a change into the trunk, but may get no takers if it is too incompatible with project goals, or a taker may try but fail. That is a risk that sponsors and developers need to take into account.

I think this would turn into a real nightmare...tons of politics. Say IBM sponsors a bug fix, Sun sponsors a different one, and Sun's bug makes it to 1.5 but IBMs doesn't make it until 1.6. Who is going to referee which bugs get more priority? Don't the drivers already have enough to worry about without adding in paid for bugs? And how many users are going to be alienated because the bug they paid for gets ignored for a long time? I think a system like this one could work if their are /very/ strict guidelines and rules. Rule # 1: the MF admins and drivers have the final say, and not even large companies can affect the direction of Mozilla developement. Other rules would have to be worked out, but I think I got my point across.

If a company wants a strategic feature, they will (and already do) pay their own developers to work on it. That won't change. Offering cash for bugfixes could be incentive for fixing the little bugs that fall through the cracks. The ones that affect only a minority of sites, so are low priority, little appreciated, and take forever to be fixed. If your site is one of the affected sites but you don't have time or know-how to fix it yourself, offering cash may be a way to raise its priority in someone else's mind. (This need not take core developers off high priority tasks. Instead, other developers who would otherwise spend less time on mozilla may spend more time.)

Interesting idea but not practical at this time and way too many potential headaches with it. Closing this idea.

-> biz

*** Bug 227382 has been marked as a duplicate of this bug. ***

I know this bug has been closed, but I am offering a $500 bounty for the code to implement a bounty framework in Bugzilla. Details are at http://www.markshuttleworth.com/bounty.html please see that page for the latest status rather than relying on this comment, which might be out of date by the time you see it. I believe this will be a significant benefit to the Mozilla project and other projects that use Bugzilla. I understand that having bounties around raises a lot of questions. But most of those questions are only an issue if the project decides to change its management as a result of the existence of the bounties. Right now, independent developers are entirely free to decide for themselves how to spend their time. They might choose bugs that are of personal interest, or they might look for bugs that are particularly demanding, or particularly popular (the votes system). I would like them also to be able to see what bounties are available, and factor that into their search. I'm starting to put numerous bounties out there, and tracking them would be much easier with this feature. It would also help developers to find the bounties if they are part of the bugzilla fabric rather than on a separate site. I have some thoughts on extending the framework to allow meta-tracking of bounties across multiple Bugzilla instances, but that can wait for now ;-) Please follow the guidelines on the page listed above if you are interested in the bounty.

The dynamics of this are potentially complicated, but it might be nice to have a simple, official statement about bounty comments in bugzilla from staff. For example: "mozilla.org currently has no pay-to-fix ("bounty") system. Contributors can make brief comments if they wish to announce a bounty, but long discussions should be avoided to prevent bug drift. mozilla.org does not encourage or enforce bounty agreements, so any agreements between individuals should not be assumed to carry endorsement or approval of mozilla.org or its staff." (NOTE: I'm not on staff, I'm just giving sample text here, reflecting the two concerns I would have, which is comments in bugzilla causing drift, and people assuming tacit organizational endorsement. I am looking bug 28586 and the bounty for it, so I do admit I have some desire to get some position on this discussion.) (NOTE2: I'm not trying to re-start the discussion about how bounties should work. That is too complicated to discuss in a single bug.)

I think the bounties should go to Mozilla Foundation as a donation

Note that the implementation of bounties in bugzilla is bug 124096. Mark's bounty should probably be on that bug.

This is a duplicate of bug 124096, not a WONTFIX.

The WONTFIX here applies to Firefox and friends. Bug 124096 would implement the feature in Bugzilla but it wouldn't be turned on for the Firefox product in bugzilla.mozilla.org.