I’m reproducing here some conversation between Steve Carson and myself from the UNESCO IIEP forum on open content.
Steve Carson from MIT asked:
In all of the projects discussed so far, there seems to be a tension between the desire to provide rich digital learning materials–which usually demand more complex technologies–and the desire to make learning materials as widely available as possible–which often demands much simpler technologies. The projects presented thus far each address both concerns, but with different levels of emphasis on each. Since your group has been involved in a number of projects, I’m wondering if you might share your experiences with these trade-offs (or if you see this as being a trade-off at all).
Great question! This is a key question! In my answer I restrict myself
to talking about the domain of open educational resources (that is,
not commercial resources.)
There are people who have the desire to produce the rich materials you
spoke of. And as you indicate, the richness of these materials is
generally inversely proportional to their accessibility by users in
the developing world. If our interest is in serving the developing
world, should we discourage these people from creating and releasing
these rich digital materials? Or should we encourage them to change
their approach and start producing some other kind of materials?
As long as we’re relying on people to freely share their materials, I
think we have to happily accept whatever they’re willing to share. I
don’t think we can possibly afford to discourage anyone from sharing
anything at this point.
I believe we must view the vast body of open educational resources as
“content infrastructure.” By “content infrastructure” I mean that
instead of thinking about open educational resources as being the
educational opportunity we are trying to share with people (the end of
our work), we should think about them as the basic resources necessary
for doing our job (a means to the end of our work). A vast collection
of open educational resources is, of course, the first milestone in
our work, not the end of our work.
I think an analogy to open source software is useful here (I’ll use
the Apache webserver as the example). Eric Raymond said that every
good piece of software starts with a programmer “scratching his own
itch.” I think what he meant is that what makes OSS great is that it
is written by the person with the need. Not written in response to use
cases or market data. And if the software meets the developer’s need,
it will likely meet someone else’s. Apache is a piece of software that
meets the need of its developers (and several other people).
Originally it was written to run on Unix. But today, programmers have
ported Apache to at least 15 platforms
I think we have to approach educational materials in this same way
(and let others approach it in this way). You can’t create educational
materials that function effectively in every single context any more
than you can write software that runs on every single platform (no
Java comments, please). I think we should focus on solving specific
instructional problems, and make sure that our solution at least works
for someone. Then other developers can “port” our materials to their
“platform,” or in other words, other instructional designers can adapt
our materials to solve local instructional problems.
This is why I like projects like OpenCourseWare and Connexions. These
are materials designed by their users â€“ faculty at MIT, Rice, USU, or
other places – that they use themselves. We know they work somewhere
for someone. That gives me confidence that I could “port” those
materials to my “platform” and expect some success. It should give
others that same confidence. Content is infrastructure, and as the
OCWs and Connexions continue to come online, the next great wave of
work for those of us interested in bringing educational opportunity to
the developing world will focus on building instructional design
capacity so that this content infrastructure can be successfully
leveraged and utilized locally.
I think. =)