The major arguments against a Moodle implementation seem to be as follows:
1) no guarantee that the installation can be fixed if something goes wrong
2) requires reliance on a commmunity of users that may or may not be willing or able to help
3) you can elect to contract with a third party Moodle partner to offer technical support, but there's no guarantee that this third party will stay in business or be able to offer satisfactory performance
As a result, institutions lean towards playing it safe, i.e., with a closed source solution like Bb, etc.
So, how does one counter this argument? The ideal argument, IMO, would be as follows:
1) Moodle's architecture and source code are much easier to fix and plumb than other LMS's.
2) As a result, there is a greater likelihood that institutions could acquire the ability to fix Moodle problems themselves and, therefore, not have to rely on the user community or a third party for help when things go badly wrong.
How feasible do you think this argument is?
Peter,
Point 3 is pretty shaky -- check out Blackboard's balance sheet. And on the best of cases, you are locked-in to buying expensive services off a monopolic provider. Ask for references from BB customers about response times, service level, etc.
On the other side ofthe fence, there is a long list of Moodle Partners, it is a healthy, competitive market, with a market presence growing (0% to 56% in UK in 3 years) and many of them with customers willing to give references.
Please _search_ this forums. There is a _lot_ of material on this...
Point 3 is pretty shaky -- check out Blackboard's balance sheet. And on the best of cases, you are locked-in to buying expensive services off a monopolic provider. Ask for references from BB customers about response times, service level, etc.
On the other side ofthe fence, there is a long list of Moodle Partners, it is a healthy, competitive market, with a market presence growing (0% to 56% in UK in 3 years) and many of them with customers willing to give references.
Please _search_ this forums. There is a _lot_ of material on this...
Hi Peter,
Agreeing with Martin's comments...
What guarantee is there a that any business will be around in x years? If a proprietary provider withdraws for whatever reason you may be be without support options completely or locked into another monopoly. With Moodle / OS there are many more options.
On point 2: Yes indeed! Hence Moodle Partners.
On point 1 (and the satisfactory performance part of point 3): Anyone who believes that closed source solution support is always timely and effective (or that you will actually receive it once you've paid for it) is living in an alternative universe*. Lack of support by closed source solution providers was a recurring theme raised by visitors to our stand at ALT-C 2006 this week. It would be unprofessional of me to expand upon this here... perhaps clients of closed source solutions could add some real life examples to help you make your case.
* That universe is still quite densely populated.
Agreeing with Martin's comments...
What guarantee is there a that any business will be around in x years? If a proprietary provider withdraws for whatever reason you may be be without support options completely or locked into another monopoly. With Moodle / OS there are many more options.
On point 2: Yes indeed! Hence Moodle Partners.
On point 1 (and the satisfactory performance part of point 3): Anyone who believes that closed source solution support is always timely and effective (or that you will actually receive it once you've paid for it) is living in an alternative universe*. Lack of support by closed source solution providers was a recurring theme raised by visitors to our stand at ALT-C 2006 this week. It would be unprofessional of me to expand upon this here... perhaps clients of closed source solutions could add some real life examples to help you make your case.
* That universe is still quite densely populated.
Hi, Martin. What do you suggest searching under to find the other threads on this topic?
Go to advanced search, scope it to this forum, and search for 'blackboard' 
There is also a great thread where people were discussing Humbold Uni's survey after running Moodle and BB in parallel. Michael, what is a good keyword for that one?
There is also a great thread where people were discussing Humbold Uni's survey after running Moodle and BB in parallel. Michael, what is a good keyword for that one?
"van duzer" (Joan was one of the principle authors).
These arguments work against BB, also:
The major arguments against a Blackboard implementation seem to be as follows:
1) no guarantee that the installation can be fixed if something goes wrong
(see Prarie State University, also see the CSU Chico final report (page 4), which now that Vista has become a Blackboard product, quite interesting.
2) requires reliance on a commmunity of users that may or may not be willing or able to help
The best support for commercial products is often from user-to-user forums and listservs (for instance the ASU Blackboard-L listserv
3) you can elect to contract with a third party Moodle partner to offer technical support, but there's no guarantee that this third party will stay in business or be able to offer satisfactory performance
Seen above. The best guarantee for any LMS is experienced local staff, you will need programmer/analysts and DBAs to run a commercial system reliably at any scale over a few thousand users, and perhaps by looking at the history of CourseInfo, Prometheus, and WebCT, it may be clear that commercial products may be purchased and merged or canceled at any time. There are much bigger fish in eLearning and the <big profits> are not in the sales of software licenses--for instance what if BB wins the suit and then is bought by the Apollo group?
The major arguments against a Blackboard implementation seem to be as follows:
1) no guarantee that the installation can be fixed if something goes wrong
(see Prarie State University, also see the CSU Chico final report (page 4), which now that Vista has become a Blackboard product, quite interesting.
2) requires reliance on a commmunity of users that may or may not be willing or able to help
The best support for commercial products is often from user-to-user forums and listservs (for instance the ASU Blackboard-L listserv
3) you can elect to contract with a third party Moodle partner to offer technical support, but there's no guarantee that this third party will stay in business or be able to offer satisfactory performance
Seen above
I agree with most of what has been said, esp. the shakiness of closed-source support. We use Bb at our institution, and I have a plethora of horror stories. Believe me.
I also agree with you, Michael P., that the best support often comes from the various user lists that grow up around closed source solutions like Bb. It never ceases to amaze me as I look at the 200 or so messages that come in every day on the various Bb lists that I'm on that Bb users are all paying Bb for support they don't get. In other words, if the suppport were of a high enough caliber from the closed source provider, then surely the user lists would be unnecessary. The closed source provider would provide detailed, timely support to the users that would make the lists unnecessary. However, this is obviously not the case.
With Moodle, users are already doing what Bb users -- and presumably other closed source users -- are doing, i.e., using lists and forums to discuss ideas and solve problems. Of course, the only difference is that Moodle users pay nothing for this service and support. Bb, et al, pay major bucks for this service.
But here's where I disagree with some of what's been said in this thread. Yes, Bb is certainly vulnerable to going under, as any business is. But the extent to which they now enjoy a monopoly makes this less and less likely. In fact, if you were going to base your decision about which LMS/VLE to adopt solely on the question of who is going to be around in 5 years, I'd say that Bb is probably the most likely to be around.
Let me put this issue another way. Say you're a CIO at State U. You are charged with picking a LMS/VLE for your institution. You hear about Moodle. Sounds good. Free. Robust user community. But what happens when something goes wrong? With a closed source provider like Bb, you can apply leverage via the contract you signed and the money you are giving them via the license. In short, you have something to bargain with because you can withhold payment or you can stop doing business with them, i.e., there's a reason for them to want to help you. In the open source world, what reason is there for someone to help you other than their being nice?
It's this kind of logic that -- IMO -- escapes most CIO's. No offense to them, but it really is a paradigm shift. Think of the CIO's response: "So we're going to bet the future stability and integrity of our enterprise LMS/VLE on the good graces of a bunch of strangers? How do we hold these strangers accountable? And what if they're wrong? Or what if none of them can help us fix our problem?"
To counter this, you can offer the services of a Moodle partner. But how long have the Moodle partners been in business? And what is the likelihood of their staying in business longer than Bb will stay in business? From the CIO's perspective, it's a crapshoot. But it's a bigger crapshoot to bet on the Moodle partner staying in business longer than Bb. So, in the end, the CIO bets on Bb. Not because the product is better, not because the service is better, and certainly not to save money. No, the CIO bets on Bb because it will be around longer.
To counter this line of thinking, I think it might be possible to suggest that Moodle can be run and supported in-house by existing staff. Of course, these staff would need to be trained and supported in PHP and other enabling technologies that make Moodle run. But, in the end, you could argue that State U. could do without the help of the Moodle user community and a Moodle partner and be just fine when problems occurred.
But then the CIO would wonder about the costs of maintaining and supporting such a staff of people. In essence, at least one person on staff would have to be a bona fide Moodle expert -- a top gun PHP programmer at the very least. But what happens if this person chooses to leave State U.? And can I affford to pay this person?
Perhaps this is the lesson: to implement Moodle successfully, you have to have a top PHP person that you must assume can leave at any minute and that your implementation of Moodle will have to survive the down-times when you are looking for a replacement. The question is -- can the institution survive the down-times? The way around this would be to have 2 Moodle/PHP experts on staff at all times. But how many institutions can afford 2 Moodle/PHP experts?
I also agree with you, Michael P., that the best support often comes from the various user lists that grow up around closed source solutions like Bb. It never ceases to amaze me as I look at the 200 or so messages that come in every day on the various Bb lists that I'm on that Bb users are all paying Bb for support they don't get. In other words, if the suppport were of a high enough caliber from the closed source provider, then surely the user lists would be unnecessary. The closed source provider would provide detailed, timely support to the users that would make the lists unnecessary. However, this is obviously not the case.
With Moodle, users are already doing what Bb users -- and presumably other closed source users -- are doing, i.e., using lists and forums to discuss ideas and solve problems. Of course, the only difference is that Moodle users pay nothing for this service and support. Bb, et al, pay major bucks for this service.
But here's where I disagree with some of what's been said in this thread. Yes, Bb is certainly vulnerable to going under, as any business is. But the extent to which they now enjoy a monopoly makes this less and less likely. In fact, if you were going to base your decision about which LMS/VLE to adopt solely on the question of who is going to be around in 5 years, I'd say that Bb is probably the most likely to be around.
Let me put this issue another way. Say you're a CIO at State U. You are charged with picking a LMS/VLE for your institution. You hear about Moodle. Sounds good. Free. Robust user community. But what happens when something goes wrong? With a closed source provider like Bb, you can apply leverage via the contract you signed and the money you are giving them via the license. In short, you have something to bargain with because you can withhold payment or you can stop doing business with them, i.e., there's a reason for them to want to help you. In the open source world, what reason is there for someone to help you other than their being nice?
It's this kind of logic that -- IMO -- escapes most CIO's. No offense to them, but it really is a paradigm shift. Think of the CIO's response: "So we're going to bet the future stability and integrity of our enterprise LMS/VLE on the good graces of a bunch of strangers? How do we hold these strangers accountable? And what if they're wrong? Or what if none of them can help us fix our problem?"
To counter this, you can offer the services of a Moodle partner. But how long have the Moodle partners been in business? And what is the likelihood of their staying in business longer than Bb will stay in business? From the CIO's perspective, it's a crapshoot. But it's a bigger crapshoot to bet on the Moodle partner staying in business longer than Bb. So, in the end, the CIO bets on Bb. Not because the product is better, not because the service is better, and certainly not to save money. No, the CIO bets on Bb because it will be around longer.
To counter this line of thinking, I think it might be possible to suggest that Moodle can be run and supported in-house by existing staff. Of course, these staff would need to be trained and supported in PHP and other enabling technologies that make Moodle run. But, in the end, you could argue that State U. could do without the help of the Moodle user community and a Moodle partner and be just fine when problems occurred.
But then the CIO would wonder about the costs of maintaining and supporting such a staff of people. In essence, at least one person on staff would have to be a bona fide Moodle expert -- a top gun PHP programmer at the very least. But what happens if this person chooses to leave State U.? And can I affford to pay this person?
Perhaps this is the lesson: to implement Moodle successfully, you have to have a top PHP person that you must assume can leave at any minute and that your implementation of Moodle will have to survive the down-times when you are looking for a replacement. The question is -- can the institution survive the down-times? The way around this would be to have 2 Moodle/PHP experts on staff at all times. But how many institutions can afford 2 Moodle/PHP experts?
Peter,
Yes, Bb is certainly vulnerable to going under, as any business is.
I don't think you actually looked at BB financials
Also... read this forum a bit -- have you seen BBWorld'06 included a few sessions on using Moodle? In comparison, this year, almost all MoodleMoots feature a talk or two from tertiaries that have migrated from BB to Moodle.
But how long have the Moodle partners been in business? ... From the CIO's perspective, it's a crapshoot
I call FUD on that. There is at least one Moodle Partner that runs a big chunk of the infrastructure for national elections, a whole TLD (.NZ domains), a major Telecom, and several e-govt projects.
Now, clearly you haven't really read the list of Moodle Partners. Go do that. Now! Find which moodle partner I am talking about. Look at the list of clients for that Partner.
(Or read my profile, but that's cheating. Do read check the partners list.)
So we're going to bet the future stability and integrity of our enterprise LMS/VLE on the good graces of a bunch of strangers? How do we hold these strangers accountable? And what if they're wrong? Or what if none of them can help us fix our problem?"
Business is always about trusting a bunch of strangers to do something you need. You sign an SLA and you pay them for the Service Level you've Agreed. Before agreeing to too much, you contact their current/former clients to ask about the quality of their service. Business as usual...
In that sense, a fair strategy is to acknowledge that as an LMS user you care for the functioning software and the service. Evaluate that: ask BB and Moodle users about initial setup (time, cost, complexity), about the perceived reliability, and about the service that they contracted along (cost vs quality). Ideally, talk with Moodle institutions that are contracting a Moodle Partner for services if you are considering retaining a Moodle Partner as a risk-avoidance strategy.
This is a normal procurement process. Be fair, drop prejudices and counter FUD with good info
Bb because it will be around longer.
FUD. It is in the hands of a sole company. As Michael Penney indicates, it can be bought and EndOfLife'd in a matter of a year or two. It happened to WebCT not long ago.
With Moodle however, there is a successful ecosystem with many commercial companies, independent programmers and tertiary institutions doing core development. It takes a lot of people with many disparate interests to change their long-terms commitment to Moodle and do something else. If it ever happens (not that I can see it happening), it will mean that the "something else" works for everyone else, and has a reasonable "upgrade/sidegrade" path from moodle...and therefore is likely to work out for your uni too
No-one can buy out Moodle. As long as there is interest, it will continue to be developed. Ask WebCT users about the certainties of the commercial world.
Ask WebCT users about the certainties of the commercial world.
Yes indeed. My campus spent tons-o-cash to migrate the entire university to WebCT Vista (except for those of us who decided to strike out on our own, install Moodle or some other alternative system, and handle our own servers and support). No one really knows what's going to happen to that investment.
Will Bb create a WebCT->Bb migration tool? If so, will it work? Will they continue developing both systems in parallel (this seems very unlikely to me)?
What happens to all the courseware that's locked up in the proprietary WebCT format? I don't think anyone knows the answer to these questions right now, possibly not even Bb itself.
If Martin D. suddenly decided to close down moodle.org and go surfing for the rest of his life, my department would still have all of its data intact. We could, if necessary, write our own tools to export our data to some other format. Most likely we wouldn't even have to go that far, since Moodle has such a large and vibrant community of developers. It's a near-certainty that someone else would write the tools we'd need, or that we could collaborate in creating those tools. But if we HAD to go it alone, we could. We WOULD be able to access our course and research data. No matter what.
I've mentioned this several times in the past, but it bears repeating: a major factor in my program adopting Moodle was the absence of vendor lock-in (the other major factor was that it's far, far easier to use for both instructors and students).
Economics didn't really enter into it at all. We have a nice shiny WebCT Vista system on campus which we can use for "free" (i.e., it doesn't come out of our budget), but we just don't trust proprietary systems for long-term data retention.
We used to use another system for our discussion forums (not WebCT or Bb). When our university decided to stop licensing that system, our data went away (we did get a raw HTML dump of the whole system, which no one has ever had the time to parse and get back into a usable format). Once bitten, twice shy.
Yes indeed. My campus spent tons-o-cash to migrate the entire university to WebCT Vista (except for those of us who decided to strike out on our own, install Moodle or some other alternative system, and handle our own servers and support). No one really knows what's going to happen to that investment.
Will Bb create a WebCT->Bb migration tool? If so, will it work? Will they continue developing both systems in parallel (this seems very unlikely to me)?
What happens to all the courseware that's locked up in the proprietary WebCT format? I don't think anyone knows the answer to these questions right now, possibly not even Bb itself.
If Martin D. suddenly decided to close down moodle.org and go surfing for the rest of his life, my department would still have all of its data intact. We could, if necessary, write our own tools to export our data to some other format. Most likely we wouldn't even have to go that far, since Moodle has such a large and vibrant community of developers. It's a near-certainty that someone else would write the tools we'd need, or that we could collaborate in creating those tools. But if we HAD to go it alone, we could. We WOULD be able to access our course and research data. No matter what.
I've mentioned this several times in the past, but it bears repeating: a major factor in my program adopting Moodle was the absence of vendor lock-in (the other major factor was that it's far, far easier to use for both instructors and students).
Economics didn't really enter into it at all. We have a nice shiny WebCT Vista system on campus which we can use for "free" (i.e., it doesn't come out of our budget), but we just don't trust proprietary systems for long-term data retention.
We used to use another system for our discussion forums (not WebCT or Bb). When our university decided to stop licensing that system, our data went away (we did get a raw HTML dump of the whole system, which no one has ever had the time to parse and get back into a usable format). Once bitten, twice shy.
I have to agree with this! Even though we hosted BB (5.5 basic) on our own servers (against some degree of pressure from the company--they do sell hosting and the sales reps certainly recommend the package deal), we had no access to the database. I did go though and manually archive and export a copy of every course on the system prior to taking it off line, but we really had no way to capture much of the data. Even the stats had to be exported manually (I did this for a research project; it took a number of hours and we had a fairly small system).
The archives did include all course documents that were uploaded, but we lost all quiz pools (my fault, because I did not take the time to export each pool in each course separately
) and all discussion board information. That wasn't a huge problem as most of our instructors used the system primarily as a repository of documents.
Until all systems can export courses or segments of courses in some kind of portable format, you are working within the limitations of the system. They are all, I think, still proprietary to some degree although many folks are looking for solutions to that particular problem!
I feel much better about using Moodle. I can customize it myself, or hire something done, and I have complete access to the data and the database. Nobody is going to tell me that they are end-of-lifing my version, and forcing me to buy a new server that can host the new software (that really happened, as BB5.5 was no longer supported as of Sept. 2005). That, plus the steep cost increases were big factors in choosing Moodle on our campus.
atw
The archives did include all course documents that were uploaded, but we lost all quiz pools (my fault, because I did not take the time to export each pool in each course separately
) and all discussion board information. That wasn't a huge problem as most of our instructors used the system primarily as a repository of documents. Until all systems can export courses or segments of courses in some kind of portable format, you are working within the limitations of the system. They are all, I think, still proprietary to some degree although many folks are looking for solutions to that particular problem!
I feel much better about using Moodle. I can customize it myself, or hire something done, and I have complete access to the data and the database. Nobody is going to tell me that they are end-of-lifing my version, and forcing me to buy a new server that can host the new software (that really happened, as BB5.5 was no longer supported as of Sept. 2005). That, plus the steep cost increases were big factors in choosing Moodle on our campus.
atw
I did go though and manually archive and export a copy of every course on the system prior to taking it off line, but we really had no way to capture much of the data.
Yep. I wonder what the campus library would say if you suggested a model in which all the books would be burned if the university failed to pay an annual fee, or even if the vendor went out of business?
Of course, electronic texts with DRM are making headway, so I guess not everyone cares about that issue
Yep. I wonder what the campus library would say if you suggested a model in which all the books would be burned if the university failed to pay an annual fee, or even if the vendor went out of business?
Of course, electronic texts with DRM are making headway, so I guess not everyone cares about that issue
These are great points, Tony. Even migrating courses from one BB version to another has been problematic (and still is, see the ASU Blackboard-L list), it is hard to imagine a transistion from the CE and Vista codebases is going to be easy.
Great points on lock-in as well, especially importing IMO for fully online programs. I call it the 'rent vs. own' decision, when institutions build a new building or campus, they generally own the buildings, and they are generally 'open source', eg. you can modify, expand, paint, etc. the buildings without having to ask the landlord or original architect and contractor's permission.
Commerical systems are generally more like renting buildings from a landlord, you have to pay an ongoing fee or you get kicked out and you have to ask permission to modify the buildings for your instructional needs.
For most campuses renting buildings is seen as a temporary, emergency measure, while with the LMS (which may have more traffic than any other 'classroom' on campus), renting has somehow become SOP.
Great points on lock-in as well, especially importing IMO for fully online programs. I call it the 'rent vs. own' decision, when institutions build a new building or campus, they generally own the buildings, and they are generally 'open source', eg. you can modify, expand, paint, etc. the buildings without having to ask the landlord or original architect and contractor's permission.
Commerical systems are generally more like renting buildings from a landlord, you have to pay an ongoing fee or you get kicked out and you have to ask permission to modify the buildings for your instructional needs.
For most campuses renting buildings is seen as a temporary, emergency measure, while with the LMS (which may have more traffic than any other 'classroom' on campus), renting has somehow become SOP.
The same is/was true for WebCT. Upgrading from the older version to Vista was a major effort. It took months, as I recall (I wasn't directly involved). Nothing like the painless upgrades that we've seen with Moodle.
(yes, we sometimes see people in the Moodle forums who've have upgrade problems, but nothing like what appears to be the case with Bb and WebCT).
The lock-in issue is fundamental. Professors would never use paper notebooks or overhead slides that required an annual fee to keep the materials from becoming inaccessible, so why is it acceptable for on-line materials?
(yes, we sometimes see people in the Moodle forums who've have upgrade problems, but nothing like what appears to be the case with Bb and WebCT).
The lock-in issue is fundamental. Professors would never use paper notebooks or overhead slides that required an annual fee to keep the materials from becoming inaccessible, so why is it acceptable for on-line materials?
No-one can buy out Moodle. As long as there is interest, it will continue to be developed. Ask WebCT users about the certainties of the commercial world.
This is the key point. This represents a paradigmatic shift in how people think about software purchases, service, and support. People who support and embrace open source get this. Those that don't, don't. At least not yet. Perhaps they never will?
The irony here is that if folks choose to have their decision to support a VLE based solely on fear (of the future, of things that might go wrong and can't be fixed), then they will likely shy away from open source. But the decision to embrace or eschew the fear (as just one element of being in this field) opens them up to making a decision based on other things: quality of the product, quality of support, ability to shape the product and control their destiny, etc. In other words, if you take it as a given that the future is inherently unpredictable and that no VLE is guaranteed success, you'll be more free to adopt an open source solution. The advantage is that the more people who do this, the greater the likelihood of its success and its longevity.
Those that cave to FUD increase the likelihood of closed source. Those that see FUD for what it is increase the likelihood of open source succeeding.
This is the key point. This represents a paradigmatic shift in how people think about software purchases, service, and support. People who support and embrace open source get this. Those that don't, don't. At least not yet. Perhaps they never will?
The irony here is that if folks choose to have their decision to support a VLE based solely on fear (of the future, of things that might go wrong and can't be fixed), then they will likely shy away from open source. But the decision to embrace or eschew the fear (as just one element of being in this field) opens them up to making a decision based on other things: quality of the product, quality of support, ability to shape the product and control their destiny, etc. In other words, if you take it as a given that the future is inherently unpredictable and that no VLE is guaranteed success, you'll be more free to adopt an open source solution. The advantage is that the more people who do this, the greater the likelihood of its success and its longevity.
Those that cave to FUD increase the likelihood of closed source. Those that see FUD for what it is increase the likelihood of open source succeeding.
"how do we hold somebody accountable"
It really annoys me everytime I hear that. I haven't seen the BB license agreement, but if I was a betting man I would lay good odds that it says something like that they are in no way responsible for anything that goes wrong. A cursory glance at the Moodle lists shows that there are many people who care pasionately about solving other people's Moodle problems. No you can't hold them accountable, but you can't hold a closed-source company accountable either.
It really annoys me everytime I hear that. I haven't seen the BB license agreement, but if I was a betting man I would lay good odds that it says something like that they are in no way responsible for anything that goes wrong. A cursory glance at the Moodle lists shows that there are many people who care pasionately about solving other people's Moodle problems. No you can't hold them accountable, but you can't hold a closed-source company accountable either.
I haven't seen the BB license agreement, but if I was a betting man I would lay good odds that it says something like that they are in no way responsible for anything that goes wrong.
From what I can turn up in a quick Google, they have the usual disclaimers in their EULA. As you say, not responsible for anything.
I guess a good response to this would be to have someone read the Microsoft EULA, then ask how he/she can justify using MS products for mission-critical applications. You're sure not going to hold Microsoft accountable under the terms of that beauty, not even if your copy of Word malfunctions and kills someone.
From what I can turn up in a quick Google, they have the usual disclaimers in their EULA. As you say, not responsible for anything.
I guess a good response to this would be to have someone read the Microsoft EULA, then ask how he/she can justify using MS products for mission-critical applications. You're sure not going to hold Microsoft accountable under the terms of that beauty, not even if your copy of Word malfunctions and kills someone.
even if your copy of Word malfunctions and kills someone
Now, THAT'S a malfunction!
-- Art
Now, THAT'S a malfunction!
-- Art
May I recommend to you The Case of the Virtual Killer Robot by
Richard G. Epstein?
Okay, that was slightly off topic, but not that far off! An interesting read.
atw
Okay, that was slightly off topic, but not that far off! An interesting read.
atw
Hi, Howard. We use Bb at our campus and I'm very familiar with the SLA. It's very clear about what is done if Bb fails to meet the terms of the SLA. We also use the Bb ASP, and it's also very clear about what happens if things go awry. Data recovery is guaranteed under certain service level terms, i.e., spend more money and get guarateed data recovery within a guaranteed amount of time. If they do not meet the guarantee, Bb will credit your account a certain amount of money per hour that the site is not up and running. In this case, withholding dollars = holding them accountable.
That said, we have run into many cases where a tool does not work as advertised. We are simply told to wait untl a patch or future release is available. For example, we waited more than 2 years for a Mac-compatible WYSIWYG. SSL has never worked on our site. We can't query the production database, etc., etc.
That said, we have run into many cases where a tool does not work as advertised. We are simply told to wait untl a patch or future release is available. For example, we waited more than 2 years for a Mac-compatible WYSIWYG. SSL has never worked on our site. We can't query the production database, etc., etc.
Perhaps this is the lesson: to implement Moodle successfully, you have to have a top PHP person that you must assume can leave at any minute and that your implementation of Moodle will have to survive the down-times when you are looking for a replacement.
I missed this before. This is completely wrong. Of the 8 Moodle installations on this campus (that I know of), none of them have a dedicated "top PHP person" on staff, much less two.
I do a bit of PHP hacking on our Moodle servers from time to time (generally when someone wants to collect some kind of data; education research is what we do here), but that's a very, very small part of my duties. I spend a lot more time on instructional design (when I write code for fun, it's usually Ruby or Scheme these days, not PHP).
If I left tomorrow, the worst that would happen is that people wouldn't get custom features for a while. There wouldn't be any "down time" involved.
Addendum: if you're talking about a monolithic system for a large university, you should certainly have experienced Unix system administrators and DBAs on-board (just as you would with WebCT, Bb, or any other system of this scale), but even in that case I don't see PHP programmers as mission-critical. Nice to have so that you can do customizations, sure. Essential to keep the system from going down, no way.
I missed this before. This is completely wrong. Of the 8 Moodle installations on this campus (that I know of), none of them have a dedicated "top PHP person" on staff, much less two.
I do a bit of PHP hacking on our Moodle servers from time to time (generally when someone wants to collect some kind of data; education research is what we do here), but that's a very, very small part of my duties. I spend a lot more time on instructional design (when I write code for fun, it's usually Ruby or Scheme these days, not PHP).
If I left tomorrow, the worst that would happen is that people wouldn't get custom features for a while. There wouldn't be any "down time" involved.
Addendum: if you're talking about a monolithic system for a large university, you should certainly have experienced Unix system administrators and DBAs on-board (just as you would with WebCT, Bb, or any other system of this scale), but even in that case I don't see PHP programmers as mission-critical. Nice to have so that you can do customizations, sure. Essential to keep the system from going down, no way.
In short, you have
something to bargain with because you can withhold payment or you can
stop doing business with them, i.e., there's a reason for them to want
to help you.
I'd say you can't do this at all. Your BB license states that if you don't pay, you have to stop using the system. Try turning off your LMS for 1 week, and your CIO will most likely be out the next. Looking at the reasons CSU Chico chose Vista, do you think BB's support record is going to improve if CIO's feel they have no other choice?
Regarding the number of staff I mentioned, note that I did not say "PHP Experts". Anyone running a large scale LMS of any flavor, commercial or open source, should have some familiarity with computers, programming languages, and databases. You'll need that level of staff skill to debug problems, handle upgrades, and design appropriate server configurations for your user load if you are running your own servers. This has been studied, see John Norman's report on the Educause CIO list, or at: http://www.campus-technology.com/print.asp?ID=18779
"Last year, John Norman, director of the University of Cambridge Centre for Applied Research in Educational Technologies (UK), conducted an informal study of US institutions to determine how many full-time programmers were required in a standard higher ed IT department to complete day-to-day programming tasks. He found that each school needs at least two technical support people for every 20,000 users. According to the IMS study, however, out of approximately 4,000 leading institutions in the US, only the top 300 have the human resources necessary to implement software; the other 3,700 need help."
John surveyed institutions running Blackboard, Coursework, dotLRN, and Moodle, for this data, by the way.
If you are one of the other 3700, isn't it hard to justify spending 1-2 salaries on an annual license, when you need the same number of staff to run the commercial system reliably?
WRT to whether BB will be around in 5 years, well people said that Peoplesoft would never be purchased and phased out, also.
The fact that BB's only real market is the educational sector raises a final question for CIOs: good deals can be made with Oracle, Apple, and Microsoft since education is not their main market, they can afford to give great deals to the edu sector as part of marketing.
For BB, the same rules may not apply: they don't have any other market to make profits in to offset losses in Education. Perhaps only by locking up the market with patents and then charging much more than they are now, will they be able to make enough profit to satisfy their shareholders and creditors.
This seems a troubling course for US education, given that students are routinely graduating with very high debt loads, or avoid college alltogether due to the rising costs (my undegraduate work was at SUNY, for instance, where tuition and fees have more than tripled since then).
Finally, WRT to vendor lock-in, if you are not happy with the support from a commercial LMS vendor, you can only change the support by changing your entire LMS, which is very expensive to do. With an open source LMS that has commercial support, you can change support partners without changing your LMS. This gives you as a customer more bargaining power, which is often a good thing.
I'd say you can't do this at all. Your BB license states that if you don't pay, you have to stop using the system. Try turning off your LMS for 1 week, and your CIO will most likely be out the next. Looking at the reasons CSU Chico chose Vista, do you think BB's support record is going to improve if CIO's feel they have no other choice?
Regarding the number of staff I mentioned, note that I did not say "PHP Experts". Anyone running a large scale LMS of any flavor, commercial or open source, should have some familiarity with computers, programming languages, and databases. You'll need that level of staff skill to debug problems, handle upgrades, and design appropriate server configurations for your user load if you are running your own servers. This has been studied, see John Norman's report on the Educause CIO list, or at: http://www.campus-technology.com/print.asp?ID=18779
"Last year, John Norman, director of the University of Cambridge Centre for Applied Research in Educational Technologies (UK), conducted an informal study of US institutions to determine how many full-time programmers were required in a standard higher ed IT department to complete day-to-day programming tasks. He found that each school needs at least two technical support people for every 20,000 users. According to the IMS study, however, out of approximately 4,000 leading institutions in the US, only the top 300 have the human resources necessary to implement software; the other 3,700 need help."
John surveyed institutions running Blackboard, Coursework, dotLRN, and Moodle, for this data, by the way.
If you are one of the other 3700, isn't it hard to justify spending 1-2 salaries on an annual license, when you need the same number of staff to run the commercial system reliably?
WRT to whether BB will be around in 5 years, well people said that Peoplesoft would never be purchased and phased out, also
The fact that BB's only real market is the educational sector raises a final question for CIOs: good deals can be made with Oracle, Apple, and Microsoft since education is not their main market, they can afford to give great deals to the edu sector as part of marketing.
For BB, the same rules may not apply: they don't have any other market to make profits in to offset losses in Education. Perhaps only by locking up the market with patents and then charging much more than they are now, will they be able to make enough profit to satisfy their shareholders and creditors.
This seems a troubling course for US education, given that students are routinely graduating with very high debt loads, or avoid college alltogether due to the rising costs (my undegraduate work was at SUNY, for instance, where tuition and fees have more than tripled since then).
Finally, WRT to vendor lock-in, if you are not happy with the support from a commercial LMS vendor, you can only change the support by changing your entire LMS, which is very expensive to do. With an open source LMS that has commercial support, you can change support partners without changing your LMS. This gives you as a customer more bargaining power, which is often a good thing.
Michael P. said:
Regarding the number of staff I mentioned, note that I did not say "PHP Experts". Anyone running a large scale LMS of any flavor, commercial or open source, should have some familiarity with computers, programming languages, and databases. You'll need that level of staff skill to debug problems, handle upgrades, and design appropriate server configurations for your user load if you are running your own servers.
We are just staring to use Moodle, so help me understand this. Here's an example of what I'm confronting. Let's say we go with Moodle for the entire university. We upgrade to a new version, and suddenly something doesn't work as it should. Users complain. So I write to this forum and ask for help. I get a couple replies, but the problem still persists. A few days go by. The problem is still there. Since we have no experienced PHP programmers on staff, we have no way of digging into the code. We keep waiting for someone to write to the forum with a solution. But no one does.
In this situation, what would we do? What have others done? How likely is this scenario?
Regarding the number of staff I mentioned, note that I did not say "PHP Experts". Anyone running a large scale LMS of any flavor, commercial or open source, should have some familiarity with computers, programming languages, and databases. You'll need that level of staff skill to debug problems, handle upgrades, and design appropriate server configurations for your user load if you are running your own servers.
We are just staring to use Moodle, so help me understand this. Here's an example of what I'm confronting. Let's say we go with Moodle for the entire university. We upgrade to a new version, and suddenly something doesn't work as it should. Users complain. So I write to this forum and ask for help. I get a couple replies, but the problem still persists. A few days go by. The problem is still there. Since we have no experienced PHP programmers on staff, we have no way of digging into the code. We keep waiting for someone to write to the forum with a solution. But no one does.
In this situation, what would we do? What have others done? How likely is this scenario?
We upgrade to a new version, and suddenly something doesn't work as it should.
I guess I'd want to hear more specifics about what kind of "something" you have in mind. The color scheme is wrong? The server doesn't work at all? Resources are missing?
First off, you probably wouldn't put a new version into production without first installing it on a test server and restoring some old courses on it. Then you'd examine those restored courses to make sure everything is working as it should (for a campus-wide installation, you'd want to do extensive testing with a good sample of your courses).
If everything looked fine on your test server, you'd wait for a natural break (such as the break between semesters), make sure you had full backups (which you should be doing routinely anyway), and install the new version. Then you'd test the courses on the live hardware before you start using it with actual students (if this is over a semester break, the instructors who are setting up their courses for the new semester will likely notice any major issues long before the students start using the courses). If disaster struck, you'd just roll back to the previous version, restore your backups, and go back to working on your test server to find out what went wrong.
That's how we do it here. Those who run large installations may have more extensive advice.
I will say that we've never had to roll back to a previous version, but we're always prepared to do so before doing an upgrade.
I guess I'd want to hear more specifics about what kind of "something" you have in mind. The color scheme is wrong? The server doesn't work at all? Resources are missing?
First off, you probably wouldn't put a new version into production without first installing it on a test server and restoring some old courses on it. Then you'd examine those restored courses to make sure everything is working as it should (for a campus-wide installation, you'd want to do extensive testing with a good sample of your courses).
If everything looked fine on your test server, you'd wait for a natural break (such as the break between semesters), make sure you had full backups (which you should be doing routinely anyway), and install the new version. Then you'd test the courses on the live hardware before you start using it with actual students (if this is over a semester break, the instructors who are setting up their courses for the new semester will likely notice any major issues long before the students start using the courses). If disaster struck, you'd just roll back to the previous version, restore your backups, and go back to working on your test server to find out what went wrong.
That's how we do it here. Those who run large installations may have more extensive advice.
I will say that we've never had to roll back to a previous version, but we're always prepared to do so before doing an upgrade.
Big +1 on Tony's approach! Deserves to be on docs.moodle.org!
One tiny enhancement I'd propose. I would say
"First off, you probably wouldn't put a new version into production without first making a DB-level backup of your production database, and restoring it (+moodledata) on a test server (make sure the test server cannot send emails!). And then run the upgrade on the test server.
Then you'd examine and test the upgraded moodle..."
One tiny enhancement I'd propose. I would say
"First off, you probably wouldn't put a new version into production without first making a DB-level backup of your production database, and restoring it (+moodledata) on a test server (make sure the test server cannot send emails!). And then run the upgrade on the test server.
Then you'd examine and test the upgraded moodle..."
Agreed with Tony. But let's assume that you don't catch something on the test box and you go into production. What if there is a show-stopper on your production server?
Yes, you could roll back to a previous version. But I'm wondering what the Moodle community does in situations like this. More broadly, I'm wondering how an open source solution responds to situations like this.
Again, I'm trying to counter the oppostion (thus the title of this thread). The opposition will say, "But what happens to your Moodle installation if you hit a major bug or error on your production system? Who's going to help you?"
What do you say?
Yes, you could roll back to a previous version. But I'm wondering what the Moodle community does in situations like this. More broadly, I'm wondering how an open source solution responds to situations like this.
Again, I'm trying to counter the oppostion (thus the title of this thread). The opposition will say, "But what happens to your Moodle installation if you hit a major bug or error on your production system? Who's going to help you?"
What do you say?
Who's going to help you?
The people you are paying for the service of giving you support (either an ongoing contract or a per-incident issue. And/or your peers (via mailing lists / forums).
I'm wondering how an open source solution responds to situations like this.
Open Source doesn't change the fact that -- at its core -- the software industry is one of services. In fact, it brings the focus back to them.
So it is "how the software industry respond to situations like this".
If something goes wrong with BB (software) you can call BB (company)... as long as you are paying them for the service. They have 3 tiers: Basic, Gold and Platinum. Please go and check.
In fact, if you are really risk-averse, with Moodle you can contract several support companies. You can't do that with BB
(BTW, have you checked the moodle partners list? It is not too hard to follow the trail to some really powerful documents supporting the OS model.)
What do you say?
This thread is going in circles.
The people you are paying for the service of giving you support (either an ongoing contract or a per-incident issue. And/or your peers (via mailing lists / forums).
But what if you elect not to pay someone to provide this kind of service and support? You would then have only your peers to provide help. But what if your peers cannot provide the support you need?
This is crucial because it establishes the foundation on which an implementation would exist. I'm perfectly OK with saying, "A successful Moodle implementation relies on hiring a service provider to provide support in the event the production environment experiences failures or errors that the Moodle user community is unable to help with." But is this true?
Sorry if this seems like I'm going in circles. I merely want to establish the conditions for an ideal Moodle implementation. It seems to me that support is the key issue for Moodle and has the potential of being its Achilles' heel. Thus the need to counter this area with a sound argument, i.e., "Yes, support is an issue. But the support that the Moodle user community provides is similar to the kind of support that Bb users get from their peers via the various user lists. This support is timely and very thorough. However, to ensure that there are no support issues that might trip us up, we can contract with X Moodle partner to provide service and support on as-needed basis."
How does this sound to you?
But what if you elect not to pay someone to provide this kind of service and support? You would then have only your peers to provide help. But what if your peers cannot provide the support you need?
This is crucial because it establishes the foundation on which an implementation would exist. I'm perfectly OK with saying, "A successful Moodle implementation relies on hiring a service provider to provide support in the event the production environment experiences failures or errors that the Moodle user community is unable to help with." But is this true?
Sorry if this seems like I'm going in circles. I merely want to establish the conditions for an ideal Moodle implementation. It seems to me that support is the key issue for Moodle and has the potential of being its Achilles' heel. Thus the need to counter this area with a sound argument, i.e., "Yes, support is an issue. But the support that the Moodle user community provides is similar to the kind of support that Bb users get from their peers via the various user lists. This support is timely and very thorough. However, to ensure that there are no support issues that might trip us up, we can contract with X Moodle partner to provide service and support on as-needed basis."
How does this sound to you?
But what if you elect not to pay someone to provide this kind of service and support? You would then have only your peers to provide help. But what if your peers cannot provide the support you need?
Peter, I don't mean to be rude here, but this thread is starting to sound less like a request for information and more like a troll.
Support is no more an "Achilles heel" for Moodle than it is for any other software, commercial or otherwise. If you want 24/7 support, you pay for it. If you don't, you don't. That's no different for Blackboard, WebCT, Moodle, or any other course management system. The fact that Moodle is open source doesn't enter into the calculation in any meaningful way that I can see.
You have to decide what level of support you need and provide a budget to implement that level of support, either by hiring someone on-site, by contracting with an outside firm, or by deciding to rely on the Moodle forums. The person implementing the system needs to make a rational assessment of the risks involved, and take steps to minimize those risks that appear to be realistic. The point is that this has absolutely NOTHING to do with whether the software is commercial or free.
"A successful Moodle implementation relies on hiring a service provider to provide support in the event the production environment experiences failures or errors that the Moodle user community is unable to help with." But is this true?"
It will come as a great shock to the thousands of us who aren't doing anything of the sort that our Moodle installations aren't "successful".
Peter, I don't mean to be rude here, but this thread is starting to sound less like a request for information and more like a troll.
Support is no more an "Achilles heel" for Moodle than it is for any other software, commercial or otherwise. If you want 24/7 support, you pay for it. If you don't, you don't. That's no different for Blackboard, WebCT, Moodle, or any other course management system. The fact that Moodle is open source doesn't enter into the calculation in any meaningful way that I can see.
You have to decide what level of support you need and provide a budget to implement that level of support, either by hiring someone on-site, by contracting with an outside firm, or by deciding to rely on the Moodle forums. The person implementing the system needs to make a rational assessment of the risks involved, and take steps to minimize those risks that appear to be realistic. The point is that this has absolutely NOTHING to do with whether the software is commercial or free.
"A successful Moodle implementation relies on hiring a service provider to provide support in the event the production environment experiences failures or errors that the Moodle user community is unable to help with." But is this true?"
It will come as a great shock to the thousands of us who aren't doing anything of the sort that our Moodle installations aren't "successful".
Can't best Tony on this I keep 2 phrases:
The fact that Moodle is open source doesn't enter into the calculation in any meaningful way that I can see. If you want 24/7 support, you pay for it. If you don't, you don't.
The fact that Moodle is open source doesn't enter into the calculation in any meaningful way that I can see. If you want 24/7 support, you pay for it. If you don't, you don't.
I second that! Put it in the docs somewhere...!
In other words... Peter's statements carry the assumption: "Blackboard (the company) will give us support for free". Which is false -- they'd go out of business if they did.
Blackboard Inc will sell you a license and a service. Maybe in a bundle, maybe not. But you must recognise and separate the two things if you are going to do smart shopping.
Tony - I don't know what a troll is. Do you mean little men that live under bridges?
I want to run Moodle successfully at my institution. To do so, I have to convince the powers that be that this is possible. To convince them, I have to address the issues that stand in the way. Support is a major issue.
The point is that this has absolutely NOTHING to do with whether the software is commercial or free.
But this is precisely the point. If the software is not free, e.g., Bb, it comes with service and support as part of what you pay. It may not be very good support, but it's support nonetheless. If the software is free, e.g., Moodle, it does not come with service and support. As you say, you have to pay for that. But that means that the free software is not free software at all.
I'm looking for some help here. So I'm trying to understand how other places have addressed these issues. Sorry if I've pressed your buttons. I mean no offense. I simply want to make this work.
I want to run Moodle successfully at my institution. To do so, I have to convince the powers that be that this is possible. To convince them, I have to address the issues that stand in the way. Support is a major issue.
The point is that this has absolutely NOTHING to do with whether the software is commercial or free.
But this is precisely the point. If the software is not free, e.g., Bb, it comes with service and support as part of what you pay. It may not be very good support, but it's support nonetheless. If the software is free, e.g., Moodle, it does not come with service and support. As you say, you have to pay for that. But that means that the free software is not free software at all.
I'm looking for some help here. So I'm trying to understand how other places have addressed these issues. Sorry if I've pressed your buttons. I mean no offense. I simply want to make this work.
Peter - you say: "If the software is free, e.g., Moodle, it does not come with service
and support. As you say, you have to pay for that. But that means that
the free software is not free software at all."
No it doesn't. Remember that "free software" according to the Free Software Foundation doesn't mean "costs no money". "Free software" means "gives you the freedom to run, copy, distribute, study, change and improve the software". No-one is ever going to claim that you can run an enterprise-scale system for zero money. But this other meaning of "free" actually brings a variety of benefits to your institution.
The crucial cost advantage that Moodle gives you over commercial systems such as Blackboard (in this respect, at least) is that not only does the license cost zero, but you are also free to shop around for the support contract, which is not possible with Blackboard. Any economics student could tell you whether you (as the customer) get a better deal in a competitive market or in a monopoly market...
No it doesn't. Remember that "free software" according to the Free Software Foundation doesn't mean "costs no money". "Free software" means "gives you the freedom to run, copy, distribute, study, change and improve the software". No-one is ever going to claim that you can run an enterprise-scale system for zero money. But this other meaning of "free" actually brings a variety of benefits to your institution.
The crucial cost advantage that Moodle gives you over commercial systems such as Blackboard (in this respect, at least) is that not only does the license cost zero, but you are also free to shop around for the support contract, which is not possible with Blackboard. Any economics student could tell you whether you (as the customer) get a better deal in a competitive market or in a monopoly market...
Dan-Leaving aside the non-Moodle partners that might be able to provide support, can you really say that the Moodle partners are a competitive market themselves pricewise?
OK, that's a fair point. The market isn't completely "open" because the number of companies that can claim to be Moodle Partners is limited. So it's a skewed market - although still not a closed one (since anyone can set up a business supporting Moodle, they just can't use the trademark), and far from a monopoly.
Great point, Dan. This is very helpful. I will use this as the foundation of my pitch!
"If the software is free, e.g., Moodle, it does not come with service and support."
Not entirely true. If you don't engage the service of a consultant such as a Moodle partner you "only" get the support of these forums, i.e. a global audience that includes experts that may include the person who initiated the project in the first place (M Dougiamas).
Of course if you engage a consultant you will probably get some kind of service level agreement with a guaranteed response time. The Moodle forums are not a substitute for commercial level support for a mission critical system, but it's not true that you will not get any support if you don't engage a consultant.
These issues may seem self evident to those who have been around free/libre software for a while, but the concept of "you gets what you pay for" is embedded in most other areas of life so it is not surprising that it needs analysing int he context of free/libre software.
By the way the discussion over the implication of the two meanings of the word free has caused some people to use the words libre and gratis to emphasise differece between the zero financial cost meaning and the freedom to use as you wish meaning.
These issues may seem self evident to those who have been around free/libre software for a while, but the concept of "you gets what you pay for" is embedded in most other areas of life so it is not surprising that it needs analysing int he context of free/libre software.
Marcus - yes, this is it exactly. The people I work with have very little sense of what open source, free, libre, and gratis mean. As you can tell, I'm also trying to get my head around the concepts and their implications so I can address/speak to their mental frame. I think a lot of people in the Moodle community take these concepts for granted. But for relative new-comers like me -- and certainly for those unfamiliar with these concepts -- they are revolutionary, even counter-intuitive.
So the issue for Moode evangelists is to understand that most people uunfamiliar with these core notions -- open source, free, libre, and gratis -- are going to be a little freaked out.
I'd love to hear from folks who encountered this kind of situation and what they did to make people less freaked out.
Marcus - yes, this is it exactly. The people I work with have very little sense of what open source, free, libre, and gratis mean. As you can tell, I'm also trying to get my head around the concepts and their implications so I can address/speak to their mental frame. I think a lot of people in the Moodle community take these concepts for granted. But for relative new-comers like me -- and certainly for those unfamiliar with these concepts -- they are revolutionary, even counter-intuitive.
So the issue for Moode evangelists is to understand that most people uunfamiliar with these core notions -- open source, free, libre, and gratis -- are going to be a little freaked out.
I'd love to hear from folks who encountered this kind of situation and what they did to make people less freaked out.
First, I showed our people in brutal detail exactly what we were using the course management system for
(document repository was top application, percentage of courses taught
compared to percentage taught with CMS support was extremely small, and
courses taught with CMS that were actually visited by students at least
one time per week was vanishingly small). This information showed
that we were most emphatically not getting the cost/benefit we wanted
for the license fees. So then they were ready to look at some
possible alternative systems.
We talked about more types of costs. I have charts that show comparisons between the two systems for admin costs, equipment costs, and OS/Database costs. Then we have projections about how much it really costs in faculty time to convert courses from the first system to Moodle. We knew that faculty would have to absorb the conversion effort; we simply had no money to pay extra stipends and no staff to do it for them. So we admitted that up front and tried to quantify it.
Then we talked about the support issues and the Moodle business model. I explained about the partners and how they contribute to Moodle.com, about "giving back to the community" through the forums and CVS (which is often done on "company time", so someone else is, essentially, absorbing that cost as regular salary but the community reaps the benefits), and the option of hiring support per hour from a Moodle partner since full hosting was NOT considered to be a good solution for us. People thought that was sensible, and flexible enough to meet our needs.
Last, we talked about possibilities. I told them about all the features Moodle offered that we did not have with our proprietary system. There was room to grow and try new things! That was exciting.
What made this work, I think, was that I did a real pilot study for a whole semester. We had actual data and real people to give testimonials. When Moodle was shown to be statistically equal to the competition with paired-t tests in a large number of use categories, and I added on the cost/benefit information, it was much LESS difficult to make a decision. We weren't working with rhetoric. We were working with a more objective data set.
We do not have a php programmer helping to run Moodle, by the way. Although I am a member of the Computer Science Department, my ability with PHP code is negligible. I can edit according to instructions, but that is all. We haven't had any problems with the code! Any problem we have had has more to do with the operating system or interruptions in power (or the time the backup device got disconnected and we ran out of room on the volume!)
I don't think you ever mentioned what size instance you were looking at. I am sure that large institutions have a whole different battle than those of us who are smaller (we are at 1400 or so students, much smaller than you may be!)
Maybe none of this helps you; you seem to be more interested in the support and admin part. But it seemed to me that you couldn't make the case without looking at students and faculty also. We were willing to take a little risk to get more benefit. But maybe that had to do with the fact that we had little to start with!
atw
We talked about more types of costs. I have charts that show comparisons between the two systems for admin costs, equipment costs, and OS/Database costs. Then we have projections about how much it really costs in faculty time to convert courses from the first system to Moodle. We knew that faculty would have to absorb the conversion effort; we simply had no money to pay extra stipends and no staff to do it for them. So we admitted that up front and tried to quantify it.
Then we talked about the support issues and the Moodle business model. I explained about the partners and how they contribute to Moodle.com, about "giving back to the community" through the forums and CVS (which is often done on "company time", so someone else is, essentially, absorbing that cost as regular salary but the community reaps the benefits), and the option of hiring support per hour from a Moodle partner since full hosting was NOT considered to be a good solution for us. People thought that was sensible, and flexible enough to meet our needs.
Last, we talked about possibilities. I told them about all the features Moodle offered that we did not have with our proprietary system. There was room to grow and try new things! That was exciting.
What made this work, I think, was that I did a real pilot study for a whole semester. We had actual data and real people to give testimonials. When Moodle was shown to be statistically equal to the competition with paired-t tests in a large number of use categories, and I added on the cost/benefit information, it was much LESS difficult to make a decision. We weren't working with rhetoric. We were working with a more objective data set.
We do not have a php programmer helping to run Moodle, by the way. Although I am a member of the Computer Science Department, my ability with PHP code is negligible. I can edit according to instructions, but that is all. We haven't had any problems with the code! Any problem we have had has more to do with the operating system or interruptions in power (or the time the backup device got disconnected and we ran out of room on the volume!)
I don't think you ever mentioned what size instance you were looking at. I am sure that large institutions have a whole different battle than those of us who are smaller (we are at 1400 or so students, much smaller than you may be!)
Maybe none of this helps you; you seem to be more interested in the support and admin part. But it seemed to me that you couldn't make the case without looking at students and faculty also. We were willing to take a little risk to get more benefit. But maybe that had to do with the fact that we had little to start with!
atw
AT - this is gold! Thank you. Would you be willing to share some of the materials you used to make your case?
FWIW - I've been trying to get detailed usage stats out of Bb for more than 3 years. The tools allow you to track student usage pretty well, but there's no way to determine which instructors are using which tools for what purpose and with what degree of effectiveness. In other words, no way to measure what I call AROI - Academic Return On Investment. Your analysis of how the proprietary tool was actualy being used is a great idea, one that I have wanted to do for a while. I'm failry certain that the majority of our users are using our Bb system mostly to post announcements and make their sylllabi available. So this is what we're spending all this money on???
We are a much larger institution -- over 17,000 students and 1,200 instructors. Also about 1,200 staff who would use the system.
Have you contracted with an outside suppport person or partner? Have you come across any instances where you could not get the support you needed? If so, what did you do? My CIO will (obviously) want to know these kinds of details.
FWIW - I've been trying to get detailed usage stats out of Bb for more than 3 years. The tools allow you to track student usage pretty well, but there's no way to determine which instructors are using which tools for what purpose and with what degree of effectiveness. In other words, no way to measure what I call AROI - Academic Return On Investment. Your analysis of how the proprietary tool was actualy being used is a great idea, one that I have wanted to do for a while. I'm failry certain that the majority of our users are using our Bb system mostly to post announcements and make their sylllabi available. So this is what we're spending all this money on???
We are a much larger institution -- over 17,000 students and 1,200 instructors. Also about 1,200 staff who would use the system.
Have you contracted with an outside suppport person or partner? Have you come across any instances where you could not get the support you needed? If so, what did you do? My CIO will (obviously) want to know these kinds of details.
I went throught every course on the system that last semester
(baseline) and counted! It took hours. We only had 130
courses and if they didn't have students enrolled or show any use
(surprising how many of those there were), I didn't count them. I
think I wound up with 89 that I checked. You could do a random
sample if you have too many. Get someone to run a random number
list and pull the designated courses for your survey. I think you
will need an N of around 100 (get a stats person to tell you how many
constitute a good sample based on the number of courses you have on the
system. I can't remember the formula for that!) In the end,
your N will depend on how much time you
can spend checking. Have a list--you have to do the same thing
for each course, so you must define carefully what you are looking
for. I deliberately chose to check for things that I could
directly compare to moodle.
I have never had to contact an outside support person, although I contacted each Moodle Partner in the US for prices on per hour assistance. Not all of them work with Windows servers! So far, we have done very well. Never had ANY trouble with the Linux system; small trouble migrating from LAMP to WIMP. Since our faculty are STILL not using many of the collaborative tools yet, we might have avoided some pain. I have to be honest!
I would suggest that you do a pilot project that is robust enough to generate the data that you need. Can you do a college? Can you do a large department? Actually having the experience for a whole semester closely approximates a full scale implementation. We felt like we were arguing from a position of strength, not a position of conjecture.
I posted this back in April.
http://moodle.org/mod/forum/discuss.php?d=42276&parent=202057
atw
I have never had to contact an outside support person, although I contacted each Moodle Partner in the US for prices on per hour assistance. Not all of them work with Windows servers! So far, we have done very well. Never had ANY trouble with the Linux system; small trouble migrating from LAMP to WIMP. Since our faculty are STILL not using many of the collaborative tools yet, we might have avoided some pain. I have to be honest!
I would suggest that you do a pilot project that is robust enough to generate the data that you need. Can you do a college? Can you do a large department? Actually having the experience for a whole semester closely approximates a full scale implementation. We felt like we were arguing from a position of strength, not a position of conjecture.
I posted this back in April.
http://moodle.org/mod/forum/discuss.php?d=42276&parent=202057
atw
Great advice, AT. Thanks also for the link.
We are in Phase 2 of a Moodle pilot. Last semester, I ran Phase 1 with one course and one instructor. Went very well. Over the summer, I asked for volunteers to particpipate in Phase 2. We just began the semester and the Phase 2 pilot with 8 instructors. I will survey students and instructors after the semester and collect data, e.g., satisfaction, usability, comparison with Bb, etc.
I'lll be sure to share the results here.
We are in Phase 2 of a Moodle pilot. Last semester, I ran Phase 1 with one course and one instructor. Went very well. Over the summer, I asked for volunteers to particpipate in Phase 2. We just began the semester and the Phase 2 pilot with 8 instructors. I will survey students and instructors after the semester and collect data, e.g., satisfaction, usability, comparison with Bb, etc.
I'lll be sure to share the results here.
I will share my questionnaire if you want it. Just send me an
emailed message. Our pilot got quite a lot bigger than we had
expected. We hoped for 6 faculty members, and we got 18!
The second semester, we had even more. It helps to be able to
survey more students. I had randomly selected 325 and got back
177 surveys. Of those, 76 used both BB and Moodle, so those were
the ones I used for the statistical analysis.
atw
atw
Hate to disagree with my own colleague but we did have a php programmer available for our pilot (there isn't one for the new installation.).
But most of what I did was customization -- things like altering Quickmail for student use, removing the "login as" capability for instructors. We did add a number of modules to the system as well. Only once did I have to swat a "glitch" which was triggered by an update to PHP (I could have simply rolled back the PHP update I guess). It was hardly a fulltime job nor am I an expert php programmer.
For a vanilla version of Moodle I shouldn't think a php programmer would be required. A reasonably savvy system administrator should be able to do the job, perhaps with some consulting support.
But most of what I did was customization -- things like altering Quickmail for student use, removing the "login as" capability for instructors. We did add a number of modules to the system as well. Only once did I have to swat a "glitch" which was triggered by an update to PHP (I could have simply rolled back the PHP update I guess). It was hardly a fulltime job nor am I an expert php programmer.
For a vanilla version of Moodle I shouldn't think a php programmer would be required. A reasonably savvy system administrator should be able to do the job, perhaps with some consulting support.
Yes, you are quite right. I was speaking of not having a php programmer for the current (WIMP) instance. A big reason we felt comfortable doing a large pilot was because we had a person (you!) who could step in a fix things. Like the numerous times I blew up the front page. . . Our current sysadmin is pretty savvy, but he doesn't consider himself a php programmer.
But now that I know that Peter's situation is definitely an enterprise system, I wonder if our experience is all that germane. With 17,000 users, you would need to pilot the systems that matter to such numbers: ldap enrollment and course creation and maybe load balancing. Our situation is comfortably 1 server. His might require a cluster. When I go to conferences, people from the large schools really do have a different set of concerns and they usually have to do with the large scale nature of the situation.
We should start this thread over with that knowledge in the first post! We might come out in a different place!
atw
But now that I know that Peter's situation is definitely an enterprise system, I wonder if our experience is all that germane. With 17,000 users, you would need to pilot the systems that matter to such numbers: ldap enrollment and course creation and maybe load balancing. Our situation is comfortably 1 server. His might require a cluster. When I go to conferences, people from the large schools really do have a different set of concerns and they usually have to do with the large scale nature of the situation.
We should start this thread over with that knowledge in the first post! We might come out in a different place!
atw
Tony - I don't know what a troll is. Do you mean little men that live under bridges?
Yes, but also this variant: http://curezone.com/forums/troll.asp
Yes, but also this variant: http://curezone.com/forums/troll.asp
"Yes, support is an issue. But the support that the Moodle user
community provides is similar to the kind of support that Bb users get
from their peers via the various user lists. This support is timely and
very thorough. However, to ensure that there are no support issues that
might trip us up, we can contract with X Moodle partner to provide service and support on as-needed basis."
I for one found this useful. Short, communicative statements like the above can be very helpful for non-technical decision makers.
first making a DB-level backup of your production database
We hadn't been doing DB-level backups to install on the test server, but I'm going to start. Thanks!
We hadn't been doing DB-level backups to install on the test server, but I'm going to start.
In reply to Peter Campbell
Re: implementing Moodle - countering the opposition
by Martin Dougiamas -
> To counter this, you can offer the services of a Moodle partner. But how long have the Moodle partners been in business? And what is the likelihood of their staying in business longer than Bb will stay in business? From the CIO's perspective, it's a crapshoot. But it's a bigger crapshoot to bet on the Moodle partner staying in business longer than Bb.
Peter, this is a ridiculous argument with a simple answer. There is ONE Bb, there are many companies who can support Moodle and many options to choose from. One tree vs a forest of trees (all growing bigger every month).
Peter, this is a ridiculous argument with a simple answer. There is ONE Bb, there are many companies who can support Moodle and many options to choose from. One tree vs a forest of trees (all growing bigger every month).
In reply to Martin Dougiamas
Re: implementing Moodle - countering the opposition
by Michael Penney -
It is true that many of the 'pass/fail' check lists US .edu CIOs use when evaluating products include points like:
These points tend to show up most often in medium size to larger insitutions check lists, and tend to favor big trees over small ones. Of course most of these check lists arose when evaluating closed source, single vendor systems (the vendor provides the support).
They don't work well when evaluating projects when a single application may have multiple support vendors. However, since these pass/fail check-lists tend to get passed from one institutions decision making process to another, it can take some time for them to evolve.
- Length of time vendor has been in business (this would be the partner in the case of commercial support)
- Number of employees of vendor
- Number of similar sized institutions vendor supports.
These points tend to show up most often in medium size to larger insitutions check lists, and tend to favor big trees over small ones. Of course most of these check lists arose when evaluating closed source, single vendor systems (the vendor provides the support).
They don't work well when evaluating projects when a single application may have multiple support vendors. However, since these pass/fail check-lists tend to get passed from one institutions decision making process to another, it can take some time for them to evolve.
My experience is that in many educational sectors people are indeed "playing it safe"... and going with Moodle. Here in the UK at any rate, the Further Education sector is moving apace from commercial solutions to Moodle. Things are slower in Higher Education, but give it a year or two - my prediction is that you will see a similar move. The OU adoption has made a lot of people stop and think.