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

List:       kde-devel
Subject:    Apologies and clearing of misunderstandings
From:       Maurizio Colucci <seguso.forever () tin ! it>
Date:       2005-03-14 21:21:14
Message-ID: 4236004A.4040706 () tin ! it
[Download RAW message or body]

Hello,

I realize that a big part of the quarrel is due to the fact that I haven't 
been clear at explaining my intentions, in my original post.

I gave the impression that the KDE developer community should be *forced* 
to 	accept a feature when it has been paid for by users.

This was never my intention.

I also seem to have given the impression that, in some way, KDE policies of 
code quality and patch acceptance should change, to be dominated by users will.

Also this was never my intention.


I was simply trying to say that, *if* a developer accepts a task, then he 
*must deliver* the code he promised. Whether the code he produces is accepted 
into KDE is yet to be seen. No one is forcing KDE developers to do anything. 
His patch would be subject to the *same* policies and scrutiny that *any* 
patch currently is.


For all that, I am very sorry. Please accept my excuses. And, please, allow 
me to state, this time in a hopefully clear way, my intentions. Especially 
read points 2, 4, 5, and 12.

If you still feel system would threaten any of your interests, or freedoms, 
any at all, *please* let me know.



----



1.
We supply a web site, a central place where any user can post a request for a 
feature (or bug fix) that he needs. For example, he can request a patch to 
KDE, or Gnome, or Xorg, which does a certain thing. Or he can request a full 
application.

He only specifies the functionality, and nothing else (no money, no timeline).




2.
Those developers who need money visit the web site periodically, and look at 
the requests.

On the other hand, developers who do not need money, or who do not like to be 
told by users what to do, will simply ignore the web site and continue to do 
what they have been doing so far: program for free and under their own guidance.





3.
If a developer freely decides to accept a task, then he posts a reply. This 
reply is something like

       I believe I can implement that feature for 3000$ in 5 months. Let
       donations begin. Donations close in 20 days, on September 3.



   Notice the developer defines one money sum (3000$) and two times (September
   3, five months).






4.
When he posts the above reply, the developer is free to modify the 
requirements, to rephrase them, or to specify them better. This can be useful 
because, sometimes, users don’t propose the best way to solve a problem. 
Also, often their requests are too vague and fuzzy.




5.
Anyway, before posting the above reply, the developer had better be careful: 
if the code he eventually produces were not accepted into KDE-Gnome-Xorg, 
later he would receive negative ratings from the donators. This would make it 
difficult for him to receive a donation next time. So, before he writes the 
above offer, he had better make sure the KDE-Gnome-Xorg community is willing 
to accept such a feature.

This problem, of course, does not exist if the request is about a standalone 
application.

Also, the developer had better carefully choose the amount of money he asks 
for: if he asks for too much, the threshold may not be reached in the given 
time, and he will not be able to work at all. If he asks for too little, he 
may have to stop development without delivering, which would make him receive 
negative ratings.



6.
Donations begin (for that specific feature). Any user can donate freely, or 
not donate at all.

Users decide whether to donate, and how much, according to the developer’s 
rating. Each developer has a “rating” which represents his “reputation”. It 
is a number that depends on how well he fulfilled previous tasks. He has been 
voted directly from his previous donators, after he delivered. If he failed 
to deliver what he promised, or did it badly, he will presumably have a low 
reputation level, and will get fewer donations.


(Note: a consequence of the reputation system is that donations are specific 
to a given developer. Donations are not only per-feature, but also 
per-developer.)




7.
When a user donates (to that developer for that feature), the money is not 
transferred immediately to the developer (because we still don’t know if the 
3000$ threshold will be reached).

Instead, when a user makes a donation, he just leaves the credit card number, 
so the web site is sure he will keep his word and not withdraw his offer 
later, on September 3.




8.
At any given time, before September 3, the web site shows a slider with the 
overall donation. So users can quickly check how much money is needed for the 
3000$ threshold to be reached.




9.
(optional) At any time, before September 3, the developer can choose to lower 
the threshold, or to accept the current amount of money. This can be useful 
in case some other developer is offering himself to do the same job for less.

A developer can also cancel his offer at any time, in which case no money 
transfer happens, and he looses only a few reputation points.





10.
On September 3, two things can happen:

(A) The overall donation has not reached 3000$. This means that either
     not enough people regard the feature as worthy of 3000$, or
     that the time limit has been chosen poorly by the developer, not giving
     people enough time to notice the feature.


     In either case, the feature will not be implemented, and any activity for
     the feature ends here.



     Also, in this case no money is taken from the bank accounts of donators.
     No money transfer at all has taken place.

(B) The overall donation has reached 3000$ (or it didn’t but the developer
     accepts nonetheless). In this case, the money is transferred to the
     developer’s bank account, and he starts coding. He will deliver in at
     most five months (time he had previously chosen).


     The money is not transferred all at once, to deter the developer from not
     working or disappearing, after he got the money.





11.
During the five months of development, at any time, the developer must make 
available the code developed so far. This is needed to prove he is actually 
working. If he doesn’t, the web site stops transferring the sum money 
periodically to his bank account.




12.
After five months (time that the developer itself had chosen), the developer 
publishes the final code he has produced.

This code may or may not be accepted into mainstream products, such as KDE, 
Gnome, Xorg. The KDE-Gnome-Xorg communities must not change anything in their 
policies of code quality, or their policies of code acceptance. They are not 
forced to accept the patch. For those communities, everything continues 
exactly as it was. The KDE-Gnome-Xorg developer community may not even know 
that the patch was paid for, and in any case they don’t need to care. All the 
developer community will notice is a pleasant increase in participation from 
unknown outsiders, which previously seemes to not exist.





13.
The donators give a rating to the developer. This rating will be based on 
their personal level of satisfaction, in relation to what the developer 
promised.

In particular, if the software does not work well or was not accepted into 
KDE, thee rating will presumably be bad, and the developer will find it 
harder to get donations next time.

----

My best wishes,

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]