Google Summer of Code with Kotlin 2025

1. Check out the GSoC FAQ and the program announcement.

2. Familiarize yourself with the Kotlin language:

   • The official Kotlin website is a great place to start.

   • Read the official documentation to get a better understanding of the language.

   • Take a look at the Kotlin courses on JetBrains Academy or the Android team's Training options.

   • Follow the Kotlin X or Kotlin Bluesky accounts to stay up to date on the latest news and developments.

   • Check out the Kotlin YouTube channel for tutorials, tips, and the latest updates.

3. Get to know the Kotlin open source community:

   • Explore the general Kotlin contribution guidelines.

   • Join the Kotlin Slack channel to connect with other developers and get help with any questions you may have.

   • Join the #gsoc channel to ask questions and get support from the GSoC team.

1. Check out the project ideas and select the one you would like to work on.

2. If you are not familiar with Kotlin, read the introductory info on the Kotlin website.

3. Refer to the GSoC contributor guidelines.

4. Apply via the GSoC website.

   • We suggest that you write a working code sample relevant to the proposed project. You can also show us any code sample that you are particularly proud of.

   • Describe why you are interested in Kotlin and your experience with it.

   • If you participate in open source projects, please reference your contribution history.

   • If you have a GitHub, Twitter account, blog, or portfolio of technical or scientific publications, please reference them as well.

   • Disclose any conflicts with the GSoC timeline due to other commitments, such as exams and vacations.

Thank you! We look forward to reading your applications!

The Kotlin team wants to expand official Kotlin support not only for Gradle and Maven build systems, but any other build system as well and support them natively in JetBrains IDEs with minimal effort. On the other hand, we also want to provide basic Kotlin support in non-JetBrains IDEs – one part of such support is being able to get Kotlin-specific information from any build system supporting Kotlin.

The solution to these requirements could be a Build Server Protocol (BSP) which provides an abstraction layer between the build system and IDE.

The goal of this project would be implementing a prototype which uses the BSP protocol to get all the required information for IntelliJ IDEA from a user project so that it will be possible to work with Kotlin code in the project. To limit the scope of this prototype, the user project will use Gradle to build itself automatically.

Preferred skills

• Knowledge of Kotlin

• Understanding of how to write Gradle plugins

• Bonus: understanding of how to write plugins for IntelliJ IDEA

Possible mentors

Yahor Berdnikau, Bálint Hegyi, and Reinhold Degenfellner

Tasks for applicants

• Task #1. Why are you interested in this project?

• Task #2. Practice assignment: Create a Gradle plugin which exposes a specific task. This task should, in the presence of the Kotlin Gradle Plugin, retrieve all the Kotlin sources’ structures and output them. Including tests would be a bonus.

This project aims to create an open-source Kotlin Multiplatform (KMP) library that supports Gemini using Vertex AI in Firebase on at least Android and iOS. It will showcase best practices in creating KMP libraries for existing services, with a focus on appropriate production implementation (for example, proper API key management, user-managed API keys support, and client throttling).

Expected outcomes

• A new Kotlin Multiplatform library with support for an existing Google service

• Sample code and documentation

Preferred skills

• Kotlin

• Kotlin Multiplatform

• Mobile development (Android and iOS)

Possible mentors

Matt Dyor, and the Google team

Bazel's support for Kotlin is evolving, but proper Kotlin Multiplatform (KMP) integration remains a challenge. This project aims to improve Bazel's KMP support by addressing dependency resolution issues, enhancing rules_kotlin and rules_jvm_external compatibility, and enabling cross-platform builds.

Key improvements will focus on handling platform-specific dependencies (expect/actual mechanisms), improving Gradle metadata support, and ensuring a smoother developer experience for KMP in Bazel.

Expected outcomes

• Enhanced dependency resolution for Kotlin Multiplatform in Bazel

• Improved integration with rules_kotlin and rules_jvm_external

• A working KMP build setup in Bazel for seamless multiplatform development

Preferred skills

• Kotlin Multiplatform and Gradle

• Bazel build system

• Dependency resolution strategies

Possible mentors

Shauvik Roy Choudhary, and the Uber team

The Language Server Protocol (LSP) is a widely adopted standard that enables code intelligence features such as autocompletion, go-to definition, and refactoring across different editors and IDEs. While there is currently no official Kotlin LSP server, there is significant demand for one in the community. A publicly maintained, community-driven implementation can support broad use cases, including code migration, AI-powered code assistance, and seamless integration into various development environments.

