Want to become a Chamilo developer? Here are a few tips to help you on your path to success. This guide is designed specifically for the 2.* versions, which are the current development branch starting in 2026.

Understanding Chamilo

Chamilo started as a fork of Dokeos in 2010. Dokeos was forked from Claroline in 2004. Claroline was born in 2002 in Belgium.

As such, Chamilo has, still today, some very old, very procedural code, together with some very recent framework-based code (Symfony 6.4, for v2). It has also moved around 2005 from a one-database-per-course structure to a single database with tables shared between resources of all courses, so you might find remains of weird stuff in the code (like database prefixes), in particular if you work on migrations from older versions. In the run up to v2.0, we have also added a "resources" layer, which essentially tries to reference every possible resource that requires some kind of ownership control into the resource_node table.

Chamilo's code structure

Most of the new code is now developed inside the src/ folder (with a structure matching Symfony's default), with the legacy code (things that have not yet been completely transposed to Symfonfy's structure) still in the public/main/ directory. This legacy directory contains one directory per course tool, and the public/main/inc/lib/ directory contains most of the global legacy libraries, and most notably the main/inc/ directory that contains the global.inc.php file, loaded by most legacy pages.

Chamilo's database structure

You can find a schema of the database on the Database structure page. What you need to know, in short:

• resource_node defines resources and their hierarchy (what they are attached to, at creation time)
• resource_link defines where those resources can be seen/used (i.e. courses, sessions, groups, ...)
• resource_file defines the files attached to those resources
• c_* tables are course-tools related tables
• track_* tables are user-data collection tables
• all other tables (or almost all) are of global use (not specifically related to a course)

Coding conventions

Our Coding conventions are very important to us, and several automated processes will check that your Pull Requests respect those conventions before we review them.

Contributing code/features

All public issues are registered in the https://github.com/chamilo/chamilo-lms/issues page. If you are going to work on a specific issue that is not publicly registered, we invite you to register it first on this page to ensure that multiple people will not work on the same feature separately at the same time.

Some private issues (usually bugs or new features some customer of an official provider asks them to work on) might be tracked on a separate system, but we encourage you to register an anonymized version in the issues list to get additional feedback.

You are also encouraged to develop your code in a personal branch of the project, then submit them as a PR (Pull Request/Merge Request). To do that, start by forking the Chamilo project (branch 1.11.x) in your personal account on Github, then create a new branch. Once you are happy with your branch (you tested it locally), submit it as a Pull Request by connecting to your Github interface, on your branch's page, against the chamilo/1.11.x branch.

Pull Requests validation

This Pull Request will then be automatically checked against a series of validation processes. If something fails, you can still send code changes (commits) to your own branch, and the Pull Request will automatically be updated.

Once your Pull Request validates, we will start the manual review. This can take several weeks. Don't hesitate to post a message in your issue from time to time (once a week?) asking for a review. We (the maintainers team) see those messages and will try to validate as fast as we are available (we also have very large numbers of tasks to work on outside of the Chamilo project on Github, so our time is limited). We might start a review process for which we will ask you to update code or answer a few questions.

Once the review process is over, your code will be included in Chamilo and be available in the next release if it matches the rules of the release cycle.

Release cycle

Our release cycle has a series of rules that might require specific decisions regarding the integration of Pull Requests. Check the details here: https://github.com/chamilo/chamilo-lms/wiki/Release-cycle

Finding help

Developers communicate on a Slack channel. You can ask to be included to the channel by sending us a message through the chamilo.org contact form, or through a comment on a pull request.