I would like that all developers (others may participate as well of course) help setting up a list to define how development tasks completed could be rewarded.
This will be followed by a public poll to define how the rewards would be perceived...
and a private poll for developers to know what their opinion on the matter is
Please, contribute to http://meta.wikimedia.org/wiki/Bounty
thanks :-)
__________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail
Anthere wrote:
I would like that all developers (others may participate as well of course) help setting up a list to define how development tasks completed could be rewarded.
This will be followed by a public poll to define how the rewards would be perceived...
and a private poll for developers to know what their opinion on the matter is
Please, contribute to http://meta.wikimedia.org/wiki/Bounty
thanks :-)
Hello,
Personally, having users happy when I fix a bug or implement a new feature is enough for me. Imho a simple thanks through irc is more rewarding than 10 US$.
Ashar Voultoiz wrote:
Personally, having users happy when I fix a bug or implement a new feature is enough for me. Imho a simple thanks through irc is more rewarding than 10 US$.
Well, this is a noble attitude, and I applaud you for it, but in practice few people think like that.
Myself included, I won't deny.
Timwi
On Sat, 24 Jul 2004 18:09:54 -0700 (PDT), Anthere anthere9@yahoo.com wrote:
I would like that all developers (others may participate as well of course) help setting up a list to define how development tasks completed could be rewarded.
People tend to be competitive. Turn it into a game.
Those making requests should be given a certain number of "points" per day that they're allowed to assign to their requests (or to already existing requests). When a developer completes a task, they're awarded all the points for that task.
Then you need a scoreboard that shows which developers are "winning".
This is basically the same thing Ashar was talking about (making users happy) except that it's easier to quantify.
-Bill Clark
On Sun, 25 Jul 2004 17:58:38 -0400, Bill Clark wclarkxoom@gmail.com wrote:
People tend to be competitive. Turn it into a game.
Those making requests should be given a certain number of "points" per day that they're allowed to assign to their requests (or to already existing requests). When a developer completes a task, they're awarded all the points for that task.
Then you need a scoreboard that shows which developers are "winning".
Open-source is 20 years old. There are thousands of open-source projects. Some are successful, most are not. The development of open-source projects is on public record. There are mailing list archives, project web sites, history of CVS commits.
We don't have to guess or invent new ways of making open-source projects succesful. Much safer strategy is to analyze past, which is rich with examples, and identify processes that lead to success. Those who forget the past...
I've followed my share of open-source projects. Big and small, succesful and failed.
I've never seen "rewarding with points" system applied in practice. Therefore it's unlikely that it's a good idea and it's certainly very risky to try things no-one has tried before.
I've seen attempts to apply "bounty" systems to open-source (sorry for lack of reference, I forgot the names of the projects). They all failed (as in: didn't produce a lot of new, good code).
I don't know a single succesful open-source project that implements bounty system. Even less one that can claim that its success is caused by bounty system.
I've seen projects that flourish despite not having any external rewards systems in place (mono is a recent example, but there are of course plenty of them: GNOME and KDE projects, subversion, eclipse, gcc and I would consider wikimedia to be quite successful so far as it works well enough to support a massive undertaking as WikiPedia).
It's safe to conclude that you don't need bounty system to have succesful project.
The real question is: what is?
I think the discussion "is bounty system good or bad" is premature, stems from a haphzard idea of an individual (as opposed to systematic exploration of possible options to improve mediawiki project).
It diverts attention from much more important question: "what are the ways to improve mediawiki".
Krzysztof Kowalczyk | http://blog.kowalczyk.info
Krzysztof-
Open-source is 20 years old. There are thousands of open-source projects. Some are successful, most are not. The development of open-source projects is on public record. There are mailing list archives, project web sites, history of CVS commits.
We don't have to guess or invent new ways of making open-source projects succesful.
Yes, we should just all keep doing whatever we have been doing for 20 years and be happy, and never try anything new. By the way, this whole Wikipedia idea is kind of crazy. People should just use CVS to edit the encyclopedia, why come up with something new when there is a perfectly good process in place already? Jesus Fucking Christ, what kind of crap attitude is this? "We don't have to guess or invent new ways"? No, we don't, but guessing and experimenting is the source of all innovation.
Much safer strategy is to analyze past, which is rich with examples,
Which you aren't even familiar with to the extent that you could name them. I can: CoSource, SourceExchange, the Free Software Bazaar. All these models have been examined and have failed for different reasons. CoSource failed for lack of VC, but had quite a lot of successful bounties completed at the time it closed down (check archive.org). SourceExchange was targeted at corporations, not individuals. The Free Software Bazaar was a static HTML website maintained by Axel Boldt, who lost interest at some point, but it was reasonably active and led to some completed projects.
The open code market idea is certainly not new, and it is one which is increasingly being explored, refined and adopted, and which will eventually inject the one thing into the open source process which is currently missing from it: money. I advise you to at least do some basic research and read, for example, Jordi Carrasco-Muñoz' paper "The Open-Code Market": http://firstmonday.org/issues/issue8_11/munoz/index.html
As well as "A history of markets for open source software": http://www.ms.lt/en/workingopenly/markets.html
I've never seen "rewarding with points" system applied in practice. Therefore it's unlikely that it's a good idea
"I've never seen a wiki applied in practice for building an encyclopedia. Therefore it's unlikely that it's a good idea." Look, please familiarize yourself with basic logic before you make bullshit arguments like that.
and it's certainly very risky to try things no-one has tried before.
The risk in minimal. If it alienates people, we scrap the system and don't do it again.
I don't know a single succesful open-source project that implements bounty system.
Your ignorance is unfortunate.
I've seen projects that flourish despite not having any external rewards systems in place (mono is a recent example, but there are of course plenty of them: GNOME and KDE projects, subversion, eclipse, gcc and I would consider wikimedia to be quite successful so far as it works well enough to support a massive undertaking as WikiPedia).
GNOME has a bounty system, and it works: http://www.gnome.org/bounties/ http://www.gnome.org/bounties/Winners.html
Mozilla has recently started bounties as well: http://www.markshuttleworth.com/bounty.html
It's safe to conclude that you don't need bounty system to have succesful project.
Well, you can set up whatever straw man you want and shoot it down, but that has never been the point of the proposal. Read it.
Erik
On 26 Jul 2004 02:47:00 +0200, Erik Moeller erik_moeller@gmx.de wrote:
Yes, we should just all keep doing whatever we have been doing for 20 years and be happy, and never try anything new. By the way, this whole Wikipedia idea is kind of crazy. People should just use CVS to edit the encyclopedia, why come up with something new when there is a perfectly good process in place already? Jesus Fucking Christ, what kind of crap attitude is this? "We don't have to guess or invent new ways"? No, we don't, but guessing and experimenting is the source of all innovation.
As someone who insists on using basing logic in discussion, you set up a nice strawman yourself.
You're right that the fact, that something hasn't been tried before doesn't mean that it shouldn't be tried. If that was my only argument, it would have been bogus.
I believe my arguments are a bit stronger than that. I claim that: * there are better ways to improve mediawiki project * we can find those ways by analysing what worked well for other projects in the past * bounty systems have been tried and failed, either miserably (producing nothing) or just plain failed (dind't produce expected or eve significant improvements, the word "significant" being the key)
Which you aren't even familiar with to the extent that you could name them. I can: CoSource, SourceExchange, the Free Software Bazaar. All these models have been examined and have failed for different reasons. CoSource failed for lack of VC, but had quite a lot of successful bounties completed at the time it closed down (check archive.org). SourceExchange was targeted at corporations, not individuals. The Free Software Bazaar was a static HTML website maintained by Axel Boldt, who lost interest at some point, but it was reasonably active and led to some completed projects.
I don't see how showing examples of failed projects that tried to use bounty system supports your argument that bounty systems are a good idea.
Whatever your opinion is on why they failed, the only objective evidence we have is that they failed.
The open code market idea is certainly not new
I agree. I further claim that it has been tried and failed.
and it is one which is increasingly being explored, refined and adopted, and which will eventually inject the one thing into the open source process which is currently missing from it: money. I advise you to at least do some basic research and read, for example, Jordi Carrasco-Muñoz' paper "The Open-Code Market": http://firstmonday.org/issues/issue8_11/munoz/index.html
Thanks for the pointer. I've read the paper. It basically says: "here's an idea and why I think it should work". Then I went to the website (http://www.opencodemarket.org/ which really is http://jordiweb.net). As you can see by reading http://jordiweb.net/docs/IT/The_Open_Code_Market.html (essentially the same thing that was submitted to firstmonday) he published his idea on May 2003. Over a year passed and nothing else has happened.
While I won't claim that his idea is worthless because he failed to implement it in practice, I certainly don't see how you can present it as a pro-bounty argument.
As well as "A history of markets for open source software": http://www.ms.lt/en/workingopenly/markets.html
Thanks, this is interesting information.
I knew about CoSource and SourceXchange - and they seem to me just another failed dotCom business plans, a lot of hype, high-profile launch and high-profile bust. Hardly an example of success.
Free Software Bazaar: "few dozen projects were completed, mostly for about $50, one for $1,000". And they're gone. Again, hardly an example of success.
Open Avenue - as far as I can tell total failure. No sign of even modest accomplishments (not even completing a few dozen projects) and the website redirects to an interesting (not work safe) place.
Asynchrony - the only thing that is alive today. But they weren't really about bounty system, more like matching people with ideas but unable to program with programmers, and taking a cut if they deliver anything. Very safe business for Asynchrony but probably much less successful for those who worked on projects. Regardless, today they are just a IT service/consulting company. They changed the business model.
Software Carpentry bounty to develop SC Config/Build/Test/Track. I wouldn't call that a sucess either. Despite offering $200 k, the system, to the best of my knowledge, has not been delivered.
They did pay some bounties for completed designs and http://roundup.sourceforge.net is an implementation of SC Track (although it's not founded by the bounty - it's an independent, unpaid effort). So you might call it a partial success but as far as reaching the initial objectives, it's just a failure. Additionally it (roundup) shows that more was achieved by unpaid, motivated individual than by the bounty system.
I don't know a single succesful open-source project that implements bounty system.
Your ignorance is unfortunate.
I agree and I thank you for providing links so that I could educate myself.
Now I can say that I'm familiar with several cases where bounty systems were applied. And they all failed.
I'm still looking for an example of an open-source project that successfuly implemented bounty scheme. By "success" I mean that a significant portion of the code/functionality can be directly linked to bounties offered. In particular, the GNOME and Mozilla bounties you mentioned are, at best, failed experiments.
GNOME has a bounty system, and it works: http://www.gnome.org/bounties/ http://www.gnome.org/bounties/Winners.html
Mozilla has recently started bounties as well: http://www.markshuttleworth.com/bounty.html
Both those projects failed.
GNOME bounty resulted in fixing 11 bugs (http://www.gnome.org/bounties/Winners.html). 32 bugs for which a bounty was offered were *not* fixed (http://bugzilla.gnome.org/buglist.cgi?product=bounties&bug_status=UNCONF...) despite the fact that there were 5 months to do the work.
That's for a system that has around 700 new bugs opened weekly and as much bugs fixed (http://bugzilla.gnome.org/reports/weekly-bug-summary.html) and is approaching 150.000 bugs in total. Do you consider that a sucess? Especially if you factor in all the work that went into nominating bugs for bounties, creating web pages, evaluating the patches.
It also seems that it has been dropped by GNOME team - it was last done in november 2003 and there's no activity aftter that. It's just another failed experiment.
Mark has funded one project (http://www.schooltool.org/) in septemeber 2003. Calling it a bounty stretches a definition. If you read the announcement (http://www.markshuttleworth.com/schooltoolbounty.txt) he's just funding (almost) full-time programmers to work for him and develop a software that is available as GPL.
The "real" bounties that are offered since at least december 2003 (see e.g. http://bugzilla.mozilla.org/show_bug.cgi?id=181866) for smaller projects are still unclaimed.
Complete failure.
0 out of 5 Mozilla bounties were claimed. And Mozilla is progressing just fine. Even if those 5 bounties were completed, the impact on Mozilla would be insignificant.
Well, you can set up whatever straw man you want and shoot it down, but that has never been the point of the proposal. Read it.
The proposal is about offering bounties (or other rewards) for completing developement tasks. As far as I know, this has not been implemented *succesfully* in the past although many tried.
None of the examples you've presented can be called a success for any reasonable definition of success.
What evidence there is that bounty system work *well* ?
Krzysztof Kowalczyk | http://blog.kowalczyk.info
Krzysztof Kowalczyk wrote:
Whatever your opinion is on why they failed, the only objective evidence we have is that they failed.
I think it makes a lot of sense to examine why other projects failed.
Take LiveJournal, for example -- the Bazaar system that I based my idea upon. Under your definition you're going to tell me that it "failed" simply because the Bazaar is no longer used. However, I was there when it happened, and I participated in it. I can tell you from first-hand experience that it was an incredible success. Developer motivation increased significantly, and the bounties that were paid out were for much-needed work on the software.
The real reason why it was shut down (heck, it wasn't even explicitly shut down, it was just neglected) was not that it was unsuccessful, but just that the alternative they went for in parallel -- namely, hiring employees for software development -- was just as successful, but much less of a hassle.
I don't know much about finance, so I can't say how feasible it is for the Wikimedia Foundation to hire software engineers, but intuitively one would think that Wikimedia would benefit from such a Bazaar-like system for as long as there is a significant risk that donations suddenly drop and would no longer suffice to pay an employee. In my mind, the Bazaar system has an advantage for both sides: Developers can still be volunteers (i.e. opt out of any commitment any time they want), and Wikimedia needn't be afraid of financial problems arising from it (since never more than a given percentage of a month's donations are spent on these bounties).
Timwi
Krzysztof-
- there are better ways to improve mediawiki project
There are many ways to improve MediaWiki, and there's no reason for them not to coexist.
- bounty systems have been tried and failed, either miserably
(producing nothing) or just plain failed (dind't produce expected or eve significant improvements, the word "significant" being the key)
This is simply false, as improvements such as "Gaim/addressbook identity integration" (a $2500 bounty) are certainly significant, see http://www.gnome.org/bounties/Winners.html, Timwi probably could give similar examples for LiveJournal development. CoSource, before it was shut down, had over 350 requests with a total value of $180K. It was not an open bidding process, instead the CoSource company hired a Russian programmer to complete requests (a total of over 20 proposals were implemented). SourceExchange is not even close to what we have in mind here. An example for a bounty-style system (again not identical to what has been proposed) that is quite successful is Google Answers (answers.google.com).
Your problem is that you seem to be unable to differentiate between different kinds of systems and different types of success and failure. Once you see money + open source, your mind switches into "FAILURE! FAILURE! FAILURE!" mode and rational arguments become irrelevant. The project *has* to have been a failure because otherwise you might have to acknowledge that bringing money and open source together might not be such a bad idea after all.
Most importantly, you cannot equate a competitive bounty system, or a business-oriented market like SourceExchange, with a call for tenders that allows for different types of contractual agreements between the Foundation and its existing team of developers, with a technically competent steering committee that prepares the CfT, and with an application period within which volunteers can step forward. These are totally different things and acknowledging that difference would be a great step forward.
Whatever your opinion is on why they failed, the only objective evidence we have is that they failed.
No, that is not "the only objective evidence", and that is exactly the problem. You are ignoring that the FSB was a static HTML website maintained by one individual who lost interest. You are ignoring that CoSource was a dot-com which crashed because its business value was far smaller than its investments, and that its working model was vastly different from what has been proposed for Wikimedia, etc. etc.
Looking at history is a good idea only if you're actually willing to make an effort to understand it, instead of just using it to justify your preconceived notions about reality. Only if we have some understanding for the *reasons* these projects were discontinued or failed we can decide whether there are any valuable lessons to be learned for our own experiment.
Your attitude seems to be: "Oh, some bounty systems failed, so this is going to fail, even though it's completely different, and the reasons the other projects failed are completely irrelevant to what you are trying to do." There's a name for that attitude. It's called FUD. What are you so afraid of?
Free Software Bazaar: "few dozen projects were completed, mostly for about $50, one for $1,000". And they're gone. Again, hardly an example of success.
18 completed projects - roughly the same amount as CoSource, without a single dollar of venture capital and maintained by a single individual with a text editor and a telephone (used for confirming identities) - are hardly an example of failure either. There was clearly a lot of interest in Axel's project, but the implementation was lacking. We are not trying to implement a generic market for open source projects here, we are not even trying to implement a Wikimedia bounty system, we are trying to complement the existing development process with a controlled tender procedure.
GNOME bounty resulted in fixing 11 bugs (http://www.gnome.org/bounties/Winners.html).
Um, no, these weren't bugs but features, some of them quite significant.
That's for a system that has around 700 new bugs opened weekly and as much bugs fixed
Again, you do not seem to understand the difference between bugs and features. The bounties were largely on significant features or changed application behavior. To compare something like Gaim/evolution identity integration with something like "combobox list mode doesn't support scrolling" is simply ignorant.
Do you consider that a sucess?
I consider 11 completed tasks a success, yes, even though the specific model used by GNOME isn't the one I would recommend for Wikimedia (and I wouldn't be surprised if most GNOME developers have never even heard about the bounty system). An open bounty offer that is not taken up doesn't cost anyone anything. You can keep a bounty open for a year or two and hope that - as it did in 11 cases for the GNOME project - it will steer and accelerate development in the right direction.
What evidence there is that bounty system work *well* ?
I have never claimed that there is evidence that the described development model - call for tenders - will work well. I claim that there is no evidence that it won't, that your claims of prior failure are not applicable and also exaggerated, and that it is worth a try to give the Wikimedia Foundation and its members a voice in the development of the software which powers all Wikimedia websites, as well as rewarding the developers who have and continue to spend so much time on the project.
Regards,
Erik
On 26 Jul 2004 19:20:00 +0200, Erik Moeller erik_moeller@gmx.de wrote:
Your problem is that you seem to be unable to differentiate between different kinds of systems and different types of success and failure.
Now you're making me more stupid that I really am. I think I've made it clear that every project (CoSource, Gnome, Free Software Bazar) we discussed was slightly different.
Makes little difference: they all failed in the end.
Most importantly, you cannot equate a competitive bounty system, or a business-oriented market like SourceExchange, with a call for tenders that allows for different types of contractual agreements between the Foundation and its existing team of developers, with a technically competent steering committee that prepares the CfT, and with an application period within which volunteers can step forward. These are totally different things and acknowledging that difference would be a great step forward.
I do acknowledge that. You brought those examples, not me. I just showed that they all failed.
If you think those examples are not relevent to the discussion, why do you bring them up?
Looking at history is a good idea only if you're actually willing to make an effort to understand it, instead of just using it to justify your preconceived notions about reality.
Ad hominem attack.
GNOME bounty resulted in fixing 11 bugs (http://www.gnome.org/bounties/Winners.html).
Um, no, these weren't bugs but features, some of them quite significant.
That's for a system that has around 700 new bugs opened weekly and as much bugs fixed
Again, you do not seem to understand the difference between bugs and features. The bounties were largely on significant features or changed application behavior. To compare something like Gaim/evolution identity integration with something like "combobox list mode doesn't support scrolling" is simply ignorant.
Thank you again for calling me names. That's really ok, I don't mind. I do mind twisting the reality.
Gnome uses bug tracking system. A single "bug" can track a defect (i.e. what we also sometimes call a bug, hence the confusion) or a feature request.
I understand those differences - I was simply using Gnome terminology. They link each bounty to a "bug" i.e. a single entry in bug tracking database.
Do you consider that a sucess?
I consider 11 completed tasks a success, yes, even though the specific model used by GNOME isn't the one I would recommend for Wikimedia (and I wouldn't be surprised if most GNOME developers have never even heard about the bounty system).
Well, and there's a difference between us.
I don't consider a bounty system whose result was fixing 11 out of 43 bugs over 4 month period (and I'm really gracious here, attributing all the fixes to the bounty) while at the same time regular development brought estimated 600*4*4=9600 bug fixes (again, to be gracious I tone down my numbers here) to be a success.
And that's the closest thing you'll ever get to what wiki foundation can do. It was an official thing, sponsored by Gnome foundation, they obviously put effort into nominating bounty bugs, prepared nice web pages, had irc channel for discussion, had clear rules and I don't think they failed to evangelize this as much as they could.
They did try. And the result was simply dismal.
What can you possibly do better in wikipedia foundation case (except buying ad during superbowl) ?
An open bounty offer that is not taken up doesn't cost anyone anything.
It does cost the time and effort for preparing the bounty and managing the system.
And finally, that's not the point. It doesn't make sense to have a bounty system that doesn't work, even if it doesn't cost much. What we're trying to figure out is if bounty systems are a good way to improve wikimedia software.
And though you've made it clear that all past failures don't really matter a single bit because, well, we're all different and this time we'll do it right, I'll repeat: all past (several) attempts at bounty systems were failures. Draw your own conclusions.
Krzysztof Kowalczyk | http://blog.kowalczyk.info
On Monday 26 July 2004 19:20, Erik Moeller wrote:
GNOME bounty resulted in fixing 11 bugs (http://www.gnome.org/bounties/Winners.html).
Um, no, these weren't bugs but features, some of them quite significant.
That's for a system that has around 700 new bugs opened weekly and as much bugs fixed
Again, you do not seem to understand the difference between bugs and features. The bounties were largely on significant features or changed application behavior. To compare something like Gaim/evolution identity integration with something like "combobox list mode doesn't support scrolling" is simply ignorant.
come on Erik. While the number of bugs indeed is higher than the number of opened/closed features it doesn't make the failure much smaller. Just check
http://bugs.kde.org/weekly-bug-summary.cgi
(yes, this is KDE, but for GNOME it won't be much different) - 133 wishes opened, 185 wishes closed per week(!). And they fulfilled 11(!) features in 6 (!) months - that's hardly something I would call successfull.
I don't see any reason why developers should get money for implementing features while Wikipedia contributers won't get anything for their time and hard work. This doesn't sound fair to me. IMHO the money is much better spent on hardware.
best regards, Marco
Marco Krohn wrote:
I don't see any reason why developers should get money for implementing features while Wikipedia contributers won't get anything for their time and hard work. This doesn't sound fair to me.
I wonder how many people say this solely because they think they can contribute more/better as an editor.
Timwi
side note for Erik
------
Erik, I tried the little attribution thingy for when we do not write from cpov. Look what happened :-) http://meta.wikimedia.org/w/wiki.phtml?title=Developer_payment&curid=945...
Anthere wrote:
Erik, I tried the little attribution thingy for when we do not write from cpov. Look what happened :-) http://meta.wikimedia.org/w/wiki.phtml?title=Developer_payment&curid=945...
Oh, sorry. I wasn't supposed to remove that? :)
I guess I should have checked who it was from. I wouldn't have thought that *you* wrote it. It looked like an attack on you (personally, I found the "sigh" to sound like "oh no, not another one of Anthere's silly ideas").
If you want, put it back in.
Timwi
Timwi wrote:
Anthere wrote:
Erik, I tried the little attribution thingy for when we do not write from cpov. Look what happened :-) http://meta.wikimedia.org/w/wiki.phtml?title=Developer_payment&curid=945...
Oh, sorry. I wasn't supposed to remove that? :)
I guess I should have checked who it was from. I wouldn't have thought that *you* wrote it. It looked like an attack on you (personally, I found the "sigh" to sound like "oh no, not another one of Anthere's silly ideas").
If you want, put it back in.
Timwi
ROFL
No :-)
It was an attempt to follow some principles suggested, which were that when starting a discussion at first person on meta, we should identify ourselves to avoid confusion with community point of view :-)
Well, I made progress in 2 years. I am always loggued in now, and sometimes I even sign :-)
Krzysztof Kowalczyk wrote:
It's safe to conclude that you don't need bounty system to have succesful project.
The real question is: what is?
I think the discussion "is bounty system good or bad" is premature, stems from a haphzard idea of an individual (as opposed to systematic exploration of possible options to improve mediawiki project).
It diverts attention from much more important question: "what are the ways to improve mediawiki".
Krzysztof Kowalczyk | http://blog.kowalczyk.info
I would like to insist on a couple of things
First, I have no clearly set opinion myself on the topic, which is why I feel fairly confident to ask you what you think and not to deform it :-)
Second, we can not really say that this discussion on bounty is premature. No discussion ever is, as long as it is discussion :-) And since a couple of people are interested, and Erik in particular supports it very much, then it is best to discuss it openly.
Third, this discussion is in particular triggered by the irc discussion we had yesterday (see http://meta.wikimedia.org/wiki/Foundation_website_meeting%2C_July_2004) during which 2 features development were suggested on that bounty system.
Fourth, as far as I know, though a developer seem to think otherwise, the money which will be used for bounty system (IF we decide to try that option) will likely to be WMF one, and in this case, it will be the board to vote whether to spend or not to spend, and how much to spend. Now, we are aware it is a controversial matter, so what we will do will depend essentially of how the developers feel like it, and how all editors feel like it. Hence, the current discussion.
1) As mentionned by Elian and others, it would be nice that we identify better which features are currently requested, and which requests are really supported
2) Then to see which ones are more urgent
3) Then to have this clear to newcomers, so that there is not a barrier to entry for new developers
4) And suggest ways to reward those taking on tasks.
I'm concentrating my comments on this subject in the meta page, but I just wanted to make a wry comment on the subject line of this thread. MediaWiki development is the most rewarding job I've had so far, despite the fact that I've never made any money from it.
-- Tim Starling
Bill Clark wrote:
On Sat, 24 Jul 2004 18:09:54 -0700 (PDT), Anthere anthere9@yahoo.com wrote:
I would like that all developers (others may participate as well of course) help setting up a list to define how development tasks completed could be rewarded.
People tend to be competitive. Turn it into a game.
Those making requests should be given a certain number of "points" per day that they're allowed to assign to their requests (or to already existing requests). When a developer completes a task, they're awarded all the points for that task.
Then you need a scoreboard that shows which developers are "winning".
This is basically the same thing Ashar was talking about (making users happy) except that it's easier to quantify.
-Bill Clark
Thanks for the feedback Bill
I added your comment here http://meta.wikimedia.org/wiki/Developer_payment
It is much easier for follow up
ant
Anthere wrote:
Thanks for the feedback Bill I added your comment here http://meta.wikimedia.org/wiki/Developer_payment It is much easier for follow up
Hm, I would be vastly grateful to anyone who could summarise the system I proposed on the other mailing list (foundation-l) on a meta page where it will be discussed. :-) (I would do it myself, but I have this project deadline next week :/)
Timwi
Timwi wrote:
Anthere wrote:
Thanks for the feedback Bill I added your comment here http://meta.wikimedia.org/wiki/Developer_payment It is much easier for follow up
Hm, I would be vastly grateful to anyone who could summarise the system I proposed on the other mailing list (foundation-l) on a meta page where it will be discussed. :-) (I would do it myself, but I have this project deadline next week :/)
Timwi
Could you do the summarizing please ?
Anthere wrote:
Timwi wrote:
Hm, I would be vastly grateful to anyone who could summarise the system I proposed on the other mailing list (foundation-l) on a meta page where it will be discussed. :-) (I would do it myself, but I have this project deadline next week :/)
Could you do the summarizing please ?
Well, I'll do it after the deadline, but if someone wants to beat me to it ...
On 25.07.2004 17:58:38 -0400, Bill Clark wrote:
On Sat, 24 Jul 2004 18:09:54 -0700 (PDT), Anthere anthere9@yahoo.com wrote:
I would like that all developers (others may participate as well of course) help setting up a list to define how development tasks completed could be rewarded.
People tend to be competitive. Turn it into a game.
Those making requests should be given a certain number of "points" per day that they're allowed to assign to their requests (or to already existing requests). When a developer completes a task, they're awarded all the points for that task.
Then you need a scoreboard that shows which developers are "winning".
I think this will lead to worse software, because it shifts the focus from "writing good software" to "making money/win the game". There have been several studies in the past on this topic:
http://www.gnu.org/philosophy/motivation.html
Frithjof
Frithjof Engel wrote:
I think this will lead to worse software, because it shifts the focus from "writing good software" to "making money/win the game". There have been several studies in the past on this topic:
This is well-known study, but it has a week point.
They state, "Creativity and intrinsic interest diminish if task is done for gain" but actually the only things they can compare are * people doing open software for fun and entertainment; and * people who are employees and have to develop the uninteresting parts of software as part of their job.
The study does not take into account the possibility of "paid volunteers", because there have been few such systems in the past.
If someone wants to do uninteresting programming for money, they can get a better pay at a real job. A Bazaar-like system like the one I'm proposing is different: payment provides motivation to get involved, but developers would still be working on the things they personally find interesting. Hence, I believe, "creativity and intrinsic interest" will be preserved.
Timwi
On 26.07.2004 15:03:52 +0100, Timwi wrote:
Frithjof Engel wrote:
I think this will lead to worse software, because it shifts the focus from "writing good software" to "making money/win the game". There have been several studies in the past on this topic:
This is well-known study, but it has a week point.
They state, "Creativity and intrinsic interest diminish if task is done for gain" but actually the only things they can compare are
- people doing open software for fun and entertainment; and
- people who are employees and have to develop the uninteresting parts
of software as part of their job.
They compare groups of people doing exactly the same work.
The study does not take into account the possibility of "paid volunteers", because there have been few such systems in the past.
The reason for that is that it would not work. You either work because of the money you earn or because of the fun you have. There is no middle-way IMHO. Imagine you want to do something for a specific project, you look at the TODO-list and evaluate each task by considering different aspects like the time you want to invest, your interest in that topic, your skills, etc. When TODO list suddenly start to offer money for a specific task, people would change the priorities regarding the task, see the following:
Ordinary TODO list: * Fix bug that the app cannot handle filenames longer than 255 chars * Fix memory leaks when editing file * Implement an export feature
Reward-driven TODO list: * 1$ For fixing bug that the app cannot handle filenames longer than 255 chars * 2$ Fix memory leaks when editing file * Implement an export feature
Don't you immediately start to evaluate the tasks based on the money you can make? Your interest for developing shifts automagically.
If someone wants to do uninteresting programming for money, they can get a better pay at a real job.
ACK
A Bazaar-like system like the one I'm proposing is different: payment provides motivation to get involved, but developers would still be working on the things they personally find interesting.
As hard as it sounds, but I think bringing in payments would corrupt the whole development process.
Hence, I believe, "creativity and intrinsic interest" will be preserved.
I don't :)
Frithjof
Frithjof Engel wrote:
On 26.07.2004 15:03:52 +0100, Timwi wrote:
The study does not take into account the possibility of "paid volunteers", because there have been few such systems in the past.
The reason for that is that it would not work. You either work because of the money you earn or because of the fun you have. There is no middle-way IMHO.
You're digressing. I was talking of "paid volunteers", and then you say "it would not work". It did briefly work for LiveJournal. Whether it would work for Wikimedia has yet to be discovered, and I would like to ask you to refrain from jumping to conclusions before we know anything for definite.
Ordinary TODO list:
- Fix bug that the app cannot handle filenames longer than 255 chars
- Fix memory leaks when editing file
- Implement an export feature
Reward-driven TODO list:
- 1$ For fixing bug that the app cannot handle filenames longer than 255 chars
- 2$ Fix memory leaks when editing file
- Implement an export feature
Don't you immediately start to evaluate the tasks based on the money you can make? Your interest for developing shifts automagically.
You're forgetting something important here. Shifting the developers' focus is the *whole point* of offering payments. If it really was the way you described, all the better! That's what we *want*! Because that way we could get the developers to work on exactly those things that are needed most, by offering payment for them.
However, I doubt many people are that one-sided. Well... obviously, I don't know what most people are like, but I can say what I'm like and hope that I'm not alone. :-) No, the introduction of money into the equation would not entirely eliminate the factor of interest for me. If you offer only 2$ for a bugfix that I have absolutely no motivation to work on, then I will feel it's not worth the 2$. On the other hand, a simple/easy bugfix that has no money attached to it may still get my attention. (And in all honesty, that's bad. We want the important bugs to be fixed, not the easy ones.)
Timwi
Am Mon, 26 Jul 2004 15:03:52 +0100 hat Timwi timwi@gmx.net geschrieben:
Frithjof Engel wrote:
I think this will lead to worse software, because it shifts the focus from "writing good software" to "making money/win the game". There have been several studies in the past on this topic: http://www.gnu.org/philosophy/motivation.html
This is well-known study, but it has a week point.
They state, "Creativity and intrinsic interest diminish if task is done for gain" but actually the only things they can compare are
- people doing open software for fun and entertainment; and
- people who are employees and have to develop the uninteresting parts
of software as part of their job.
The study does not take into account the possibility of "paid volunteers", because there have been few such systems in the past.
Sadly, I don't know much about programming and so my question may appear "stupid", but what sort of contract are you going to make with a "paid volunteer"?
What sort of quality can be guaranteed by that sort of job?
Does one have to prove his abilities before taking on the job?
If one does a coding job out of his/her own motivation it might be buggy and the code is going to be revised. Any found bugs are going to be corrected by the ones caring most.
Will the rewarded developer only be rewarded after there is no bugs found anymore? Or at least not for the past two weeks?
But when you say you pay him like an artist (and some programmers if not many are artists indeed) is he responsible for his mistakes? Is it the job of "unrewarded volunteers" to correct bugs?
I can imagine it's a good idea to have that bounty thing when you do commercial open source programming. So you can get something done for some money. But with a free project accomplished by a somewhat enthusiastic community it's going to be difficult.
Are you going to "reward" writers for badly needed articles on wikipedia too later on? Or the ones that try to preserve a certain level of quality of the articles?
I got the impression that any voluntary work on a project like wikipedia is going to cause a lot of discord and distrust. With a project like say kde or gnome on the other hand I think it could be handled better and might be pretty useful.
Hmm, I might change my mind in the not too distant future but at the moment that's my two cents.
--manfred
If someone wants to do uninteresting programming for money, they can get a better pay at a real job. A Bazaar-like system like the one I'm proposing is different: payment provides motivation to get involved, but developers would still be working on the things they personally find interesting. Hence, I believe, "creativity and intrinsic interest" will be preserved.
Timwi
tic@tictric.net wrote:
Sadly, I don't know much about programming and so my question may appear "stupid", but what sort of contract are you going to make with a "paid volunteer"?
I don't know much about the legal side of things, but since other organisations have done it before, I'm sure we can learn from them what needs to be done. In the case of LiveJournal, Sandy Fitzpatrick would be the one to contact.
What sort of quality can be guaranteed by that sort of job?
What sort of quality can be guaranteed (or even expected) from a team of completely unpaid volunteers? With all due respect to the current and past developers, from a software engineering point of view MediaWiki is very bad quality the way it is now.
Does one have to prove his abilities before taking on the job?
Again, does one have to prove his abilities before participating in the unpaid volunteer effort? Your questions have nothing really to do with a payment system. You're asking about how volunteer teams work. We already have a volunteer team.
Will the rewarded developer only be rewarded after there is no bugs found anymore? Or at least not for the past two weeks?
I can't speak for other systems that have been proposed, but in the system I'm envisioning, people would receive less compensation for their work if the voters feel their work was done with very bad quality and led to more bugreports being opened.
Also remember that *not all* bugs and features need to be paid for. Only those that are important but nobody would want to work on them without payment.
But when you say you pay him like an artist (and some programmers if not many are artists indeed) is he responsible for his mistakes? Is it the job of "unrewarded volunteers" to correct bugs?
You're asking more and more questions about the system as it is already. This has nothing to do with rewards in the form of payment. We *already* have volunteers, and we *already* have people who write features and make mistakes (it's only human). We *already* have to ask ourselves whose responsibility it is to clean up after them, and we *already* have the problem that nobody feels truly responsible. The payment system alleviates this problem by increasing motivation.
If a new feature introduces new bugs, bugreports can be opened in our bug tracking software. If someone likes to fix them for free, very nice. If not, a payment for that can be offered too.
Are you going to "reward" writers for badly needed articles on wikipedia too later on? Or the ones that try to preserve a certain level of quality of the articles?
Don't think too far. The payment system for developers is only an experiment, anyway. Nobody knows if it will work out. If it *does* work out, there is certainly no reason not to use the same system to reward work on actual articles -- but let's concentrate on one side of it first.
Timwi
wikitech-l@lists.wikimedia.org