This project aims to develop a Kotlin LSP implementation, ensuring compatibility with key LSP features and broadening Kotlin's accessibility across development environments.

Expected outcomes

Develop a Kotlin LSP implementation

Preferred skills

• Kotlin

• Language Server Protocol (LSP)

• Plugin or extension development for IDEs

Possible mentors

Shauvik Roy Choudhary, and the Uber team

Maven Central is one of the most popular Maven repositories for publishing JVM-focused libraries and projects. It is actively used by Apache Maven or Gradle-based open-source projects, and based on Sonatype Nexus v2, pending migration to a newer version. There is ongoing migration of open source projects to a new Maven Central Instance, which has a very different API implementation and needs special support in the build tool plugins. Developing a Gradle plugin that is compatible with the new Maven Central publication APIs would help the library authors building with Gradle to have a smooth experience with the new process.

Currently, there are multiple implementations of Maven Central publishing plugins in Gradle, for example, the Maven Publish Plugin or the New Maven Central Publishing, which already tries to adopt the new APIs. During the application or the community bonding phase, a potential contributor would need to review the implementations and either suggest an existing plugin to update or decide to build a new plugin or fork. The deliverables would include either a new version of an existing plugin for Maven Central publishing or a new plugin for Gradle. We anticipate the implementation to be in Kotlin or Java and to have proper test coverage and documentation. Additional deliverables may include Kotlin DSL extensions to simplify the use of the plugins and Declarative Gradle extensions.

Expected outcomes

• Updated Maven Central publishing plugin or a new plugin

Preferred skills

• Kotlin

• Gradle

• Maven Repositories

Possible mentors

Oleg Nenashev, and the Gradle team

Gradle is working on Isolated Projects – a new feature that greatly extends the configuration cache to further improve performance, particularly the performance of Android Studio and IntelliJ IDEA sync. From the developer experience standpoint, it is one of the most expected features in Gradle.

One of the problems for Isolated projects is the lock contention in the Gradle core, with plugins sometimes getting in the way of parallel execution. We would like to reduce the lock contention, especially in the key Gradle Build Tool plugins for Java, Kotlin, Android, and Kotlin Multiplatform ecosystems. Contributors are welcome to choose the deliverables based on their interests and the desired project size.

Potential deliverables include but are not limited to:

• Embed the Configuration Cache Report tool into the Gradle Profiler (or "implement a GitHub Action for it")

• Profile Gradle and a few popular Gradle plugins in various projects, with automation of the test suite on GHA

• Determine potential areas and plugins where lock contention can be reduced, with or without Configuration Cache

• While around, contribute to other areas of Configuration Cache compatibility in the target plugins

• Implement some of the discovered improvements

Expected outcomes

Implementing extensibility features in the Kotlin DSL for Gradle and improving support for common project integrations

Preferred skills

• Kotlin

• Gradle

• Java

• Performance analysis

• Profiling

Possible mentors

Oleg Nenashev, Laura Kassovic

There are more than 50 Jenkins plugins that are implemented with Gradle. There is a Gradle JPI plugin, but it is not fully compliant with Jenkins hosting requirements and needs an update. In this project idea, the aim would be to recover the Gradle developer flow for Jenkins, reach feature parity with the Apache Maven flow (Parent POM, Plugin Compatibility Tester, Jenkins Bill of Materials, and others), and to improve the developer experience for those who develop Jenkins plugins with Gradle.

Contributors are welcome to choose the deliverables based on their interest and the desired project size.

Potential deliverables include but are not limited to:

• Refreshing the Gradle JPI plugin and making it compliant with hosting best practices

• Migrating the Gradle JPI plugin codebase from Groovy to Kotlin

• Implementing a new convention plugin for Jenkins Plugins that would cover the main features of Jenkins plugin Parent POM, with Kotlin and Kotlin DSL. This would include not just building the plugin, but also testing and static analysis according to Jenkins' best practices

• Adopting the refreshed plugin and/or the convention plugin in the most popular Gradle plugin, including the Gradle plugin itself

• Integrating the Gradle plugin into the Plugin Compatibility Tester and Bill of Materials

• Documenting the updated Gradle development flow for Jenkins plugins

Expected outcomes

Updated Gradle JPI plugin and/or new convention plugin for Jenkins, published on Jenkins Update Center and the Gradle Plugin Portal

Preferred skills

• Kotlin DSL

• Kotlin

• Gradle

• Jenkins

• Java

Possible mentors

