New Developer Info
This page is meant to provide new developers with information about how the Blender development process works, where to find info and how to find a good project to work on.
Most communication happens on mailing lists, irc chat and the bug and patch trackers. See the Contact for more information. When in doubt and no particular channel seems to match your question, mail the bf-committers mailing list and you will get an answer there or get redirected to the right channel.
No spamming or flaming on the lists or irc channel is allowed. Please stay on topic in the lists, and follow good net etiquette. Also do not send html messages to the mailing lists. Html messages can be contain a variety of security problems and as such tend to be mistrusted by many people.
Sunday IRC Meeting
Currently (January 2016), a new schedule for dev meetings is being experimented, aiming at being more accessible for people far away from EU timezone:
Check http://blendercoders.xyz for a version of the schedule adapted to your timezone.
If you want to start developing in Blender you will have lots of startup questions. You can ask them in the #blendercoders irc channel each day of the week.
For regular developers, every Sunday there is a development meeting in #blendercoders. It takes place at CET or CEST 16:00, see the Sunday Meeting page for more information (including meeting notes of past meetings). The Sunday meeting is where all the developers bring each other up to speed on their various projects and make decisions on releases, merging branches, accepting features, ... .
During the meeting, stay on topic. If you want to seek approval for project ideas, or contact another developer, log in before the meeting, hang around after or message another developer personally during meeting time.
See Building Blender.
Blender development is structured similarly to Python's BDFL model (BDFL stands for Benevolent Dictator For Life). The idea is that the project is managed by one person, in this case Ton Roosendaal, who delegates design decisions to a group of module owners, while still maintaining a veto right of what goes into Blender.
Your First Project
Once you have blender compiled you're probably wondering where to start tinkering. If you are a Blender user then there is probably some niggling thing you would like to add or change. If you are new to Blender then you will need to take a look and see what you might work on.
There are no hard and fast rules about where to start, so find an area that interests you and start looking onto it.
Some hints for your first projects:
- An area of interest (even better, an area of Blender you use)
- Double check it is not already done.
- Don't choose a project that spans across many files and areas of Blender, since you may get bogged down trying to understand everything at once.
Here are some areas that can give you a foot in the door:
Adding in small features is a good way to start getting your hands dirty, even if you don't make a patch to commit, it can evolve into something more useful, take a new direction, or spark interest in new areas to develop.
Here is a [list of quick hacks] - that core developers think could be reasonably tackled as a first blender project without a major time commitment (i.e. a task that would take a core developer less than 4 hours to accomplish, but might take quite a bit more time for a new coder who needs to learn the code base).
One of the easiest ways to get involved with coding Blender is by fixing bugs. Bug-fixing lets you focus on a small part of the Blender source rather than trying to understand it all at once. The list of current bugs is on developer.blender.org. So pick an area of interest and start fixing! When you have got it, make a patch and submit it.
The editors directory is usually a good place - it is where most of the operators live. Have a look at the header files and structs related to what you are interested in working on. The headers usually have the best overview of what a function does. To find the struct a simple grep or other search for struct Foo.
You can also start with writing python scripts, the API for our python tools - is similar in many ways to our C API. You can often find out where some C code lives by seeing the python tool tips by hovering over a button and seeing what the operator name is. If you add a console window you can see what is output to it when you do an action, then just search the code.
Also putting a break on a function in a debugger and doing a back trace can help you find the path code took to get to your function of interest. Or you can start blender from the commandline with the -d option and every command is printed to the console.
If it is a bug in your code, load your test file and the information you have found out about the bug to pasteall.org then ask for help in #blendercoders in irc.freenode.net. If no-one can help you there you can try emailing firstname.lastname@example.org.
Steps for getting a patch into Blender
- Find an area in Blender you want to improve upon.
- Find whoever "owns" the code and check if he agrees with your project. See the list of module owners. Generally the best idea is to talk to the owner(s) in #blendercoders, but new developers might want to email the mailing list instead.
- Post a design document on this wiki, creating a new page linked from the Projects page.
- Do the actual coding :)
- Once you have code, see the Contributing Code section on how to make a patch get it submitted, reviewed and included.
We encourage everyone to use the Blender Wiki to document code work and to share proposals. Note that we strictly apply the rule "No code gets in trunk without documentation!". Also never hesitate to include good example .blend files and tests and videos showing the feature.
People who only want to help with technical documentation are welcome too. Just use the general contact information here to get started.