Clarification on EduGlu

It’s awesome that people are talking about, and referencing, and critiquing EduGlu. Keep the conversations going! I do need to clarify a couple of things about it, though…

EduGlu is not mine. It wasn’t my idea. It isn’t my project. The concept is a logical/natural extension of lots of otherinterestingprojects in the area (and may be better implemented directly in any one of those, rather than building something new). This incarnation of the concept(s) grew out of a series of great discussions over a few days in Vancouver, by dozens of other folks (educators, geeks, researchers, academics, administrators…) and each discussion wound up converging toward this EduGlu idea, and away from the school-as-blog-host model.

It is currently just a thought exercise to frame discussions, and to help figure out what the requirements and issues are. The EduForge.org site for the project was set up explicitly to make it not “mine” but “ours” – anyone is free to contribute in any way they are willing and/or able. That includes toying around with the thought exercise.

EduGlu isn’t simply an aggregator. I think that’s part of what it has to do, but it’s the less interesting part. It’s really a way of thinking about the aggregation. Of running queries against the aggregated data to create custom, on-the-fly views of the data. It’s not simply about storing a bunch of RSS and providing an interface to view it. It’s about organizing that information in a meaningful way, in the context of an existing academic setting. Feeds will belong to individuals, who are associated with institutions, classes and cohorts (to start with, anarchy can reign later). Being able to set up “smart folders” or saved queries or whatnot will help individuals begin to make sense of all of this aggregated stuff.

In the initial stages of thinking about this, it’s important to not focus on implementation. I’m tempted to say “hey! I could do this in [insert platform here] pretty quickly!” – but then I begin by being constrained by the capabilities/limitations/metaphors of [insert platform here]. Once the concepts of this beast have been fleshed out by connecting a bunch of neurons, then it’s safe to start thinking about implementation.

Yeah, don’t want to derail the thinking here, like I said I think the LMOS concept is aiming at a bigger (and it seems to me messier) target, but I did think there was maybe some complimentary thinking going on that might be helpful to reflect on.