Look, one day all software is going to die. It’s going to hit design limits. Designing software isn’t dissimilar to a chess game: Making bets about what you might need a few moves down the line, and making design decisions based on that. Eventually, you’re going to run out of moves, or the opponent will do something that changes the landscape.

So these comments are from a user coming from love, who has customized Moodle for use in a school institution.

I think Moodle has run its course in terms of being something viable that’s worth investing five years into. I think something else has to emerge, or use something else.

Illustration that we are at that point with Moodle:

One day I was modifying the theme for our moodle installation, and I came across one of the many comments often seen when reading Moodle source code. Something like:

// the code below is bad, this is a hack, never ever do this anywhere else!

I turned to my colleague and proclaimed that reading Moodle source was hilarious. I was thinking that because if you’re saying no one else should ever do X anywhere else, what you are really saying is: “No one, ever, should be doing X ever, and the only reason I am doing it this way right here is because there has been an epic failure on more than one axis.”

My colleagues thought that with my comment I was being a smartass. (Not a surprising conclusion from inductive reasoning, either.) I didn’t mean reading the source code was hilarious, though, but the source comments.

It’s a bit shocking to think there are so many of these are sprinkled through Moodle’s source, and there are hundreds of thousands of institutions who are very deeply invested in Moodle—and at least one who admirably bets the whole farm on it.

The other things about Moodle that reveals its teetering age:

• It depends on cronjobs to get basic features, such as email notifications. Really now, cronjobs?
• It’s actually a design decision to assume that users may well have JavaScript turned off. The problem with that is that JavaScript has gone a long way from being a potential security vulnerability. Students at a school simply aren’t going to turn it off, and if they’re hooked up to enterprise managed accounts, there’s absolutely no way it get turned off for them.
• Given the above, AJAX is still well under-utilitzed. For example, when you change the course format, the page does a complete request and response in order to display the options for that particular kind of course. What year is it, 1990?
• It doesn’t have “row-level” permissions system for resources. That means that you can’t say that a particular user has permission to view or read a particular resource at that particular context. Yikes.
• No global search feature. Yes, you heard me right. No global search. To be fair to Moodle, there isn’t much you can do about this for installations that are on shared hosting solutions. But again, I repeat, Moodle is showing its age. Schools aren’t even going to consider shared solutions. (Right?!)

There are a lot of things that Moodle has been at the forefront of. One which impresses is its LTI integration. Thank you! However, there are external technologies that have developed since Moodle’s inception which challenges the offering:

• HTML5 Local Storage. With this, users will never lose any data when filling in forms and things, and losing data in the middle of a lesson is just unacceptable.
• WebSprockets. This would allow Moodle to move away from running cronjobs every 15 minutes or so, and instead have things be a bit more event-driven. It would require a massive re-write and change basic assumptions.
• “NoSQL” Database Options. Up until a few years ago, if you were developing a web app you weren’t even thinking about anything except a relative database using the SQL query syntax. The problem with that is that the software have to be able to describe the datatypes its going to use ahead of time. With NoSQL options, you don’t have to do that.

In other words, it’s a ripe time for a bit of disruption…