On ELF, OKI, etc, I don’t think I disagree and see the value in your approach and look forward to reading more on it. I wasn’t proposing looking at those particularly from the perspective of practicality, only that in terms of enumerating all of the integration points that might be specific to elearning, the provide a more complete starting point for eliminating possibilites than doing it off the top of your head (or at least the top of my head – I can barely keep anything straight these days). But like I said, don’t really disagree, and look forward to seeing where you are going with this series. Great work and thanks for the considered reply. Cheers, Scott

Regarding OKI and eLF, your observation that I’m treading some of the same ground is spot-on. But there are three reasons why I’ve chosen to “return to first principles”, as you’ve aptly put it. First of all, I’m interested in an architecture that can be practically built today. My sense is that we’re probably years away from having an eLF-compliant LMS and even farther away from having an ecosystem of pluggable components. In contrast, the approach I’ve described so far could probably yield a competitive system with just a handful of programmer months required to implement it. And I suspect that we’d get 80% of the benefits of eLF compliance in the process.

Which brings me to my second point. My sense of OKI and eLF from the outside is that they didn’t necessarily place a high premium on creating a gentle slope for programmers to create tools. Instead, their approach seems to have been to catalog all the integration interfaces they can think of and describe fairly robust standards for them, with an emphasis on comprehensiveness. This is a valuable thought exercise, but I’m not entirely convinced that it yields sustainable standards upon which sustainable FOSS projects can be built. Successful FOSS projects, it seems to me, tend to place some emphasis on habitability for the programmers.

And finally, I have seen no public discussion of why OKI and eLF have defined the integration interfaces the way they have. What pedagogical principles are they observing? What teaching and learning affordances are they trying to achieve? Without that discussion–without that public discussion–it would be very easy for the standards designers to simply enshrine the flaws of the current generation of systems (such as stunted notions of groups) If, after our return to first principles, we discover that OKI or eLF has already come up with a strong technical implementation of the affordances that we need for our system, then that’s great. It confirms the value of those standards. If not, then that’s also valuable.

I like this exercise and the line of thought you are taking with your ‘LMOS’ notion, but I wonder if it’s necessary to scale back to first principles like this. It seems to me that the folks who have worked on both OKI and the Elearning Framework have done a lot of legwork to identify some of these critical integration points, and so to reach your goal of a system that uses general pieces as much as possible while enabling extensibility and respecting that which is peculiar to education, maybe another approach would be to go through either of these and identify the points they’ve raised that should be considered just more generic platform characteristics, and what we’d be left with are those education specific points.
In any case, like I said, I think this series you’ve been writing on the ‘LMOS’ idea is very useful and I’ve been quoting it regularly in presentations on service oriented approaches and other alternative approaches to extneding the conventional CMS. Keep up the great work! Cheers, Scott Leslie