On Feb 9, 2011, at 6:18 PM, Gwern Branwen wrote:

2 years ago in February 2009, I wrote up a history of Summers of Code through 2008 (http://www.haskell.org/pipermail/haskell-cafe/2009-February/055489.html). But the Wheel turns, and years come and pass, leaving memories that fade into 404s; a wind rose in Mountain View, whispering of the coming Summer...

I have considerably expanded and updated the coverage: http://www.gwern.net/Haskell%20Summer%20of%20Code.html

There was some discussion of this on reddit. [1] Below is a slightly cleaned-up version of my comments there. I really appreciate this roundup. But I think the bar is set somewhat too high for success. A success in this framework seems to be a significant and exciting improvement for the entire Haskell community. And there have certainly been a number of those. But there are also projects that are well done, produce results that live on, but which aren't immediately recognizable as awesome new things. Furthermore, GSoc explicitly lists a goal as inspiring young developers towards ongoing community involvement/open source development, and these notes don't really take that into account. For example, I don't know of any direct uptake of the code from the HaskellNet project, but the author did go on to write a small textbook on Haskell in Japanese. As another example, Roman (of Hpysics) has, as I understand it, been involved in a Russian language functional programming magazine. So I think there needs to be a slightly more granular scale that can capture some of these nuances. Perhaps something like the following: [ ] Student completed (i.e. got final payment) [ ] Project found use (i.e. as a lib has at least one consumer, or got merged into a broader codebase) [ ] Project had significant impact (i.e. wide use/noticable impact) [ ] Student continued to participate/make contributions to Haskell community A few more detailed comments about projects that weren't necessarily slam dunks, but were at the least, in my estimation, modest successes: GHC-plugins -- Not only was the work completed and does it stand a chance of being merged, but it explored the design space in a useful way for future GHC development, and was part of Max becoming more familiar with GHC internals. Since then he's contributed a few very nice and useful patches to GHC, including, as I recall, the magnificant TupleSections extension. GHC refactoring -- It seems unfair to classify work that was taken into the mainline as unsuccessful. The improvement weren't large, but my understanding is that they were things that we wanted to happen for GHC, and that were quite time consuming because they were cross-cutting. So this wasn't exciting work, but it was yeoman's work helpful in taking the GHC API forward. It's still messy, I'm given to understand, and it still breaks between releases, but it has an increasing number of clients lately, as witnessed by discussions on -cafe. Darcs performance -- by the account of Eric Kow & other core darcs guys, the hashed-storage stuff led to large improvements (and not only in performance)[2] -- the fact that there's plenty more to be done shouldn't be counted as a mark against it. [1] http://www.reddit.com/r/haskell/comments/fid5w/haskell_summers_of_code_retro... [2] http://blog.darcs.net/2010/11/coming-in-darcs-28-read-only-support.html Cheers, Sterl.