A Federated Approach Could Make OER More Numerous, Findable, and Attributable

For as long as I have been involved in the Open Education Resources community there’s always been that moment in a conversation where someone comes up with the “brilliant” idea of building a central OER repository to solve the OER “findability problem”. I usually bite my tongue until it bleeds at that point and do math problems in my head to avoid saying something rude.

The repository approach to OER gets findability exactly backwards. Imagine you wanted to make a certain genre of novels more findable; say, science fiction novels dealing with interstellar trade. You have a meeting with fellow authors, who tell you that they always bump into potential readers who say they would love to read more sci-fi novels about interstellar trade, but they can never find any good ones at the online bookstores they frequent. There’s one author available at this store, another at this one. None of the 28 stores seems to have everything. You have at this point two strategies available to you:

  • “We should create one *master* store which will have all Sci-Fi on Insterstellar Trade in it (called SFIT!). It will have both the physical books and an ordering mechanism to order books from any of the other stores that have SFIT titles. When authors publish, they’ll know to contact us and have us update the index, letting us know all the places where their books are being sold, and maybe giving us a physical book for our own store! Problem solved!”, or
  • “We should try to get our novels in more stores.”

There might be some reason that the first approach makes sense, though frankly, I’ve never seen it argued for persuasively. In general, the simpler way to go is the second way — if you want to make something more findable, put it all over the damn place.

When I’ve brought this up before, the reasonable objections to this have generally been:

  • Fork avoidance: Copies in separate spaces develop seperate lives, with editors feeding back into two seperate instances, and editing that could be used to make one awesome copy makes two mediocre ones.
  • Attribution: So I copy something to my achive, host it in a new space, then change it a bit. Then someone copies it from me, changes it a bit and hosts their copy. Attribution starts to get complicated.
  • Psychological Issues: Isn’t copying to my site stealing? There’s a way in which we still think of the “payoff” for resources as some sort of site traffic.

And these are real issues. But they are exactly the sort of issues that plenty of people in the past few years have been tackling. Github makes forking less painful, and deals elegantly with attribution. Recent editing tools such as Draftin turn the community revisions process on their head. Here’s the author of that tool talking about how forking is good for the soul:

When I share a Google Doc, collaborators overwrite my master copy. It’s insanely difficult to accept individual changes they’ve made. However, when you share your document using Draft, any changes your collaborator makes are on their own copy of the document, and you get to accept or ignore each individual change they make.

This seems to me an evolution of how we are solving knowledge management problems. I’ve heard this shift described before as a shift from collaboration to federation — there’s a governing body at work in both the GitHub and Draftin examples that allows changes to propagate through the federated instances, but at any given time individual users are in complete control of their copies (in the language of federation, “self-governing”). You can compare this to your normal experience with MS Word where there is one copy of a document, and revisions must be resolved, or Wikipedia where there is one definitive article on which people must reach consensus. There are certain places where that approach makes sense. There’s something to be said for the convention that Wikipedia articles can’t be forked — people have to hash it out and come to agreement with people with whom they disagree. But for an awful lot of scenarios, the consensus piece is a drawback.

This is why, in my quest to build a cross-institutional wiki, I’ve found Ward Cunningham’s proposal for a federated wiki so interesting. Cunningham, the inventor of the first wiki as well as of the methodology called “extreme programming”, is, at the age of 64, still one of the most insightful people around when it comes to issues of what hinders individual and group productivity. And looking at his mid-90s creation — the wiki — he’s become convinced the problem is too much emphasis on consensus — the preference that there be a single copy of the wiki. In his federated wiki, to make a change is *always* to fork a page. Your change happens in your own space.  If people find your change useful, they pull it back into their copy. It’s a GitHub approach, it’s a Draftin approach. It’s not collaborative; it’s cooperative, it’s federated.

What the first wiki did was replace the 404 page with a “create this page” interface, and replace the “Email the Webmaster” link with an edit option.

What the federated wiki does is replace the edit button with a “clone” button, trusting the version tracking software on the backend can easily resolve the forks that people care to resolve. You come to a page, click edit, and now that page fork lives on your site. Maybe that gets merged back to the other site. Maybe it stays your own edit. There’s still plenty of reasons why writers would want to resolve versions and propagate changes. But there’s no imperative to do that.

That’s a huge shift in how we think about digital artifacts and networks, and it’s got me thinking about OER and copies again. I’m early in my thinking about it, but I would really encourage you to watch the video below and think about how such a model could inform our edtech efforts — whether they be efforts around OER or cross-institutional collaboration. Is this a productive direction? Is it a possible one?

Ward’s not a great presenter, and you can see him struggling to explain the concept below. But its worth the effort to try to understand this, I think. Plus, it’s Ward Freaking Cunningham, and this video only has 2,000 views whereas Sugura Mitra’s has tens of millions of viewers for reinventing kiosk computing. Watch it based on principle alone! Ideas matter!

 


6 Comments on “A Federated Approach Could Make OER More Numerous, Findable, and Attributable”

  1. […] A Federated Approach Could Make OER More Numerous, Findable, and Attributable → […]

  2. […] been doing – although I have to admit I had no idea until I saw Mike’s prior post A Federated Approach Could Make OER More Numerous, Findable, and Attributable about his work in this […]

  3. Kate says:

    Just delayed thanks for this, Mike. Clear, helpful, especially for people like me who can see what would be magically good but need help figuring out how to make it so. Federation is a really powerful concept to me, which really means: thanks to you, I get it, and I’m not lying on the floor with a bump on my head and cheeping birds.

    • mikecaulfield says:

      That’s great to know! It’s not an easy concept – it runs against the grain of a lot of assumptions about how web collaboration happens.

  4. […] occurred to me this morning that one of the things Mike Caufield (and I guess some tools like PenFlip, Draftin) advocate is to replace the wiki/google docs (where […]


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 130 other followers