1 Nov 2012
MoodleRooms posted a great comparison and analysis of some core LMS features. I spotted some inaccuracies and started a little conversation on Twitter. Unfortunately, it’s not a great place to go through the details. First, you should take a look at the original here. Done? Great, let’s take a closer look.
I’m not an Instructure employee (though I used to be) – so keep that in mind as we walk through this point-by-point.
First, let’s fix some numbers. TechCrunch reports 4.5+ million users – so I’m guessing that’s a safe number to use. It’s quite a bit higher than the estimate MoodleRooms gives. This is completely forgivable; it’s not standard practice to tell competitors your subscription numbers.
Next on the numbers front is languages. I use Canvas in both English and Spanish, which makes the “1″ reported here also incorrect. I would be willing to bet that there are more, though I can’t be certain. Update: see the bottom of the post for the full list of languages supported by Canvas.
On to the meat. Things get more subjective as we descend into the marketing buzz words like “Cloud Nativity”, “Dedicated Engagement Teams”, and others. I’ll try and respect MoodleRooms’ intent as we discuss.
Cloud Nativity has been touted by Instructure for the Canvas product for a while. By their definition, if I understand it correctly, a cloud-native application is software that was designed for exclusive use on the cloud. By cloud, they mean something like Amazon’s EC2 – a dynamically scalable, effectively limitless pool of resources that are not constrained by an in-house infrastructure. MoodleRooms outlines their definition a little differently: they’ve defined the cloud as any infrastructure with that type of scaling capacity, including those that are built and managed in-house. I’ll buy that: it’s just a different way of looking at things. In either respect, Canvas fits the bill.
“Non-Disruptive Release Cycle” is another buzz word – one that competes directly with the “Continuous Release” concept espoused by Instructure’s Canvas. There have been pains with both approaches – with a bi-yearly release schedule, schools have to go without much needed features and (frequently) bug fixes – at least until the next release cycle. This, of course, depends on the provider; MoodleRooms asserts that they deploy security and bug fixes continuously and I see no reason to question that . The schools will know for sure. On the “Continuous Release” side, adding new features can potentially interrupt the established workflow of teachers, administrators, and students as they use the LMS. I know from experience that Instructure is very guarded in their release of new features. They do all they can to ensure it is not disruptive to their clients (teachers, students, and administrators) in the least.
I’ll personally add another requirement to qualify for a “Non-Disruptive Release Schedule”: the ability to deploy updates without bringing a system down. This takes us back to cloud nativity, since an application designed for its deployment environment should at least consider seamless deployment of updates. Canvas handles this beautifully. I can’t say for Moodle – but I would love to find out. In either case, I would assert, from personal experience, that Canvas qualifies as having a “Non-Disruptive Release Cycle”. This is, however, subjective – it is my own opinion.
We should touch on the “Open Source Eco-system” as well. To see a “No” in the Canvas box is surprising: by the definitions outlined in the same document, it seems to certainly qualify. Several schools are running their own open-source versions of Canvas. Many have submitted code back to the core product. There is a healthy and dynamic eco system surrounding Canvas – which is, of itself, open source. I’m sure this will be corrected.
The last of the relatively subjective categories worth touching on are support and training. MoodleRooms is an excellent model of a commercial entity backing an open source project in a very traditional and dependable way. Canvas is certainly a break from that model – they offer no support or training for open source installations. I believe that Canvas was not given credit here by virtue of that restriction. This, however, is not the whole truth. Every one of Instructure’s many, many customers receives training and support by dedicated teams. It is a little funny, in some respects: Canvas is such a simple product to use that students and teachers commonly don’t need training to get up and running. Regardless, I think I would prefer to see the whole truth of the matter reflected in the chart: Canvas offers dedicated training and support to all of their paying customers.
There are a few other elements in the table that could be addressed – you can do some amazing things to customize Canvas, for example. Check out https://cap.instructure.com/login for a Halloween surprise! This post, however, is much longer than I intended. I’ll close it here, wait for comments, and hope it helps to clear things up.
Update: I was just informed of this by a friend:
Canvas certainly has more than English and Spanish! Thanks!