Looking for a bit of feedback from the Moodle community with this post, so please add any comments. Actually, looking for feedback from any community that uses an LMS, not just Moodle.
We’re struggling a bit right now with an upgrade strategy for Moodle. Recently, Moodle has implemented a regular release schedule, releasing a new, major release twice a year (December/June) with minor releases 6 times a year. While I am a generally fan of the Agile “release early/release often” development philosophy, it is quickly becoming obvious that this is going to be operationally challenging to keep up. In my understanding of the release early/release often philosophy, the changes in each release are meant to be incremental improvements and not feature driven. The problem I am seeing with Moodle right now is that the changes are not incremental. Some of them are downright massive.
Our story is that we have just finished launching Moodle 2.1. We did not upgrade from Moodle 1.95 to 2.1, opting to have 2 learning platforms running to minimize disruption for the students as the two platforms are quite different. So, we have bit the bullet internally and are phasing in Moodle 2.1. New students in new programs are in 2.1, existing students finish their programs in 1.9.
The 2.1 project took us over a year to plan and deploy, partially because we had so heavily customized the 1.9 platform that it took a lot of code rewriting to make sure 2.1 would do what we wanted it to do. We went from over 400 customizations in Moodle 1.95 to less than 10 in Moodle 2.1. We abstracted those customizations and have now redeployed most as modules or plugins. All this was done in the hopes that future upgrades would be more nimble. There was (and still is) a weariness with doing “mega” upgrade projects that take over a year of intensive resources to plan and deploy. We wanted to be able to roll out quick updates a few times a year as close to the Moodle schedule as possible. That was the theory.
In practice this is much more difficult, mostly because the pace of change coming out of Moodle core development is massive. We have just launched 2.1, but now find ourselves 2 versions behind. By December with the release of 2.4, we will be 3.
Now, going from 2.1 to 2.2 will be pretty invisible for our end users as the changes are not that different, and don’t touch some of our customizations. But going to 2.3 means quite major changes at there are overhauls of some key features of the LMS that touch many of our users (navigation, a complete rewrite of assignments, new activity and file picker, key places where our users interact with the LMS). 2.4 looks to be bigger still, with the addition of team assignments, which is one of our key customizations. So, do we wait until 2.4 is out in December, setting our upgrade schedule back to the summer , or do we rewrite our team assignment customization to work with 2.3 knowing that it will be useless in the future? Our work becomes redundant next year.
All this is to say, even these dot upgrades (which we thought would be fairly minor and easy to keep up with) are becoming what we hoped they wouldn’t be – mega-upgrade projects. But now they happen yearly instead of every few years. We are looking ahead and trying to figure out, do we live in perpetual Moodle upgrade land to the point where we operationalize Moodle upgrades each year, or do we stop and sit where we are?
Technically, it takes massive resources for us to do these upgrades, primarily because customizations need to be examined and tested against the code changes. But we have good coders, and they can do the work. The bigger issue is prepping our users and supporting faculty through a constant change cycle. Now, change is good, but when you find yourself in a situation where you are expending huge resources to manage change well, you kinda go is it worth it?
We’re feeling a bit frustrated right now and find ourselves at a high level crossroads. Is this constant upgrade cycle becoming our new reality? It’s becoming obvious that we underestimated the changes each dot release of Moodle is bringing. We were expecting smaller, incremental changes that would have a fairly minor effect on our end users or customizations, not entire rewrites of core components or massive UI changes.
So, my question to you, if you have stuck with me this far (thank you) is how are you managing your Moodle upgrades with the new Moodle release schedule? Do you have regular upgrades scheduled, or is your strategy to sit and wait awhile?
Any insight into your situation and how you manage the upgrade cycle is appreciated.
I are using a very plain Moodle Install yet have the same struggle in the benefits and challenges of change. I need to integrate Equella and a some high quality plugins so can't lag too far behind the current Moodle Version. Technically its is challenging to keep it all in sync, but the real issue really is in User Confidence in a stable environment. We don't have the resources to rewrite training materials constantly. I have watched Joomla CMS, and WordPress move these processes of maturation and have major rewrite to code and interface design as funding improves and more developers contribute. What do i need now??
It is necessary for one to be up to date all the time. That is certainly why, as a developer of the MLMS, it is easy for me to upgrade all the new version release of Moodle.
Hi Clint,
The approach I take with my clients is to upgrade Moodle twice a year. Typically, I will copy the site, upgrade and deploy a development instance, and allow clients to test for 7-14 days. After this I will upgrade the instance in production with the clients consent and part of a plan.
All of my clients run a vanilla Moodle with perhaps 1-4 extra modules, and a custom theme. Thus the upgrades do not require much prep work.
Security updates from Moodle are applied only when they are exposed on the instance in question. In most cases, the security fixes are related to systems clients are not even using, like web services etc. Sometimes security patches are needed, and I just apply them to the specific file using subversion to avoid the need for an upgrade mid-year.
Hope this helps,
Brent.
Thanks, Brent. Sounds like you are right in step with the Moodle release schedule. I imagine your upgrades happen in the summer and at Christmas? How do you find your clients have been reacting to the changes in the past couple years with Moodle? Any sense they are suffering from upgrade fatigue?
We are using a very plain Moodle Install yet have the same struggle in the benefits and challenges of change. We need to integrate Equella and a some high quality plugins so can't lag too far behind the current Moodle Version. Technically its is challenging to keep it all in sync, but the real issue really is in User Confidence in a stable environment. We don't have the resources to rewrite training materials constantly. I have watched Joomla CMS, and WordPress move these processes of maturation and have major rewrite to code and interface design as funding improves and more developers contribute. The key difference is that other CMS have minimal disruptions to the end user experience through this growth period. For a Learning Management System the teachers developing courses, and Learners, are exposed to this constant change. We don't have an answer to this problem either!
One bit I have really appreciated lately with WordPress upgrades is that they have incorporated contextual help so well with upgrades. After you upgrade and login, there are pop ups that direct you to what has changed in the interface, and what is new. Every page you go to as an administrator or an author you are greeted with a prompt on what’s new. Something like that would go a long way to improving the upgrade experience for users.
I definitely agree with what Patric has written. I would concentrate on upgrading to 2.2 as there are a multitude of bug fixes and enhancements that your instructors would be very happy to see. Examples are Rubrics and the mobility theme built right in.
However, at the moment 2.3+ changes things so dramatically, and there is no way to turn certain things off, that I would not consider that move. They have also 'half built' things in 2.3 that don't actually work yet (very ugly way to develop functionality), that results in some confusion for users.
So my two cents is that it is worth the time and energy to move to 2.2, but then stick there for the time being
Thanks for the comment. Yeah, 2.3 seems to be another big change. I know change happens, but it would be much easier to keep up and plan upgrades if there were not always major feature changes.
Maybe if Moodle does keep to 2 major upgrades per year, they could make on a features update and one a back end update? Try to minimize the disruption to the end user, who are the ones I ultimately worry about. We techs will survive. It’s the end user (especially faculty) who seem to end up suffering the most.
This new model of Moodle being a moving target is a huge challenge to medium and large installations. I have noticed that those with small instances have been quick and eager to jump to 2.3 which I consider the dog's breakfast. Radically altering the file system was bad enough but adding drag and drop that you cannot disable forces admins to make bad choices for good reasons. Do not even get me started on the new activity chooser!
Supporting a user database of 30,000+ and 1200 course shells per term I have had to rely on extremely detailed documentation and rapid development strategies to keep up but I see the Moodle upgrade schedule impossible to keep up with unless holding back to a single major upgrade over the summer where there is time to update all the documentation and prepare for the inevitable backlash of change.
In my own private instance I will stick with 2.2 until the ability to toggle back key workflows are allowed. I am even considering adopting the edu-sharing integration with Alfresco to completely circumvent the file picker issues and hunker down until my confidence in the development choices improve.
Thanks for your comment, Patric. Sounds like you guys are in a similar position. Let me ask you, do you guys have a regular upgrade schedule, or do you just keep an eye on Noodle and make a decision to upgrade based on things like new features, etc. What criteria do you use to upgrade?