In Derek Morrison's Auricle article E-Learning: challenges to the neo conservative model? he states: “The biggest impediment I see to the vision is those vested interests who will apparently embrace the vision (of interoperable functional components) but somehow will still manage to operate a classic 'lock in' model.”
I've just been looking at a catalogue of VLE extensions (APIs) as provided by one of the commercial vendors, and I must say that I was very impressed with the additional functionality that was offered by some of these APIs … but I have a number of concerns about this approach. I'm sure that I'm not alone - anyone who has found the current genre of VLEs to be lacking, is also likely to salivate at the thought of a “powerful learning extension that enables instructors and students to create, share and comment on blogs within a course”, or “a dynamic blog and web site builder that permits students and instructors to create and showcase journals and web sites in a central location”. Functionality of our VLEs can be hugely improved through the use of these extensions, and what's even better (so we are told by the vendors) is that we can even create our own APIs.
It's rather stating the obvious I know, but commercial VLEs are long-term, and increasingly onerous, financial commitments, and since the majority of APIs only function at Enterprise Level, it can generally be assumed that anyone considering making use of this kind of extension has already paid a significant amount of money to their vendor. Furthermore, since most commercial vendors licence their product annually, this is an ongoing expense - and yet we still haven't considered the hidden costs that no one told you about at the time 🙂
Put simply, if my institution is paying huge sums of money for a tool, I expect it to have the majority of the functionality that I require. What I don't expect is to have to pay (in one of the cases that I looked at), another $10,000 (annually) for additional functionality that should have been there in the first place.
Yes, I know - the diverse requirements of FE and HE make it impossible to design a VLE that will suit everyone (which is why we have suggested elsewhere that the monolithic VLE may have had it's day, and that the way forward is through individual tools, selected for their fitness for purpose, and brought together in some meaningful way).
True, API integration allows us to select functionality that will be of use in our own institutions, but if this is the only way to keep all of the people happy all of the time, wouldn't we do just as well to select our tools based on functionality and not on which ones happen to integrate with our VLE? Looking through my API catalogue, some of the solutions appear to provide the discrete sets of functionality that I require, but even so, I'm not sure that I want these hard-wired into a VLE - let's face it, if I select my toolset carefully I can essentially render my VLE redundant anyway. This surely has to be the more flexible way forward.
It seems odd that it is so readily accepted that third party vendors (and developers within the HE and tertiary sector) are designing add-ons that in some cases just 'plug' the holes in the functionality of another vendor's product. Some might argue that the open source world functions in this way, but the crucial difference is that users of open source software aren't presented with a multi-layered licensing structure.
I can certainly see the attraction for VLE vendors. It enhances the functionality of their products whilst also spreading the costs - don't forget though that this approach also has the added advantage (from the vendors perspective) of further locking you into their VLE.
As the title of this article suggests what is perhaps evolving here is a variant of the business model for the humble inkjet printer, i.e. you buy the inkjet from us at an apparently reasonable cost and then we can sell you the ink ad infinitum. Even better we can get some of you to make new inks for us:)
There are undoubtedly some Auricle readers who may wish to sweep such apparently endless debating of such inconvenient 'technicalities' to the side so that they can concentrate on the pedagogy and actual student experience … faciliated no doubt by their vendor's systems.
Firstly, if we didn’t 'debate the technicalities', we would ultimately find ourselves subject the whims of commercial vendors. Isn't about time that FE/HE sector took control of their future with regards to e-learning? With the vendors (or their shareholders) in the driving seat is this going to be possible?
I agree that we shouldn’t get too hung up on the tools, and that it is our choice of pedagogy and our approach to teaching and learning that matters most. Having said that, no VLE is pedagogically neutral - the majority of mainstream VLEs have an implicit pedagogy that suits the transmissive style of delivery. You can work around this to an extent, but at the end of the day you will always be competing with a system which takes a particular view of the world and how people learn. So perhaps it’s not surprising that we see so many people using this style of VLE as a repository – it was primarily designed to replicate the lecture model.
