Totara have made the decision to fork from Moodle in order to allow us to make deeper architectural changes we believe are necessary to modernise the platform and provide key functionality required in the corporate Learning Management space. More information on the background of this decision can be found here.
This document provides more details on the likely impact of the fork on organisations that wish to migrate from Moodle to Totara, or are reliant on Moodle plugins or themes.
Soft fork versus hard fork
The term 'fork' indicates a divergence between two codebases leading to functional differences and code incompatibilities. A hard fork refers to a sudden cut-off where after the fork no code is shared between the two projects. With a soft fork code can continue to be shared for some time, with bug fixes or features continue to be pulled in when it makes sense to do so.
In this case Totara is making a soft fork, and therefore the divergence and incompatibilities will be gradual over time. We are likely to continue to pull in code from Moodle for an extended period of time. The impact of the soft fork will be dependent on which features are implemented in both Moodle and Totara, and how those differences interact with each other. This in turn will determine how long we can support upgrade paths for and also plugin and theme compatibilities.
Approach to divergent changes
Our overall approach to diverging from Moodle is that we will do so only out of necessity. There is no benefit to introducing unnecessary differences so when possible we will continue to use Moodle's plugin architecture to extend rather than modify core code. When a core improvement is necessary we will attempt to introduce the change in a backward compatible way so existing code developed for Moodle will continue to function without requiring changes.
Known and unknown impacts
Assessing the future impact of the decision to fork can be difficult because some of the impacts depend on factors outside our control. The direction which Moodle chooses to take may significantly impact how quickly we diverge. There are however some areas that we are aware of or that we have more control over. Details on the expected impact of our fork on those areas is given below.
Competency Frameworks and Learning Plans
Totara introduced competency frameworks and learning plans in the very first release of Totara. Recently Moodle have made the decision to add Competency based education to Moodle using the code from an earlier Totara release as a starting point. This is currently it is targeted for inclusion in Moodle 3.1.
Since the same functionality will exist in both products merging 3.1 into Totara is likely to lead to significant conflicts or duplication in functionality. Our handling of this will depend on the details of the Moodle implementation. If the Moodle implementation is largely unchanged, it should be possible to migrate competency and learning plan data from Moodle's model to Totara's model and support a full upgrade from Moodle 3.1 to a later release of Totara. If Moodle have made changes to the code to add functionality that we see value in we may be able to merge that functionality into Totara. On the other hand, if Moodle have made complex data model changes or added functionality that is unsuitable for our customers it may be difficult to provide a smooth upgrade path. This will be assessed once Moodle 3.1 has been released and we begin the process of integrating parts of it into Totara.
UX / Themes
The lack of a clean modern look and the difficulty modifying the appearance themes has been an ongoing point of feedback for both Moodle and Totara, and we feel that some fundamental changes are required in order to modernise the platform. While this work is taking a number of forms, there are two which are important in the context of compatibility.
In order to give theme designers more control and flexibility we are prioritising converting Totara to use templates. In order to minimise differences with Moodle we have decided to use mustache templates as they are already in use by Moodle. There are some areas where it might be necessary to extend Moodle's template solution to achieve what we need but we expect it to be backward compatible.
Moodle currently uses a modified version of the Bootstrap CSS framework in its "bootstrapbase" theme. The key difference is that the framework has been modified to apply Bootstrap appearances to Moodle CSS classes. Our preference is to modify the template HTML to use native bootstrap classes, therefore allowing Bootstrap to be used without modification. This may mean some HTML changes to core templates, which is likely to make Moodle and Totara 2.2 - 2.9 themes incompatible with Totara 9.0. While this work is being assessed we would like to be able to provide a "legacy" theme which retains the old HTML templates. This would allow earlier themes to continue to be used on Totara 9.0 simply by switching the "parent" theme to use the legacy one. However the feasibility of this approach is still being assessed at this stage.
In Totara 9.0 we are converting icons to use the "Font awesome" icon library. This will improve the consistency and appearance of icons in all themes. We will retain backward compatibility by allowing icons without a specified font icon to continue to use the original image version, and will make it straightforward to convert graphical icons into font based ones in third party code.
We have decided to implement our own forms library to solve some of the limitations and problems with the current Moodle forms library. The new library will sit along side the existing library so any forms based on Moodle's formslib will continue to function unchanged. The new library will provide significant new capabilities, but will be largely compatible with Moodle's library when building a form. Therefore converting a Moodle form to use the new library will be a very straightforward process in the majority of cases. Totara will undertake the work to convert all the forms in Totara extensions to the new library. The new library will likely offer some new capabilities not currently available in the Moodle forms library.
Multi-tenancy is a much requested feature, and one which is more important in the corporate space than an academic setting. Moodle did consider adding multi-tenancy to Moodle but the project was cancelled at the specification stage. We would like to add multi-tenancy into Totara, but given the extent of the changes required it would be very difficult to implement in Totara while still tracking the Moodle project completely. Since there is no appetite for implementing Multi-tenancy in Moodle this is one of the key reasons why we decided to fork.
Realistically implementing multi-tenancy is also likely to be one of the larger factors that will lead to divergence between Moodle and Totara post-fork. Unless we can come up with a clever way to implement it without impacting existing Moodle code (unlikely) fundamental changes will be required that will make merging Moodle code significantly harder.
Multi-tenancy is not currently scheduled for development in 9.0 but there is significant interest from multiple parties, and so it may well be in place for Totara 10.0.
The table below details the known and expected upgrade path support from versions of Moodle to Totara. Upgrade paths from any earlier version of Totara to a later version are always supported. If you have a client that is currently running Moodle and is considering upgrading to Totara the safest course of action is to not upgrade past Moodle 2.9 since an upgrade path will then definitely be supported.
|Moodle version to upgrade||Minimum Totara version||Supported?|
|3.1||10.x||Likely yes, though migration of competency/learning plan data may not be possible|
|3.2||10.x or 11.x||Unknown|