Nick Hill wrote:
I envisage many wikipedia servers around the world,
supported by private
individuals, companies and universities. Much like the system of mirror FTP
and mirror web sites. All these servers are updated in real time from the
core wikipedia server. From the user's perspective, all are equivalent.
Each of these servers can do everything the current wikipedia server can do
except for accepting update submissions. Updates from users are accepted
only by the core wiki server.
Reasons for such an architecture:
1) Growth of bandwidth useage may put financial pressure on Wikipedia.
Growth may follow a non-linear growth curve.
2) The cost of implementing one very fast, reliable, redundant machine is
more than the cost of farming out work to many quite fast, unreliable
systems none of which are mission critical. Especially true where there are
people willing to donate part of their hard drive, CPU and net connection
(or even an entire system) to a good cause such as wikipedia. (Overall
system reliability can be guaranteed by using DNS tricks to ensure users
and queries are only directed to working machines).
Given wikipedias limited technical resources, we need to make a choice
between making small scale changes to the system (which may make 30-50%
change in availability) or to make architectural changes which can scale to
improvements of 100x or 1000x magnitude.
I confess to complete ignorance with the technical aspects of these
proposals. Be that as it may, there still needs to be a review of the
administrative structure of the project. There was some discussion a
couple months ago about forming a non-profit corporation, but that was
quickly forgotten.
A project that continues to depend on funding from a single source is
always at risk. Similarly, depending on ad hoc demands of $50 from
everybody may work once or twice, but it does not give any kind of
financial security. Aside from any moral issues about depending on
handouts from a single benefactor, there is the reality that no person's
pockets are bottomless and we have no idea where the bottom is. It is
irresponsible for the group as a whole to wait for a message from Jimbo
like "I want to contribute more, but I can't." Messages like that never
come at convenient times; they often coincide with major equipment
breakdowns or necessary technical expansion.
The brand new dedicated server is less than a year old, and it already
has difficulties coping with its volume of work. I think that Nick is
conscious of the potential costs that we could be facing. This is
evident from his willingness to look for lower cost alternatives. I
would like to see the budgetting alternatives in terms of costs and in
terms of what will be needed from participants over an extended length
of time.
It is my experience that most volunteers find corporate boards,
budgetting and issues of long term fiscal planning to be frightfully
boring, but facing these issues is a question of fiscal responsibility.
Eclecticology