Thoughts on Moodle
The fact that Moodle is open source is a big plus in my opinion. This should not be taken to imply that there will be no cost to implement Moodle, as it would be wise to spend money for support and training, at least initially. This will be the case whatever LMS we adopt, though.
But with no license fees, an open source product has potential to save us money down the road, should we get comfortable enough with the product that we don't feel we need to pay for support any more. Also, we can rest easy that we won't suddenly have the rug pulled out from under us. Even if any of a number of unlikely events came to pass (Moodle goes commercial, or development comes to a halt) we will still be able to continue using the product in its current state for as long as user's browsers continue to work with it. This is likely to be a very long time.
Another plus for Moodle is that it has a large user base among schools, and in particular among small liberal arts schools.
One major feature of Moodle - its modularily - is of concern to me. On the surface, it sounds like a great feature. If Moodle is lacking some functionality you desire, you either search for a module someone else has written, or you write one yourself and you're all set. But in practice this can cause confusion and difficulties.
To illustrate this, let me use some examples from Movable Type, the blog software we use here. Many people have written "plug-ins" for Movable Type, to add functionality not present in the core product. These plug-ins would work in the same way that Moodle modules would work so issues we've had with plug-ins will give a good idea of issues we can expect with modules in Moodle. I'll list some of these below.
- There are often many plugins to do the same job. Sorting through which one to choose can take quite a long time, and it's not always clear we've made the best choice in the end.
- It's not easy letting the user know that a plugin is available, or pointing the user to documentation for a plugin. Tags are a good example of this. The Movable Type Help system makes no mention of them because they aren't a core feature, and the plugin only shows up on an administrator's screen since there are no user-configurable settings associated with it.
- If the core system is upgraded the plugin may break. Or the functionality may have been added to the core system in the meantime. This can cause confusion for the user, who may want to continue using the feature the old way. Again, tags are a good example. Movable Type 3.3 has been released but we have not yet upgraded (probably will in the summer). They have added a tagging feature, and it works differently that the tag plugin we are currently using. This may cause some pain for those using the current tagging plugin when we upgrade.
- Despite knowing all that I just said about problems with plug-ins, I'm still drawn to use them if they provide me with a feature that I want right now. I can anticipate faculty pushing for us to add Moodle modules because they really want the functionality immediately, and us agreeing to do so, even though we know this may cause us all trouble down the road.
If we eventually decide to implement Moodle, or any other product that allows modular feature creep, I think we should have a policy right from the start about how we will deal with this.
Comments
really nice article!
I agree with you.
Moodle is more easier to install and customize than other LMS such as Sakai.
Also, Moodle has alot of materials and documentations.
Posted by: elearning | November 21, 2008 6:52 AM