A lot of people ask how the development of Moodle operates. This page should give you a working overview that should help in understanding a lot of other developer documentation.
The key players
- Martin Dougiamas
- Martin is the founder lead developer of Moodle. Generally he tries to facilitate democracy and meritocracy but occasionally has to make executive decisions on things.
- Moodle HQ
- The mostly-Australian team of more than 20 developers who are directly funded by the Moodle project to work full-time on core developments.
- Moodle Partners
- Over 50 companies around the world that provide Moodle services. These companies often have their own developers and may contribute to Moodle directly by working on core code or by creating plugins.
- Component leads
- A number of people around the world have volunteered to lead various components in Moodle. This involves maintaining existing code as well as listening to the community and improving that component with new features.
There are many other people contributing to Moodle in many ways. For a full list see the Moodle developers page on moodle.org.
How we develop the Roadmap
The Roadmap lists the new features being developed for the next major version. This list is derived mostly from the issues with large numbers of votes in the Moodle Tracker, so please vote for what you want! Other influences include general discussion, surveys and feature requests at Moodle Moots and in the Moodle forums.
Component leads decide on features in individual components so make your case to them!
Moodle major releases (with big new features) are now on a regular 6 month cycle, in June and December. Each major release increments the version number by 0.1 (eg 1.9 -> 2.0 -> 2.1 -> 2.2 -> 2.3) and starts a new branch of minor releases.
Minor releases (with bug fixes only) are now on a 2 month cycle, unless a security emergency occurs. They will increment the major release by 0.0.1 (eg 2.2 -> 2.2.1 -> 2.2.2).
The full details of these can be seen in the Releases.
Moodle HQ is committed to supporting major releases for 12 months of general fixes (usually 6 point releases) and 18 months (an additional 6 months) of security fixes.
That means we usually release minor versions for the last three major branches.
Issue tracking is an important part of a continuous quality control process. It involves reporting of problems (bugs), ideas for improvement and new features. Unlike most proprietary software programs, Moodle issue reporting and tracking information is open to everyone. Moodle's issue tracking system is called the Tracker.
All Moodle users are encouraged to be active participants when it comes to testing. Anyone with a Tracker user account can create, view, comment on, vote, and watch bugs.
As you might guess, a large software project like Moodle with hundreds of contributors and varied opinions can be difficult to manage.
Over time we have developed a number of well-defined processes for getting code in and out of Moodle and for governing everyone's workflow in a way that is fair and clear.
See our Process document for full information on our development processes, including how you can contribute to the project.
Over time we have distilled our best practice in writing code down into our Coding Guide. These rules cover the formatting and layout of all our code to make it consistent across the code base. If you plan to write Moodle code, you need to read it thoroughly.
Plugins and APIs
Although Moodle is open source and you can change anything you want, the best and most maintainable way to extend Moodle is to write a plugin (sometimes called a module). Plugins are a directory of code that can be simply "dropped" in into any Moodle installation and it will be detected, installed and automatically made available as a tool within the Moodle interface.
See our Plugin documentation for full details of the various types of plugin available.