Summer of Code 2007 – “Six Months” On

In the past, I have written a report about the fate of the Mozilla Summer of Code projects, six months after the projects closed. In this case, due to delays on my part, it’s more like ten months, and the SoC 2008 is already up and running. Still, better late than never. For reference, here are the reports from the 2006 and 2005 SoCs.

In 2007, we had ten projects. I’ve spent some time looking into the current status of all of them, and thought I would share those results with you.

I should say before I start that the following assessment is just how I see it, sometimes based on limited information. People with better knowledge should feel free to post corrections.

Name Student Mentor Story Current
Code useful to
Enable Roaming Support in
Nick Kreeger David Bienvenu A seemingly-comprehensive patch was written and
there were several rounds of review and discussion. Work continued
until December, but then seems to have stalled at the review
Patch has been awaiting review since December
Potentially Yes – making all sorts of mailnews fixes. (But was
involved before.)
Implementing cross-session download
Srirang G. Doddihal Dan Mosedale Written during SoC; completed just before
Part of Firefox 3 since alpha 8 Yes Yes, odd bits and pieces.
Places: Indexing Visited Pages Kunal Kumar D. Jain Dietrich Alaya A patch has been created, but needs updating to take
review comments into account.
Patch has been awaiting update by student since
December 2007.
Potentially No
Link Fingerprints Edward Lee Gervase Markham Implementation written, but spec (RFC) received a
chilly reception from the IETF; student ended up doing other work at
MoCo HQ.
Project dead. Probably not Yes – the power behind AwesomeBar, also working on
Download Manager.
JPEG2000 Support for Firefox Benjamin Karel Stuart Parmenter Six platform-specific extension XPIs produced (3
platforms x FF2/3). Progress reports. No sign of the code
getting checked in.
Code is available as XPIs. Unknown Yes, odd bits and pieces.
Microsummary Generator Web Service
Ryan Flint Myk Melez Basic functionality implemented but
it still needed a lot of polish and additional
development at the end of the SoC
No further development Probably not Yes – works for Mozilla Corporation
Camino : Tabosé Jeff Dlouhy Stuart Morgan Feature was implemented. Progress reports. Working, if unpolished, code on trunk Yes Yes
Integration of Thunderbird with Vista
Desktop Search
Damitha Pahan Fernando Scott MacGregor Some code was written but the project seems to have
died at the end of the summer.
Some code in the bug; no idea if it works. Probably not No
Make SeaMonkey Not Suck As A News
Markus Hossner Karsten Düsterloh Various patches were written and checked in. Communication over ICQ so no progress reports. Code in Seamonkey. Yes No
Firefox automation & Tinderbox
K Harishankaran Nagappan Alagappan Testcases were written. Code used in tests. Yes No

So of the 10 projects from 2007, 8 or 9 had happy mentors at the end, 4 had code which was immediately and directly useful to the project, and several people are still part of either the Mozilla or another open source community. This is about the same proportion of happy mentors as 2006, but a smaller proportion of projects produced directly useful code. There could be several reasons for this. At least one project foundered on issues outside the control of student or mentor; a couple more got stuck at the review stage (one because of the student, another because of us). So a mixed bag – but I guess we can’t have total success all the time :-)

7 thoughts on “Summer of Code 2007 – “Six Months” On

  1. One of the biggest wins here has to be resumable download support. Kudos to Srirang G. Doddihal for a key Firefox 3.0 feature in my opinion.

  2. What happend with indexed history ? Right now opera have this functionality it seems that firefox could have this future and it would be pretty useful.

  3. Is there any excuse at all for the Mozilla side to be the blocking factor (a la Roaming Support in Thunderbird)? Seems like someone should be helping to make sure the Mozilla side isn’t the blocking factor. Either a “super-mentor” that oversee’s several projects, or simply someone that is an official nag to prompt the mentor to keep going when the mentor hasn’t responded in a week (or so).

    Regardless of who is at fault, it is sad that so much effort can go into projects and so few of them end up being used. Furthermore, if a project produces a substantial improvement but are not yet perfect (maybe the Indexing Visited Pages patch falls into this), should they not be incorporated into the trunk anyway so that they don’t go stale as the trunk ages – and to give others the chance to pick it up and polish it to completion? How finished and polished does it need to be?


  4. “Is there any excuse at all for the Mozilla side to be the blocking factor?”

    Well, I think there are 2 parts to the “Mozilla side” here – if the mentors aren’t mentoring, then that’s something that should be fixed (and maybe a super-mentor or some kind of SoC overseer could do that).

    If the code doesn’t get used because it’s not brought up to sufficient quality (and yes it does have to be finished and polished before it gets in, generally), or because it’s waiting on a review; I think that’s a bit of a different issue. Code not “making it” isn’t unique to SoC projects. Lack of reviews or lack of followup from contributors happens elsewhere too, and I think it’s kind of a fact of life in an open project. I don’t think many people would advocate allowing code to go into products when it’s not ready. “Firefox 3 – now safer, faster, and also including a few bits of code that someone dumped in there which we hope someone might make work some day”.

    Should SoC projects get some kind of priority in product planning (i.e. taking resources away from some other feature in the product plan)? I’m not sure people would go for that either.

    In these examples, the code generated seems to be readily available. The chance is there for the unfinished stuff to be picked up, updated if necessary, and incorporated. I’m not sure if or how anyone could be compelled or encouraged to do that if they’re not already. The most obvious options would seem to be that mentors commit to finishing up unfinished projects, or that students commit to finishing things beyond the end of their paid time. Requiring either of those would seem likely to put people off being students/mentors. So I guess the only thing to do is to draw attention to the unfinished in the hopes that someone will pick it up… as Gerv’s blog has just done :)

  5. Marc: decisions about code getting checked in or not are made on an individual basis, but it’s fair to say that “check it in now and clean it up later” is not really part of the way we work.

    I agree it’s not ideal when the Mozilla side is the blocking factor, but Thunderbird is short-handed at the moment (they only have one GSoC student this year for precisely this reason) and there have been various changes of plan. I guess DavidA has to balance whether he thinks it’s the right thing to invest engineering time in getting that patch where it needs to be.


  6. There are 4 other projects listed at the end of the dependency list in bug 377241.

  7. James: we adopted some SoC applications and funded them independently, but they were not part of the SoC proper. So I didn’t include them in the analysis.

Leave a Reply

Your email address will not be published. Required fields are marked *