Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.8+) Gecko/20020204 Ability for anyone to fund specific bugs (e.g., PayPal) Ithink it would be very useful if anyone could donate some cash to a bug they want fixed. The way it might work is: 1) create a keyword called "funded" (or sponsored) 2) an experienced developer posts a "cost estimate" 3) Persons interested in having this bug fixed could then "donate" cash (via PayPal?) to an account for that bug (managed by mozilla.org). 4) If the required ammount is reached, the bug is released for "sale". 5) if a person wants to make some extra cash, and agrees with the estimate, he then takes the bug (after approval by mozilla.org) and fixes it. 6)After the bug is fixed (r & sr), the the programmer gets the money. Of course, the programmer would need some guarantee that nobody else fixed "his" bug. Therefore, Isuggest to give hime a timelimit to fix the bug. During this time, noone else may submit a patch, or, if they do, the programmer still gets the reward. After the timelimit, anyone can submit a patch (and get the reqard?). Of course, the permission to open bugs to funding would not extend to bugs that are critical. Only bugs that have been lying around and/or are considered not urgent could be released by mozilla.org for sponsorship. I really think that we could attract a significant amount of outside help with this method. I know I would donate a few Euros (or dollars) for a few pet peeves of mine (e.g., bug 115981, bug 115574, bug 115027) PS. Please don't brush this aside because it requires a significant initial effort to set up.

See also bug 76609.

Reassigning all of my "future" targetted bugs to indicate that I'm not presently working on them, and someone else could feel free to work on them.

Reassigning all of my "future" targetted bugs to indicate that I'm not presently working on them, and someone else could feel free to work on them. (sorry for the spam if you got this twice, it didn't take right the first time)

Perhaps simplify the concept. Make the system more of an "Honor" system. All bugzilla does is keep track of people (Bugzilla registered email address and name), how much each is willing to pay, and using what methods (Paypal, check, etc.) Perhaps also a note from each person on what they specifically require out of the fix before they are willing to pay. Done this way, it shold be fairly straight forward to add. It should work in a similar fasion to the CC bugzilla field, except that you can only add yourself. If a bug is fixed it is up to the individual to decide if it is fixed to their sastifaction and pay up. I know there are a number of small bugs in Mozilla, mostly RFEs that I would be willing to put a few bucks here and there to get fixed. The main feature required is allowing for queries showing bugs with bounties, so developers looking to make some money can easily find some paying bugs. Keeping the bounty stuff seperate from the actual, useful bug discussion might help to keep the disscussion on topic, as well as giving us non-coders a way to help out. Can we add "bounty" to the summary? Any other synonyms?

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

Yes! Yes! Yes! Some people don't care about my work being deleted and mark my bugs as WONTFIX or minor I believe that the true motivating resource is might... and our convention of might is $$$... So I will use my hard work to give somebody else food so that they may also be mighty... and I get more mighty by having my bugs fixed! win-win So, Maybe have a pay pal account field for developers who want some money.. and have it be on the honor system to start out with... and have I pledge $5 to fixe this bug... and then.. who gets the money? maybe the person who wrote the patch.. and the person who incorporates it... and the people who approve it.. The only problem I can see with this is that developers might go patch happy.

Bug 227398 looks related.

I would say dupe 91037

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

Adding the word "bounty" to the summary to make this bug easier to find. Prog.

Sounds like a multi-tiered approach would be easiest to implement. Thinking out loud: 1) pledge system - "I pledge $5 to getting this fixed. Here's what I need to see specifically to pay up. " table bounties bug_id user_id bounty_amount bounty_comments paid the UI might resemble Votes. The paid column would only be settable by the assigned-to: programmer when the bug is verified. One could build a welcher-index from the paid field to help programmers decide if someone is likely to pay. To display the bounty field on a query results list and to support searches there would probably need to be another table like: table total_bounty_pledged bug_id bounty_pledged that would be precomputed whenever an individual's pledge changed, for performance reasons. There would also need to be a mechanism to turn bounties on and off in the preferences. 2) Include payment method field, links to paypal checkout or whatever, store whether payment was actually made. 3) Actual e-commerce in bugzilla. 4) Escrow accounts.

I forgot to add for the pledge system there should be some tools to help with payments - the programmer should have a tool where he can send a mail to all pledgers, for payment requests or feedback. When a bug is marked verified the mail to pledgers should include a reminder to pay up. Any user should be able to get a page of his unpaid pledges and their status. If someone wants to pay by check, that brings up the issue of mailing it to someone, hence needing an address, hence needing to store personal addresses for users. We could just ignore that for now. Oh, and to start with the bug verifier ought to make sure the assigned-to actually reflects who did the work. Should there be any help there? Maybe some JavaScript hooked to Commit on change to Verified - "This bug has a bounty of $500 - please verify that Peter Lairo actually did the work on this bug before verifiying"?

