[Foundation-l] Re: Information flow

Mon Aug 22 22:03:38 UTC 2005

Anthere wrote:

> In the case of my poll, it was quite simple who would make the 
> final decision of which tasks really ought to be done. The one 
> paying. In this case the Foundation. Which would make that 
> decision depending on feedback from the community AND the 
> developers.
> [...]
> Hmmm, on another note. Some "developments" were paid by other 
> organizations, without these developments being necessarily 
> widely requested by the community. But this is liberty. Why 
> would we prevent another organization to pay for the development 
> of certain features ????

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 at aronsson.se)
  Aronsson Datateknik - http://aronsson.se