Ashar Voultoiz wrote: A bounty system assumes someone (unpaid? community vote? donator decides?) can define the tasks and assign the bounties. One question in Anthere's poll was "Which tasks, if any, really ought to be done, but currently are not?". That method of design can only result in a bazaar. To build a cathedral you need an architect with somewhat dictatorial powers, and the authority and salary for an architect is the least likely outcome of a bounty system. For example, what if there is a $2000 bounty for adding complex graphics and another $2000 bounty for improving performance? These bounties are in conflict. Who is to decide? Eric Raymond thinks bazaars are better than cathedrals because of this lack of authority, but not everyone agrees with Eric Raymond. For example, Linus Torvalds' architectural control over the Linux kernel is a good example of dictatorial powers at their best. Wikipedia has been extremely successful despite (not because) the lack of a technical architect, especially in the last two years. Some people ask how the Swedish Wikipedia can be the 5th biggest with a language spoken by only 9 million people. One strong reason is that the Swedish wiki community enjoyed sub-second response times at susning.nu in 2002 and 2003, while Wikipedia's utter sluggishness during software phase II and III scared away thousands of volunteers. After susning.nu closed, this community has moved over to the Swedish Wikipedia. Just imagine if Wikipedia had performed like that in every language. And once again, I do this only to promote Swedish language among Germans: http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/017624.html While I appreciate Anthere's outreach, the board should not ask the developers which features need to be implemented. The board should promote growth of free contents (e.g. more encyclopedia articles, more dictionary definitions, more photos, etc.) and investigate why some sectors are growing slower than others. If there are technical bottlenecks, such as slow response times or lacking features, the developers should be informed and asked (and perhaps paid) to help the situation. The goal is never technical features, but the quicker generation of more contents. This is just like any commercial company where the board monitors customers and sales, except that the Wikimedia Foundation is not a profit-optimizing organization but a free-content-optimizing one. So don't ask why the Swedish Wikipedia is growing so fast, ask why all the others grow so slowly. We can do better than this. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

Anthere wrote: Nothing should stop, say, IBM from downloading the MediaWiki source and pay their own programmers to add functionality to it. If IBM wants to distribute this new software, GPL forces them to publish their source code as well. The version manager for MediaWiki might want to include such changes in the next release, otherwise it becomes IBM's own fork of the software. Both ways are fine. This software development could occur within or outside the Wikimedia Foundation. Linux, Apache, MySQL, and PHP are developed outside, and the Foundation only choses which version to use and which features to enable. The MediaWiki software is only slightly different in that the development "belongs" to the Foundation. It doesn't really matter if this development is driven by bounties or not. What does matter is how the Foundation selects which products and features to use on the Foundation's own servers. This is really not a development issue, but one of operations. This is where the 5-15 seconds response times of 2002-2003 were a real failure, that caused real damage to the project, as editors were leaving, or at least unable to convince their friends to join the project. New features were taken into use as soon as they were developed, and nobody seemed to monitor the performance. Every enthusiastic developer could introduce new bottlenecks. If Wikipedia had had a board in 2002-2003, it could have appointed an "editor satisfaction officer" or a "productivity officer", with responsibility to question the editor community what slowed them down, and how productivity could be improved. I believe many editors would have put the blame on the slow response times. The Foundation's server operations people should require that every new software feature can be monitored and enabled or disabled on its own. This is an architectural issue. Good software performance can save large investments in hardware. And even more, smart software can improve editor productivity. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

Brion Vibber wrote: There is nothing more to wish for in response time, server uptime, and features. It worries me a little that so much money needs to be spent on hardware, which I think could be done with less. However, the board should focus on a higher level, asking what makes contributors more or less productive, or what makes people join or leave the project. In order to analyze what makes some projects more successful than others, we need statistics to know which projects are successful. Why hasn't Wikistats been updated since May? And will we ever see web traffic statistics again? -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

Lars Aronsson wrote: In 2003 the problem was lack of hardware. We disabled every non-essential feature: just about every query page, search, even watchlists at times. A number of innovative performance features were developed, which kept our backs off the wall. We would have been better off at that time with a financing officer than a productivity officer. -- Tim Starling

On 8/23/05, Lars Aronsson <lars(a)aronsson.se> wrote: I don't think you realise Wikimedia's popularity. http://www.alexa.com/data/details/traffic_details?&range=2y&size=la… I'm pretty sure that Wikipedia has more features than that site in addition to receiving a couple of magnitudes more traffic. I can't speak for the devs, but I know full well that they were doing profiling and still are. I think you should be more respective until you know what actually goes on.