When talking about managing an open-source technology integration, there are a ton of debates about “to do” or “no to do” adaptations to the code. Many of the exposed reasons often fall into a dogmatic discourse, the originating motivation is understandable : the lack of architectural mastering that set many of the moodle administrators and technical crew in a “black box” situation, i.e., having between hands an “opaque thing” we do not really know how it works. But if we respect the given rules, it should work.

All is about trouble of the technical crew assigned to making moodle work.

Directly opposed to this “prudent” way of managing the platform lifecycle, is usage and requirement for doing “better”, “clearer”, more “user friendly” user experience. Often this view stucks on core limitations, i.e., unforecasted consequences of code design, unexpected or not imagined uses cases, etc. Moodle has a LOT of tuning and overriding possibilities and techniques, thus those cases of hanging on a “really tricky override case” are few.

The purpose of this chapter is to demonstrate that locking on a Moodle Intrinsic limitation is not a pure fatality. All depends on a fair evaluation of the balance between Maintenance Trouble amount vs. Usage Benefice. Most of the reluctance factors to accept core overrides are measured by the “factor of Trouble occasionned for Moodle tech mainteners crew'.

We propose further some theorical approach of the concern:

First will we propose a theorical definition of the “Technical Impact” of a design decision. The technical impact (Imp) roughly determines how amount of effort will be necessary to maintain properly a working application:

The impact unit should be not far from some Energy measurement.

It can be modelized roughly as a function of increasing factors: Number of maintenance operations - Nop, complexitxy of operations - Xop, and probably an organisational factor that increases when both number and complexity grows. Organisational factor can include f.e. an increasing of the number of actors in the operations and the loss in coordination.

Opositely, there is one big factor that helps reducing the technical impact : Automation (Aut). The more automated you are (including also power tools, not necessary fully automated), the less the technical impact will be a trouble.

Now we can address the notion of “Trouble”. “Trouble” is a subjective notion, and wil not affect all actors the same way. Maintainers will have “Trouble” in having to maintain complex things and make it available for users. Users will be troubled in not having friendly enough or unefficiant tools, stakeholders will be troubled to get informed and harassed that thing do NOT WORK well.

Back to general index