This page is work in progress for the upcoming GSOC 2018
Google Summer of Code
This year the Scala team applied again for the Google Summer of Code program to work with enthusiastic students on challenging Scala projects
This page provides a list of project ideas. The suggestions are only a starting point for students. We expect students to explore the ideas in much more detail, preferably with their own suggestions and detailed plans on how they want to proceed. Don’t feel constrained by the provided list! We welcome any of your own challenging ideas, but make sure that the proposed project satisfies the main requirements mentioned below.
How to get involved
The best place to propose and discuss your proposals is our “contributors” discussion forum. This way you will get quickly responses from the whole Scala community.
Previous Summer of Code
Here are some project ideas. The list is non-binding and any reasonable project related to Scala that is proposed by a student will be thoroughly reviewed.
Mill Build Tool
Mill is a new Scala build tool, inspired by CBT and Bazel, which aims to be a full substitute for Scala’s venerable SBT. Building upon the principles laid out here and here, Mill aims to be dramatically simpler than current build tools both inside and outside the Scala community while still preserving the rich functionality people expect from a build tool.
This is a catch-all header for multiple possible Mill-related projects, whose exact scope will be finalized closer to the GSOC date
Supervised by @lihaoyi
Scalafix in the editor
Scalafix is a linting and refactoring tool, which aims to help automate migration between different Scala compiler and library versions. Currently, the primary way to interact with Scalafix is in batch mode through a command-line interface. However, many users have requested the ability to use Scalafix interactively through an editor.
A proof-of-concept integration running Scalafix from VS Code through the Language Server Protocol is already working. Many popular IDE refactorings like “Move class” and “Organize imports” are missing, however.
The scope of this GSOC project would be to implement new Scalafix refactoring rules to be used from an editor. The project can start small with simple refactorings, and gradually step up as progress happens. Scalafix is a fast moving project, so you will be working in a codebase with multiple contributors.
Supervised by @olafurpg
scalajs-bundler provides useful features with a high level of configurability, making it easier for Scala.js developers to use NPM packages. However, several important requests haven’t been fulfilled yet: moving the parts that fetch NPM packages to a separate sbt plugin, making it possible to use scalajs-bundler without sbt, documenting how to get a super productive development setup with fast hot-reloading, etc. The GSOC project consists in tackling all scalajs-bundler remaining issues for a 1.0 version.
Supervised by @julienrf.
CBT support for Play Framework
Implement everything necessary to have a smooth development experience with Play framework and cbt, e.g. restarting the server on change, bundling/minimizing js/css, integration with scalajs. Take guidance from sbt plugin.
Supervised by @cvogt.
CBT Coursier integration
Supervised by @cvogt.
CBT Ticket hunt
Bring down these open tickets for cbt by picking some of the most urgent or interesting ones.
Supervised by @cvogt.
Debugger integration for Scala Native
Scala Native is an optimizing ahead-of-time compiler for Scala. It’s implemented in Scala and generates optimized LLVM IR for the whole program. In this project you’re going add support for LLVM source-level debugging information to the compiler toolchain. This information is necessary to make external debuggers such as LLDB and GDB work with Scala Native applications.
Supervised by @densh
Windows support for Scala Native
Scala Native started as a *nix-only toolchain. A number of major APIs such as files, sockets and threads are implemented on top of POSIX APIs. This poses major challenges in porting the toolchain to Windows. In this project you’re going to continue working on the Windows port of Scala Native based on prior work by @muxanick.
Supervised by @densh
Binding generator for Scala Native
Scala Native provides bindings for several C and POSIX APIs out of the box. To help complete and maintain the list of supported APIs as well as seamlessly use 3rd party native libraries support for automatically generating bindings is needed. The goal is to create a Scala Native program that parses C header files using libclang and generates a Scala Native API as well as an sbt plugin to use the binding generator in a project.
A previous proof-of-concept may serve as a starting point.
Supervised by @jonas
Web-based test UI for Bloop
Supervised by @Duhemm.
The Scala REPL is a tool for evaluating expressions. This project is going to aim at making the REPL more modern and easier for programmers to use. We’re going to work on features like multi-line editing or watch variables that update as you work on your program. We’re going to start small and go from there.
Supervised by @marialivia16.
Link to the corresponding code repository, if relevant.
Supervised by @username.
Requirements and Guidelines
General Student Application Requirements
This is the seventh time the Scala project has applied to the Summer of Code, and from previous years’ experience, increased popularity of the language and stories of other mentor organizations we expect a high number of applications. First, be aware of the following:
- Make sure that you understand, fulfill and agree to the general Google Summer of Code rules
- The work done during GSoC requires some discipline as you have to plan your day-to-day activity by yourself. Nevertheless, you can expect regular contact with your mentors both via the usual means of communication for you project as well as personal guidance via email, chat or phone. The mentor is there for you in case you get stuck or need some guidance during your 3 month coding project.
- The official SoC timetable mentions May 14 as the official start of coding. If you have time, you are encouraged to research your proposals even before that (and definitely learn the basics of Scala, if you haven’t done that already).
Student Application Guidelines
- Student proposals should be very specific. We want to see evidence that you can succeed in the project. Applications with one-liners and general descriptions definitely won’t make the cut.
- Because of the nature of our projects students must have some knowledge of the Scala language. Applicants with Scala programming experience will be preferred. Alternatively, experience with functional programming could suffice, but in your application we want to see evidence that you can quickly be productive in Scala.
- You can think of Google Summer of Code as a kind of independent internship. Therefore, we expect you to work full-time during the duration. Applicants with other time commitments are unlikely to be selected. From our previous experience we know that students’ finishing their studies (either Bachelor, Master of PhD) are likely to be overwhelmed by their final work, so please don’t be too optimistic and carefully plan your time for the project.
- If you are unsure whether your proposal is suitable, feel free to discuss it on our “contributors” discussion forum. We have many community members on our mailing list who will quickly answer any of your questions regarding the project. Mentors are also constantly monitoring the mailing list. Don’t be afraid to ask questions. We’d love to help you out!
General Proposal Requirements
The proposal will be submitted via the standard web-interface at https://summerofcode.withgoogle.com/, therefore plain text is the best way to go. We expect your application to be in the range of 700-1500 words. Anything less than that will probably not contain enough information for us to determine whether or not you are the right person for the job.
Your proposal should contain at least the following information, but feel free to include anything that you think is relevant:
- Please include your name (weird as it may be, people do forget it)
- Title of your proposal
- Abstract of your proposal
- Detailed description of your idea including explanation on why it is innovative (maybe you already have a prototype?), what contribution do you expect to make to the Scala community and why do you think your project is needed. A rough plan of your development and possible architecture sketches.
- Description of previous work, existing solutions (links to prototypes or references are more than welcome!)
- Write us about yourself and convince that you are the right
person for the job (linking to your resume/CV is good but not
- Mention the details of your academic studies, any previous work, internships
- Any relevant skills that will help you to achieve the goal (programming languages, frameworks)?
- Any previous open-source projects (or even previous GSoC) you have contributed to?
- Do you plan to have any other commitments during SoC that may affect you work? Any vacations/holidays planned? Please be specific as much as you can.
- If you apply to more than one GSoC project, especially if you also apply for a project in another organization, specify which project you prefer. In case two organizations choose to accept your applications, we can then give you the project that is most important to you. Preferring the project of another organization will not influence our decision whether to accept your application.
- Contact details (very important!)