Why Mashups Make the LMOS

Regular readers know that I’ve been flogging the notion of a Learning Management Operating System (LMOS) pretty hard. The other day, LMOS partner-in-crime Patrick Masson and I published an article about the need to make LMS’s mash-up-friendly. Well, today, ZDNet editor David Berlind effectively connects the dots between the article and the LMOS concept.Berlind makes the analogy between a mash-up-enabled web and a traditional operating system like Windows XP or Mac OS X. Essentially, mash-up APIs take the place of operating system APIs. (He has some very nice diagrams to illustrate his point.) But there are two critical differences between the traditional OS and the web OS (or the hypothetical Learning Management OS). First, the barrier to entry for programming your own specialty tool is much lower with the web OS:

why might this ecosystem snowball the way none before it has (not to say that the ones before it haven’t been unbelievably successful)? Because, with mashups, fewer technical skills are needed to become a developer than ever. Not only that, the simplest ones can be done in 10 or 15 minutes. Before, you had to be a pretty decent code jockey with languages like C++ or Visual Basic to turn your creativity into innovation. With mashups, much the same way blogging systems put Web publishing into the hands of millions of ordinary non-technical people, the barrier to developing applications and turning creativity into innovation is so low that there’s a vacuum into which an entire new class of developers will be sucked.

For the LMOS, that new class of developers should be teachers and students. Not everyone will be up to the task, of course. But then, not everybody knows how to use formulas in spreadsheets, either. But if you have a reason to create a reasonably sophisticated spreadsheet, you can learn how to do it on your own without needing any training as a programmer. The same is true in many cases with mash-ups.

The second critical difference between a traditional OS and the web OS is the locus of control for the developer APIs. In the Old World, Apple, Microsoft, or whomever controlled the affordances that developers have to create new applications. But in the New World of the web OS, that power is distributed:

Another great aspect of the mashup ecosystem is that instead of the OS vendors being in charge of providing the APIs, that’s left to the operators of Web sites. In true bazaar-like fashion (as in The Cathedral and the Bazaar), what this means is that anybody can add any API at anytime which in turn makes the mashup ecosystem incredibly ripe for innovation. After all, when has a developer not said, “I wish there was an API for XYZ to do some heavy lifting for me?” That desire to scratch an itch is where innovation begins and now, there’s no paperwork to fill out, phone calls to make, or slotting of priorities to do in order to get itches scratched. Wanna add an API to the Internet? Go right head. Start innovating.

Just as non-developer power users are empowered to use the system in ways that blurs the line between usage and development, more sophisticated developers are empowered to blur the line between application development and operating system development. Anyone with the right skills can build the next Flickr or del.icio.us and empower power users to create extensions on top of it.

Now, there is one difference between the ecosystem that Berlind describes and the evolution of virtual learning environments that we invisioned. It has to do with the “M” in LMOS. We don’t just want to offer many different affordances. we want to orchestrate them. We want to allow users with different permission levels (students, faculty, administrators) to shape the learning environment in different ways, and we want to create a certain amount of mash-up automation, so that different applications within the same system can discover each other and work with each other without requiring developer intervention. That’s why we started talking about a service brokers. This is…well…challenging to accomplish in practice. Our colleague Bernie Durfee has sketched out a first use case implementation to start exploring how this would work in practice.