Summer of Code

It's been a couple of weeks since the formal end of Google's Summer of Code programme where the Plone Foundation were represented with three students. On the whole, it has been a success, though there are lessons to be learnt.

Right up front, I'd like to say - Thank you Google! It's not every day an organisation spends $3m on handouts to the open source world. Plone certainly will feel the benefits of the work that have come out of this for years to come.

First - the successes. Hanno Schlichting, mentored by Alec Mitchell, has done some great work on our i18n architecture, that benefits not only Plone, but the CMF and Zope (3) communities as well, and produced a bunch of collateral benefits, such as a GenericSetup syntax for local site setup in Zope 3. I don't think anyone really doubted that Hanno would kick ass, being one of our more consciencious and consistently solid contributors, but it's great to see him rewarded and motivated by the programme. Hanno blogged about this progress here.

Markus Fuhrer, mentored by me, also made some giant strides. He was working on PLIP 157 - Content Rules Engine. To be fair to Markus, he was thrown in rather at the deep end, building a "pure" Zope 3 package at the base to model the use case and a first cut at the Plone UI for it. Unlike Hanno, Markus had no previous Plone experience, and much of this was new to his mentor as well. Moreover, the task was to build a very open-ended framework, taking as much complexity as possible away from people wanting to build new "rule elements" (actions that you can string together to form a rule that is executed upon some event) and plug them into the system. That necessarily put a lot of the complexity in the framework itself.

Being an old friend and living in London, we were able to pair-program (with plenty of Falafel and Diet Coke) about once a week. The biggest victory in my eyes is that Markus now has a good understanding of how this architecture works, and it is my sincere hope that he will be able to stay involved with its maintenance and further development. PLIP 157 is currently under review for Plone 3.0. You can check out the review bundle for yourself. I also hope that the plone.contentrules package (which has no Zope 2 or Plone dependencies, and thus should work in pure Zope 3 applications as well) will be of use to the wider Zope community.

The last student we took on was less forunate. He was tasked with PLIP118, refactoring PlonePortlets into a more general and modern (as in, less Archetypes-dependent) solution for managing portlets in Plone. Unfortunately, we never saw any code. I worry that perhaps we scared him away (his task of was similar complexity to Markus'), and he eventually broke communication with us, without producing any code.

In the aftermath, I picked up this work with a view to get it ready for the Plone 3.0 review deadline. A huge thank-you to Philipp von Weitershausen for helping me with many of the Zope 3 details, and to Geir, Dorneles and Helge from PloneSolutions and Christof Hammerlie (who was working with us at the Archipelago Sprint), who not only made the original PlonePortlets but helped with use cases and design. You can check out the review bundle for PLIP 118 if you are interested in how this works. Similarly to plone.contentrules, I'm hopeful that plone.portlets can be useful to the Zope 3 community as a standalone component.

The lessons we learnt

There are many things to learn from the Summer of Code experience, especially if Plone wishes to participate in the programme should Google run it again. Here area few:

1. Plan early! In the days leading up to the deadline for proposals, there was some chaos. I believe we benefit both ourselves and our students the most by having clear proposals with agreed scope for students to pick, and by having well-prepared potential mentors. Internal debates about what is a reasonable scope for an SoC project and what potential projects are more important than other ones should probably happen before applications have to be rated in earnest.
   
2. Don't expect too much! We were initially hoping to get about 10 students. That was completely unrealistic. There are many organisations and a few meta-organisations like Apache and GNU who (deservedly) get many more students. Reputation, previous year's experience and relevance to the world at large seemed to be important factors for Google to determine the allocation. And yes, we are smaller than Drupal, say - we have to adjust our expectations accordingly.
3. Evaluate proposals carefully! It's very hard to evaluate a student based on the short text they submit. The potential mentors pushing for a particular project may also be blinded somewhat by the desire to see that work done.
   
   Our three highest rated students ended up being one safe bet (Hanno), one student I could vouch for (Markus) and one unknown that we were hoping to get involved in the community. I personally think that was a decent balance. Hanno deserves recognition for the great work he does, Markus ended up producing something very solid; and getting fresh talent involved is an explicit and important goal, even if there is more risk taking on an unknown.
   
   Unfortunately, there were other students marginally below the line (like Tim Hicks, who got as many points as the third student and seemed a victim of chance for being excluded). In fairness to Tim, he probably would have been a safer bet, having already contributed to Plone by way of Quills, Ploneboard and other components. Balancing the risks and benefits of betting on an unknown is important, especially when the number of allocated students is low. Having clear, honest and selfless discussions among the evaluators on the students in question is paramount.
   
4. Communicate! One of the problems with the portlets work that got canned was that we never formally kick-started the student. We offered to help, but expected the student to pull more than we'd push. In this case, that didn't happen.
   
   The student ran into trouble (such as trying to install Plone 2.5 on Zope 3.0) that we could have avoided if we were more directly aware of what he was doing. I take some self-criticism for being qutie tough on the student in this case, out of frustration that he had spent a lot of time doing something we could have told him would be a dead end - all because we were out of the loop. Unfortunately, the pattern repeated itself with subsequent problems, and communication did not noticably improve.
   
   Of course, the communication loop has two ends that need to stay active. Mentors are busy, but have a responsibility towards the student. Different students may need different amount of time invested in them. Furthermore, not every student will be as used to the constant email and IRC communication that we all take for granted. We need to be understanding of this, and help the student get over the initial bumps. We need to be helpful and friendly, and have realistic expectations of how much of a learning curve the student has to climb (and not just in terms of the work, but also just the experience of being part of an open source community).
   
   Equally, students have a responsibility to be the more active party. They are being paid a not-insignificant amount of money to do a job (mentors are not paid, mentoring organisations are paid $500 per student, compared to the $4,500 each student receives). It is not something to be taken for granted, and it is expected that the student should be as many hours into this as they would any other summer job. And this is hard - a student (Markus excepted) doesn't have a boss looking over their shoulder when they are blogging instead of working. They have to take significant responsibility for their own planning and be self-managing. They have to be able to ask for help when they are stuck. They have to be able to manage expectations with their mentors and define the scope of what they believe they can acheive. Naturally, some candidates will be better at this than others.

On the whole, Summer of Code has been a very enjoyable experience, and I believe a very positive thing for Plone. We are grateful to Google, and grateful to our students and mentors. Hopefully, we'll get to do it all again next year :)