Hi,
It seems like some people are saying that getting workable code out of the Google Summer of Code is a relatively minor aspect of the program - maybe the third or fourth most important outcome of it, behind things like finding new developers, getting better at mentoring, teaching software development, etc. I disagree with this view - I think creating useful projects is the most important part of GSoC, and that this aspect of it should be taken much more seriously than it is. That's for a few reasons:
1) It's Google's money that's paying for all of this, and in their listing of goals for GSoC, they do list most of these things in some form, but the #1 goal they list is "Create and release open source code for the benefit of all". [1]
2) It's a real waste to not use this resource to get actual improvements to the software, given the (relatively) limited resources that the Wikimedia Foundation and MediaWiki have. GSoC offers free money, and a framework, for getting development done - it's a tremendous resource that should be taken full advantage of.
3) As MZ notes, even from the vantage point of recruiting developers, having unsuccessful projects is a problem - putting all that effort in, with nothing in the end to show for it, can be demoralizing. And that sort of thing can accumulate: if talented young open-source developers are considering doing a GSoC project for Wikimedia, and they look at the track record for the WMF's previous GSoC project, they may draw negative conclusions about it, and maybe about doing MediaWiki development in general.
So how can this be improved? Having mentored three successful GSoC projects for the WMF, I have some perspective on this. As MZ also notes, WMF projects so far have tended to be too large in scope for the length of time allotted. But that's not something that's easy to correct - estimating development time is always a challenge, even when the developers involved are experienced and not newbies. And smaller projects tend not to inspire anyone, mentors or students.
So here is my proposal: there should be in place some plan of action, ideally for every project, in case it goes overlong and doesn't get completed in time. That can take several forms: a commitment by the mentor or another experienced developer to finish up the project; a commitment by the WMF to fund the student to finish it, if the student turns out to be serious and it's just a simple lack of time that was the issue; a commitment by the WMF to fund someone else to finish it or just a commitment by the student to finish it themselves, on a volunteer basis. The last of those is tricky, because that tends to be the conclusion at the end of uncompleted projects anyway - the student keeps working on it, but that usually only lasts for a few months before the student's school work and/or regular work get in the way, and then the project often falls by the wayside. A commitment on the WMF and/or mentor side would be the ideal thing - and if there's no such guarantee for a specific project, then that should be taken into consideration when deciding on whether to accept it.
Of the three projects I mentored, none of them produced something that was fully usable on the final day of GSoC. In all three cases, more work was put in - the first time, by the student, the second two times by me. The post-GSoC work was significant in all cases, but it was still a lot less than it would have been to try to do the project from scratch. It was a comparatively small amount of effort, to get the code to at least "beta"-level or higher, that ended up making a huge difference. Something like that, from what I've seen, is almost always needed - so it should be factored into the planning.
[1] http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faq...
-Yaron