Summer of Code 2012

The XMPP Standards Foundation is applying to be a mentoring organisation for Google Summer of Code 2012. Project ideas are towards the bottom of this page.

Org acceptances haven't been announced yet, the following text is dependent on us getting in.

We're hoping to be participating in the Google Summer of Code for 2012. Other useful resources include:
 * Our GSoC Org Page:
 * The JDev Discussion List: JDEV discussion list
 * The JDev MUC room: [xmpp:jdev@conference.jabber.org?join jdev chatroom]

Feel free to talk or chat with developers at any of the above resources about potential Summer of Code ideas. Also have a look at the ideas list below, and get in touch with potential mentors for any projects that take your fancy.

= Introduction = XMPP is the Extensible Messaging and Presence Protocol, an XML wire protocol for real-time communication that emerged from the Jabber open-source community. Our community is not a single open-source project because it is not focused on a single codebase. Instead, our community is centered around open standards and open protocols. However, even though there are closed-source implementations of XMPP, we still have a strong commitment to open code and there are many free and open-source projects in our community participating in GSoC under the XSF's umbrella.

We have participated in the Summer of Code since its inception and have learned many lessons, among them:
 * We try to choose half a few excellent projects and really focus on them.
 * It is difficult to choose excellent projects, so the more helpful information you can provide, the better.
 * We also try to choose excellent mentors and match students with mentors.
 * We expect regular reporting (via blog) and weekly or near-weekly meetings.
 * We take the Summer of Code very seriously and we expect our students to treat it like a full-time job.

This page lists some potential project ideas that students can work on. This is similar to a "Request for Proposal" process for your summer job. The mentors and other project members have defined these RFPs as a way to help structure the summer work. Many of these projects are are relevant to our overall community. A select team of longtime XMPP developers and former mentors will review all the student proposals and "interview" many of the students so that we can make the best possible choices.

If you have any questions about the XSF's involvement with the Google Summer of Code, please contact Mike Taylor via email or (preferably) IM.

Thanks for your interest, and good luck!

=Before Applying= Read this page, understand the available projects and find one you'd like to do. With the idea below there'll be contact details for possible mentors - contact them, get to know them a bit and let them help you in your application. Several of our projects have associated 'teaser tasks' designed to get you set up with a build environment (where appropriate) and running and testing the application, then writing a small change and getting it reviewed - this gets you used to the way the summer would go for you (and the mentors used to you), and is a great way to get to know if you and the project are a good fit for each other.

=How to Apply= Application instructions are available at the main GSoC site on the XSF's page.

There is an application form available at that page, and you should complete all the parts. Here's some of what you need to include:
 * Some details about you (what code languages you like, what programming courses you've taken, etc.)
 * Results of your preliminary research into the protocols and codebases you might work on
 * Your ideas about how to approach the project, including an outline of what work you think is required, a rough timeline of the work, etc.
 * Possible problems you think you may face

In general, we consider your GSoC project to be a summer job, so try to provide detailed information that will enable us to decide if you deserve to earn the money Google will be paying. Our project ideas are like "RFPs" -- your application is your proposal to get the job. Please treat it seriously. Thanks!

=Project Ideas= There are many possible software applications available to work on under the XSF's umbrella for GSoC - here are some ideas for different projects.

Swift
Swift's goal is to provide an IM client that does things 'right' with a good user interface, solid quality, and standards-compliance. This year there are again several opportunities for working on new functionality in Swift. This page lists some of the high priority tasks the Swift development team has. If you're interested in any of these (or other) Swift ideas, please jump into the [xmpp:swift@rooms.swift.im?join swift@rooms.swift.im] room and chat it over with Remko and Kev. Swift is a C++ project, so C++ proficiency is required, with either knowledge of or willingness to learn about unit testing (and ideally test-driven development).

Conversation History

 * Summary: Implement all aspects of keeping conversation history, both local and remote.
 * Difficulty: Easy-Medium
 * Details: Swift doesn't currently store any transcripts. A student would likely start by producing a prototype user interface for accessing chat history, then write the library code to access a remote archive, and plug these together and finally work on a local archive. This is likely to be a very satisfying project, with enough challenge to be interesting, but not so much that it's frustrating - plus it's a very popular feature request.

VoIP Support

 * Summary: Implement support for voice (and optionally video) communication.
 * Difficulty: Medium/Hard. This project requires XMPP and VoIP protocol work.
 * Details
 * Implement signaling using the Jingle XMPP protocol, extending the File Transfer support from last year.
 * Implement firewall traversal (using standard traversal protocols: ICE, TURN, ...)
 * Implement real-time-protocol (using standard RTP)
 * Investigate frameworks for hardware interaction & media encoding/decoding.

Constrained Swift

 * Summary: Implement support for XMPP protocols that are targeted towards (resource-)constrained environments
 * Difficulty: Medium
 * Details: XMPP provides protocols for dealing with 'constrained' environments: session resumption and incremental roster retrieval for bandwidth-constrained situations, BOSH for places where keeping a long-lived connection is hard, SIFT for limiting the amount of incoming traffic, Link-local for serverless locations, ... Support for these protocols is not only interesting when XMPP software is used in these particular situations, it also makes the client faster and more reliable in general. In this project, you will study the protocols that can improve Swift in these situations (Session Management, BOSH, SIFT, Link-local, ...), and extend Swift (and the underlying Swiften XMPP library) to support these use cases.

Multi-account Support

 * Summary: Implement support for multiple accounts
 * Difficulty: Medium
 * Details: Swift currently only supports one account at a time. Supporting multiple accounts is one of the most requested features for Swift. Although this is technically not hard to implement, it involves quite some design decisions on providing a clear and easy-to-understand user interface. This project is about designing a good user interface for multiple account support.

Multi-resource support

 * Summary: Implement and standardize techniques & protocols for supporting being connected with multiple clients simultaneously.
 * Difficulty: Medium
 * Details: Although XMPP has supported multiple simultaneously connected clients from the start, the user experience is in practice seldom what a user would expect. This has not been a big problem up until recently, since most people tend to connect with only one client at the same time. These days, however, people are constantly going back and forth between their always-on mobile IM client and their desktop. Enabling a good user experience for this requires new protocols and techniques for transferring conversations between devices, ... This project is about implementing these protocols to streamline the use case of multiple resources

User activity/profile

 * Summary: Implement social aspects in user profiles
 * Difficulty: Easy
 * Details: XMPP (Through the PEP offerings) supports many social-ish data structures, including a user's location, their mood and their current activity. A student working on this project would add support for these protocols to Swiften, and build a 'user profile' UI around these data to give a view on a contact's state that goes beyond the usual 'Name, address, telephone number' profile. A nice touch would be adding map overlays to the location data, so you could see where all your friends were on a map together, and the suchlike.