This is Mozilla's list of green-lit project proposals for the 2018 Google Summer of Code.
Are you a student looking to apply to GSoC with Mozilla? You're in the right place. This page lists all the confirmmed Google Summer of Code projects. New suggestions can be made on the Brainstorming page. Do not edit this page yourself; contact Mike Hoye or Florian for edits.
If you're interested in participating in Mozilla's GSoC program, you can choose from the list below, but you do not have to. You can submit a proposal for your own idea. You should look at the guidelines, though, and discuss your ideas or application in the #introduction channel on IRC.Mozilla.org. This is important, as GSoC projects must have a supporting member of the Mozilla community to evaluate and mentor them, named in the application.
You should do the following:
- Talk to the mentor. Contact details are on this page; if all you have is a nickname, reach out to them on IRC.
- 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. Applying to more than that will seem like spam.
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://irc.mozilla.org/#introduction. If you have questions of any other sort, send mail to Mike Hoye. He will try and respond promptly and direct your questions to the right person.
- The following projects have been tentatively greenlit, pending milestone clarifications.
2018 Project List
|Title||Details||Skills Needed||Reporter||Mentor(s)||Additional Comments|
|D3D11 backend for gfx-rs HAL||gfx-rs is a graphics abstraction library written in Rust and currently used for prototyping and investigation of Vulkan Portability and WebGPU by Mozilla. The Hardware Abstraction Layer (HAL) of gfx-rs currently supports Vulkan, D3D12, Metal, and OpenGL. We want it to be powering WebRender for Firefox Quantum and Servo, and since WebRender currently runs on D3D11 (through Angle), we need to provide a native D3D11 backend. The implementation can be based off the existing D3D11 code in gfx-rs pre-HAL, and the main challenge is porting the code, optimizing, and ensuring it can successfully run the reference test suite.||Candidates should be familiar with Rust as well as low-level graphics development. Not having D3D11-specific experience is acceptable, given the willingness to learn it and a properly setup Windows development environment.||Dzmitry Malyshau (Mozilla)||Dzmitry Malyshau (Mozilla)|| Proposal Timeline:
|Servo: Prototype ways of splitting up the script crate||Servo is a web rendering engine written in Rust. One specific module contains a huge amount of code that is expensive to compile all at once. This project is intended to explore ways of splitting it into separate modules to achieve better build performance without breaking the complex set of interdependencies that exist in the code.||Candidates should be familiar with Rust, in particular using it in projects made of multiple crates and relying on features like traits and associated types.||Josh Matthews (Mozilla)||Josh Matthews (Mozilla)||Full project description page|
|web-platform-tests: Improve test manifest workflow and performance||web-platform-tests is a project for writing a cross-browser test suite, which is used across all major browser engines. The list of tests is stored in a JSON manifest file which is slow to generate and which we currently check in to the Firefox repo. These things create a poor developer experience. The goal of the project is to move to a system where the manifest is downloaded on demand for Firefox developers, and then to explore ways to speed up manifest generation such as employing parallelism or moving performance hotspots to Rust.||Candidates should be confident programming in Python.||James Graham (Mozilla)||James Graham (Mozilla)||Full project description page|
See WebAssemblyStudio repository for new version of the WasmFiddle.
Students will contribute to: extending the functionality of the notebook; making the notebook code more robust and performant; helping to shape the user experience; and creating example notebooks.
|JS; HTML; CSS; React/Redux; familiarity with at least one scientific computing language preferred (ex: MATLAB, Mathematica, Julia, Numpy/Scipy, R, etc). Science/math background is a major plus.||Brendan Colloran (firstname.lastname@example.org)||Brendan Colloran (email@example.com)||In addition to helping to build the notebook, actively dogfooding it will be an essential part of our work. This means that students with a scientific and/or applied math background will be encouraged to build example notebooks that demonstrate visualizations, simulations, data analyses, etc., on topics of their choosing. In addition to mentoring students on software development, we will provide mentorship in scientific computing and data science.|
|Automatically detect web compatibility issues (autowebcompat)||Build a tool to automatically detect web compatibility issues using machine learning tools.||Python (knowing Keras or having experience with machine learning is a plus)||Marco (:marco) (Mozilla)||Marco (:marco) (Mozilla)||The project involves collecting data (screenshots of websites in different browsers), labeling it, training a neural network to automatically detect when a website is rendered differently in different browsers.|
|Autogeneration of style structs in Servo's style system||Prototype how to run cbindgen on Servo's style system values module to auto-generate style struct definitions for C++ and Rust, which would enable the removal of 5k+ lines of unsafe and slow Rust <-> C++ conversion code. This can be done on a per-struct basis, so prototyping the general mechanism with a simple one like color would be the first step, migrating more and more as time goes on.||Primarily Rust (though no need to be really advanced), probably a bit Python for build system integration, and basic C++ since it needs to get generated.||emilio||emilio||Full project description|
|Timely Security Analytics|| InfoSec uses the Mozilla Defense Platform, MozDef to aggregate logs and alert on time series. This project seeks to create a structure for extract, transform, load operations (ETL) to process these time series events using MapReduce (Apache Spark). The project will have three milestones:
For more information see: Google Doc
 Michal Purzynski :michal` (mozilla)
|This project represents a unique opportunity to work on one of the only fully open source SIEM projects in the community -- MozDef. The MozDef platform is running in production at Mozilla and ingests 14,000,000 events per year. The current alert system uses time series rules to generate meaningful alerts for the infosec team and Mozilla's Operations Center. We're hoping that with the help of qualified student(s) this rich data set can also generate alerts using basic machine learning techniques. This is a unique opportunity to work on aggregation of disparate sources of data: NSM, CloudTrail, etc. into spark. Real-time alerts over large quantities of data.|
|C++ Static Analysis||Add new checkers specific to our base code.||Strong C++ experience and clang infrastructure.||Sylvestre||Andi||In order to tackle issues during the development phase, Mozilla wrote a bunch of static analyzers checkers based on clang-tidy. In this project, we will focus on writing more checkers (either generic to C/C++ or specific to Gecko programming patterns).|
|TLS scanning in Rust for Mozilla TLS Observatory|| Mozilla TLS Observatory is a hosted service that provides hindsight and compliance checking on the configuration of HTTPS servers. The goal of this project is to rewrite the ciphersuite scanner in Rust to support scanning TLS 1.3, but also maintain the ability to scan old version of TLS, all the way back to SSL2.0. This will likely require interacting with older versions of OpenSSL.
Performance is also a strong requirement for this project. TLS Observatory scans thousands of sites every hour, and saving precious seconds on each scans make a big difference to the infrastructure.
Finally, because this is a replacement of Cipherscan, this project requires maintaining backward compatibility with integrations that rely on specific flags, or json outputs.
The final goal is to ship this project into the production infrastructure of TLS Observatory.
|Programming skills in C and Rust. Strong understanding of TLS and micro-services architectures.||Julien Vehent||Julien Vehent|| Cipherscan is the measuring tool that Mozilla uses to keep on eye on TLS configurations across the Internet. It is instrumental to the TLS guidelines work we do over at Server Side TLS. This project will directly contribute to tooling that operators rely on worldwide to keep their websites secure.
This is a fairly complex project that requires programming, networking and cryptography skills. Candidates will require skills in all three areas to succeed (GSoC is not long enough to learn them on the go).
|A/B testing framework for Android||In Firefox for Android we are using an A/B testing framework based on "Switchboard". We want to re-write this framework in Kotlin as a standalone-library that can be used in our other Android apps.||Android, Java, Kotlin||Sebastian Kaspari (:sebastian)||Sebastian Kaspari (:sebastian)|| See more detailed project description:
List of issues/tasks:
|Native Android XML support in Mozilla localization infrastrucure||Mozilla develops software for various platforms, one of which is Android. Localizations of Android apps are typically stored in the XML dialect, which is not supported by Pontoon, Mozilla's localization tool. That means our localization process is unnecessarily complicated, because we need to convert between Android XML files and files supported by our localization tools. Your task will be to solve this problem by writing translation quality checks for compare-locales and adding support for the XML dialect to Pontoon.||Python||Matjaž Horvat (Mozilla)||Axel Hecht (Mozilla)|