Oleg Nenashev, Stefan Wolf

Many projects, including Gradle, have a lot of Kotlin DSL samples and code snippets (see the Gradle Docs for examples). Testing them against multiple versions poses certain challenges because the snippets often represent incomplete code for the sake of brevity. We would like to build a test framework that simplifies the verification of those samples within a unit test framework (Kotest or JUnit 5) on GitHub Actions or TeamCity. Later we would be interested in doing the same for Declarative Gradle samples.

Expected outcomes

Implementing extensibility features in the Kotlin DSL for Gradle and improving support for common project integrations

Preferred skills

• Kotlin

• Gradle

• Java

• Static analysis

Possible mentors

Oleg Nenashev, Laura Kassovic

The IntelliJ Platform Gradle Plugin, a plugin for the Gradle build system, simplifies configuring your environment for building, testing, verifying, and publishing plugins for IntelliJ-based IDEs. The plugin manages the build, test, and verification steps while keeping up with the constant changes introduced in the IntelliJ Platform. The IntelliJ Platform Gradle Plugin is used by JetBrains, third-party developers, and external companies to integrate their workflows with JetBrains tools.

Expected outcomes

• Introduce Gradle Reporting to provide detailed, configurable verification task reports.

• Utilize Gradle Worker API to enable parallel execution of the verifyPlugin task against multiple IntelliJ Platform versions, reducing the task execution time.

• Explore additional Gradle enhancements to further improve plugin development workflows.

Preferred skills

• Kotlin

• Gradle

• IntelliJ Platform

Possible mentors

Jakub Chrzanowski, JetBrains

OpenRewrite is a powerful framework for automating code migrations and refactorings in a structured manner. While OpenRewrite has strong support for Java, the Kotlin ecosystem would benefit from a more comprehensive set of OpenRewrite recipes to help developers seamlessly migrate their codebases.

This project aims to expand the Kotlin OpenRewrite recipe collection by adding more automated transformations, such as migrating Java-based AutoValue classes to idiomatic Kotlin data classes, modernizing Kotlin code to follow best practices, and enabling more seamless migrations across Kotlin versions. These recipes will help Kotlin developers maintain clean, up-to-date, and idiomatic codebases with minimal manual effort.

Expected outcomes

• Development of new OpenRewrite recipes for Kotlin code migrations

Preferred skills

• Kotlin

• OpenRewrite framework

• Java-to-Kotlin migration strategies

Possible mentors

Shauvik Roy Choudhary, and the Uber team

Bazel's rules_jvm_external provides a structured way to declare external Java dependencies, but it currently lacks proper support for Bill of Materials (BOM) files. BOM files are widely used in Maven and Gradle to manage dependencies in a consistent manner without requiring developers to specify individual versions. This project aims to enhance rules_jvm_external by adding BOM support, allowing developers to use BOM-based dependency resolution within Bazel. The project may involve contributing to an existing open-source effort or implementing BOM support directly in rules_jvm_external, ensuring compatibility with widely used dependency management approaches.

Expected outcomes

• Implementation of BOM support in Bazel rules_jvm_external

• Improved dependency resolution and usability for Bazel users

• Documentation and examples for using BOM support in Bazel

Preferred skills

• Starlark (Bazel's scripting language)

• Bazel build system

• Dependency resolution strategies

Possible mentors

Shauvik Roy Choudhary, and the Uber team

Gradle recently introduced a new Problems API that allows Gradle and third-party plugins to propagate issues and warnings in a unified way. This API provides clean and actionable error reporting and more insights into the console output, dedicated HTML reports, and connected observability tools. IDEs such as IntelliJ IDEA or Android Studio can also access the details via Gradle's API integration tool, and can show warnings right in the code editor. Several core features and plugins have already adopted the Problems API: Java compilation, dependency resolution errors, deprecation warnings, etc. We want the code quality plugins for Kotlin to adopt this API, too; it would significantly improve the developer experience for 100,000+ Kotlin developers using Gradle.

In this project, we invite contributors to choose a number of Kotlin code quality plugins, such as Ktlint, Detekt, Diktat, ArchUnit, or Checkstyle for Kotlin, and integrate them with Problems API. You can also work on integrating a similar analysis for Gradle builds defined with KotlinDSL.

Expected outcomes

• Implement Problems API integration in the mentioned plugins

Preferred skills

• Kotlin

• Gradle

Possible mentors

Oleg Nenashev, Balint Hegyi, Reinhold Degenfellner