This article contains the list of project ideas for Google Summer of Code with Kotlin 2025, and contributor guidelines
Kotlin resources:
- Kotlin GitHub repository
- Kotlin Slack and the #gsoc Slack channel
If you got any questions, contact us via [email protected]
{style="note"}
-
Check out the GSoC FAQ and the program announcement.
-
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 account to stay up to date on the latest news and developments.
- Check out the Kotlin YouTube channel for tutorials, tips, and the latest updates.
-
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.
- Check out the project ideas and select the one you would like to work on.
- If you are not familiar with Kotlin, read the introductory info on the Kotlin website.
- Refer to the GSoC contributor guidelines.
- 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 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
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_kotlinandrules_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
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 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
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
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
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
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