And hello! What is this IMS GLC Common Cartridge specification? http://www.imsglobal.org/commoncartridge.html
Everyone seems to be backing it. And they promise a common way to port content to all LMS platforms seamlessly.
In order to deliver course content for LMS platforms, content providers find they must build, test and distribute their content for each platform. This duplication of effort increases both production time and costs. Delivering content for specific platforms also limits the development and distribution of content by smaller content providers and acts to exclude less widely used LMS platforms.
The Learning Management System (LMS) market currently spans several course delivery platforms including, but by no means limited to, Angel, Blackboard, Desire2Learn, Moodle, Sakai and WebCT. Most of these systems each use their own proprietary formats for course content and pose an expensive problem for content providers wishing to distribute content across platforms. Many smaller or locally-developed systems are limited in their support for these proprietary formats.
The Solution
The Common Cartridge will define a commonly supported content format, able to run on any compliant LMS platform. It will enable content providers to achieve lower production costs whilst expanding the effective market by eliminating platform dependency. This will both stimulate production by larger content providers and open up the market to their smaller counterparts. The LMS providers in turn, will have a stronger business case to take to their customers, as schools, colleges, universities, training departments and certification programs will have available a broader catalog of offerings reaching deeper into the curriculum.
Wasn’t that the promise of SCORM?
Viplav Baxi's Meanderings 
Read this with interest – I have heard “SCORM” for a number of years, but still have not seen how it has made my life any easier! In fact, it is about to get a lot more complicated since we have an LMS that claims to be able to take advantage of this. Certainly it gives you the ability to build a level of communication/tracking between a course/LMS, but it also ups the development effort/skill required and support. I worry about the cost of doing this versus a measurable return for the increased cost and complexity.
The central problem is that SCORM has been thought to apply towards the end of the content development cycle, not at the beginning where it should logically start. The problem has affected not only content developers but also the mindset of tool makers who think of it as a deployment-time consideration – as yet another format to publish to. Starting at the beginning of the cycle ensures that the developer really understands the different attributes of the course content and is able to visualize the learning experience especially as it relates to re-use, accessibility, durability, interoperability and run-time interactions between the learner and the backend LMS.
With SCORM 2004, some of this will start to happen earlier in the cycle and I am hoping it is going to become easier to develop courses using SCORM and being able to seamlessly integrate it with compliant LMSs.
To reduce the cost and the impact on the effort/skill required, the authoring tool must automate SCORM compliance through features that allow easy selection of SCORM options. For a content developer, the emphasis should be more towards crafting the learning experience (deciding what, when and how information needs to be communicated back) rather than programming it. This could be done by extending current authoring tools by wizards that take the developer step by step through a series of options.
Thanks for raising this concern!