Look At That Doggy In The Window
5 min read
David Wiley recently posted on what some folks are calling Open Educational Resources, or OER's. This post extends my comment left on David's original post.
In his post, David starts by examining the difference between producers and consumers of Open Educational Resources, with an emphasis that Good Things '„¢ start happening when the Consumers become the Producers through the magic of wiki-style group editing.
He suggests that one of the impediments to broader re-use of OER's results from the original R living in a strict context -- ie, the R came into existence because of a specific educational need in a specific educational place, and reusing the R will be difficult in part because no two contexts are alike.
This leads to a comparison of OER development to Open Source development, particularly the notion that OER creators, like Open Source developers, are people who develop resources to "scratch" a personal "itch."
It's an interesting and thought provoking conversation, but one that breaks in a few places. Wiley is right on when he speaks of context being a limiting factor in reusing open content. However, he concludes:
Perhaps instead of sharing watered-down, decontextualized, 'professional' versions of our educational materials we should share context-rich, personality-laden ones.
This conclusion sidesteps the issue.
If content is going to be reused in a different context, then it actually needs to be reused in a different context. This context shift cannot occur when the resource remains locked in the originating site, firmly within its original context. A resource only becomes reusable when the next user can pick it up and take it with them (The analogy that comes to mind is taking a kid to a sports store and showing them a soccer ball on display in a window, and then telling them to have a great match, but that they need to play the match with the ball remaining off-limits behind the glass). Pointing to a resource on the web, and even editing a currently existing resource, only accomplishes part of the task. While it's great that we have a growing body of freely accessible content, we'd be foolish to pretend that it couldn't be better.
And this brings us to the Open Source comparison, and why Open Source development is thriving: with open source, you can take it with you. I can download Apache, MySQL, and PHP and install them on my computer. I can build a Mediawiki site, and install Drupal, and install Moodle. As I do this, the little mice in my brain start moving and spinning their wheels, and when I have questions, I can look into the code, or change the config settings, on my machine, in my own context. If I have an idea that makes sense, I can bring it back to the community. If it makes sense to enough people there, then the idea gets picked up. If it doesn't, then so be it. But I can still use my resource, in my way, and connect back to the community as needed.
This portability is the missing piece in creating widely re-used Open Content. There are some initial forays into moving content between sites -- Mediawiki has an excellent xml import/export feature; Moodle has the ability to back up pieces of courses, and Drupal has an array of import/export options. RSS import also provides the means to move content between sites. However, all of these methods require a comfort level with technology that stretches many users. Personally, I haven't met many people inside or outside education who are particularly comfortable cutting and pasting an xml file.
For Open Content to work, moving content needs to be simple. A user should be able to select anything from a page in a lesson to an entire chapter, and the selected contents should be exportable from one site and importable to another via a web UI.
It's also worth noting that the obstacles here are not technical. As RSS demonstrates, a lightweight solution does a great job moving large amounts of content between sites. However, until someone proposes a general spec, nothing will move.
So, here goes:
- Use the native solutions already under development or in use in Moodle, Drupal, and Mediawiki. For Moodle, this would be the backup/restore feature; in Drupal, the Import/Export API , and in Mediawiki, the XML import/export functionality. For what it's worth, the Mediawiki import/export seems to work with the fewest hitches.
- Code a central filter to convert content from one site into an appropriate format for the other. This process would likely need to include some choices about supported and unsupported markup. This filter would need to ship as an included library with the import/export block/module/extension for each application
- For each application, build a form that managed the import into each application; ie, a web UI that exposed the import/export functionality. Our target for reuse is not the technically proficient user, but a more general audience. Exporting and importing content -- from a single page to an entire course -- needs to be as complex as downloading an attachment from email, and subsequently re-sending that attachment in another email. Think of all the forwarded jokes you have received in the last week. It needs to be that simple.