Here's my brief, independant (I was working on the problem, then looks to see if there was a bug) analysis. "first we need to decide how bounty can be put onto projects. There are three ways that bounty could be set. Prepaid bounty. Bounty votes and PayOnDelivery bounty. The company and sponsors would be expected to put pre-paid bounty into the pot, bounties could be withdrawn with notice given if no-one is thinking of claiming them after a period of time. Votes for bounty, here users by votes and each vote is worth x in bounty, sponsors and the company could also set bounty in this way. Part of the 'vote' money will be pooled making a for profit system. This profit could be used to fund pre-paid bounties and help with server costs. PayOnDelivery bounty, here the user must be registered and possibly paid into a minimal sponsorship package and possibly paid for credit verification. The user/s can then set some amount of bounty on a bug to be paid when that bug is finished. I would expect work disputes to be settled by the company/sponsors and bounty setter. Maybe there should be banding in payondelivery systems, so small people can pay a few dollars and get rated by there paying up there of. medium people would have to be subscribers, or have moderate voting blocks. they could set payOnDelivery of upto a few hundred dollars. Full subscribers would be able to set payOnDelivery for unto a few thousand dollars or maybe more depending on there raiting. So, groups need to have credit associations. profiles need to have credit associations. there need to be a bounty table setup that holds bounty set on bugs by profiles. there needs to be a system in-place to convert votes onto bounty. There needs to be a notification system and methods for bounty to be claimed. when a user fixes a bug and that bug is closed fixed then all payondelivery people are informed. Some payment method needs to be arranged (paypall or whatever). the fixer needs to be informed about the people who own him money. the fixer needs to report on who's paid up and who hasn't (and the payers need to note that there debit is paid off). so there needs to be an owed to column and paid confirmed column in the bounty table. an expires column would also be nice ,but this would be in a future version. new table bounty bounty_id int no null primary key bug_id int not null -> bugs:bug_id user_id int not null -> profile:user_id type int not null :flags (maybe a lookup) ,amount int not null >0: in some kind of currency, say USD for the moment ,expires date (or unix time stamp) ,owedto_user_id -> profile:user_id (can be null if owned to no-one) ,paid int not null : flags true/false ,claimed int not null : flags true/false ,paymentmethod int not null : not sure at the moment, possibly paypall type thing? amendments to user table. bountvotes int not null, number of bounty votes left. credit, amount on offer, # paid , $ paid, # not-paid, $not-paid. new table bounty votes amend votes to have a bounty flag" Basicly, I'm trying to setup a not-for-profit company ironing out the bugs in linux and improving linux usability, paid for by writing drivers, contracting work, and any money Ican possibly scape out of bountie. So it's in my interest, and everyone elses e.g. if you want you adsl modem to work. (http://www.projects.sourceforge.net/eciadsl

Here's a spec for a simple evolvable system. If someone who knows bugzilla code will mentor me, I'll try implement it. I think I know enough perl and sql to do a nice job. Overview ======== 1. A bugzilla user can set a pledge amount for a bug. 2. A bug displays individual pledges, and a pledge total. 3. When a bug is closed, each pledger is emailed a Foundation donation link. That's it. Pledgers pay by using existing donation mechanisms. Pledgers can choose to pay more or less than they originally pledged, can delay payment, or can pay nothing. That's life. The Foundation might try to correlate a given bug's donations to devs that worked on that bug. They might set a rule whereby they only disburse monies received via bug donations to non-staff devs. The point is that the Foundation can experiment with how best to encourage bug donations (which is what really matters about a bug donation system imo). Details ======= I use the word "pledge" rather than "bounty" to better reflect the meaning -- it's not guaranteed, and it's to be paid to the Foundation, not (directly) to any developer. A) Add pledge line to top of bug page below current voting line == Bug 12345 blocks: [ ] Show dependency graph Votes: 8 Show votes for this bug Vote for this bug Pledged: US$ 30 my pledge: US$ [ 25] Additional Comments --------------------------------------------------------------- | | If Al Truist were logged in, his bug 12345 page would look as above. B) Display pledge amount in comments == Note the pledge figure toward the right of comments #4, #5, and #7: ---- Comment #3 From Ebenezer 2005-06-21 23:58 PDT [reply] ---- Whinge, whine... ---- Comment #4 From Don Ation 2005-07-10 05:48 PDT US$ 5 [reply] ---- Waffle, waffle... ---- Comment #5 From Al Truist 2005-07-16 14:35 PDT US$ 25 [reply] ---- Mutter, mutter... ---- Comment #6 From A N Other 2005-07-16 14:47 PDT [reply] ---- Blah, blah... ---- Comment #7 From Al Truist 2005-07-16 15:12 PDT US$ 25 [reply] ---- Blah, blah... Ebenezer and A N Other haven't pledged. Don Ation has pledged $5, so all his comments show $5. Al Truist has pledged $25, so all his comments show $25. C) Add coding (beyond whatever's needed for displays shown above) == 1. Add a pledges table, index is bug id & user id, other field is small int. 2. Read/write "my pledge" field from pledges table. Logged out: blank. 3. On post, if field left blank, don't write. If 0 entered, write null. 4. When a bug is closed, pledgers are automatically emailed. D) Email == English language email. Perhaps several, allowing for eg WONTFIX resolution, or maybe just one with suitable text. Links to the bug and to the Foundation donation page with bug # pre-loaded, asking them to honor their pledge if they feel the bug was adequately resolved. F) Documentation == 1. Write help page explaining pledge system. Link from "Pledged" (See A) above). 2. Add pledge system documentation to bugzilla doc. Phase 2 ======= Maybe later: 1. Add small int paid field to pledges table. When pledge paid, set paid field in corresponding pledges record. 2. Search, sort, and/or display bugs by pledged, paid amount.

