Comparisons and advocacy

>I'll ask our lead programmer, Martin Langhoff to provide a bit more on the Why?
that would be grate! thnks Richard.

>>(Wow! Did I say "brief outline"?

This is a gem of a server strategy guide for large installations that *has* to go into the Moodle documentation--easy to understand and full of valuable experience.  Przemek, how do we integrate this into the docs?  

Hmm, as I understand it, the in memory database is the data on the mysql cluster. The async. writes to disk are more like an initial backup. So selects, writes, are (again if I understand MySQL's  description) done on the in memory database, not on the disk database.

It may well be that MySQL is spinning this and it doesn't really work that way, but the as I understand the concept it makes sense to me as a way to scale the db in a similar way to how apache scales. Otherwise your cluster data transfer is always going to be limited by the speed of your disk subsystem.

But this brings up another question. Don Hinkleman reports adding servers to scale Moodle to handle hundreds of concurrent quiz takers. Was this done with a single db server, unconected db servers, or were they using a db cluster?

I am not a data base person, but your comments concerning the greater stability of Postgres over MySQL lead me to ask the question: how difficult is it to migrate a live Moodle from MySQL to Postgres?

"could you please share as much as you can with the forum"

Mark: I'd be happy to share information re: the LMS evaluation process we went through at AU.

The most challenging task was convincing the administration to give serious consideration to an open source LMS.

We framed the open source argument in terms of licensing costs, flexibility (access to code), pedagogical focus, and a dynamic development community. We're already using some open source products at AU (UPortal, and PLONE, for instance), and these products have already been integrated with our existing proprietary systems (e.g., Banner), so the worth of open source couldn't be dismissed out of hand.

Once the administration agreed to evaluate an open source product, the challenge was identifying and promoting the best candidate. I promoted Moodle over other products such as ATutor because I thought it the all-around strongest open-source candidate available.

The evaluation process involved 2 teams: a test group and a core group. The test group comprised hands-on users--course designers, web developers, technical support, helpdesk, administrators, instructors, etc.; the core group comprised managers and administrators. Representatives from across the University were invited to participate. The test group were tasked with piloting the LMS under consideration; they then reported to the core group, who considered the technical strengths/shortcomings of the LMSs in a more political light.

The test group took on WebCT Vista first, because negotiations between the administration and WebCT were already underway. The WebCT Vista test drive helped the test group develop a more explicit needs assessment, which were further refined into a list of evaluation criteria. Each of the 3 LMSs was then evaluated in terms of those criteria.

I don't want to give the impression that this was a neat, technical exercise: it wasn't. There was a lot of sometimes contentious debate/disagreement re: the evaluation criteria and process. Our CIO did an excellent job of keeping the evaluators on task and moving the evaluation ahead--something that had been missing in past efforts to resolve the LMS issue. In some respects, the CIO's promotion of WebCT Vista served to hold people's feet to the fire, forcing the compromise and consolidation necessary to promote alternatives. In fact, the most difficult/trying part of the whole ordeal was identifying the evaluation criteria and process, not choosing the LMS.

The choice of criteria and an evaluation process had the side benefit of introducing those in administration to the concerns of those in course production and delivery and vice versa, so the evaluators ended up learning a lot about aspects of the University they hadn't been familiar with.

Although we ended up with a list of criteria to evaluate the competing LMSs, all the parties involved realized this was not simply a matter of comparing LMSs in terms of feature sets. The spreadsheet of criteria we ended up with was more properly a complex tapestry than a simple tool: the front of the tapestry looks to tell a simple, uncomplicated story; the reverse, however, contains the untidy and complex mass of threads that make the simple tale possible.

Consequently, although it may be tempting, it would be a mistake to take the list of criteria we developed for AU and simply apply that list in another contextthe choice of an LMS is fraught with not just technical but also political, economic, cultural, and personal factors. These concerns need to be aired and worked through--they should not be avoided simply because they can't be accommodated in a spreadsheet of techncial features. My point, I suppose, is that although our choice of LMS was ultimately based on a list of discrete criteria, those who were scoring the list were well aware that this was much more than a purely quantitative exercise. Even when we introduced weightings to represent the greater or lesser significance of some criteria, the scoring was based more on the discussions and debates that arrived at a particular criterion than the criterion in and of itself.

I can share more with those who are interested but that's probably more than enough for now.