The world of open source software can be intimidating. Code and build complexity aside, each project’s culture is also different and they all do things differently. Some use Git, some Mercurial, others still SVN. Some have great documentation, others don’t. Some have documented processes, some have a one-person buildmaster. Some are very newbie friendly and others not so much. After examining a few open source projects from a developer-contributor perspective, the one that has captured my attention so far is Firefox.
I use Firefox everyday and wanted to contribute to its source code, for bragging rights if nothing else. And Mozilla makes it really easy to start. They have a Developer’s Guide that tells you everything you need to get started. There is a lot of information there though, and some of it is slightly outdated, so it can still be confusing and make you feel lost. Here are the steps I took to submitting my first patch to Firefox:
- I compiled Firefox following these build instructions. It took about 75 minutes on my machine (Intel Core2 Quad Q9550 w/ 4GB RAM)
- I looked for a bug to work on in Bugzilla. Mozilla has a list of good first bugs for newbies like me. I read through that list but didn’t find anything that immediately caught my eye. I just continued browsing Bugzilla until I saw a new bug that sounded simple enough for me to fix. (I later found a mentored bug list which contains bugs with a designated mentor that you can go to for help.)
The C++ output was a little trickier. I saw all these PR_LOG() calls throughout the code, but couldn’t figure out where the output was going. With help from #developers, I was able to enable these logs statements. I had to recompile Firefox with debug on and set environment variables NSPR_LOG_MODULES and NSPR_LOG_FILE to start the C++ logging. The PR_LOG() output will go to the file specified in NSPR_LOG_FILE.
- Having the edit-compile-debug cycle down, I was now on more familiar ground. I found a potential fix for the bug and created a patch for it.
- I read that a patch should be tested locally before being submitted for formal test and review. Again, there’s documentation on testing your patches, but it was daunting. I asked for help again on #developers. Someone told me in my case, I just had to run “mochitests” and only on the modules I changed. I did so and submitted my patch and test results for both formal automated testing and review on Bugzilla.
- I don’t have privileges on the Mozilla testing server (Try Server), so I asked someone on IRC to help me with this. jdm on #developers did so for me (thanks!).
As of last night, the automated test passed (I think) and I’m awaiting review and acceptance and/or comment on my patch. Then I can say I have code in Firefox!