« A Weblog Learning Management System | Main | Open Source e-Learning Platform from MIT »
April 16, 2003
The Pain of Multiplicity Heterogeneity
First, a note: If you're just catching up on this conversation via the blurb in Online Learning Daily, you might want to start with George Siemens' post, then my response, then back and forth. I'm putting out one more attempt at clarity, then dropping out of this thread. :-)
George wants to point to complexity as the enemy of standards. Stephen Downes said "Complicated standards result in complicated and inflexible software, exactly what people don't want and don't choose." I agree with Stephen's point, and I want to make it clear that I don't think complexity should necessarily be the ultimate goal, in and of itself. However, neither do I think complexity is the enemy.
The "pain of multiplicity" I referred to comes about when we wind up with with either multiple, heterogenous standards or multiple, heterogenous versions of the same standard. The "pain of multiplicity" could also be expressed as the "pain of heterogeneity." Come to think of it, heterogeneity is really the term I should have used, instead of multiplicity.
In our field, we have an alphabet soup of standards (IMS, AICC, SCORM, ARIADNE, LTSC LOM, SIF, etc.) that only overlap somewhat, nevermind being interoperable. The goal should be to bring the work that has been done together, to homogenize that heterogenity. It seems to me that these standards bodies are making progress on bringing these standards together. I'd like to see that process reach its end before we scrap it. Is the way we're getting ot the end -- i.e., resolving a half-dozen different specifications -- the best route? Probably not. But it's where we are; I don't see going back to the starting point or introducing yet another new "simple" standard as a solution that moves us away from the heterogeneity.
I would hate to see the form of heterogeneity we have now (multiple standards) be replaced by a different form of heterogeneity (many multiple versions of the same standard). I think that situation can be caused by rapid release of different versions of a simple standard, as George appears to advocate. I think of the "Best Viewed With ___" buttons that arose in the mid-nineties browser wars, while Netscape and IE proliferated multiple browser versions, each with their own quirky takes on the simultaneously evolving HTML standard. Or the fiasco around the RSS 0.93/1.0/2.0 iterations last year that froze anyone want to do RSS development. This is why I argue that standards definition can't follow the open source software development credo of "release early, release often" and remain effective as a standard while doing so.
A simple standard? Sure, I'm all for that. I think we'll see if the recent work with RSS and RLOs will bear fruit, so maybe the proof is in the pudding (to mix my food metaphors). I think we all probably agree that complexity, in the sense of multiple, heterogenous standards, is problematic. However, I believe that complexity, in the sense of standard that obtains its flexibility through richness and depth, is preferable to flexibility obtained through rapid, iterative releases.
The latter has the potential to result in a situation where we have different software or tools that support different versions of the same standard. Choice is best provide when different software supports the same standard. That's when the end users win.
[Please note: this post wins the award for All-Time Most Instances of the Word "Heterogeneity." In accepting this award, I'd like to thank the academy for teaching me to use five-dollar words like "heterogeneity" and "serendipitous" and "masticate."]
Posted April 16, 2003 09:24 PM