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.

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.com/patents_and_ims_common_cartridge/
been resolved to your satisfaction?

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.

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 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

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.

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.