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