OER as Snapshot vs. OER as “Runnable Code”

Today I was reading Pamela Fox’s blog post about discussions inside Coursera on whether they want to open up their code. It’s a thoughtful treatment of the subject, and contains I think a nice discussion of some of the hidden costs of going the open source route. It’s great to see engineers at Coursera thinking about this (see, I am not the anti-Coursera ravebot you all thought I was! I can be nice when I see good things! Show me good things!)

What Pamela ends up on is a desirable compromise — a halfway point between open and closed she calls the “source snapshot” approach:

A “snapshot” is a dump of some part of our codebase, taken at a point in time and copied into a public repository. It may be an incomplete dump (missing dependencies or server-side, e.g.), it would not necessarily be runnable, and it would have no guarantees of being up-to-date or ever being updated in the future.

What’s fascinating is to think of these two models — open-sourcing and snapshotting — in terms of OER, and in particular OCW. Read that paragraph again, and you’ll realize that “Source Snapshot” defines what OpenCourseWare has largely been in the past. Materials from a course (but not all the materials), not runnable out of the box, with no expectation of updates or upkeep.

As Pamela points out, this is a good intermediate step:

The snapshot would still be useful, for developers looking to see how we approached some aspect in the codebase, and also for us to refer to in talks and blog posts. It would also be a way for us to dip our toes into the open source waters, and to see what developers are most interested in. If a particular snapshot got a lot of attention, then maybe one day, when we felt we had the resources, we would turn it into an actual living open-source library and spend the time needed to nurture that community.

And again, we see the parallel here, where most institutional reuse of OCW ends up influencing approach to course design without being directly reused. To get reuse, however, you need to go the extra mile.

We’ve talked about this before, of course.  There’s this ancient post of mine on Openess as Reuse vs. Openness as Transparency, and Stian Haklev’s amazing dissertation on the history and context of OCW in China makes an expanded version of this distinction central to its analysis (see the “Typology” on page seven for starters). Others have made similar distinctions.

But it’s useful, I think, to see it through this slightly different lens of “snapshots” vs. “open source”. To paraphrase Chris Kelty, an anthropologist of the Open Source community, such analogies are “good to think with” in that they provide new angles on old questions.

In this case, what the analogy allows us to ask is this: If we see open-source as a continuum from “source snapshot” to ‘true’ open source, what elements would we need to move from Point A to Point B?

This view sees transparency and reuse not as two seperate concerns, but as potential stages of a project’s development. That’s problematic but it’s also liberating, because the minute we see “OCW as open source” as built on top of “OCW as snapshot”, we see much of what makes the difference in software would also make the difference in OCW. To move OCW beyond the snapshot phase OCW would need to be:

  • More runnable. It should be usable, not just viewable. Real repurposable content shipped for immediate use in whatever wrapper (LMS, WordPress, EdX) it runs natively in. No more PDFs. No more quizzes as documents.
  • Dependency-free. It should contain everything it needs to run. No copyright redactions, no references to textbooks not included, no mentions of class activities that aren’t provided in the materials.
  • Community-supported. It would need a community around it, and a conscious (and funded!) effort by the original developer or developing institution to nurture that community through its initial stages.
  • Maintained and updated. It should have a community or institution that commits to the ongoing pruning and extension that such projects require so that they do not become empty husks of linkrot. (See Dave Cormier’s post for how that might work).

I think we’re getting there, slowly. But it’s hard, and the transition from “source snapshot” to “open source” is more resource intensive than many realize. Thinking about it in these terms helps us explain why it is resource intensive, and under what circumstances that use of resources might be warranted. Again, not a perfect lens and not the only lens on this (not nearly), but one that I am finding useful at the moment.

About these ads

4 Comments on “OER as Snapshot vs. OER as “Runnable Code””

  1. scarsonmsm says:

    A great way to looks at this, and yes, I think the question of the resources required is key. We actually use the language of “snapshot” at MIT OpenCourseWare to describe what we are doing, and our content stands guilty of all the shortcomings you describe. On the other hand, we’ve been able to achieve considerable scale and comprehensiveness in our publication, and that serves many of our users very well. We did some estimates of what it would take even to move away from PDF to HTML/MathML etc, and our costs would increase tenfold, with a corresponding decrease in our output. These are difficult tradeoffs for sure.

  2. mikecaulfield says:

    In retrospect, I think I may have heard either you or Lindsey use the term in 2008/09, which is why maybe it stood out for me. (In retrospect, I should have gotten down to Boston more!).

    What about the second point though — that for snapshots that generate a certain level of interest (Pamela uses the Minimum Viable Product analogy here) the jump might be justified. I’m thinking of the Lewin class here, etc. Get to a million downloads, and you get the bump?

    I definitely agree that for a lot of classes the ROI on moving past snapshot doesn’t work, but think this idea of an interest threshold is intriguing.

  3. Less important than the notion of moving OER from snapshot to running code, of course, but… let’s not let charity get in the way and forget the obvious, pragmatic reason Coursera doesn’t go Open Source (noting along the way that the contention they don’t have time to maintain a public code base is *horse shit*) and instead contemplate provide non-working, incomplete snapshots: reducing competition.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 129 other followers