[freenet-dev] Freenet GSoC 2007 detailed roundup

[Matthew Toseland]

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 : http://emu.freenetproject.org/pipermail/devl/attachments/20071024/fb686bd9/attachment.pgp