So I’m sure you know this — supporting 50 individual WordPress blog sites is draining and expensive. But if you have that sort of scale, you can get WordPress Multiuser instead, and put em all on that, and its rather cheap to maintain. Likewise, as efforts around a technology expand, support per person goes down because the community can start to help with support, and more importantly people start to learn by looking at other people’s models.
The same is true of wikis. Fifty wikis will kill you stone cold dead. But one big wiki where different classes can edit their corner of it — that’s pretty cheap, comparatively at least.
Niche stuff like the Assignment Bank ds106 built and Alan is refactoring is really expensive too — if you do it one class at a time. But once that configuration and integration cost is spread over multiple classes it won’t cost you much per class at all.
The term for these sort of things is scalability, and the key idea is that as scale increases, marginal cost of product and support approaches zero. Your 500th customer costs you a fraction of your first.
We heard a lot about scalability in the MOOC craze — scalability of classes, primarily. And thinking about that is a worthwhile task I think, even if some of those experiments haven’t exactly panned out.
But for people looking for an *easy* win, it’s staring us right in the face. Because the easiest way to really unleash the potential of these technologies is to kill the unprofitable bits of fragmentation and build at scale. What if a *state* or *province* just said — “You know what — we’re going to support one wiki installation across all our two-year and four-year institutions for student use in the classroom. We’ll support it centrally, and let you all work out the details of how to share it.”
Not one wiki contract, mind you. One wiki.
What would that do?
What if a state said, hey, instead of running UMWBlogs and UVaBlogs and So and So Community College Blogs we want to hire the UMW team and we want to support a set of multi-site installs available to all schools in the state. Or if an organization such as AAC&U or EDUCAUSE said look, as part of your benefits, all your students get to run blogs on this thing we’re going to build. Not special pricing on a contract, but something we actually own, maintain, and develop based on your feedback.
What would that do?
Suddenly your wiki isn’t a ghost-town — you’ve got the scale to have a real community around it. Suddenly your WP install is getting upgraded without anyone at your institution having to touch it. Alan could build out an install just for various assignment banks, with specialized themes. That models problem goes away, because you’re not relying of ten people to jumpstart this at your institution, but hundereds of people across many institutions.
But we don’t do this. We buy institutional repository software that no one ever uses. We support our own WordPress install and have the painful year or two where five people are on it, and we have to decide whether we push through, or ditch it. We build a new wiki for every class.
This is really a simple calculus. This isn’t scaling as a metaphor. This is straightforward scaling. Yet we’ve rushed right past it. We buy state contracts with vendors, or support open services locally. we don’t do open services at the state or consortium level.
Why?
Hapgood 
Leave a reply to L.O.B. | bavatuesdays Cancel reply