We're getting some commons questions regarding GSOC, which boil down to "how do I write a successful application". I've taken the common starting point and generalised my comments, questions and suggestions in the hope of helping those in the crunch. This will also go on the Kamaelia website linked from the GSOC pages. As such this is written on the assumption the reader is someone interested in putting in a GSOC application.

> I want to write a simple kamaelia based [....] for Google Summer of Code,

That's a very clear, definite, good statement. It's incredibly simple to get a hold of, so the questions really arise around "what sort of look/feel do you want to have", and "how do you want the [...] to work" and "how do you want communication between [...] to work" as well as "how do you plan to maintain persistent information as well as dynamic (maybe shared) state". (if any)

If you've sent existing code, this helps a lot with evaluating your idea, especially if it relates directly to your idea. Really, this boosts your application likelihood of acceptance dramatically.

Some general points:

• You need a mechanism for handling initialisation of the system and activities using the system.
• You may need to think about the transition from initialisation to the normal operation. (eg login vs logged in)
• You'll need to think how you manage global state (managing the model)
• You'll need to think how you manage specific state (managing interactions)
• You may need to think about file/definition formats
• If the system is multiuser, with interactions, you'll need to define that mechanism. That could be a protocol, use a pre-existing protocol, or just a mechanism for forwarding internal messages.
• You may want to consider user to user interactions vs global vs localised (eg talking in a room)
• You will need to think how existing components can assist you.

Regarding how you go about development, some points:

• First of all think "what's the simplest possible version that would work?" (single windows GUI, single web page, single screen, single ...)
• Then consider how you extend it in each of the possible directions you're thinking of going, growing organically. (this makes it easier to track your development)
• Consider something really cool as a possible next step, after all, things may be simpler than you expect.

> The system will [...] and [...] and [...] and put [...] and [...] into a [......]

Consider some of the of the implications for each thing you suggest. Do components already exist that can support it? (eg {SQL, webcam, ardunio, twistedintergration} components don't *at present* exist, but would be useful). Recognising what's missing from the component set and how your project helps grow the project is important. Both for us, and for you (since creating components is kinda the point of these projects :). You'll need to think ho your new components will operate and how they'll be used. However DON'T overengineer or think "I'll do this in case someone needs it". If you don't need it, leave it out. If you need it, put it in. You can however sometimes make your life easier by generalisation. Tease these aspects out in your application.

Finally, you need to put the whole thing into the application template covering the various areas we need to assess the project:

• Short one line of what the task is designed to achieve/create.
• A practical, clear result of what will be possible as a result of achieving this task. This is best described in the case of a user story.
• The context in which this task sits. Has this task any history? Is it the result of any previous tasks - either within the project or outside.
• What benefits will be gained by working on this task, and achieving its goals? Speculative as well as certained/realistically expected benefits are valid here.

Regarding the actual application template which is here:

• http://kamaelia.sourceforge.net/SummerOfCode2006Template (yes, this is the same template :-)
  

Some key things:

• We expect you to divide the project deliverables up into two categories "will deliver" and "given sufficient time".
• The Project Details section is where you get to describe lots of the things I raise in terms of questions above. The application character count limit though is worth bearing in mind. (ie detailed, but not too ott maybe)
• Project Schedule is really a guestimate of what you think you will have done by when. It will probably be wrong, but by listing it we can see if you're way ahead of schedule (which can be good - if you have a project with lots of scope for growth - which you do), or if you're really behind, in which case we can re-evaluate the schedule if its for good reasons.
  Key things to think of:
• What do you think you will have done by the mid term evals. For that think "what will I get done by July".
• What do you have confidence of getting done between then and mid-august.

Finally, bear in mind we won't be able to take all applicants, but want to take good applications. If you follow this advice you have a much better chance of success.