No, this isn’t another tired post complaining that we should think of all “consumers” as also being “producers.” Of course we should.
This is a post about a much more subtle problem with the way we’re thinking, that I am increasingly convinced is putting the field of open educational resources (OER) at risk.
It is both an axiom and mantra in the OER circles I move in that OER is a producer-driven field, and that the producer-driven nature of the field is a very bad thing. Producers have a tendency to produce what they *think* the consumers want, but are actually out of touch with the true needs of the consumers, and consequently produce things that are of little value in the real world.
Many people believe that the “producers-are-out-of-touch-with-reality” issue is the core problem with uptake and reuse of OERs. We’re not engaging the consumers (end users), we don’t really understand what they want and need, and consequently we produce OERs that just sit there on the web and aren’t ever reused.
I’m not sure if being producer-driven is the problem. In fact, the problem may be just the opposite.
In his seminal essay the Cathedral and the Bazaar, Eric Raymond states a number of rules that he believes govern successful open source projects. The most fundamental is also the most frequently quoted:
Every good work of software starts by scratching a developer’s personal itch.
I’ll call this Raymond’s Rule. While this quote is frequently brought up in the context of OER conversations, it must not be well understood in those contexts. The rule doesn’t say, “Every good work of software starts with a comprehensive survey of user needs.” It does not, in effect, say every good piece of software is built in response to specific needs expressed by actual consumers in the real world. It does, in fact, say just the opposite: Every good work of software starts by scratching a developer’s personal itch. In other words, every good work of open source software begins life as a producer-driven work.
Let’s try to really think about Raymond’s Rule in the context of OER. We don’t build software (generally speaking), we create content. We aren’t software developers (generally speaking), we’re teachers. Let’s restate Raymond’s Rule in terms of OER by making these two substitutions:
Every good OER starts by scratching a teacher’s personal itch.
Empowerment enthusiasts, one moment please. ‘Teachers’ as used above means “anyone who develops educational materials to support learning,” and can include both a school teacher (who needs materials to help teach something to his students) and a self-learner knee-deep in her Personal Learning Environment (developing materials to support her own learning).
The secret sauce in both the cases of the good open source software and the good OER is an actual, bias-riddled, context-bound, historical person located squarely in a concrete place and time addressing their own specific instructional problem.
Note the special phrase “their own” in the previous paragraph. A person who has conducted a comprehensive user survey in order to be “consumer-driven” has a very low chance of creating an OER that meets a specific teacher’s specific need. The comprehensive survey will, most likely, include dozens and dozens of real user needs, all of which the surveyor will attempt to meet in order to be consumer-driven. Consequently, the OER they create will suffer the same fate as other attempts at pleasing everyone – it will please no one. In other words, no one will use the OER – not even the author, since s/he didn’t build it to meet a specific need they had.
A decade ago when we argued about learning objects and how to design them so as to be most easily reusable, I temporarily believed that since “reuse” operationalizes as “recontextualize,” the simplest way to make learning objects easy to reuse was to make them as decontextualized as possible. I made a number of (if I may be allowed to say so) rather eloquent arguments to this effect. And technically speaking, I was right.
However, in the same vein as my recent post about Bekir, the decontextualization approach privileges efficiency while ignoring an important human cost. In this case, the important human cost is that decontextualized resources are as boring as anything you can possibly imagine. They go out of their way to avoid connecting their contents with any prior knowledge or experience or other context you may have. They are generally about as engaging as Keanu Reeves and Kathy Ireland in a radio drama whose dialog was written by George Lucas.
(See how that example of Reeves, Ireland, and Lucas draws on your previous experience with their films? Do you also see that, if I wanted to make this post as easy to reuse as possible in every corner of the globe, I have to omit that reference?)
When OERs or other learning objects are dry, boring, and awful, no one wants to reuse them. This is because no one wants to begin from something dry, boring, and awful. People want to reuse things that are interesting, engaging, and effective. Difficultly, “interesting,” “engaging,” and “effective” are all locally defined qualities. Like beauty, they are “in the eye of the beholder.” One man’s “boring” is another man’s “engaging.”
Let’s connect these dots…
- People want to reuse things they like.
- People don’t want to reuse things they don’t like.
- The characteristics of an OER that cause a consumer to “like” it differ from consumer to consumer.
How are we, then, to create OERs that everyone will actually reuse? The answer, of course, is that we can’t. We don’t need a dozen more “professional sounding” Introduction to Programming courses that have been decontexualized to serve everyone (while actually pleasing no one). We need 500 more Introduction to Programming courses with some personality and some attitude. We need the chunky bacon of Why’s Poignant Guide to Ruby. When there are real choices out there (not “choices” between 17 clones that can’t be differentiated), then people will start finding OERs they like. This will lead to people reusing OERs. (Even Linux comes in many flavors.)
Let’s come back to the consumer-driven / producer-driven question and look at open source software as an example. Open source software projects are successful when:
- a specific person with a specific need develops a specific solution to **their own** specific problem,
- that person then shares that specific solution with the world,
- other specific people with the same or a very similar specific need find the solution and adopt or adapt it to solve their own specific problems, and
- adaptations and extensions of the solution, developed to make the solution solve additional, closely related problems, are shared with the group.
In other words, open source software is the epitome of a producer-driven work. The work begins life with one producer, one with a specific personality and attitude, and continues life with a group of like-minded producers. These producers engage in a kind of work we might call “produce-to-use,” because they make software to satisfy their own needs. This guarantees that the software they produce will be useful to and used by someone. Of course, every project is happy to have users that might be described as “users-only,” but these do not contribute to the long-term growth or health of the project.
On the other hand, there seems to be a kind of “business model envy” in the OER field. We occasionally think that we need to conduct user surveys and then provide “the consumers” what they want – that is to say, sometimes we try to act like a “consumer-driven” business, because business books tell us that being consumer-driven is good. And in the business world, it undoubtedly is. In the business world almost all consumers are “users-only,” which is fine because they pay in order to consume, and they sustain the health and growth of the business by paying.
Problematically for the world of OER (like the world of open source), consumers who are “users-only” do not sustain projects. The entire point of OERs is to give them away for free. No one pays. People who find OERs and reuse them as is do not contribute to the health and growth of the project.
Neither open source software nor open educational resources are a business. Neither can be sustained like a business. Consumers don’t pay for them. Obviously there are the Red Hats of the world who have devised ways to build sustainable businesses around open source software. The same will soon be true in the OER space for companies who build sustainable businesses around open educational resources. But the sustainability of OSS and OER projects themselves derives from the activity of the “produce-to-use” group. (Or from successful wrap-around businesses subsidizing them.)
People in the OER field hate the phrase “if we build it, they will come.” Unfortunately, this is almost exactly the approach the open source world takes (very successfully) to developing software. We might restate slightly more precisely as “if I build it so that it makes me happy (meets my needs, reflects my personality, etc.), perhaps it will make some like-minded others happy, too.”
Perhaps we OER’ers should stop feeling guilty about our producer-driven approach and should instead embrace it. Perhaps instead of sharing watered-down, decontextualized, “professional” versions of our educational materials we should share context-rich, personality-laden ones. This will create real choice for “consumers” of OERs, some of whom will choose to become co-producers as Raymond described. Perhaps the OER field needs two new slogans:
Proud to be producer-driven!
and something like
To create the highest chance of reuse in other contexts, make your OERs as context-specific as possible.
Or maybe I’m wrong, and it’s just the jet-lag talking.