(In reply to comment #14) > received via bug donations to non-staff devs. The point is that the Foundation > can experiment with how best to encourage bug donations (which is what really > matters about a bug donation system imo). > > Details > ======= > > I use the word "pledge" rather than "bounty" to better reflect the meaning -- > it's not guaranteed, and it's to be paid to the Foundation, not (directly) to > any developer. I am pretty sure the Mozilla Foundation has no interest in becoming a pledge clearing house. Besides, most of the bounties/pledges would imo be regarding bugs that were not a priority for the Mozilla Foundation, but somebody else (the entities offering the money), so there isn't even an incentive for MF to involve itself. In the spirit of open source (release early, release often), I would suggest implementing the least bit of functionality to get this going. Anybody who really starts to think about this will end up with something like eBay, but I don't think we need to implement another eBay to start with (if ever). It has probably been said before, but here's my take: * Add the ability to say you add/remove x dollars to your pledge * Have a field that shows the total amount pledged, with a link to details That looks almost exactly like votes. If you'd allow everyone to give as many votes as they wanted, and changed "votes" to "dollars", you'd have this system. You have comment fields to specify additional information (for example the exact conditions for your pledge, or even state you want to pay in some other currency). If it is more than a few bucks, you really want to make a contract anyway, so the pledge/bounty system would act more like a way to find contracts.

(In reply to comment #15) > I am pretty sure the Mozilla Foundation has no interest in becoming a pledge > clearing house. I obviously confused you by mentioning what the Foundation might choose to do. The Foundation would receive money. That's it. It would have no obligations to route the money anywhere but to its bank account. > It has probably been said before, but here's my take: > > * Add the ability to say you add/remove x dollars to your pledge > * Have a field that shows the total amount pledged, with a link to details That's what I proposed. > That looks almost exactly like votes. If you'd allow everyone to give as many > votes as they wanted, and changed "votes" to "dollars", you'd have this system. Yes. Except you'd be missing: > You have comment fields to specify additional information (for example > the exact conditions for your pledge, or even state you want to pay in > some other currency). If it is more than a few bucks, you really want > to make a contract anyway, so the pledge/bounty system would act more > like a way to find contracts. Which is one of several reasons why I made (setting or changing) one's donation be part of one's comments.

(In reply to comment #16) > The Foundation would receive money. That's it. It would have no obligations to > route the money anywhere but to its bank account. My assumption here is that we want to help individuals provide incentives for other individuals to implement features/fix bugs. Mozilla Foundation plays no role in that. If someone wants to donate money to the foundation they can do so already, and I don't see much benefits in tying their donations to bug fixes by someone else. Take me for example: I could work 10 hours to fix some bug that had a $100 pledge to it. Or I could just send in $100 myself to the foundation, which would be cheaper to me (I'm assuming my time has value equal to or close to what I get paid from my normal job).

I'd also like to see Bugzilla support bounties / pledges / sponsorship. Even if Mozilla/Bugzilla doesn't use it itself, it'd be great to support it for the MANY other projects that use Bugzilla. The Mantis ( http://mantisbt.org/ ) bug tracking system includes a sponsorship option; see: http://manual.mantisbt.org/manual.configuration.sponsorship.php That way, every time you report a bug or feature request, you can include an amount you're willing to pay for it. That means that any project that uses the Mantis bug tracker (like Plucker, http://www.plkr.org/ ) automatically includes a bounty system. Various projects like GNOME have bounty systems; see: http://www.gnome.org/bounties/ There's even one for Mozilla: http://kb.mozillazine.org/index.phtml?title=Bounties I expect that end the long run this will need to be configurable for different projects. For many projects, simply recording pledges, and then totalling up the pledges from users, is more than enough. Many projects don't need a clearinghouse system; they just need a way to record the pledges (so that a developer can find the $-sponsored ones and know what the current total is), including the amount and deadline, and a way to tell the pledgers that the bug's been satisfied along with instructions on where to send the money using a check and snail mail. Some projects may need more formal mechanisms (processes for vetting requirements, performing intermediation, using PayPal automatically, handling money through a trusted third party, etc.) I suggest implementing something simple first, and let people gain experience with that. Once you know what others want, you can implement complex systems. But for many, a simple pledge recording system is sufficient. I suggest a simple system allows this: * record deadline and amount for each person for a given bug. A user should be able to add a pledge AFTER their initial bug report, allow any allow each person to add additional pledges (e.g., up the ante), and allow other users to pile on with pledges to raise the total. Make sure the template includes "we don't operate as a clearinghouse; please be honest, and pay immediately if your pledge has been honored." * report the total pledged $$ for a given bug * when the bug is marked as satisfied, it should be able to automatically send an email with instructions on how to send the money. KDE folks have noted that it'd be nice if Bugzilla implemented bounties: http://dot.kde.org/1097981481/1098263373/

(In reply to comment #18) > Even if Mozilla/Bugzilla doesn't use it itself, it'd be great to > support it for the MANY other projects that use Bugzilla. Yes. My original proposal is technically general to bugzilla. Even though I mentioned the Foundation, it's not (just) for bmo. It could be switched on by others first. Maybe I could start by patching the KDE instance. > That way, every time you report a bug or feature request, > you can include an amount you're willing to pay for it. As you say yourself later, it's better that any user can pledge, not just the initial reporter. For various reasons, in my original proposal the initial report does not deal with pledging. I still stand by that. I propose that pledging is instead left to subsequent comments (including one by the initial reporter if they wish to pledge). I'd appreciate seeing others' arguments for and against including pledge stuff in the initial report. Here's a few of mine: Cons: - Encourages flamewars as people get their lines crossed about technical merit and pledge issues. (I'm tempted to go so far as to recommend that an initial report that mentions a pledge should automatically be WONTFIXed.) - About doubles the work: need to do fiddle with at least 4 screens and 2 input forms instead of 2 screens and 1 input form. > http://kb.mozillazine.org/index.phtml?title=Bounties Others have said that this is the sort of approach (a separate site/database) we should build on until that becomes so big and successful that it's clear that we would benefit by having something in bugzilla. I think that's wrong-headed. I strongly believe that having pledge fields in your face as you use bugzilla will quickly and dramatically increase voluntary contributions from both pledgers and coders. It doesn't have to be deployed on bmo until it's proven elsewhere; but someone needs to code it to see if it works as David and I think it will. Furthermore, I'm voluntarily offering to code such a system. I would prefer that someone who knew bugzilla mentored me before I start. Though I'm starting to get itchy fingers. > I expect that end the long run this will need to be > configurable for different projects. I intended that from the get go. Any "XXX" (defined below) could specify the URL for the "marketing" page (that describes how pledging works), the "closing" emails (that are sent after bug closure; but see below), and a currency format (I'm currently assuming it's OK to restrict pledges to an integer; is that OK?). XXX is the smallest bugzilla unit of deployment within which an existing bug must stay during its lifecyle. So it can't be as small as a component, because one can change the component that a bug is assigned to. It could be a bugzilla instance. It may be that it could be something smaller than that, I don't know bugzilla well enough to say. > For many projects, > simply recording pledges, and then totalling up the > pledges from users, is more than enough. Quite. > Many projects > don't need a clearinghouse system; they just need a way > to record the pledges (so that a developer can find the > $-sponsored ones and know what the current total is), > including the amount and deadline, The mozillazine page linked above can highlight valuable bugs. I'm assuming that as a second phase of effort we can push further in the overview direction by writing pledge reports, and/or adding a pledge field to bug listings, and/or adding a pledge field to search screens. But, though desirable, none of that is essential for an initial implementation, imo. For many reasons, I think we want to discourage *formal* deadlines. Comments can explain deadlines and other conditions. Obviously this means that one must read all pledgers' comments to determine if any part of a pledge total has expired. Or more generally, how various pledgers' deadlines (and other conditions) work out. A formal deadline field and appropriate coding can be added later if a beta test or initial deployment makes it clear it's beneficial. > and a way to tell the pledgers that the bug's been satisfied > along with instructions on where to send the money > using a check and snail mail. If a pledger is on the CC list they'll presumably get an email if the bug's status changes to closed. Perhaps that's appropriate and enough, at least for an initial implementation. The donation (not pledge) link would presumably then be a part of either the bug page or of every email. Alternatively, we can, as I originally proposed, add code specifically to send dedicated pledge/donate related emails to pledgers after a bug closes. > Some projects may need more formal mechanisms > (processes for vetting requirements, performing > intermediation, using PayPal automatically, > handling money through a trusted third party, etc.) > I suggest implementing something simple first, and let > people gain experience with that. Once you know what > others want, you can implement complex systems. Precisely. I see almost none of this as being bugzilla's province, but experience and time is needed to dictate this sort of thing. (I can already see a justification for recording actuals (donations) back into the Pledges table and making use of that info in various ways. See my original proposal.) > But for many, a simple pledge recording system > is sufficient. I suggest a simple system allows this: > * record deadline and amount for each person for a given As discussed earlier in this comment, I propose we leave deadlines to comments. > bug. A user should be able to add a pledge > AFTER their initial bug report, allow any > allow each person to add additional pledges > (e.g., up the ante), and allow other users to pile on > with pledges to raise the total. Make sure the template > includes "we don't operate as a clearinghouse; > please be honest, and pay immediately if your pledge > has been honored." Right. > * report the total pledged $$ for a given bug Right. See my original proposal for details. > * when the bug is marked as satisfied, it should be > able to automatically send an email > with instructions on how to send the money. See earlier in this comment for discussion of email.

I've been pondering the "pay up!" process. After considering a number of routes, here's what I've tentatively concluded: 1. Add a Donation (distinct from Pledge) link to the page for all Donation enabled bugs. 2. Add a Donation/Pledge request signature to all emails sent out for a Donation enabled bug. That's it. When closing a bug, or in subsequent days/weeks/months, one might choose to mention pledges/donations in a comment. Perhaps add some software that on some non-intrusive schedule (every 12 months while a bug is open, then 1, 2, 4, 8 months after it closes?) automatically adds friendly bug comments noting Pledge and Donation to-date figures. (This requires some Donation integration.) Any comments?

Exellent Ideas, where are we? Do we need a bounty on setting up bounties? :-)

Exellent Ideas, where are we? Do we need a bounty on setting up bounties? :-)

I'm considering taking this project on. I'd like to go the EBay route ;) Please read this to the end before criticizing parts of it. Here's what I'm thinking: Pledging money on its own means nothing because nothing backs the pledge. I can create an account and pledge $1,000,000 or I can be honest and pledge $20. This makes pledges fairly meaningless. I think the way to make a pledge meaningful is for the person to actually send the money to a holding organization ( an account on PayPal ) henceforth referred to as BountyTrust. A hundred people can pledge $5 each to fix a bug and when fixed the fixer(s) will get $500 in proportion to their contribution. When a bug is closed there will be a settling period ( say two weeks ) whereby people claim a share of the bounty. At the end of this closing period if all people signed up for the bounty agree on its distribution it will be allocated accordingly. Otherwise members of BountyTrust will arbitrate and decide on the allocation. We are all engineers here, so I know I need to state this: THIS IS NOT 100% PERFECT. THERE WILL BE CONFLICTS AND PROBLEMS. Obviously the policies we set into place should try to reduce these to a minumum. We just need to remember the absolute worst case scenario is that people lose the money they pledged and the contributor doesn't get the money they hoped for. Maybe this will happen 10% of the time. As long as the contributor and pledger understand that this is a possibility, it is ok. 90% of the time it will still have worked to encourage people to fix problems. If you don't want to take the risk, you don't need to pledge or sign up for the bounty. Bugzilla ( and other bug tracking software ) would need be modified ( might be as easy as including an image from the BountyTrust site ) to show the bounty and allow pledges towards it. Eventually a system of trust can be setup whereby you don't need to send the money in order to pledge based on your record of giving in the past. ( EBay-ish ) Here are the issues that need addressing: Are there any tax/legal issues involved with sending money to unknown people from all over the world for what is essentially their labor? How is BountyTrust setup so that the owner can't abscond with all the money it holds? How is BountyTrust setup technically so that a hacker can't steal the money? I know is a complicated way to do it, but I think its the right way. I think once implemented it will make a significant impact on open source projects. -Dan

Dan, "BountyTrust" may = fundable.org http://www.fundable.org/groupactionguide

Good ideas, Dan. A couple things: - You mention people "signed up for the bounty". Will this be some sort of reservation system where you sign up to tackle it to the exclusion of all others? What if that person or group doesn't show? Will there be a timeout period? - For there to be arbitration and money-handling, there must be arbiters and money-handlers. Will these be volunteers from the Bugzilla community?

Thanks Bill, I didn't know about that. Fundable.org is definitley related but different in a bunch of ways from BountyTrust. ( fixed up front goal, no contributor payment resolution, no arbitration capabilities, ... ) If there is a concensus that something like BountyTrust is the right way to go I will contact the Fundable.org people to see whether they would be interested in implementing this, sharing code, or sharing information.

This is a matter for discussion. I advocate not having a reservation system and settling matters by all those who register as being contributors AFTER the bug has been closed. Tamir ( who e-mailed me ) advocates for the contributor registering before s/he starts work. As for where the arbiters and money-handlers come from, I would suggest that the money-handlers are from BountyTrust for ease of monitoring things. Also, this makes it easier for a donator to give money to multiple bugs across multiple projects. The arbiters I suppose should ultimately be people from the respective project (Bugzilla, Mozilla, Linux, ...) However, to keep things simple initially I would suggest that BountyTrust people would also arbitrate initially. Yes, since this discussion has started on the Bugzilla site I imagine that BountyTrust will initially be made up of people from the Bugzilla community.

The Mozilla Foundation already deals with money, as do many other large projects that use Bugzilla and may consider adopting this system (Redhat, OSDL, Gentoo Foundation). GNOME and Limewire already offer bounties in this manner, and I believe they handle the monetary things themselves. So could each individual project that adopts this system act as its own BountyTrust as it sees fit? That way Bugzilla would only be providing the technical means, not the policy behind them. Also, http://opensourcexperts.com have a payment-for-features program running right now, they may be good people to get into contact with for details on how to set this up, whichever way it happens.

Joel, all the code to BountyTrust would be open source of course. So nothing would prevent a project from being their own 'trust.' We can code BountyTrust with this possibility in mind. There are however several advantages to keeping it separate from Bugzilla/Mozilla Foundation: 1 - Trust information can ( eventually, not for version 1.0 ) be used between different projects to pre-vet certain pledges as being reliable. This way you could pledge money without the overhead of actually sending it, since you are a known entity and trusted by virtue of your past contributions. 2 - Small projects aren't going to want to deal with the hassle/time/money of setting up their own trust. Heck, I'm not sure that Bugzilla/Mozilla will want to. 3 - Other bug trackers can use this easily if it is independant of Bugzilla. ... OTOH, tight integration into Bugzilla would make for a much nicer user experience. I'd lean towards making BountyTrust independant yet designed to integrate seamlessly ( via API ) with Bugzilla ( or other bug tacker ). This is probably another thing that should be taken into account for design purposes but put off until after the initial version.

Well, I'm not sure what I'm able to contribute to this, but I'd like to see something finally get off the ground. What are you thinking for the next step?

I'd like to wait a couple of days to let people weigh-in and see if this proposal has support. If it does we should SourceForge a project and start discussing design on the mailing list. I should say this up-front though: I will not code this in Perl. I'm happy with Python/Zope or Java. If someone else wants to code this in Perl I'd be happy to help with basic design. Sorry if that's a problem for some of you. I have my preferences as irrational as they may be ;)

I would like to begin working on this, but I need some help first. I need to get some fairly influential commiters to agree that this will get committed (used) when it is finished. I don't want to spend lots of time working on this for nothing. Any leads on these influential commiters? Is there a dev-list I should post to? The rough plan is as follows: 1 - Design 'ideal' system 2 - Talk to people who have existing solutions ( fundable.org, opensourceexperts, ... ) to see if we can avoid setting up our own organization to handle this and also to learn from them. 2 - Implement simplest possible version of ideal system. This will have MINIMAL Bugzilla integration ( maybe just a graphic link ), with information being posted as comments. 3 - Tighter integration with Bugzilla. BountyTrust will lose more and more functionality to Bugzilla until it is just an organization/api for handling the money transfers themselves ( as opposed to the registration, dispute resolution, etc... ) Thoughts?

Dan, I don't think you're going to get anywhere unless you start writing some code and take a chance. Of course, you should start small and implement core functionality first and let each piece get accepted before you work on the next. However, until you have an actual patch that can be applied to the latest source tree, I seriously doubt you're going to get anyone's attention.

I hate to say this, but it turns out I can't work on this. I just decided to start a business and that doesn't leave much time for this kind of thing. It's too bad, I really think a solution to this bug would be quite a big step for the open source movement.

(In reply to comment #22) > where are we? I remain interested in implementing the plan I proposed -- but I want help. (My current guess is that learning bugzilla will end up taking something like 10% of the time involved if I am helped by someone who knows bugzilla code, and 90% if I don't.) > Do we need a bounty on setting up bounties? :-) Any offer of substantive help (eg mentor or money) would make the task more appealing to me. Mark Shuttleworth offered a $500 bounty at bug #213437 but my emails (over a year ago) asking about that went unanswered.

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

This seems like a good idea but it seems like the biggest hurdle is a workable arbitration system that doesn't involve any risk or commitment from the Mozilla Foundation. The feature and overall system would have to be designed in such a way that the Foundation isn't a party to the exchange and couldn't be obligated to implement a bounty, even a paid bounty, under any conditions. Like, what if someone fixed a bug or implemented a feature, and the change got reverted? It seems like the best you could do is arrange a code-in-exchange-for-money thing or a one-time-custom-build-in-exchange-for-money; the person who accepted the bounty would be unable to guarantee that the fix or feature would make it into the product.

This would make an excellent plugin, once plugins are working. I might even write it myself.

If we could put a bounty on this bug I bet it would get fixed a lot faster ;) -Dan

Anyone can easily go to http://rentacoder.com (or any similar site) and submit a request for any particular bug in this database. Just say something like, "I'll pay $X for anyone to fix bug Y".

A company called BountySource ( http://www.bountysource.com ) is doing something much like the BountyTrust proposal. They are doing a bugzilla replacement rather than bugzilla integration. I e-mailed them suggesting that integration might make more sense.

It would be best to mimic or integrate with systems that already exist. But a bunch of the systems that "already exist" seem to be offline... http://www.gnome.org/bounties http://www.markshuttleworth.com/bounty.html http://www.ubuntulinux.org/community/bounties/ Were these folded into some other project? http://www.opensourcexperts.com/bountylist.html is still around... We really need something like this. The problem with the open source community is that most people are volunteers, or at least choose which bugs to work on voluntarily, so all the cool popular stuff gets written, whereas if something is greatly desired by a small group of people, but not the devs, you're out of luck. "It's open source; write it yourself!", they say, but we don't know how to code. If everyone dedicated their lives to coding, there would be no computers to code on. :)

I think this could be put as an auction. Users start donating money to kill the bug, and it price starts raising until a developer thinks its enough for him to work on it. This way it wouldn't be necessary to wait for someone to make a cost estimate, and it would be fixed with the minimum money possible.

What Carlos says it's interesting, let's make a workaround for this bug in the bug itself: why not starting to put money amounts and keep having the total amount in the whiteboard for example? As there is no way to obligate to the final payment, the developer(s) that finally applies would have to trust on the funders promise. I'll start: I would pay $30 bucks for this.

Hello, I wanted to report that the links are brokens but I do see this comment dated a while back. Also, I think universities with students is the right place to garner enough developers to get work started on many more task that need to be done. For example, Topcoder Inc. , seems to have design, development, assembly, testing, etc. Please PM me or email me ,if tasks need to be done, and I shall also try my best garner enough skilled developers to get tasks done(especially features that really need to be there for whatever XYZ reason ) (In reply to comment #42) > It would be best to mimic or integrate with systems that already exist. But a > bunch of the systems that "already exist" seem to be offline... > > http://www.gnome.org/bounties > http://www.markshuttleworth.com/bounty.html > http://www.ubuntulinux.org/community/bounties/ > > Were these folded into some other project? > http://www.opensourcexperts.com/bountylist.html is still around... > > We really need something like this. The problem with the open source community > is that most people are volunteers, or at least choose which bugs to work on > voluntarily, so all the cool popular stuff gets written, whereas if something > is greatly desired by a small group of people, but not the devs, you're out of > luck. "It's open source; write it yourself!", they say, but we don't know how > to code. If everyone dedicated their lives to coding, there would be no > computers to code on. :)

> (In reply to comment #42) > > It would be best to mimic or integrate with systems that already exist. But a > > bunch of the systems that "already exist" seem to be offline... > > > > http://www.gnome.org/bounties > > http://www.markshuttleworth.com/bounty.html > > http://www.ubuntulinux.org/community/bounties/ > > > > Were these folded into some other project? > > http://www.opensourcexperts.com/bountylist.html is still around... > > > > We really need something like this. The problem with the open source community > > is that most people are volunteers, or at least choose which bugs to work on > > voluntarily, so all the cool popular stuff gets written, whereas if something > > is greatly desired by a small group of people, but not the devs, you're out of > > luck. "It's open source; write it yourself!", they say, but we don't know how > > to code. If everyone dedicated their lives to coding, there would be no > > computers to code on. :) (In reply to comment #46) > Hello, > > I wanted to report that the links are brokens but I do see this comment dated a > while back. Just FYI, another project was born recently as well to gather bounties for any opensource project out there: http://www.fossfactory.org/

Thank you Andres for the update. As I'm currently a student, my response for now after looking at that site is just "vow" (period). That's it. (In reply to comment #47) > > (In reply to comment #42) > > > It would be best to mimic or integrate with systems that already exist. But a > > > bunch of the systems that "already exist" seem to be offline... > > > > > > http://www.gnome.org/bounties > > > http://www.markshuttleworth.com/bounty.html > > > http://www.ubuntulinux.org/community/bounties/ > > > > > > Were these folded into some other project? > > > http://www.opensourcexperts.com/bountylist.html is still around... > > > > > > We really need something like this. The problem with the open source community > > > is that most people are volunteers, or at least choose which bugs to work on > > > voluntarily, so all the cool popular stuff gets written, whereas if something > > > is greatly desired by a small group of people, but not the devs, you're out of > > > luck. "It's open source; write it yourself!", they say, but we don't know how > > > to code. If everyone dedicated their lives to coding, there would be no > > > computers to code on. :) > (In reply to comment #46) > > Hello, > > > > I wanted to report that the links are brokens but I do see this comment dated a > > while back. > > Just FYI, another project was born recently as well to gather bounties for any > opensource project out there: http://www.fossfactory.org/

I had this idea years ago. Yes, this be great Idea. Requires additional text box with amount of money, as well as persons payment information. For open source projects can be considered donation, with implied potential tax deductions. Money is withdrawn into holding account. Bug lists total amount donated to it. When bug is solved contributors are payed according to contributions. Working code contributions being the most valued. for simplicity and sooner release, can have equal spliting, or encourage making big bugs into many small ones, so each part is made by a single person. There is much potential for development. We should stick to the functionally complete minimum, for initial working release.

Great idea. Should the version field of this bug be adjusted to a more recent version of bugzilla?

What we need a bounty for someone to set up a bounty system <G>! For something that seems like such a good idea, it's hard to understand why no one seems to have set one up. Last I looked, I didn't see a working one for any project on the net. What I do see on Source Forge and independent projects are contribution links to PayPal, etc., but those only work because the recipient is known ahead of time and because they're not dependent on any task being completed.

Just look how many people are willing to spend a doller, euro, pound or whatever for a mobile application. Offering bounty functionality could do so much for Mozilla, Freedeskop, GNOME, etc. projects who all are using Bugzilla and have plenty of bugs that need fixing. Fixing done by volunteers that can be compensated by bounties for their work. A minimal implementation would be to add a URL to the header of bug that leads to the particular external website offering a bounty for that particular bug. If that external website offers an API, the actual height and currency of that bounty could be retrieved and shown before that particular URL. This could look like for example: with API and with a link to http://www.bounty.zzz/id=9475 on the URL Bounty: http://www.bounty.zzz/ without API and with a link to http://www.bounty.zzz/id=9475 on the amount and on the URL Bounty: USD 137 http://www.bounty.zzz/ The search interface should initially be extended to be able to search that a bounty URL is available, nothing more. The API should work with XML or JSON. Currency should be in https://en.wikipedia.org/wiki/ISO_4217 format, including BTC for Bitcoins. An extra field could be offered called Pledgeable with the values OPEN and CLOSED. Appropriate website offering bounty services these days are: http://nextsprocket.com/ http://micropledge.com/ http://www.fossfactory.org/ and perhaps http://www.power2people.org/projects/ If someone of behalf of Bugzilla could contact these organisations, perhaps they are more then willing to help to offer an appropriate API. While you are at it, ask them also if they are willing to work with Bitcoins as well. Selling point is that such an API that only retrieves already available information would enable bounties on their websites. Interesting reading for projects using Bugzilla in combination with a bounty program is: https://www.mozilla.org/security/bug-bounty.html http://dneary.free.fr/gimp_bounties.html https://live.gnome.org/BountiesDiscussion because it is up to the projects using Bugzilla how to deal with bounties, especially when they are delegated to external services. A big benefit is that Bugzilla doesn't have to implement crowd funding itself and the projects do not have to handle the money and doesn't have to deal with accounts on money transfer brokers such as PayPal, banks and credit card companies. Allowing bounties in Bugzilla or at least creating practical coupling to external bounty services would allow many projects to more rapidly fix bugs as volunteers working on them can get compensated by the end users through crowd funding.

And two other links to be added to the list of interesting reading; https://wiki.ubuntu.com/BountyProposals https://blueprints.launchpad.net/launchpad/+spec/bountypledges

Because my bug #901968 got marked as a duplicate, I repeat my very specific request here, as it differs in key points from what is requested in this bug, and without even one of those differences, my concept falls apart and gets distorted and perverted until it’s turned on its head. (You know how that happens to things… :/) The underlying change in thinking from software as a “product” (= borderline criminal delusional nonsense) to software *development* as a *service* (= reality-based), and the associated difference in business model and financing is what this is all about. Take that away and you’re left with a **** “solution” that will never get fixed to be good enough to comply with the core goals. … Please, please don’t do that. ____________________________________________________________ This is a request to enable Bugzilla to be used for a new business model to finance F/LOSS projects, removing all concerns regarding to financing something that can be infinitely and uncontrollably copied. The idea is that, since software, being information, can never be a “product”, but making software is a /service/, adopting a service business model, just like every other service-based industry, where one gets paid for actual work (instead of stealing money from them in return for worthless copies), is the ideal way to go. So to get paid for their service, developers can set a price (in whatever currency or “currency” they like) they minimally need for a bug / feature to be worth doing. And end-users can then vote with their wallets, Kickstarter-style, using an extension of the currently existing voting system, using micro-payment provider modules. If the votes go over the set price, the work will be done (on pre-agreed terms and conditions). If it doesn’t, it stays in there, unless the developer chooses to do it anyway, e.g. out of personal preference. The developer can decide if, when it’s done, only those who voted get a copy, or just everyone. (The former only makes sense, if those people can keep it a secret, the developer wants to only partially go F/LOSS, and nobody can make e.g. a $0.01 vote just to get a copy. So basically never.) The nice thing is, that this has absolutely zero disadvantages, but completely solves the problem of rewarding people for their work while staying 100% open, improves listening to the user base, and most of all: It makes any form of copy “protection” or “right”, including lies like imaginary “property”, completely pointless and unnecessary. (Not that they ever worked or were legitimate in the first place.) The only thing “lost” will be the ability of organized crime, to hand out mere worthless *copies* that took *zero* work to make every time except the first, in return for real actual money that took real actual work to make *every* time. (Aka fraud.) Which of course is a good thing for everyone except the economically pointless “publishers”. I realize this is a lot to ask from or swallow for some people, who lived in the “old media” mindset all their lives, and may have trouble thinking the legitimate way. But it will benefit everybody, can run in parallel with everything else, is individually optional, and does no harm. So… why not start something great?

(In reply to Navid Zamani from comment #55) >... Overall, I agree with your comment. > And end-users can then vote with their wallets, > ... > So… why not start something great? Sure, do you know Perl? Go ahead and implement it :) If not, then, how much are you willing to contribute with your wallet? :) This is just to highlight that bugzilla is just meant for technical discussion, so please let's not increase the extension of this bug with no need. Plus, there are already some workarounds for this bug out there, my favourite is https://www.bountysource.com/

(In reply to Andrés G. Aragoneses from comment #56) > Sure, do you know Perl? Go ahead and implement it :) See the last paragraph of this message :) > If not, then, how much > are you willing to contribute with your wallet? :) I’m on the programmer side, getting the contributions. :) > This is just to highlight that bugzilla is just meant for technical > discussion Obviously, while the final goal was not technical, I posted this so the technical changes of this bug would be implemented in a way that would not artificially stifle this idea or choose a **** way of implementing this bug’s functionality. Because once it’s done with a wrong foundation, it is very hard to fix that or implement anything not fitting on top. That’s all I ask for: A good foundation. That doesn’t cripple the ability to use it for such a business model. Which may be anywhere between zero work and one or two conciously more generic (and hence future-proof) implementations. :) Sorry if I hadn’t been clear enough about this. > Plus, there are already some workarounds for this bug out there, my > favourite is https://www.bountysource.com/ See? that’s *exactly* what I meant with “it differs in key points”, “without even one of those differences, my concept falls apart and gets distorted and perverted until it’s turned on its head” and “a **** ‘solution’”. Bountysource, just like Kickstarter, is completely useless, because it doesn’t allow grouping projects, let alone with dependencies, is a useless joke as a bug/feature tracker (compared to e.g. Bugzilla), and is not built on the foundation of the technical features required by service-based business models. But thanks for the link anyway. I guess with all this resistance from boneheaded small-minded individuals, I’ll implement the thing myself. As soon as I re-implemented Bugzilla in a real language and as a real program.

For informations, an another website of crowdfunding want a similar feature: FreedomSponsors They make a bugzilla's plugin for it, see:http://mozilla.6506.n7.nabble.com/A-Bugzilla-plugin-for-FreedomSponsors-Can-you-help-td287367.html

Very nice! Can we get that installed here then? If other bounty sites make their own plug-ins then I guess just prioritize what to do at that time?

(In reply to xyzzy from comment #1) > See also bug 76609. This is really awesome and work smoothly. I have installed it in my system. My all sites http://luciddreamingpro.com working properly in it.

Hello, I wanted to report that the links are brokens but I do see this comment dated a while back. https://whatsappstatusall.com

Some things do get better with age. Now that we've had seventeen years to think about this... ;) It might be possible to use Etherium smart contracts to implement a bunch of this. I only understand this conceptually, but it sounds like a perfect fit for an application like this. You'd still have to design and implement all the administration/evaluation stuff, but all the payment/escrow stuff would be handled elegantly without reinventing any wheels and with almost no third party fees.

> It might be possible to use Eth... It's funny that you mention Ether, because I've been using gitcoin (powered by it and github issues) as a replacement for a lack of this feature in the most used bug tracking tools these days.

I'm also in favor of using https://www.bountysource.com/ and have good experiences with it. They have set up an entire system for this running for a while and via badges one can integrate real-time/in-browser the amount of the bounty at that moment. For sure, they are open to further integration with Bugzilla if needed. Advantage of using their service is that you don't have to reinvent the wheel and spend a lot of time on something that is already out there. At the same time, also look at what Patreon or Flattr and others can offer, also in terms of crypto currencies. There are plenty of these service out there already and the fee they ask is worth the effort of building and managing something yourself. Creating another system might be beyond the scope of Mozilla/Bugzilla.