Last year: All the students were people we already knew. Projects: - Freemail. We'd been told this would be important long term by some potential important users, as well as for dogfood, and I agree personally, but nobody really used it since then. Partly because it didn't really work, at least not for me. A year later, it's working, we have a new (anonymous!) developer, and we will hopefully include it in 0.7.0. The student dev is around from time to time, occasional commits. - Simulations. Vivee's simulations this year partly built on MRogers' sims last year. Some of the conclusions from last year we will use in future. Mrogers is around from time to time but no code. - Thaw. Runaway success of GSoC 2006. Jflesch is still actively developing it and it has many many users and is bundled with Freenet. We asked for it in a fairly vague way, he'd done a small amount of work on it already. - Installer/etc. Lots of important but boring stuff was written around that time, by one of our core devs (who remains a core dev), who got to stay out of the fast food industry and keep working on Freenet. He was a mentor this year.
This year: Many people we don't know: Outsiders. Mainly judged on their applications with some feedback. Our selection process wasn't great. Some students' actual abilities were way below that suggested by their CVs. One project had to be entirely rewritten, mostly by the mentor although with some help from the student. Most others were disappointing. Well, last year's were disappointing too really, but this year's much more so. This is partly because of a policy of having self-contained projects: in theory it should reduce mentoring load, in practice it keeps students from having to become part of the community. Six projects: - More simulations. Reasonably successful, helped us to deal with a long-standing problem and paved the way for further development in several interesting areas. Insider (known by our maths guru). Student on IRC. - Searching. This more or less works, but is rather less than we'd hoped for especially as we thought of it as a relatively easy project. Deployed. Student not visible atm. - C++ library. No documentation, few examples, but the architecture seems elegant enough, the example given is both functional and short. Not really deployable right now. Not helped by the student moving to america around the completion date! This and previous were mentored by me, and I had a lot of time off for various reasons, see below. Student not visible atm. - Blogging plugin. Not quite deployed yet due to dependancies issues, but functional, and much more code than some other projects. Insider (known by a dev). Not recently visible. - Unit tests. Generally a success, although less volume than we'd hoped for. Our expectations may have been unrealistic, and we should have encouraged the student to get into the more interesting classes sooner. These things are probably much harder for somebody new to the code, but that may be a good thing: having somebody figure out exactly what the code is supposed to do, document a little, and express it in unit tests. Almost an insider; user, at least. Made an effort to get wider involvement, active on IRC, blogged: he's an insider *now*, so this is a result, although he hasn't been seen that much recently. - New crypto setup. Had to be rewritten, with some help from the student. The rewritten version has now been deployed. On the other hand, the student has been visible consistently since the SoC, committing from time to time, so we may yet get a capable long term contributor out of it. One big question is what would have happened if we had accepted Julia Medvedeva's Summer of Code proposal. She came up with an extremely ambitious solution to our searching problem, which needed a lot of reworking but could have turned into something very useful (or perhaps into nothing); it was related to her thesis project, so she would probably have produced something. Instead we took on a different student to just implement exactly what we needed in searching... Next year obviously our selection process will be different. Several good ideas at the conference: Interview the students ASAP, get them to do some code / fix a bug, deal with applications differently in the light of what we've learned, select the best student with a useful project not the application most closely matching our immediate needs (it's going to be much quicker to implement it ourselves than to mentor the student if we get a poor student). And be more willing to fail them at mid-term! Communications: Way too much private communications on the GSoC, and very little public communication. This was a mistake. It reflected a wider culture - we only have a few devs, I review almost all commits (code review is of course a great way to find bugs, originally introduced for security reasons), but have almost always replied privately to commit mails. We need to get GSoC students involved in the project as a whole, which requires making them part of the community. In terms of wider culture, as much as possible should be done in the open, although not every last nitpick. It's an open question as to how much to use the internal messaging system vs the mailing lists (the former is quite high noise, though we can find quiet places; we have anonymous contributors using it already). Bit of a problem if your sole full time dev qualifies as a disruptive person now doesn't it? :) Regular meetings might be worth looking at. I wasn't available as much as I should have been, and didn't give my students notice when I was going to disappear for a while. Likewise, my students tended to disappear for longish periods without advance notice. One of our best students actively sought me out on IRC when his mentor wasn't available, which is great. Hopefully next year I will be able to be more consistently available to my students. Other stuff from the conference: Plugins - Our initial suspicions that well-defined APIs are vital were confirmed. We need to do something about this. Interesting hearing about others' experience - we only have a few self-contained plugins atm, and no real API; some projects e.g. Crystal Space are composed entirely of plugins. Version control - Met gitta, talked about GIT over Freenet. Maybe not GIT, maybe some other distributed VCS, but we need to be able to develop freenet over freenet in the long run (aka dogfood, though our long term reasons are a little different to Mozilla's). From talking to folk about DVCS's it shouldn't hurt the development process. Web spam - This was useful new information too - one of our core technologies may be relying on something like a CAPTCHA for several years, if they are unreliable long term then we may have to rethink. Conclusion: We would like to be in GSoC 2008. But we will do it differently! We've learned a lot, and probably gained some devs. Meanwhile last year's fruits continue to unfold. Oh and the conference rocked - much better than last year, probably largely because of more people and more warning. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20071024/fb686bd9/attachment.pgp>
