I have contributed many plugins to Moodle and am constantly developing new ones. To get started, select what kind of plugin you would like to do as the API is slightly different for each type of plugin. For the most part, mods and blocks are the likely plugins to be developed. However, I find myself developing Course formats, local plugins, reports, admin plugins and more.

In the links that mary has shared with you, you will find templates for modules (http://docs.moodle.org/dev/NEWMODULE_Documentation) and blocks (http://cvs.moodle.org/contrib/plugins/blocks/NEWBLOCK/). Local plugins follow the same basic structure as modules. The naming convention is where it changes the most. A really important thing to keep in mind is to use the DB class whenever you need to do DB functions. Do not use standard php mysql or other database calls. The DB class handles all the different types of DBs one can use, making your plugin compatible to all supported DBs.

Because plugins always follow the same structure (according to their type), it is easy to look at another contribution of the same kind and figure out how things work.

I often find that the easiest way to learn about a system is to start fixing bugs in the existing code, rather than starting to write something new.

If you would like to follow that approach, take a look in the Tracker and find something that you think is interesting that you'd like to fix - perhaps in an area of Moodle you already know as a user. Issues have a difficulty set sometimes, so picking something marked as "easy" should mean that it isn't too big a coding challenge.

The links you've been given above explain how to offer your fix for integration.

Great! In Moodle 1.8 and 1.9, there were blank blocks and activity modules; bare bones templates that didn't do anything; that you could play around with and see what you could do. Another thing is to look at existing blocks and modules and play with those to see how they work.

In my opinion, the developer documentation has been way behind what the actual code is and what it does, and the code comments range from informative to useless. I'm sure that by the time the Moodle 2.x docs are close to being comprehensive, we'll be moving on to Moodle 3.0. Be prepared to spend some time trying to work out what objects and parameters need to be passed between functions (trial and error).

Jenny,

Fix bugs? That sounds like the coding equivalent of the new guy doing everyone else's filing and photocopying. I hope you don't have interns at Moodle HQ :P

That is a common misconception about bug fixing. It is not menial work at all. It is the hardest job in software development: understanding the existing code, understanding the problem, and then working out how to fix it wihtout breaking anything else. (The book "Facts and Fallacies of Software Engineering" - which I strongly recommended - has interesting things to say about software maintenance, among other things. http://books.google.co.uk/books?id=3Ntz-UJzZN0C)

Having described it as hard, it may seem paradoxical to suggest it as something to do for a new Moodle developer to do. Butt he point is that passively trying to read and understand code is hard. Have a reason to read the code - a bug that you are trying to fix - really forces you to think about the code you are reading.

The other bit of advice is to concentrate on just one area. Moodle is a big beast, as others have said. The good news is that you don't have to understand it all at once. Work out what sort of think you want to do (e.g. block or activity module) and just concentrate on that area of the code.

Bug fixing is the best way to dip into Moodle. I get all my new developers started by working on bug fixes. But most of software development is maintenace, not new features.

BTW, I am sure you must have ran into a Moodle bug while suporting your users and had to edit core to fix it. I suggest you start there and figure out how to make the hack you did to core into a cleaned up bug patch.