Kotlin Help

Google Summer of Code with Kotlin 2025

This article contains the list of project ideas for Google Summer of Code with Kotlin 2025, and contributor guidelines

Kotlin contributor guidelines for Google Summer of Code (GSoC)

Getting started

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

  2. Familiarize yourself with the Kotlin language:

  3. Get to know the Kotlin open source community:

How to apply

  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!

Project ideas

Build Server Protocol: add Kotlin support [Hard, 350 hrs]

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 IDE with minimal effort. On the other hand, we also want to provide basic Kotlin support in non-JetBrains IDE – one part of such support is to be able to get Kotlin specific information from any build system supporting Kotlin.

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

The goal of this project would be implementing a prototype which uses the BSP protocol to get all required for IDEA information from a user project to be able to work with Kotlin code in the project. To limit the scope of this prototype – user project will be using Gradle to build itself.

Skills required (preferred)

  • Kotlin

  • Understanding how to write Gradle plugins

  • Bonus: understanding how to write IntelliJ IDEA plugins

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 on the presence of Kotlin Gradle Plugin get all the Kotlin sources structure and output to the file. Having tests is a bonus

Support Android and iOS targets in Kotlin Multiplatform for an existing Google service [Medium, 175 hrs]

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

Expected outcomes

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

  • Sample code and documentation

Skills required (preferred)

  • Kotlin

  • Kotlin Multiplatform

  • Mobile development (Android and iOS)

Possible mentor

Matt Dyor, and the Google team

Add Kotlin Multiplatform support in Bazel [Hard, 350 hrs]

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

Skills required (preferred)

  • Kotlin Multiplatform and Gradle

  • Bazel build system

  • Dependency resolution strategies

Possible mentor

Shauvik Roy Choudhary, and the Uber team

Kotlin Language Server (LSP) [Hard, 350 hrs]

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. There is currently no official Kotlin LSP server. Uber has developed an internal Kotlin LSP, but a publicly maintained, community-driven implementation can support broader 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

Skills required (preferred)

  • Kotlin

  • Language Server Protocol (LSP)

  • Plugin or extension development for IDEs

Possible mentor

Shauvik Roy Choudhary, and the Uber team

Maven Central publishing plugin for Gradle with new APIs [Medium, 175 hrs]

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. A potential contributor, during the application or the community bonding phase, would need to review the implementations and suggest a plugin to be updated, 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

Skills required (preferred)

  • Kotlin

  • Gradle

  • Maven Repositories

Possible mentor

Oleg Nenashev, and the Gradle team

Improving Configuration Cache and lock contention in key Gradle plugins [Easy to Hard, 90 hrs to 350 hrs]

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 and 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 interest and the desired project size.

Potential deliverables include but 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

Skills required (preferred)

  • Kotlin

  • Gradle

  • Java

  • Performance analysis

  • Profiling

Possible mentor

Oleg Nenashev, Laura Kassovic

Gradle convention plugin for developing Jenkins plugins [Easy to Hard, 90 hrs to 350 hrs]

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 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 Gradle Plugins into 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 Gradle Plugin Portal

Skills required (preferred)

  • Kotlin DSL

  • Kotlin

  • Gradle

  • Jenkins

  • Java

Possible mentor

Oleg Nenashev, Stefan Wolf

Kotlin DSL and Declarative Gradle documentation samples test framework [Easy to Medium, 90 hrs to 175 hrs]

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

Skills required (preferred)

  • Kotlin

  • Gradle

  • Java

  • Static analysis

Possible mentor

Oleg Nenashev, Laura Kassovic

IntelliJ Platform Gradle Plugin – Gradle Reporting and Parallel Verifications [Medium, 175 hrs]

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.

Skills required (preferred)

  • Kotlin

  • Gradle

  • IntelliJ Platform

Possible mentor

Jakub Chrzanowski, JetBrains

Add More Kotlin OpenRewrite Recipes [Medium, 175 hrs]

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.

Expected outcomes

  • Development of new OpenRewrite recipes for Kotlin code migrations

Skills required (preferred)

  • Kotlin

  • OpenRewrite framework

  • Java-to-Kotlin migration strategies

Possible mentor

Shauvik Roy Choudhary, and the Uber team

Add BOM Support to Bazel rules_jvm_external [Hard, 350 hrs]

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

Skills required (preferred)

  • Starlark (Bazel's scripting language)

  • Bazel build system

  • Dependency resolution strategies

Possible mentor

Shauvik Roy Choudhary, and the Uber team

Clean and actionable reporting for Gradle code quality plugins for Kotlin [Easy to Medium, 90 hrs to 175 hrs]

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, also have access to the details via Gradle's tool integration API, and can show warnings right in the code editorI. 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 greatly 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

Skills required (preferred)

  • Kotlin

  • Gradle

Possible mentors

Oleg Nenashev, Balint Hegyi, Reinhold Degenfellner

Last modified: 27 February 2025
Google Summer of Code with KotlinGoogle Summer of Code with Kotlin 2024