Hapgood

Mike Caulfield's latest web incarnation. Networked Learning, Open Education, and Online Digital Literacy


Amazon, OER, and SoundCloud

So Amazon is getting into the Open Educational Resources market. What do we think about that? If you read these pages regularly, you can probably predict what I’ll say. It’s the wrong model.

For over a decade and a half we’ve focused on getting OER into central sites that everyone can find. Or developing “registries” to index all of them. The idea is if “everyone just knows the one place to go” OER will be findable.

This has been a disaster.

It’s been a disaster for two reasons. The first is that it assumes that learning objects are immutable single things, and that the evolution of the object once it leaves the repository is not interesting to us. And so Amazon thinks that what OER needs is a marketplace (albeit with the money removed). But OER are *living* documents, and what they need is an environment less like Amazon.com and more like GitHub. (And that’s what we’re building at Wikity, a personal GitHub for OER).

So that’s the first lesson: products need a marketplace but living things need an ecosystem. Amazon gives us yet another market.

The second mistake is that it centralizes resources, and therefore makes the existing ecosystem more fragile.

I talked about this yesterday in my mammoth post on Connected Copies. While writing that post I found the most amazing example demonstrating this, which I’ll repeat here.

Here’s a bookseller list from a particular bookshop from 1813:

cat

How many of these works do you think are around today?

Answer: all of them. They all survived, hundreds of years. In fact, you can read almost all of them online today:

 

 

Now consider this. SoundCloud, a platform for music composers that has tens of millions of original works is in trouble. If it goes down, how many of those works will survive? If history is a guide, very few. And the same will be true of Amazon’s new effort. People will put much effort into it, upload things and maintain them there, and then one day Amazon will pull the plug.

Now you might be thinking that what I’m proposing then is that we put the OER we create on our own servers. Power to the People! But that sucks as a strategy too, because we’ve tried that as well, and hugely important works disappear because someone misses a server payment, gets hacked, or just gets sick of paying ten bucks a month so that other people can use their stuff. We trade large cataclysmic events for a thousand tiny disasters, but the result is the same.

So I’m actually proposing something much more radical, that OER should be a system of connected copies. And because I finally got tired of people asking if they needed to drop acid to understand what I’m talking about, I’ve started to explain the problem and the solutions from the beginning over here. It’s readable and understandable, I promise. And it’s key to getting us out of this infinite “let’s make a repository” loop we seem to be in.

Honestly, it’s the product of spending a number of weekends thinking how best to explain this, and the results have been, well, above average:

cc

I haven’t gotten to how copies evolve yet, but I actually managed to write something that starts at the beginning. I’ll try and continue with the middle, and maybe even proceed to an end, although that part has always eluded me.

See: Connected Copies, Part One

 



9 responses to “Amazon, OER, and SoundCloud”

  1. The above average comment is important. If the people making the copies are always using vernacular and technology that only 0.03% of the population can work with, it will have limited value… so it means getting off the bleeding edge is necessary.

  2. Mike

    In the hope that you take requests, here’s mine. I’ve come through federated wiki into wikity and for me the most important function is the one you sketched with your party example: how to propagate information about change—without simply propagating change itself—through connected copies, without everyone having to stand in the kitchen with a whiteboard marker.

    (sidenote: I’m interested in the emerging practice of people photographing snapshots of bits of presentations to keep for themselves. What are these photographs? Aides memoires, but also disconnected copies.This takes us back to the analog practice we’re all really familiar with: listening to a talk, and taking notes. That is, we make an interpretive copy, which we keep. But then what happens when we network the notes through Twitter, especially through Twitter sharing of photos of the speaker’s slides? What happens when we see multiple shots of the same slide from different vantage points in the room? Disconnected views, but also reassembled with each other if viewed from the third-party perspective of the absentee timeline.

    So at least part of the question that your raising for me is about the difference between generating connected copies, and coming across them.)

    1. I don’t know how much detail I’ll go into in the other series (this was just a quick hit) — I kind of wanted to set up a frame that would allow people to approach a wide variety of topics and see how connected copies bring together good elements of both copies and the whiteboard, but also radically change what is possible. So I want people to see this as a class of solutions: torrenting, federated wiki, IPFS, etc.

      But core to this is the idea of connection. Connected copies are “Copies that know things about other copies and related documents”. And that’s where the serendipity comes in. So I’ll get near there.

      The one thing I’m trying *not* to do is say anything that involves me thinking “Well, you really have to use this technology to understand it”. That’s my rule, to explain all this while not referencing any tech users haven’t used. So while I’ll get to serendipity, I think there’s going to be much less detail about that than in Garden and the Stream which was all about designed serendipity really.

      We’ll see. Like you I think it’s one of the most important features — unlike search, the methods of connection here help us to find things we aren’t looking for. But I *am* trying to tone the explanations down. I get a bit tired of people reacting to these ideas as if they were “trippy” when they are quite understandable, and I think that part of my reputation is a bit of a burden really. (Sigh).

      But I’ll try!

      1. You’re on a tear, Mike. Love this series.

        Maybe along Kate’s lines, I’ve noticed that Wikity & your Federated Wiki seem to support light HTML (text and images) best. Similar to Wikipedia, I suppose.

        But what of richer learning materials, materials that are more than rich text, materials that may even require a database hook-up (eg. my Desmos lessons) or other external software dependencies? This question probably moves up the chain from FedWiki to OER more broadly, where I don’t think there’s a great answer either. But if you had an answer, you’d hop the line.

      2. Dan —

        So I can tell you what federated wiki does, that serves as a possible model, but would need more newbie friendly work on it.

        In Ward’s fedwiki, there’s JSON that’s part of the main document (which could be your math or database data for instance) and then there are javascript/Node-based plugins which allow manipulation of the data underneath.

        So an item of JSON is shipped to the browser with a “type” of “Dan’s widget”. And assuming you install the plugin on the server side, you can fork it to your server.

        Then you can use that plugin interface to manipulate the underlying data. Now your forked version has different data or differently arranged data.

        The problem with Wikity is I ditched all this modularity to get it simple, and the problem with federated wiki is it’s a bit of an uphill climb for students at first (really just the “it’s weird” factor, mostly, but it matters). But I think long term, Ward’s conception of the solution is correct — widgets travel around with their data and get forked, and students can also use a toolbelt of widgets to solve and visualize problems.

        I can show you the plugin model (or Ward can) if you’re interested.

      3. “I can show you the plugin model (or Ward can) if you’re interested.”

        I’m pretty sure I’m out of my depth here already. I mainly want assurances that our best minds are working on OER platforms (centralized, decentralized, whatever) that are more than just depots for rich text or PDF. Because my usual gripes about the print medium in math class would still apply.

  3. After getting all my courses into GitHub and then playing with wikkity.cc I have to agree that you are close on a solution. Onboarding to github is too hard. I can never ask a teaxher to open up their terminal to contribute OER.

    We need push butoon remixing solutions such as wikkity.cc

  4. The key to effective OER is to follow the path all the way through the woods. How do we keep track of who uses what and ultimately who knows what? We already have all the content that anyone will need and the methods for continuing to create even more; what we don’t have is a way to record the learning experiences associated with all that content to report the recording in a useful meaningful way. Schooling is still a lot about keeping track of who knows what and then issuing some kind of certificate when some defined amount of learning or proficiency has been achieved. OER will need to be coupled with a LMS that has the reporting capabilities that Moodle is promising in their next release and that Canvas presumably already has. See http://developingprofessionalstaff-mpls.blogspot.com/ for more on this.

  5. […] Caufield outlines two reasons why the repository approach “has been a […]

Leave a comment