Derek started it Miss
My response
Richard
Actually I share some of his fears. But I think his objections pertain to a centralized deployment of Moodle rather than a decentralized one. See the following for previous discussions of this topic:
http://moodle.org/mod/forum/discuss.php?d=6487
http://moodle.org/mod/forum/discuss.php?d=18878
http://moodle.org/mod/forum/discuss.php?d=6487
http://moodle.org/mod/forum/discuss.php?d=18878
Tried to post the below comment to http://www.bath.ac.uk/dacs/cdntl/pMachine/morriblog.php?id=0
But kept getting "your comment can not be posted at this time". Which, come to think of it, makes my point almost as well (maybe much better) than my comments
.
But kept getting "your comment can not be posted at this time". Which, come to think of it, makes my point almost as well (maybe much better) than my comments
.In my opinion are two big issues with using untested code in a proiduction VLE:
This results in a set of components that can both be tested and delivered closer to 'home' eg. by your local IT folks, with a great deal more freedom than you'll get from a commercial system (where the component mix will be chosen at a greater distance and in some--sometimes large--part for reasons other than instructional).
New pedagogical constructs can be implemented in Moodle by faculty and technical staff with a great deal more flexibility than with a commercial VLE while retaining a good deal more local control than with a commercial VLE. Overall, I think the open model of Moodle is the best compromise between the desire to innovate and the need for security and reliability.
However, Moodle is already starting to work with the JISC framework, see Gustav Delius' work with the remote question type in the Moodle quiz module, for instance. As these new tools become stable and reliable (or even before that
, they can be implemented in Moodle.
However, you'll need to increase your IT budget to pay for tech staff to install, configure, and support all these new, separate tools. Having a 'monolithic' system like Moodle with an active support and development community also means that local costs can be much lower (the other side of the cost equation) and more $$ can be released to support local faculty and students in using the VLE.
One of the problems with providing a great deal of tools--in Moodle, WebCT, Blackboard, etc. is that you then need to pay your faculty to learn to use those tools if you expect to get any return in the form of more effective teaching and learning. With Moodle, you'll have money left over to deliver the training and support to help more of your faculty and students use the tools provided, as well as much greater flexibility to implement new tools, constructs, etc.
- Would the students be very happy with having un-reliable code tested out on them?
- There is also a big issue of security, if a teacher uses un-secure code and student's personal data is compromised, the institution gets sued and/or splashed all over Slashdot, not the teacher.
This results in a set of components that can both be tested and delivered closer to 'home' eg. by your local IT folks, with a great deal more freedom than you'll get from a commercial system (where the component mix will be chosen at a greater distance and in some--sometimes large--part for reasons other than instructional).
New pedagogical constructs can be implemented in Moodle by faculty and technical staff with a great deal more flexibility than with a commercial VLE while retaining a good deal more local control than with a commercial VLE. Overall, I think the open model of Moodle is the best compromise between the desire to innovate and the need for security and reliability.
However, Moodle is already starting to work with the JISC framework, see Gustav Delius' work with the remote question type in the Moodle quiz module, for instance. As these new tools become stable and reliable (or even before that
However, you'll need to increase your IT budget to pay for tech staff to install, configure, and support all these new, separate tools. Having a 'monolithic' system like Moodle with an active support and development community also means that local costs can be much lower (the other side of the cost equation) and more $$ can be released to support local faculty and students in using the VLE.
One of the problems with providing a great deal of tools--in Moodle, WebCT, Blackboard, etc. is that you then need to pay your faculty to learn to use those tools if you expect to get any return in the form of more effective teaching and learning. With Moodle, you'll have money left over to deliver the training and support to help more of your faculty and students use the tools provided, as well as much greater flexibility to implement new tools, constructs, etc.
Damn -- tried to reply but his weblog thingy didn't let me. Here's my reply:
Derek,
There is a seed of truth in your concerns. With open source tools, however, some things _do_ change for the better.
Growing use of a particular tool increases the switching costs, and when in the digital realm your data is stored within the tool, switching costs are not just the retraining of the human beast, but migration of your data. That's part of the reason why network effects in IT are so strong.
So... switching from and to different content-storing tools is costly. Right. But it doesn't make it lock-in. Let me explain.
The maker of your tools has the means to facilitate things, or make them harder. It all depends on having the right incentives and intentions. You are probably familiar with the vendor lock-in that you fear. The tool internals are baroque and complicated, and don't interoperate with tools from other vendors.
Extracting your data is right next to impossible; it uses and embedded database that you can't open, or the database schema is complex with field names are in a mix of Polish and French (don't laugh, Atmail is a good example of one such product I had to deal with, the code full of nordic languages).
To make things worse, the vendor won't let you even look at the source code or the database. The license you agreed to has all sorts of clauses to stop you from extracting the data (or fixing bugs!) on your own, under the guise of "IP protection". WebCT does it. I'm sure BB must do it too. And then there's patents they may hold.
This is particularly jarring if you have a few skilled programmers/sysadmins/DBAs working with you. You just know that if you gave them the database, the code, and a week or so, they'd export everything you want and migrate it to the new app. Or if there's a bug or missing feature, they could put it there for you.
All these strategies add up, and increase switching costs by several magnitudes. That's why frustrated geeks started calling it "vendor lock-in", and the phrase caught up with management and with industry pundits.
Vendors of Free/Open Source Software (FOSS) have a different set of incentives and a different culture. With FOSS software, your data sits in databases and code that have a simple architecture by design. Sometimes documentation is spotty, but google bit and you'll soon find juicy discussions explaining the hows and the whys.
Why so? Because FOSS project are only successful if they are easy to pick up and start coding/fixing/extending. There's a natural, almost darwinian selection: FOSS projects with ugly or unreadable/unworkable code are hard for programmers to get into quickly, and so they slowly die.
Moodle is really easy to get started with. I sent my first patch to Martin Dougiamas while reviewing it. Found a security problem and in 15 minutes I had found where in the code the bug was, and what the fix was -- a few hours later MD wrote back saying "thanks, the fix is in Moodle now".
I performed the same review with two other FOSS LMSs. All had the same bug. With ATutor it took a bit longer to find and fix -- they weren't running their project openly enough at the time, just their core programmers on the payroll, and you could tell the code was a tad harder to follow. I hear they have since made much progress in opening their project up.
With Ilias3 I spent several hours hunting, and couldn't find where the problem was in the code. Sent an email to their programming team (again, all in-house programmers, no external parties). Never heard back from them on a serious bug.
As you can see, a FOSS license isn't all there is to open source, there are bazaars and cathedrals and many shades in between. Successful bazaars are the best insurance you can get against lock-in; and Moodle is one.
Now, looking at the NZVLE project you are discussing, as the lead programmer there are a few things I have intimate knowledge of. Might be a good chance to let you know.
We are explicitly engaging the tertiaries IT departments with an open approach. Very much unlike the LMS vendors they are familiar with, we work with them helping the implementation in a completely transparent manner. I work a lot in encouraging them to look at Moodle and get involved.
While I usually joke about giving them access to the precious source code, only when they realize I literally cannot hide anything from their view their approach changes. I guess they must have been burnt a million times with tricky vendors.
Our integration strategies with Student Management Systems usually involve feeding the data to a LDAP repostory, where all sorts of services (webmail, library proxies, etc) can use it. All with Perl/PHP/bash scripts which we publish and share.
Lock-in is an old feature of that other culture we are all walking collectively away from.
regards
martin
Derek,
There is a seed of truth in your concerns. With open source tools, however, some things _do_ change for the better.
Growing use of a particular tool increases the switching costs, and when in the digital realm your data is stored within the tool, switching costs are not just the retraining of the human beast, but migration of your data. That's part of the reason why network effects in IT are so strong.
So... switching from and to different content-storing tools is costly. Right. But it doesn't make it lock-in. Let me explain.
The maker of your tools has the means to facilitate things, or make them harder. It all depends on having the right incentives and intentions. You are probably familiar with the vendor lock-in that you fear. The tool internals are baroque and complicated, and don't interoperate with tools from other vendors.
Extracting your data is right next to impossible; it uses and embedded database that you can't open, or the database schema is complex with field names are in a mix of Polish and French (don't laugh, Atmail is a good example of one such product I had to deal with, the code full of nordic languages).
To make things worse, the vendor won't let you even look at the source code or the database. The license you agreed to has all sorts of clauses to stop you from extracting the data (or fixing bugs!) on your own, under the guise of "IP protection". WebCT does it. I'm sure BB must do it too. And then there's patents they may hold.
This is particularly jarring if you have a few skilled programmers/sysadmins/DBAs working with you. You just know that if you gave them the database, the code, and a week or so, they'd export everything you want and migrate it to the new app. Or if there's a bug or missing feature, they could put it there for you.
All these strategies add up, and increase switching costs by several magnitudes. That's why frustrated geeks started calling it "vendor lock-in", and the phrase caught up with management and with industry pundits.
Vendors of Free/Open Source Software (FOSS) have a different set of incentives and a different culture. With FOSS software, your data sits in databases and code that have a simple architecture by design. Sometimes documentation is spotty, but google bit and you'll soon find juicy discussions explaining the hows and the whys.
Why so? Because FOSS project are only successful if they are easy to pick up and start coding/fixing/extending. There's a natural, almost darwinian selection: FOSS projects with ugly or unreadable/unworkable code are hard for programmers to get into quickly, and so they slowly die.
Moodle is really easy to get started with. I sent my first patch to Martin Dougiamas while reviewing it. Found a security problem and in 15 minutes I had found where in the code the bug was, and what the fix was -- a few hours later MD wrote back saying "thanks, the fix is in Moodle now".
I performed the same review with two other FOSS LMSs. All had the same bug. With ATutor it took a bit longer to find and fix -- they weren't running their project openly enough at the time, just their core programmers on the payroll, and you could tell the code was a tad harder to follow. I hear they have since made much progress in opening their project up.
With Ilias3 I spent several hours hunting, and couldn't find where the problem was in the code. Sent an email to their programming team (again, all in-house programmers, no external parties). Never heard back from them on a serious bug.
As you can see, a FOSS license isn't all there is to open source, there are bazaars and cathedrals and many shades in between. Successful bazaars are the best insurance you can get against lock-in; and Moodle is one.
Now, looking at the NZVLE project you are discussing, as the lead programmer there are a few things I have intimate knowledge of. Might be a good chance to let you know.
We are explicitly engaging the tertiaries IT departments with an open approach. Very much unlike the LMS vendors they are familiar with, we work with them helping the implementation in a completely transparent manner. I work a lot in encouraging them to look at Moodle and get involved.
While I usually joke about giving them access to the precious source code, only when they realize I literally cannot hide anything from their view their approach changes. I guess they must have been burnt a million times with tricky vendors.
Our integration strategies with Student Management Systems usually involve feeding the data to a LDAP repostory, where all sorts of services (webmail, library proxies, etc) can use it. All with Perl/PHP/bash scripts which we publish and share.
Lock-in is an old feature of that other culture we are all walking collectively away from.
regards
martin
The maker of your tools has the means to facilitate things, or make them harder. It all depends on having the right incentives and intentions. You are probably familiar with the vendor lock-in that you fear.
There's a nice economic analysis of vendor lock-in by Bryan Cantrill of Sun Microsystems.
Joel Spolky's Camels and Rubber Duckies is also a readable romp through the economics of software pricing. It starts off desktop app focused but it gets onto institutional purchases of Moodle type software later on e.g.:
The joke of it is, big companies protect themselves so well against the risk of buying something expensive that they actually drive up the cost of the expensive stuff, from $1000 to $75000, which mostly goes towards the cost of jumping all the hurdles that they set up to insure that no purchase can possibly go wrong.
and the potential pitfalls of selling Free Software:
There are just too many examples where you actually do get what you pay for, and the uninformed consumer is generally going to infer that the more expensive product is better. Buying a coffee maker? Want a really good coffee maker? You have two choices. Find the right issue of Consumer Reports in the library, or go to Williams-Sonoma and get the most expensive coffee maker they have there.
While I enjoy Joel Spolky's articles a lot, the point he makes about 'getting what you pay for' is of limited use. As long as FOSS is marketed as 'free', some people do react as he describes. However, the true nature of the FOSS economy is starting to make itself evident, and it is slowly starting to percolate. Anyone who has been awake and paying attention in the last 5 years knows that that isn't how FOSS works, even if they can't explain it fully.
It is not all about free beer -- not even about free speech. You are given the (golden) opportunity to join a community of practice as a first class citizen -- with proprietary solutions, the best you could hope for is 3rd class, after the original developer and the VARs. And I know from experience that it isn't fun being that 3rd class citizen. Hell, I've worked with VARs a lot, and it wasn't a nice place to be in either.
Using FOSS involves some efforts and costs. They are all optional -- in fact, you can be totally cheap and still get the goods. The incentive is that the more you invest, the more you get. The investment isn't necesarily about money going to a vendor (though it can be -- see for instance http://moodle.com and http://catalyst.net.nz/products-moodle.htm ) but getting involved with the tools and the community of practice. So it is an investment you had to make anyway to make good use of the tools.
The natural dynamics of FOSS, in the spaces where it works, are significantly more efficient than other models. Yochai Benkler (http://benkler.org/) is one of the leading lights in understanding the economies (and sociologies) of sharing. Definitely recommended.
(Edit: the Sun blog -- excellent explanation of why per-seat software licenses are huge scam, or at least a large economic distortion -- something everyone in the industry knows.)
It is not all about free beer -- not even about free speech. You are given the (golden) opportunity to join a community of practice as a first class citizen -- with proprietary solutions, the best you could hope for is 3rd class, after the original developer and the VARs. And I know from experience that it isn't fun being that 3rd class citizen. Hell, I've worked with VARs a lot, and it wasn't a nice place to be in either.
Using FOSS involves some efforts and costs. They are all optional -- in fact, you can be totally cheap and still get the goods. The incentive is that the more you invest, the more you get. The investment isn't necesarily about money going to a vendor (though it can be -- see for instance http://moodle.com and http://catalyst.net.nz/products-moodle.htm ) but getting involved with the tools and the community of practice. So it is an investment you had to make anyway to make good use of the tools.
The natural dynamics of FOSS, in the spaces where it works, are significantly more efficient than other models. Yochai Benkler (http://benkler.org/) is one of the leading lights in understanding the economies (and sociologies) of sharing. Definitely recommended.
(Edit: the Sun blog -- excellent explanation of why per-seat software licenses are huge scam, or at least a large economic distortion -- something everyone in the industry knows.)