[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Allow money donations for precise bugs
From:       Maurizio Colucci <seguso.forever () tin ! it>
Date:       2005-03-12 22:50:40
Message-ID: 42337240.3020301 () tin ! it
[Download RAW message or body]

Aaron J. Seigo wrote:
> On Saturday 12 March 2005 12:37, Maurizio Colucci wrote:
> 
>>Currently, in bugs.kde.org, I can *vote* for some bugs or new features. My
>>idea is to allow KDE users and fans to put their *money* in place of
>>abstract "votes".
> 
> 
> the more i think about this, the more problems i see it creating. "people 
> paying for bad features" is the least of them IMHO. 

As you say, this is the least of our problems. We could simply require that 
any sponsored feature be approved by democratic votation, before donations 
can begin.

> there's issues of who decides when it's "done"; 

This can be solved too. We can relax the constraint, and not guarantee the 
feature will be "done"; only that it will be worked on.

This way, people would probably donate less, but it may be the best compromise.

> there's issues of code quality; 

This too is solved with the above proposal (coders have no reason to deliver 
bad code anymore).

> there's issues of 
> collecting and disbursing money; legalities that would come into play?; 

Of course, this issue must be solved. Some kind of deal with PayPal or 
http://www.dropcash.com/ should be made.

> there's issues of more than one person working on the same BR and feeling the 
> shaft when one of them gets the bounty; 


Solvable: the bug gets assigned to the coder who has the highest 
"reputation". Reputation is a score that depends on how well he fulfilled 
previous assignments (donators should be able to give votes to implementors)

> the fact that i don't see 20 people 
> voting on a bug coming up with any amount of money that correlates to the 
> time involved in fixing things; 

My hope is that, once you give people a way to control how their money gets 
used, they will begin donating much more. This is the whole point.

> the fact that it isn't the patchwork that 
> needs help, it's the larger development issues which this doesn't address, 
> and so on.

No problem. The developer can decide the best way to implement the feature. 
If it requires working on qt, or xorg, instead of KDE, he can do it. I don't 
see why the donator should care *where* exactly the code goes.


---

Well, it seems to me all your objections received a satisfactory answer. I am 
really curious whether some of your skepticism has gone away now. I value 
your opinions a lot.


Now, let's see your counterproposal.

> and yet it seems like an intuitive idea. one that could work if only tweaked 
> in some way... so how about this scenario:
> 
> a concerned and excited group of KDE fans create a Friends of KDE that other 
> people could join for $N/year or month or whatever for which they get a 
> little membership card and some cool perks for being part of the team. the 
> Friends of KDE, besides being a nice avenue for grass roots promotion, would 
> then distribute this money directly to developers to cover things like travel 
> expenses to conferences, to help give them extra hours in the week to work on 
> KDE instead of working on other things (for those who have such flexibility, 
> anyways), perhaps even to sponsor one or two of our more impressive but 
> not-employed-to-work-on-KDE developers.

Unless I misunderstood the role of "Friends of KDE", this seems to me only 
some kind of tax based on generosity. You seem to be ignoring the key point. 
Allow me to repeat:

    Most people will donate only if you give them some kind of guarantee
    that their money will be used to develop the feature they want.
    Contributors must be able to control how their money gets used.

My proposal exploits the selfish interests of people, and turns it into 
advantage for the free software movement. This is a key difference with yours.


Cheers,

Maurizio


 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]