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
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
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
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.
Sounds like a multi-tiered approach would be easiest to implement. Thinking out
1) pledge system - "I pledge $5 to getting this fixed. Here's what I need to
see specifically to pay up. "
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:
that would be precomputed whenever an individual's pledge changed, for
There would also need to be a mechanism to turn bounties on and off in the
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
$500 - please verify that Peter Lairo actually did the work on this bug before
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.
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
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
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
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.
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.
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.
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).
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
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]
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] ----
---- Comment #4 From Don Ation 2005-07-10 05:48 PDT US$ 5 [reply] ----
---- Comment #5 From Al Truist 2005-07-16 14:35 PDT US$ 25 [reply] ----
---- Comment #6 From A N Other 2005-07-16 14:47 PDT [reply] ----
---- Comment #7 From Al Truist 2005-07-16 15:12 PDT US$ 25 [reply] ----
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.
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.
1. Write help page explaining pledge system. Link from "Pledged" (See A) above).
2. Add pledge system documentation to bugzilla doc.
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).
> 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
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:
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:
There's even one for Mozilla:
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:
(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
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:
- 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.
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.
> 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
> 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."
> * 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
2. Add a Donation/Pledge request signature to all emails sent out for a Donation
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.)
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
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
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, "BountyTrust" may = fundable.org
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
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
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,
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
> 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 ;)
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...
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.
*** Bug 441219 has been marked as a duplicate of this bug. ***
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...
> 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)
> 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
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:
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:
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;
*** Bug 901968 has been marked as a duplicate of this bug. ***
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
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?