I’ve been meaning to comment on D’Arcy Norman’s frustrations with not being able to export Moodle courses to a common standard. He makes a very important point:
Moodle happily ingests those formats, acting to absorb content into what then becomes an inescapable pit of quicksand. It’s a one-way trip. Content can check in, but it can never leave.
If Blackboard did that, there would be villagers marching in the streets with torches in hand. The Blackboard SCORM import/export stuff might not be perfect, but at least they try to let people move content out.
With Moodle, it’s currently a vendor lock-in proposition. The only saving grace is that the vendor just happens to be an open source project. But it’s still lock-in.
Now, I don’t know any of the specifics around Moodle’s export capabilities but, in general, universities should insist on support for some standard export capability in any platform they adopt. We all know that the cost (in time and/or dollars) of moving content from one system to another is one of the major barriers to universities who would otherwise be motivated to switch. So unless you plan on sticking with your next platform forever, make sure you press your vendor or open source community hard about supporting some sort of content exit strategy. Heck, even if your school loves Moodle (or whatever) and plans on staying with it as long as, say, John McCain wants the U.S. to stay in Iraq, individual teachers move from school to school and, depending on their contract, are usually entitled to take their course content with them. That is, if they can get it out of the LMS.
To be fair, supporting a robust, standards-based export facility is a hard problem, in part because we keep adding tools to our learning environment and each tool needs an import/export format to work in the standard. Nevertheless, basic support for export (focusing maybe on a handful of widely used tools) is far better than none.
I agree Moodle’s lack of standards-based exports is frustrating, although I can understand how in an open-source project it doesn’t tend to be an early goal to facilitate migration off the system. I don’t think this is a malicious attempt at lock-in — it’s just not something anyone has been suitably self-motivated to create.
We have done some initial work to enable importing Moodle content into Sakai (pretty cool that this is starting come up more often). More details are available in the Sakai wiki:
http://confluence.sakaiproject.org/confluence/x/oBw
The position here is quite simple. The fact is that Moodle doesn’t offer these export options YET.
It’s not a conspiracy or a deliberate omission. Anyone who needs this can either wait for it to emerge from community development or commission the development themselves.
The extent of export options is not a secret, and can be taken into account in full during the evaluation phase of the implementation project.
The vendor lock in argument is a non-starter as there are no restrictions to prevent anyone implementing this. Moodle is open source software.
Let’s hope that these options emerge soon to reassure potential and current users so that we can get back to focussing on the primary purpose for using software of this type.
I never suggested that there was anything deliberate about this. Nor would I. But this absolutely is lock-in. You can get content out of proprietary systems that don’t support export too, if you want to put in the elbow grease. It’s called copy/paste. The point is that, lacking standards-based export, there is a significant barrier to exit for schools that want to migrate. The reason why this barrier exists is irrelevant. It is a general (and perfectly valid) point I am making here about all LMSs and how universities should go about making purchasing decisions. It’s not intended to be a Moodle-specific criticism.
I agree with what John & Ray have said here. Michael you’re raising some good points but the key difference here… and the reason “lock-in” isn’t the most appropriate term… is that the Moodle/Sakai/ATutor/Etc. communities decide when content export is a priority and can develop that functionality whenever it rises to the top. I think the example John noted is a good one.
If the problem is the term, then let’s find some other term. If you want to make the case that using open source software means that the lock-in isn’t deliberate, or that motivated communities of adopting institutions have more power to change this feature, I happily concede both points. But the fact that communities can choose, at some point, to develop standards-based export is of no help to a particular institution looking to exit the platform at a particular moment. To them the distinction is academic (in a bad way). A university looking to leave a platform by, say, the next academic year isn’t going to take much solace in hearing, “Well, we don’t have export for you, but we *could* if we wanted to. Or you could develop it yourself!” It reminds me a bit of the sketch about the Protestant man talking about birth control and sex in Monty Python’s “The Meaning of Life.”
Deliberate or not: We’ll have to agree to disagree on this. IMO the tone of the comments in the introduction and the blog referred to are that the position of Moodle lacking open standards export options is somehow engineered.
Alternative phrase: Not sure what this would be other than “this feature is not implemented yet”.
Users wishing to migrate to other systems: Agreed, that the potential scenarios are cold comfort to those wanting to migrate. I can’t help conclude that where this is an issue there needs to be greater emphasis on reflecting upon whether the pre-adoption evaluation approach was sufficiently robust.
All this aside, Moodle and Moodle users (current and prospective) would benefit from the export capabilities being referred to being developed… so developers need to get coding or someone needs to get their wallet out.
I guess “lock-in” is a loaded term. I also think D’Arcy’s broader point is that the ed tech community tends to cut Moodle and other open source projects more slack on their shortcomings as platforms than they (we?)do for the proprietaries because we value their openness, and that maybe they sometimes go too far.
Your point about pre-adoption evaluation is spot-on and really hits what I was trying to get at. Universities evaluating platforms for adoption need to take into account that no platform lasts forever when putting together their evaluation criteria. They need to consider the cost of exit as well as the cost of entrance. And if the question is posed that way, then it’s possible a new Moodle adoptee might decide that paying to develop standards-based export would be something they’d be willing to absorb as an adoption cost up-front, when they’re more inclined to invest.
I’m involved with a large project where a national learning object repository should be integrated with learning management systems. The aim is, as a first step, to be able to export an existing course of an LMS and to send it in a reusable format to a repository system. The export should happen mostly automatically.
We have implemented prototypes for Blackboard Vista and Moodle (and another open source lms) to export course contents as described above. Here are the experiences:
With Moodle we had to implement an extension. We needed a skilled programmer who realized the export function. The contents were exported as IMS-CP packages. The programmer needed 10 working days.
With Blackboard Vista we were not able to realize it. The reason is that Vista does not have an API that allows to access to the contents and the way they are organized in the learning modules. The only way to export the contents is to manually export every single learning module as IMS-CP. SCORM export is not available. And yes – the entire course can be exported in an archive format. But the file is encrypted (!) which efficiently prevents all technically skilled persons from doing reverse engineering. Obviously, Blackboard by no means gives away or sells the decryption tool.
Blackboard has made an offer (not exactly cheap!) for a clumsy powerlink extension that exports programmatically the learning modules of a course. We are evaluation it now…
I leave it up to you to draw your conclusions.
Cheers
Rolf
Rolf, you did not leave any contact info – I run a repository project trying to address similar challenges, and would dearly love to talk to you about your solutions and anything we have that might be of use to you. Please send me an email if you are interested to discuss further, [email protected]
@John Lewis
Can Sakai export an entire course to an export file?
@All, Moodle by default exports an entire course to an open XML standard (moodle.xml) with the file system. There is no encryption on this XML export, and anyone is free to write a conversion tool that reads moodle.xml and converts it into another format – as Rolf aptly describes.
Open source projects generally don’t run with large profit margins or capital funding, so new features need to have either a source of funding or a source of development, documentation, and QA resources.
Moodle hasn’t had the benefit of large, open ended grant funding, so larger scale development tends to be very focused on the goals of the funding sources – generally larges institutions like OU, NZVLE, Intel Education, CIE, etc. who need specific functionality added to Moodle on a tightly managed budget and timeline – these projects are more focused on adding more functionality to Moodle than to building export formats – esp. because Moodle’s existing export format is not that hard to read and if need be convert from one XML format to another.
The SCORM format is so limited in it’s ability to support the full range of Moodle (or Blackboard) features that my personal opinion is that building a SCORM export tool would be more of a marketing talking point than an actually useful feature for most people using the LMS- folks would constantly be complaining about all the functionality that can’t supported in the SCORM specification:-(.
If D’Arcy or others can put together a grant or other source of the development resources to build and release a solidly coded and well tested and documented IMS CC export for Moodle, then folks in the Moodle community would be happy to include it – a decent export format would really need to be IMS Common Cartridge, though, IMO.
We in the Moodle development community are really working very hard to give the user community the best LMS we can with the constraints of time and resources – we would love to work on a project to provide a good IMS CC export from Moodle – I’ve been trying for years now with Jason Cole, Jim Farmer, Martin Dougiamas, Martin Langhoff etc. to put together a project to provide IMS CC export for Moodle – the lack of it is not for lack of good faith or desire on the part of the Moodle development community – however it is not a trivial project and generally non-trivial projects need to have a way to provide dedicated resources over the lifetime of the project to be successful.
We agree on many points, Michael. Again, I don’t think anybody here is trying accuse the Moodle community of malice or negligence. Nor has anyone said or implied that Moodle is technically incapable of supporting standards-based export. Nor has anyone said or implied that the standards we have are great or that compliance with them is easy. (To the contrary, in fact.) I’m not sure that I understand the level of defensiveness that this post has provoked in the Moodle community.
I would quibble with calling moodle.xml an “open XML standard.” It’s an open XML format, which is not the same. But I don’t want to get hung up on semantics at the expense of the larger issues. Let me reiterate a point I made in an earlier comment:
If universities consider cost-of-exit as one of their LMS evaluation criteria, then they might be willing to fund something like Common Cartridge export as part of their cost of adoption. If your university thinks that it wants to adopt Moodle and is willing to make an investment in it, then part of that investment should be, essentially, disaster insurance in the form of export standards support.
The Moodle community, the Sakai community, and the larger educational community need to embrace this as an issue. It is the only way that we will solve the problem. I frankly think that touting moodle.xml and the fact that anybody can build their own exporters doesn’t help motivate the community to solve the deeper problem. I believe many open source communities, including both the Moodle and the Sakai communities, sometimes fall into the trap of dismissing weakness with the old “If you don’t like it, then you can change it yourself” deflection.
I have tremendous respect for Moodle and am on record as speaking about both the platform and the community in glowing terms on multiple occasions. This isn’t a slam. It’s a challenge.
Hi Michael, sorry if my response seemed defensive, that wasn’t what I intended at all. I am struggling to convey the ground truth of the situation as I see it and the current information I have – trying to be responsive rather than defensive:-)
Doing IMS CC export properly would take significant resources and – the model of keeping costs low doesn’t provide a great deal of spare cycles for developing such a tool – I’ve been trying to put together the funding for an IMS CC export for some time now and would love to see the necessary resources come together for this project, as would I think most of the Moodle community.
The ideal solution for a common standard is IMS Common Cartridge as it describes an entire course and meets the requirement for an insturctor to move from one system to another that Jim Farmer describes here:
http://moodle.org/mod/forum/discuss.php?d=93120#p411517
The OU’s OpenLearn provides examples of courses in both from Moodle to IMS CC (see http://openlearn.open.ac.uk/course/view.php?id=3431 for example) – the project is described here:
http://cosl.usu.edu/projects/educommons/roadmap/23
and here:
http://openlearn.open.ac.uk/course/view.php?id=3073
Currently though Tim Humt reports that OpenLearn uses a different development process where the original course content is developed in their own XML format, and then output to both Moodle.xml and IMS CC.
By the way, have the potential patent encumbrances with IMS CC you mention here:
http://www.mfeldstein.wpengine.com/patents_and_ims_common_cartridge/
been resolved to your satisfaction?
Michael, this looks like a great project. I’d like to whatever I can to help raise its profile and push the idea of getting one or more new Moodle adopters to fund it. Please drop me an email to discuss this offline (online…?).
As for the potential patent encumbrances, no, they have not resolved. I am afraid that we are only in the twilight of a long, dark night in terms of edupatents.
A little clarification on ATutor, it has had content exporting as a priority since its early days. It was the first OS system to implement Content Packaging exporting, and is still the only one I’m aware of that lets you get your content out, and back into other systems in a standard way. In the Dec 08 release an early implementation of Common Cartridge is be available, already importing cartridges from OpenLearn, and now exporting cartridges. Over the first quarter of 09 the University of Bologna will be working with the ATutor team to help finish up the CC implementation.