Three Laws for successful “Google Summer of Code”-like projects

This post is aimed at mentors and organization coordinators of internship programs like Google Summer of Code. If you’re a student, you’re probably more interested in how to write a successful proposal, in which case, you better head over to this great post by Teo Mrnjavac.

It’s a very busy time for me, I’m in thesis crunch mode and applying for jobs at the same time. This is why this year I have decided to step down from my role as organizer of internship programs at ownCloud.

In the past two years I have coordinated and mentored projects for Google Summer of Code (GSoC), Outreach Program for Women and Google Code-In, and in the two years before that I have been a Season of KDE and a GSoC student myself. In all these fantastic experiences, I had the chance to observe some patterns that recur in successful projects. As the administrators of these programs repeatedly point out, success starts from the project ideas page. I agree with this, and in fact I believe that if the description of your project idea obeys some simple criteria, your mentorship will be an enjoyable experience (with very high probability).

This is the time of the year when mentoring organizations are supposed to get their ideas page ready, so I thought it would a good time to share some advices on how to write a good project description. I have synthesized the patterns I observed in a set of three laws — the term “law” here is in the sense of “adage”, as in Asimov’s laws or Atwood’s law. By the way, notice I refrained from titling this post »Cosentino’s laws«. You are welcome! 🙂

Without further ado:

First law. A project is always twice as big as you think it is.

Second law. You must provide (at least) a partial specification and a prototype to your mentee of what you want to be implemented.

Third law. If you think an issue on the bug tracker makes up a nice project idea, then something is wrong with that issue.

Even though they’re all pretty much self-explanatory, let me comment more in detail on each law.

The first one can probably be applied more generically to many aspects of life, and still it’s a rule we always forget to keep in mind when we assign a task to someone else. The factor with which a project eventually scales up varies, in software I observed that 2x is a good approximation. If you have already written a description for the project you want to mentor this Summer, a no-brainer to make it successful is going back to the project description and slicing it in half (do not recurse many times :P).

When you read the second law, you may raise the point that an intern will gain a lot of experience by writing a specification and a prototype of the project by himself. In fact, you may argue that somebody who wants to become a good software engineer should learn these important skills and not just how to monkey-code. There are many problems with that. First, writing specification is hard and writing a prototype is even harder. The time span of a project is usually 3-4 months and that’s not enough for everything. The intern will only enjoy his project if he sees code running on his machine. It’s true that ideally you want the intern to do not only coding, but also specification, prototype, documentation, … However, that is impossible, and if you have to cut off something, you can’t cut off the coding part. Furthermore, only when the mentor writes a formal specification by himself, he will figure out many details of the projects, such as size, feasibility and usefulness, which may slip out if he only writes a succinct description of the idea.

The third law is perhaps even more arguable, as it depends on how your organization handles the bug-tracker. Here I am claiming that if a bug or a feature request has the same size of a student Summer project, then you should split that in smaller issues, or remove it from the bug-tracker, because you have very small chances that somebody will fix it. Plus, bug-tracker discussions can be very technical for someone new to the organization. Tag issues that you think are good for first-time contributors as »Junior jobs«, but don’t use them as project ideas, use them as warm-ups and to select your interns.

I ask everyone to help with ownCloud’s Project ideas page. Let’s make sure each project obeys the three laws 😉

If you have questions concerning GSoC and other student/internship programs at ownCloud, contact ownCloud community manager Jos (@jospoortvliet) and organizers Jan (@jancborchardt) and Thomas (@DeepDiver1975).