MAY
14
2005

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?

Comments

I wouldn't like/want someone to pay me to implement a feature but it would be ok to get donations for what you have done so far. After all this is free software and we do this for fun.


By ismail at Sat, 05/14/2005 - 18:56

I have no provisos against donations, they share none of the mentioned potential problems of bounties.


By at Sat, 05/14/2005 - 22:14

Yes and I agree with your thought on bounties :-)


By ismail at Sun, 05/15/2005 - 09:23

A possible solution is just one-word-long: plugins!



In general, if your application support plugins (quite possible, as kioslaves were mentioned) and not just for one type of functionality, like e.g data import plugin, but for quite a few. If that's the case, you can do part of your developemnt for reward.



No matter, whether the feature is pretty weird, or no. Unless you're forced to add it to software package by default, it won't hurt - it's a custom component after all.



The idea is noting new: it's also a result of informal KDE's policy for releasing as much reusable code as possible under the LGPL.



Notes:

  • Of course this is reasonable for larger projects as nobody would want to have plugin system for Kicker's clock (but who knows?) :)
  • One-system-only plugins. Example: ActiveX container for Form Designer. I would like try to avoid such developemnts as much as possible, because portability hell (vide: never-ending OpenOffice.org's problems with MS OLE thing - we even have no time to deal with that within KOffice)

By Jarosław Staniek at Sat, 05/14/2005 - 19:28

> A possible solution is just one-word-long: plugins!

I would love to see more usage of plugins within KDE (eg within KMail). Not only for being extensible but also for some current available functionality being turned off by default resulting in a more simple, useable interface.


By at Sat, 05/14/2005 - 21:55

I've also been interested in a plugin/extension system in Kmail, and when saw this post of yours, I said: time to bug report. As I didn't found any related bug reported in bugzill,a I've just filled one: bug #105699 (Add an extension / plugin system). Do you all like the bugzilla's voting system?! then use it here hehe


By edulix at Sun, 05/15/2005 - 10:08

"What happens if the written patch fulfills the money-spending side’s requirement but not the maintainer’s?"

If the bounties are arranged properly (and as you pointed out, sadly not all schemes are), then the maintainer's acceptance will decide who gets the bounty.

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

I don't think anyone running bounties ever expects people to do it purely for the money. The way I see it, it's more of a way to bring exposure to a project and it's open tasks. We have Junior Jobs to bring such tasks to the attention of the masses, but bounties will generally reach a wider audience and have an extra reward tacked on the side.

Furthermore, they're a great way of reaching out to those who don't really grok how open soure works. If it gets the attention of someone with little income (e.g someone in school or university), there's a good chance that whilst doing the bounty they'll learn about how open source works, and that contribution to open source is fun and interesting. So it's not inconceivable that bounties can bring new developers to a project.

Lastly, the real value of bounties is marketing. It puts out a message that the project is going somewhere, and that there's a company (preferably $well_known_brans) or person out there who supports it and thinks it's cool enough to spend their money on. e.g if there's competing open source projects X and Y, and X has bounties and press about them, X will probably be percieved as being more alive, active and successful.

Anyway, that's what they're about in my somewhat twisted view of reality.

- Jeff


By je4d at Sat, 05/14/2005 - 23:57

Your thoughts are all valid and I basically agree with them. I still think there is a solution. First of all the question is, wether bounties actually work or rather have to work the way, that a single company comes up with the stuff and gives the bounties to single developers. Why can't "the KDE project" accept money in order to decide itself what bounties to setup. Here the voting system can be used as a one important criteria to select bounty jobs.


By Eva Brucherseifer at Sun, 05/15/2005 - 16:58

You are overestimating KDE users. Take a look at the smooth scrolling wish to see an example where users get seriously abuse towards the developers.

I still think we should keep the votes because they are usefull, but abuse users are an unpleasant side effect.


By Allan Sandfeld at Sun, 05/15/2005 - 22:53