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