Arthur Liu is doing a great series of posts following up on the results of Google Summer of Code '08 projects in Debian. (post 1 post 2) Most of them failed to produce code that's actually used in Debian, though there were some very successful projects, too.
My experience with ikiwiki in '07 parallels that:
latex
Patrick Winnertz produced a working teximg (latex -> image) plugin that's in ikiwiki.
The initial proposal also included doing latex -> html and wiki page -> latex conversions; that work never happened.
file upload and image gallery
Ben Coffey had an ambitious proposal to add file upload support to ikiwiki and also write an image gallery plugin using that.
Ben did produce a working file upload interface, but that code never got into ikiwiki. This was due to a combination of at least three things:
- The only outside communication with the ikiwiki community was doing a design proposal at the beginning, and a code dump toward the end of the project.
- There was an existing complex spec for how to limit who could upload what files, but Ben didn't choose to implement those access controls.
- The code dump was not even noticed until much later, when I was putting the finishing touches on my own implementation of an attachments plugin.
By the way, since I happened to do that attachments plugin as a paid consultant, I have an interesting data point: It took me 19 hours total to implement it, vs roughly a summer of work for the GSoC project. I don't mean this to reflect poorly on Ben, it just shows that someone who is familar with a code base and has thought a lot about a problem can work on it much more efficiently than a newcomer.
AFAICS, Ben never did get to the gallery part. His involvement in SoC was cut short for personal reasons.
Wiki WYSIWYG Editor
Taylor Killian produced a working interface to Wikiwyg, but it tragically never made it into ikiwiki.
This seemed to be going swimmingly -- Taylor set up a subversion repository for his work and produced several revisions of the wikiwyg plugin in response to feedback. At the end of the summer, it was close to ready to be included in ikiwiki.
Then we lost contact with Taylor, and his site fell off the net. Subversion repo: Gone. Tarballs: Gone.
The final tragic part of this story is that I had a local copy of all of Taylor's work. And when I moved ikiwiki over from subversion to git, I set up a wikiwyg branch, and put his work into it, and happily deleted my other copies of his work. But I made some kind of newbie mistake pushing that branch, and so his work never made it onto my git server, and at this point seems completly lost.
(I still hope to hear from Taylor..)
gallery
Arpit Jain produced a working gallery plugin for ikiwiki. But that code never made it into ikiwiki.
The main stumbling block seems to be that it used the lightbox javascript
library, which, at least at the time was licensed under a non-free CC license.
The code is present in a branch in ikiwiki's git repo, but at this point there is still no image gallery plugin in ikiwiki, though others are now working on other implementations.
Conclusions
I learned some important things from participating in the '07 SoC:
- There needs to be a well-defined place where students check in their code regularly, and where it is regularly reviewed. Either give them each accounts and branches in the project's main subversion repository, or better use distributed VCS. Ikiwiki switched to git as a direct result of the problems I saw with students publishing their code in the ad-hoc ways that resulted from not having that. And I keep backups of every ikiwiki git repo I am aware of, because any could fall off the net at any time.
- If your goal is to have a student develop something that is included in your project, that needs to be one of up-front success criteria for the SoC project. Otherwise, most of them will fail to get all the way there. Students need an incentive to deal with licensing issues, to respond to maintainers' feedback, and to keep following up until their code is merged. I suspect that requiring students leap over this sometimes very tall bar will scare a lot of them away though. You have to decide whether your goal is indeed to get working code in production, or if it's more to mentor a student for the summer.
- Just because one is very familiar with a code base and very productive in working on it, and has had lots of success getting others to contribute to it in the usual free software manner, does not mean that one will be a good mentor for a student working on that code base. In fact, it probably means you won't be, unless you have some prior experience teaching students. Which is why I've not participated in SoC since. :-/