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 the world’s best 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!