From MozillaWiki
Jump to: navigation, search

This page lists all the Google Summer of Code 2014 projects with confirmed mentors, and which have been approved by the SoC administrator. New suggestions can be made on the Brainstorming page. Do not edit this page yourself; contact Florian for edits.

Potential students: you may choose from the list below, but you do not have to. Feel free to submit a proposal for your own idea. However, before you do so, see the guidelines for good ideas. You can also discuss your ideas or application in the #introduction channel on IRC: irc:// . Your idea will have a significantly greater chance of being chosen if you can find an existing member of the Mozilla community who is willing to evaluate or mentor it. (You should name that person in your application.)

In addition to the specifically-named projects below, we have also tagged a number of bugs in Bugzilla with the keyword student-project. However, as the idea of a "student project" is wider than just the Summer of Code, students looking through the list will need to decide whether any particular bug listed there is actually the right size and scope for Summer of Code.

Application Advice

You should do the following:

  • Talk to the mentor. Contact details are on this page; if all you have is a nickname, get on IRC and try and contact them.
  • Read the GSoC Student Guide and follow its advice.
  • Read How Not To Apply For Summer Of Code and avoid doing the things listed there.
  • Read our examples of good applications: 1, 2, 3.
  • Apply on the GSoC site (note that we have an application template).
  • It is entirely acceptable to apply for 2 or 3 projects, if more than one catches your eye; if the applications are high quality, that can improve your chances. However, more than 3 seems like spam.

