GSoC Instructions

Our project has historically allowed a wide variety of applications on topics both solicited and unsolicited, and we do not intend to change this policy. However, every application must meet some criteria, which we have set out here, to be considered.

Applicant credentials

The application should demonstrate (by reference to previous projects, completed coursework, job experience, description, etc.) that the applicant possesses the following skills:

• Competence in programming in the applicable language for the task at hand. For Pidgin, Finch, or libpurple themselves this means C.
• An ability to effectively communicate, via written language, technical topics and precise thoughts.

Project description

Every application must describe the project the applicant intends to pursue. While this may contain information from our ideas page or other online sources, it must primarily consist of the applicant’s own words and plans. It should include:

• A description of the general task to be completed
• The applicant’s estimate of the skills required to complete the task, particularly noting those skills that will need to be developed during the course of the project. Note that it is absolutely fine if the applicant, for example, is unfamiliar with a library or protocol necessary to complete the project, if they can demonstrate that they understand what needs to be learned and how that learning will be approached.
• A general timeline of the project as envisioned, with a breakdown including major milestones (e.g., “necessary UI infrastructure”, “supporting changes to protocol X”, “draft specification for Y”).

Note that project applications need not be for projects from our ideas page. If you have a great idea for a project, that’s fine, propose it! Just be sure to describe what it is, why you can do it, and how you plan to accomplish it within the summer.

External factors

If a project or applicant has any external factors that the project should be aware of, those must be spelled out explicitly along with an explanation of how the project will be affected if those factors fail to come through or otherwise interfere. For example, if a project depends on a third-party library that is known to have limitations that may affect the success of the project, the application should describe those limitations and how they will be mitigated if they get in the way. Something like this would be appropriate:

I plan to use libfoo 3.1 to implement a foo protocol plugin, but it doesn’t yet support a pluggable main loop, which libpurple requires. The libfoo developers intend to address that, but if they do not address it by midsummer, I will implement it myself and submit a patch upstream. If this happens, I probably will not be able to complete the extended frobnicator API in libpurple, but the project will still successfully speak the foo protocol by the end of the summer.

Any potential major demands on the student’s time MUST be included, such as: finals (we know that not all school schedules line up with SoC precisely, and this will absolutely not disqualify an application!), scheduled vacations or holidays, existing summer commitments for work or school, potentially conflicting job applications, etc.

Improving your chances

After submitting a great proposal, PLEASE join us on in one of our chat rooms and discuss your ideas with the community. Experience has shown that students who are involved before the Summer of Code starts are more likely to stick with it and make good progress during the summer. In addition, this provides us more and better information about how you work with other developers and what your skill set is. You can greatly improve your chances of selection by engaging with the community early.