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 <<