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.
|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
|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
|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
|Project dead.||Probably not||Yes – the power behind AwesomeBar, also working on
|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
|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 :-)
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.
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.
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?
“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 :)
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.
There are 4 other projects listed at the end of the dependency list in bug 377241.
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.