Krzysztof- 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. 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 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. The risk in minimal. If it alienates people, we scrap the system and don't do it again. Your ignorance is unfortunate. 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 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(a)gmx.de> wrote: 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) 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. I agree. I further claim that it has been tried and failed. 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. 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 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. 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=UNCON…) 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. 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- There are many ways to improve MediaWiki, and there's no reason for them not to coexist. 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. 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? 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. Um, no, these weren't bugs but features, some of them quite significant. 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. 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. 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 Monday 26 July 2004 19:20, Erik Moeller wrote: 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

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=94…

Timwi wrote: 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 :-)

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

Anthere 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 :/) Timwi

Anthere wrote: Well, I'll do it after the deadline, but if someone wants to beat me to it ...

Frithjof Engel wrote: 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

Frithjof Engel wrote: 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. 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

tic(a)tictric.net wrote: 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 (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. 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. 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. 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. 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