I think there’s something about the Thanksgiving time of year that inspires reflection about the bigger picture — perhaps it’s because we’ve all had a few months of the academic year to put our summer plans into place, and reflect upon them.

Or maybe it’s coincidence.

But Jim, your post is impeccably timed, and Andre’s contribution above is another important aspect to consider.

I’ve been considering setting up some documentation about how to replicate the various pieces of a distributed blogging platform to support a variety of course blogging exercises — think of it as blog meets portfolio meets curriculum authoring environment, with users dropping their content into (and out of) the institutional infrastructure.

The various authoring environments (aka blogs) can come from anywhere. With tools like Pipes, and the various syndication and embed structures we’ve all been discussing, moving content is becoming easier and easier. And this allows us to break our system into multiple pieces, with only some of these pieces (ie, the central aggregation site that collects the various feeds for courses) needing to under the direct control of the institution.

I’m glossing over some significant details here, but the gist of what I’m saying is this: a decentralized structure, with clearly defined points of contact, will be easier to set up and maintain because no single piece will need to bear the brunt of the load. Can these systems scale? Yes, absolutely. However, the myth of the enterprise needs to be fully exposed here. No one system needs to do it all, and using the FUD of “it won’t scale” as an argument for not trying is pretty stale feed.

So, you want to go in on documenting the tips and tricks that make these types of systems possible? More importantly, how much of this documentation is already written and can be repurposed with this goal in mind?

Now if I just knew someplace where I could set up a wiki.

Cheers,

Bill

I agree with you that the only way that institutions are ever going to do edTech properly is if they work together and share like this. Budgets are simply too tight. However, we have been having conversations about doing the same thing here at UBC (for instance some faculties want their own system that they can control). The problems that we have come up with are the following:

1)How much do people pay for server space. Although sharing with one smaller University is fine… what about sharing with 10? Or 20? Your server will be brought to its needs.
2)The institutions or departments ¨piggybacking¨ don´t really have full control. They can´t go in and easily add themes or plugins. Customization and ownership stops for them at the WordPress UI.
3)How do we truly share development? What happens when you come up with a radical idea to improve UMW on the back end but the other institution doesn´t want to do it?

All of these concerns have pushed us to take a different model in our approach to sharing. We are busy working on making every aspect of our development easily accessible from the main blog site, everything from plugins to ways to make the database run better.That way others can easily copy what we have done, but without exposing us to the risks of actually hosting them ourselves.

That being said, we´ve already been burned by synchronization issues… us updating something critical and the ¨piggybacking¨ department not doing it leading to crisis.

I´m still not sure which is the best solution…

Thanks,
Jim