Thoughts on Votes and Bounties

Last week new KDE contributor Ivor Hewitt committed the first version of an image blocker for Konqueror which ranked first position in the list of most wanted features at that time. When looking at the next top entries you will perhaps know that many are under development: Bittorrent support in kget is being considered to be added once the kget rewrite to support plugins is finished. Support for removing attachments in KMail is the first TODO of Don Sanders (he is currently busy implementing asynchronous filtering, the most hated bug). The themeable KDM greeter exists already in KDE 3.4 although it doesn't support all GDM elements yet and misses a GUI to set it up (but see KDM Theme Manager). Client side IMAP filtering is also being worked on by Don, a new contributor requested a VCS account to implement ACL support recently, Cervisia is getting Subversion support, smooth scrolling exists in HEAD/trunk and so on. In summary many features which will make many people happy in near-future KDE versions.

Why I'm sure that they will make many people happy? Because the rank of a bug/feature is the result of how many votes it got from the KDE users in our bug tracking system. Every user can spend at most 20 votes point per report and 100 per product. And this voting works fine for KDE in my opinion. Myself and I guess others too are additionally motivated to spend time on reports which have a high encouragement. I don't understand why some other desktop project doesn't want to take advantage of their existing bug tracking system voting feature. Two reasons are usually given: The first is that users will be upset when a report with votes by several people will not be implemented for whatever reason. I don't see this happen in the KDE world but maybe the culture (between users and developers) differs. The other one is that developers could feel obliged to implement high voted nonsense or features which don't fit within the desktop's direction in the view of the developers: if you look at KDE's top 100 and further entries you will unlikely find stupid requests and if you don't allow your users to have an influence, how big however, about the direction of the desktop then you have a big problem.

Some projects in the last time organized so called "bounties": contests where a company promises rewards for implementing features. Besides the basic question whether you want a software influenced by user feedback or controlled by a single company with money there are so many potential problems and open questions with bounties, among them: some bounties don't take precaution against several people working on the same item. Some bounties are not arranged with the maintainers of the source where they are supposed to enter. The maintainer is likely the one who is supposed to invest time to advise the participant of the bounty and for sure the one who has to maintain the code later (don't expect any participant to care for his code later). What happens if the written patch fulfills the money-spending side's requirement but not the maintainer's? Will the patch author get his money anyway? Who will be doing all the administrative overhead dealing with the money etc.? For most tasks the offered reward is too low to make someone think about doing them instead of earning money with a regular paid job. For some tasks the offered reward is ridiculous high (50$ for adding an additional button in a Limewire pane?). Are you sure that the best technical solutions wins, eg in the case of integration between two company-specified projects will the result be a hack within both or will a clean interface be created in which also non-sponsor wanted/competiting applications can participate? Do you really expect that you will gain new contributors which continue to contribute to the software afterwards with such bounties? Do you want to risk to lose current active contributors doing it for fun by "poisoning" the project's spirit with money?