I'm thinking seriously about contributing to an open source project for the first time.
It's about time I put my money where my mouth is and get some code out there in the open.
As I've never done anything like this before, my head is swimming with questions:
1. Which project should I contribute to?
There are a million of them out there. Should I just pick the one that I respect the most? If that's the case, then it'd be Firefox, hands down. Should I choose the one that needs the most help? Should I choose one that's written in a language I like? What the hell language is Firefox written in anyway? C++?
2. What should I contribute?
Should I start out doing bug fixes? Should I contribute something entirely new...a Firefox extension perhaps? Oh god...I've heard some awful things about Firefox extension programming. I'm hoping the upcoming "Programming Firefox" might be able to lend me a hand there. Maybe I could start really simple and contribute a search plugin to my beloved Mycroft project.
3. How do I contribute?
How the hell do I even get the code I write included in the project? I suppose I'll have to revert back to my college senior project days and fire up TortoiseCVS or perhaps some Subversion client. How long does it take to get new code into the code base? What does that process look like?
As you can see, I've got a lot to learn. But it's about damn time.
skip to main
|
skip to sidebar
Software is about people, not code.
About Me
My name is Matt Blodgett, and I believe the most important problems in software development are non-technical.
I write from Chicago, Illinois.
Contact Me
I'd love to hear from you. Send me an email through my contact form.
10 comments :
There are a lot of ways to get involved in Firefox, including the ones you listed, but also many you didn't. I guess that makes something really simple seem really complex.
developer.mozilla.org has documents on how to get involved, and how to get involved in specific areas. Bugzilla has a keyword "goodfirstbug" that you can search on (albeit, it's underused) if you want to see what's out there to start hacking on. You can also simply start trying to reproduce unconfirmed bugs and help out that way.
We also have a dedicated IRC network where many people, myself included, would be more than happy to help you figure out what area you want to start in, and point you in the right direction - irc.mozilla.org - best channel to start in would be #firefox, my nickname is Lucy, but anyone who's around should be able to help.
Of course, you can also try getting involved via this link - http://www.mozilla.com/en-US/about/careers.html
That's worth pointing out as well.
I'd suggest that you pick a project other than Mozilla. Although the Mozilla projects are worthy, you will just get frustrated with the lack of response to requests for code review.
After a few years of trying to contribute to this project and getting frustrated with the glacial movement of code reviews, I gave up. Some years later (a few months ago) I tried again and found the response unchanged.
http://www.mozilla.org/hacking/
could be a good start
The best thing to do if you ask me, is to be selfish. Do something that impacts yourself. I got started in Mozilla by fixing bugs that particularly irritated me, and writing extensions that made my day to day use of the browser easier.
I'd check out the url p gave if you want to hack on Firefox itself and find the IRC server Majken mentioned, #extdev is good for extension development.
In some cases brodie is correct, patch review can be a slow process. It's really quite variable though. You just have to remember that just submitting a patch is unlikely to get all that far (sadly). Some reviewers also need a friendly email or prod over IRC to find out if they are going to get to your patch soon or if it would be better reviewed by someone else. Personally I generally have my patches reviewed within a week or two, though admittedly some have crept into months. The problem with fixing the things you want fixed of course is that they may not be a priority for the developer assigned to that area.
Forgot to add. On the subject of what language Firefox is written in, like most of the Mozilla apps, the frontend on Firefox is implemented using JavaScript with XUL to describe the UI. The backend platform is mostly implemented in C++.
My suggestion would be to start by doing QA. That's how I got into the Mozilla project, and it helps you get familiar with the way the project ticks without the steep learning curve of the code added on top. And also, in QA, every little thing you do is helpful. If you code, and you write a patch that's bogus, all you can do is throw it away.
I'm surprised no-one has mentioned http://www.mozilla.org/contribute/ yet - see the QA section.
I'm going to pimp bongo-project.org :)
As a young-ish project with a seasoned code base, the initial bang-per-buck ratio in terms of effort vs. features attained is pretty high. We also have a friendly community eager to help new members and, more importantly, get your code into our svn.
But, in general, I would say pick something where you can make a difference. Nothing is so soul destroying than seeing your hard-worked patches rot in a bugzilla somewhere, IMHO.
Whether or not your patches get taken, though, has a lot to do with knowing how to choose something to fix. If you're going to be heartbroken by doing work and then realizing it's not a priority, find out what bugs *are* a priority first, otherwise, see if you can make it a priority. In any project where everyone is overloaded, if you want something to get attention, you have to advocate for it - make sure it has the attention of the right people.
A mistake many people make is posting a patch, requesting review from the person they know is a dev (usually the module owner) and then waiting. The speed of review isn't glacial (thousands of fixes go into each release, and then there are the security updates), that person is reviewing their butt off, but only has time for the high priority bugs. http://www.mozilla.org/owners.html has recently seen a massive update to help avoid this. If you have a patch up though and it is being ignored, you need to find out why. Devs have to do this themselves - the reviewers don't do a search for patches created by x person and only review those - they just know to do it, and who to poke. Either the triagers on bugzilla can help you with this, or you can ask in IRC or a newsgroup.
Also check out http://zenit.senecac.on.ca/wiki for more information. Seneca is involved with Moz in a lot of ways and the zenit wiki has a lot information on getting started from reports on building moz to interesting projects. Also has notes for the "Dive into Mozilla" course - a crash course on Mozilla hacking. #seneca is another interesting channel.
Post a Comment