Note that if a project suggests it would be helpful to know XUL (Mozilla's user interface description language), you may be able to get away with learning on the job. Don't be put off from applying if the project otherwise looks right for you.

Questions about individual projects are best addressed to the potential mentor of that project. These should be listed in the table below. If you want to contact a mentor and contact details are not here, ask people in the #introduction channel on IRC: irc:// If you have questions of any other sort, send mail to Florian and Gerv. We will try and respond as soon as possible and get your questions directed to the right person. Please allow at least 48 hours for a reply.


Title Details Skills Needed Reporter Mentor(s) Comments

Firefox OS / Boot2Gecko

Title Details Skills Needed Reporter Mentor(s) Comments
A Desktop Environment based on B2G The goal is to package b2g desktop as an alternative to desktop environments like Gnome or KDE. Familiarity with packaging systems for popular linux distributions (deb, rmp, yum). Support for some APIs will also need to be implemented to provide an acceptable experience, like the Wifi api. Some gecko knowledge is a plus but not an absolute requirement.

Steps would be:

  • Package b2g desktop as a Desktop Environment.
  • Fix/add missing APIs in gecko.
  • Tune Gaia's tablet UI to be nice to use with a keyboard.
Fabrice Desré Fabrice Desré
Battery Included B2G Build Environment in a VM (FoxBox). The goal is to help potential contributor/ROM maker bootstrap their B2G/gecko/gaia dev environment without burden. Especially important for web developer (gaia). Current project already able to configure a GUI environment with Firefox Nightly, export USB/repository PATH with host OS. Familiarity with bash and unix system configuration. Vagrant or provisioning tools such as puppet/chef/salt is plus. Some helper scripts will also need to be implemented to provide an acceptable experience.

Project Site

Fred Lin

Greg Weng

Fred Lin

Greg Weng

Mozilla Platform (Gecko)

Title Details Skills Needed Reporter Mentor(s) Comments
Provide proper WebRTC testing and integration on BSD systems As of now, WebRTC is enabled by default on BSD systems but needs more testing and bugfixes in real-life situations to make it rock-solid and usable, on par with Tier1 platforms. The WebRTC code that already landed for *BSD needs proper integration upstream too. Good knowledge of C and IPC. Gaston Gaston Tasks would include finishing the sndio backend for OpenBSD (Bug #911450), upstreaming to the patches already commited to mozilla (#807492 and its dependencies), and make sure the webrtc integration tests also run fine on major BSDs. The project will be successful if an A/V call can be done from firefox nightly from a BSD to another firefox instance on Linux or Windows, and also in-between different BSDs, using the tests from and


Title Details Skills Needed Reporter Mentor(s) Comments


Title Details Skills Needed Reporter Mentor(s) Comments
WebRTC support Goal: Support voice/video chat using WebRTC via XMPP (and potentially other protocols).

Add voice and video chat to Instantbird via WebRTC. This will involve adding APIs to allow protocols to prepare a voice/video connection to a contact and some basic user interface to show the video feed.

JavaScript, XPCOM, XUL Florian Quèze Benedikt Pfeifer XEP-0320, XEP-0338, XEP-0339, XEP-0343 for XMPP
FileLinks in IMs / File transfer Goal: File transfers that work reliably for every protocol.

The Thunderbird Filelink feature allows users to upload attachments to an online storage service, replacing the email attachment with a link. This existing code could be used to implement file transfer. While some protocols support file transfer directly, this approach would provide a fallback that should always work. Designing and implementing a good UI frontend would also be required.

JavaScript, XPCOM, XUL Florian Quèze aleth The frontend should be flexible enough to be able to handle other file transfer methods when they are implemented, e.g. WebRTC for XMPP or DCC for IRC.
Improve JS-XMPP Goal: Ease working with the JavaScript XMPP implementation and implement new features.

Include better syntax for XML handling, implementing handling of MUCs and other features. Feature-parity with libpurple's XMPP support is one of the prerequisites for replacing the libpurple XMPP plug-in that is currently used. One possible improvement would be to support voice and video calls between a JS-XMPP client and a Jingle client using WebRTC.

JavaScript, XPCOM Florian Quèze Patrick Cloke
Additional JavaScript protocol plug-ins Goal: Implement new protocol plug-ins in JavaScript, or create more stable implementations of existing ones.

Instantbird supports protocol plugins implemented in JavaScript. The student will either add support for new protocols in Instantbird (if so, explain why this protocol matters) or reimplement in JavaScript an existing protocol that is poorly supported by libpurple (if so, explain what will be better supported in the new implementation, or why the current implementation is not adequate). The student working on new protocols should take every opportunity to improve the code and APIs shared by all JS protocol plugins.

JavaScript, XPCOM, maybe js-ctypes Patrick Cloke Patrick Cloke IRC, XMPP, Twitter and Yahoo have already been implemented in JavaScript and should not be considered; Some base code exists for OSCAR (AIM/ICQ); SIP, Bonjour and OSCAR are probably the most wanted protocols.


Title Details Skills Needed Reporter Mentor(s) Comments
Make Lightning Fast The Lightning Extension has a few performance problems, especially with lots of calendars. Now that the Gecko Profiler works in Thunderbird Daily, its a great time to harness its power and improve Lightning's performance. A Student working on this project should:
  1. Browse Bugzilla to get an overview of reported performance problems.
  2. Use the Gecko Profiler to identify performance bottlenecks, for example occurrence calculation.
  3. Propose a method to improve performance in a way that would move the bottleneck elsewhere and discuss with mentor.
  4. Fix the bottleneck.
  5. Continue with (2).

Depending on remaining time and student experience, adding performance tests to Lightning would be a bonus.

Javascript; Python and make for perf tests Philipp (:Fallen) Ludovic (:ludovic) / Mohit(:redDragon) A student applying for this project should be able to work with large codebases. Getting familiar with the Lightning source code early improves chances of being accepted. Look for Fallen on / #calendar if you need help getting started.
Improve Calendar Backends Lightning has historically supported two modes for calendar providers: cached and uncached. In uncached mode, each request is directly relayed to the remote end, causing a lot of traffic. Therefore, cached mode was introduced, which is close to a "real" synchronization, where only changes are transferred. In the future it would be nice to use cached mode exclusively. To do so, there need to be some changes in the backend. This project consists of a combination of the following bugs, depending on time and student skill:
  • Finish the patch I started for async storage (bug 501689)
  • Move calendar metadata from the provider inteface to the item interface (no bug yet)
  • Turn the ICS calendar into a cache-only provider (bug 780992)
  • Turn the CalDAV calendar into a cache-only provider (no bug yet)
Javascript, SQL, Philipp (:Fallen) Mohit(:redDragon) As these changes will partially require some migration steps, it is important to write unit tests for the code produced during the Summer of Code. Not all of the mentioned bugs need to be fixed for passing mid-terms and finals, please read through the bugs and consult with mentor or reporter with your suggestion when applying.
Update Lightning Invitations to Latest Specification iTip Standard allows different email clients and servers to schedule meetings based on email messages. The scheduling extension to CalDAV RFC has become a full spec now. However Lightning's invitation processing implementation lags behind. A student working on this would be expected to:
  • Explore some of the bugs related to the iTiP processor.
  • write a few mozmill tests on various invitation scenarios
  • analyse the current itip interfaces and check what can be improved, especially keeping the caldav scheduling rfc in mind
  • udpate the caldav provider to the latest spec chunk by chunk
Javascript, SQL, Philipp (:Fallen) Mohit(:redDragon) / Philipp(:Fallen) The work involved will be significantly more and would require deep analysis of the calendar code base. However, the end-product would bring cheers to a lot of users and end complaints of lightning not functioning with a particular server. As a start dive into the RFC and the buglist to find out some of the easy cases which can be solved to gauge the difficulty of the project.


Title Details Skills Needed Reporter Mentor(s) Comments
Add markdown support to Bugzilla. bug 330707. Currently Bugzilla only supports plain text for comments. Adding support for markdown allows for rich text formatting in a way which degrades nicely to plain text. Perl Byron Jones Byron Jones I have a working proof of concept which performs the markdown to html conversion in a way which is compatible with Bugzilla's existing markup. This needs to be tidied up and integrated a all points where comments are created and displayed (web UI and email). (more information)
Migrate from YUI2 to YUI3. bug 453268 Bugzilla currently uses YUI2 as its widget library. We need to migrate to YUI3 as version 2 is no longer maintained. JavaScript Byron Jones Byron Jones Yahoo started the work however progress has stalled.


Title Details Skills Needed Reporter Mentor(s) Comments
Implement speech synthesis on desktop Firefox We have an implementation of speech synthesis via the Web Speech API. Currently, only Firefox OS devices have an engine via SVOX Pico. It would be good to have speech synthesis supported on Firefox for desktop OSs as well. Also, the current implementation should be tested and updated to interop with other browsers that support speech synthesis, such as Safari and Chrome. Knowledge of C/C++, and perhaps Objective C. eeejay eeejay (and probably smaug doing the bulk of the reviewing). We should also explore how far along in the specs errata we could go.

Automation & Tools

Title Details Skills Needed Reporter Mentor(s) Comments
Add structured logging to mochitest Traditionally at Mozilla, test harnesses have written test results as arbitrary strings to stdout. Other tools that want to gather data about test runs are forced to parse the entire logfile produced by capturing stdout, and using a set of regexes on each line in order to identify test results, test summaries, and other items of interest.

We'd like to replace this very inefficient approach to test logging with a more robust mechanism: "structured logging". In this approach, a test harness writes a file containing data in JSON format for each test event that needs to be logged, as well as producing human-readable data on stdout. Other tools can then easily parse the JSON data when they want to know what happened during the test run.

We have developed the structured logging format, and started using a Python implementation for a small subset of our tests. Now we would like to use it with our Mochitest harness, which is used for running many regression tests for the Gecko browser engine. This harness has external Python components and Javascript components running in the browser, both of which need to write structured log messages to the same file in (approximately) chronological order. When run in continuous integration, the structured log file must be uploaded at the end of the test run as a test artifact.

See meta bug at bug 916295; actionable bugs for this project are bug 916265 and bug 886570.

JavaScript, Python Jonathan Griffin James Graham Detailed Outline
Mochitest failure investigator We spent countless hours investigating tests and managing known failures that occur occasionally. In many cases we have investigated test failures and cannot reproduce them while running the test by itself. It has been found that some tests alter the state of Firefox which can cause future tests to behave differently. Some tests are even written to depend on this state change.

To build this tool we need to take a given test failure and work backwards to find its failure point. Starting with the given test failure, we need to start a fresh instance of the browser/profile and verify the single test case passes on it's own. Then we can repeat this process by adding more tests for each run until we find the failure. The most logical way to add tests will be per directory as each directory usually contains tests of similiar behavior. This would be added into the mochitest python harness. Doing so will give people the ability to quickly run this locally and with a small adjustment to our Try server (passing in the correct command line arguments), we can run this on production machines.

JavaScript, Python Joel Maher Joel Maher


Title Details Skills Needed Reporter Mentor(s) Comments
Package Rust in key distributions Having {apt-get,yum} install rust deb packaging / Rust (LLVM appreciated)

Must have demonstrated packaging capabilities (packages in Debian or Ubuntu, bug fixes, etc).

Sylvestre Ledru & Luca Bruno Main issues: & Will focus on Debian/Ubuntu first


Title Details Skills Needed Reporter Mentor(s) Comments
Implement XMLHttpRequest Make common sites using XHR work in Servo. Linux or OS X only; familiarity with XMLHttpRequest; desire to write Rust code (C++ experience helpful) Josh Matthews Josh Matthews In-depth project guidelines


Title Details Skills Needed Reporter Mentor(s) Comments
Mozilla Intellego -- Terminology-driven automatic translation of web sites Intellego is an initiative to develop a machine translation platform from open corpus data, open corpus gathering techniques, and open web services APIs to lower the linguistic accesibility barrier for users and websites and further promote the exploration of freedom of linguistic expression on the web.

This piece of the project will lay the foundational code for Intellego by aiming at the completion of the first key milestone: creating an automatic translation tool for web sites aimed to translate all key source terminology in a site into the target language equivalents. This will be accomplished by scanning the DOM of a site, extracting the translatable text nodes, searching for source terminology matches from within a bilingual termbase, and returning target language terminology within the rendered page. This project will aim to perform these tasks within the Mozilla support sites.

If the student can accomplish the basic scope of the project before the necessary eight weeks, the stretch aim would be to enable the addition of context sensitive retrieval of target terminology.

  • DOM manipulation (JavaScript)
  • Information retrieval
  • XML
  • Understanding of open webservices APIs
  • Python
  • Familiarity with a library used for quickly generating a web UI to a server-side Python script
Jeff Beatty (gueroJeff) Jeff Beatty (gueroJeff)


Title Details Skills Needed Reporter Mentor(s) Comments
Implement Zest recorder and runner Create a Firefox add-on for recording and Running Zest scripts as well as editing them graphically Java Script, knowledge of Firefox add-ons Simon Bennetts Mark Goodwin, Simon Bennetts
Kitherder Kitherder is a web application that is designed to facilitate participation in the Mentorships program. Note that while this program is currently limited to security projects, the goal of KitHerder is to provide the matchmaking and relationship management features required to open the program to the Mozilla community.

The requirements here are driven by the documentation from the mentorship program and it is expected that the system will leverage accounts to reduce the amount of personal data stored in Kitherder, and issue badges using the Mozilla Foundation badge system based on participation criteria.

Goals: To take Kitherder to a level where it can be deployed to allow the matching of mentors and mentees and manage the basic relationship work.
GitHub Source:

Python, HTML, CSS, JavaScript Curtis Koenig Yvan Boily


Title Details Skills Needed Reporter Mentor(s) Comments
Porting key Meemoo modules to NoFlo is a platform for web-hackable creative image/animation apps. is a more-powerful dataflow environment, with hooks to Node.js and Arduino. This project idea involves designing a Canvas 2d library of Noflo components which will allow Meemoo components to be ported as Noflo subgraphs. Proposals should include a generative image (meemoo, processing, or vanilla js + canvas) and a sketch of the graph and low-level 2d drawing components that would be needed.

This idea could be also focused on a data visualization or 2d game. Other Noflo-related proposals welcome.
Solid javascript. Understanding of Dataflow / Flow-Based programming. Forrest Oliphant

Mozilla Science Lab

Title Details Skills Needed Reporter Mentor(s) Comments
Browsercast The goal of this project is to implement an HTML5+Javascript replacement for screencasting and integrate it with a composition tool. A prototype of the playback tool is on GitHub (see this page for a demo and explanation of why we want such a thing), and some useful experiments with composition tools have also been built (see this page for an example). The end result of this project will allow non-specialists to author an HTML5+Javascript slideshow using something like Thimble, add a voiceover, and create something that plays back in the browser (so that search engines and accessibility aids can "see" the content) with a fraction of the data download required by video. Javascript, HTML, CSS; experience with Popcorn and Thimble are useful but not essential. Greg Wilson Greg Wilson
Peer Instruction on the Web Peer instruction (PI) is a teaching technique which alternates between instructor-led Q&A and peer discussion in small groups. It has been proven to reduce failure rates in introductory programming classes (and many other courses), but is not directly supported by existing online learning platforms. The goal of this project is to use WebRTC to create a bimodal real-time voice-and-video chat system to support PI. Mode 1 is broadcast: the instructor transmits audio+video to a large class. Mode 2 is small-group discussion: learners are placed in an all-to-all chat in teams of 2-6. Crucially, the tool allows smooth switching between modes: the instructor can press a button to initiate the small-group discussion, then push another to give groups a 30-second warning, after which they are instantly pulled back into the main class. (See this page for more information.) Such a tool would be useful in other contexts, such as breakout groups for online meetings, but would primarily be intended to bring modern evidence-based teaching practices to web-based learning. WebRTC, Javascript, HTML, CSS, and something (Python, Ruby, JS) for building a simple back end to manage groups. Greg Wilson Greg Wilson