LMS - Open Source vs. Proprietary, or Moodle/Totara vs. Janison CLS
Moodle/Totara vs. Janison CLS
Considering an open source LMS? Or are you a manager whose staff have said, "Hey, why don't we get a free LMS?" Then this article is for you.
My name is Greg McLoughlin-Wilden and I've been designing and hosting eLearning solutions since 1995. In that time I've used about 15 different LMS's and played with another 20 or so.
One question I'm always asked is, "Why wouldn't I use an open source LMS, like Moodle?"
Before I answer I should remind you that Canopi designs enterprise eLearning solutions. The kind of solutions that a business, charity or sporting association might use. I've also designed solutions for the education sector but we don't host these as they are all on internal infrastructure.
So, for the purposes of this article I'm going to compare what I'd consider the two front runners in the Australian LMS market: Moodle/Totara (open source) and the Janison CLS (proprietary). We used to host clients on both of these platforms but now I only offer Janison for the simplicty of my operations, so I'll share my thoughts including the pros and cons of each.
Meet the competitors
Moodle is an open source LMS originally developed by Martin Dougiamasp from Perth, Western Australia and is the engine behind Totara Learn. Over 80,000 registered sites use it. You can download a free copy of Moodle and install it on one of your own servers, or you can part with some cash and have it hosted for you. A couple of companies specialise in Moodle hosting on shared servers, so if hosting it yourself is too big a hassle then that's a good way to go.
Janison is a company started by Wayne and Jacquie Houlden of Coffs Harbour, NSW. Their first product was called the Janison Toolbox, but it's since been superseded by their new product, the Janison CLS. You can host it yourself, but the most common method is to have Janison host it on either their web farm or on the Microsoft Azure server. The Janison CLS is what is termed a 'multi-tenanted system', so there are only two copies of the software: one for the web farm and one for Azure. They are both based on the same source code. So, when Janison updates the software, everyone gets the update.
The first major difference between Moodle and the Janison CLS is how updates occur. When a new version of Moodle is released, each customer has to download and install the new version on their own server, or get their hosting provider to do it for them. They have to do their own research on the update, reconfigure anything that got changed, and then test that everything is still working OK post-update. On my Moodle installs this is usually takes about 60 hours, and is so labour intensive that Canopi can't afford to do the updates very often, maybe once every two years.
Alternatively, Janison manages their entire update process. This happens every 6 weeks or so, and we run a couple of hours of testing post-update to make sure everything still works. Janison provide us with a Beta test environment before each upgrade, so if there is an update coming that we want a lot of input into, then we can preview and test it beforehand.
Clearly, Janison is the big winner where updates are concerned.
Choosing and installing an LMS is one thing, owning it is another. If you host your own Moodle system then you will need people on your staff who can manage servers. You'll also need some pretty high level administrators who can configure, test and change things as required. You can bet that these sort of people are on pretty high salaries. Think AU$120K or more. If your organisation is a school or university, then these skills are normally available, but otherwise they may be less accessible to you. If you're using a hosting provider then you can largely do away with the server-type people, but you will still need those high level administrators.
With Janison, I find customers don't need any of those skill-sets, as the Janison staff looks after the servers and the high level admin. However, customers will still need their own admin people to manage user and learning records.
This section has no clear winner. If you have high level technical people within reach then Moodle works OK. If not, you could well find the task of hosting a Moodle site overwhelming.
When things turn to custard
An LMS is an incredibly complicated piece of software, often made up of millions of lines of code required to work on every browser released since Noah stepped off the Ark. I remember the first big LMS I used in 1997. It would often be offline for a week at a time while a patch was developed to fix some major corruption of the data. Thankfully, things are much better these days and most systems are incredibly reliable. But truth be told, things still do go wrong from time to time.
This is where the proprietary system wins hands down. If something goes wrong you simply log a P1 job, put the kettle on, manage your users with a polite and apologetic email, while things get fixed fast. Compare this to open source systems. I can't recall the number of hours I've spent trawling through online forums trying to find out what 'Object reference not set to instance of self' could possibly mean, let alone how to fix it. I'm a reasonably capable system administrator and developer, but even I've have had some shocking late nights trying to find out how to fix a bad update or server issue.
All of my customers have different business processes and when you install any IT system you're often faced with a two choice dilemma:
- Modify your business processes to match the system, or
- Modify the system to match your business processes.
Customisation of IT systems is a tricky thing. I remember managing one Moodle install where the pharmaceutical company client wanted a slightly different enrolment process. We paid the Moodle experts to modify the enrolment code to support the business process. We thought all was well, but it only became evident later that one of the core Moodle modules had been changed. The result? Every time we wanted to update Moodle, we had to either forgo the update, or get the developer to modify the new version of the enrolment module again. This basically shut us out of future upgrades.
On the other hand, Janison do a very cool thing: if we request a custom development they use a 'plugin and options' approach. In this case, the admin gets new options and switched on their management screen to choose which options they want and which plugin to use. Result? In the two years I've been using the system with my customers I have never been shut out of an update. Gold.
If you're the business owner of a current or proposed eLearning solution, then read this very carefully.
The tendency with an open source LMS is that one, maybe two staff members get very passionate about it. They tweak it, have a play, configure it and build up an amazing amount of intellectual capital about how the whole solution is bolted together. Sure, I've seen some people get their groove on and make base code sing, but on the whole, what tends to happen is that the LMS solution becomes an extension of one or two people.
Now ask yourself this: what happens if they leave? I've watched this happen three times with devastating results. In one case the person left without notice and did not even provide the admin logins before departing. In all three cases the eLearning solution ended up being shut down because the client could not find or recruit substitute expertise in a timely fashion.
In some respects this can also happen on a proprietary system, but I've always found that the vendor will step in, reset the admin passwords and provide enough coverage to maintain the service. This will cost, but not anywhere near the cost of losing your solution.
This issue shouldn't stop you from considering an open source LMS, but if you do, make sure you have an appropriate amount of skills redundancy in your staff. In some cases having external hosting will alleviate this issue.
This one is a purely personal consideration, and mainly an aesthetic concern. But we build commercial solutions and the fact is that looks affect experience.
Maybe I'm picky, but I've never been able to get Moodle to look as nice as I wanted. I've downloaded a heap of different themes, I've customised them, and I've even paid thousands to design a client a custom theme. But at the end of the day I've never sat back and gone 'Wow, that's beautiful'. Pity.
As for the look of the Janison CLS, it blows me, clients and learners away. It's clean, fast, full of nice white space and can be customised with ease.
To me this is a no-brainer: Janison by a mile.
Security and Privacy
What would be the implications if your LMS was hacked? If you're developing an internal LMS and nobody on the internet can access your site, then you can probably skip this section (unless you suspect you have malicious staff who might want to do you some harm).
But here goes, and I hope I don't get abusive emails for this. Moodle is an open source LMS, so any budding IT student can download the source code and break it down and work out how to exploit any weaknesses. They are often just curious, fun-loving kids, but pride can do funny things and some kids tend to publish their exploits all over the internet. Absolutely, the Moodle core team is pretty good at fixing hacks as they become known, but if you want to scare yourself do this:
- Go to https://tracker.moodle.org/browse/MUA-43?jql=
- Go to 'Issues > Search'
- Open the 'Type Filter' and select Bugs and epic
- Open the 'Status Filter' and select 'Open'
- Click anywhere outside the filter box
As someone who could get sued for having one of my hosted solutions hacked, that second item scares the life out of me. At the time of writing, there were over 5,000 Open 'Critical' and 'Epic' Issues. Not many of these are security related, but some are, and these are out in the field waiting to be fixed by a developer who is not getting paid and only contributing to the source code because they believe in the product.
If one of these issues seriously impacts your operations, then you have very little influence on how urgently it gets addressed.
Consider the proprietary model, where I can get on the phone, ask nicely/angrily, pay a little/pay a lot to get something that affects me or my customers fixed. This simply can't be done with an open source system. All you can do is wait and hope someone is onto it.
I'm not into waiting and hoping. The proprietary model wins my vote.
Before I get lynched as a capitalist pig-dog, I a) like and use open source systems, and b) think that Moodle is an amazing piece of software and has its place. However, for me and the kind of work that I do, it has its limitations. So, don't not use Moodle based on this article or my opinions. Instead, consider whether the points I've raised represent a risk to your business model. If they do, then ask yourself 'Can I put in place strategies to mitigate those risks?'
I find Moodle is good where:
a) You have the right staff profile to support it.
b) Your existing process align with the capabilities of the product.
c) You can manage the security implications and assure yourself that you have it covered.
d) If an issue develops in a version of the product, that you CAN wait for it to be fixed.
As I say, these are not show stoppers. Just think about them and whether you can accept or manage any risks.
[Comments and questions welcome, just register to contribute]