メインコンテンツまでスキップ

Google Summer of Code with Kotlin 2025

この記事では、Kotlin での Google Summer of Code 2025 向けのプロジェクトのアイデア一覧と、コントリビューターガイドラインを紹介します。

注記

Kotlin のリソース：

ご質問がある場合は、[email protected] 経由で お問い合わせください。

Kotlin での Google Summer of Code (GSoC) のためのコントリビューターガイドライン​

はじめに​

  1. GSoC FAQ と プログラムのお知らせを確認してください。

  2. Kotlin 言語について理解を深めてください。

    • 公式の Kotlin website は、始めるのに最適な場所です。
    • 公式の documentation を読んで、言語への理解を深めてください。
    • JetBrains Academy の Kotlin コース、または Android チームの Training options を見てください。
    • 最新のニュースや開発状況を知るために、Kotlin X または Kotlin Bluesky アカウントをフォローしてください。
    • チュートリアル、ヒント、最新のアップデートについては、Kotlin YouTube channel をチェックしてください。

  3. Kotlin オープンソースコミュニティを知りましょう。

応募方法​

  1. プロジェクトのアイデアを確認し、取り組みたいものを選択してください。
  2. Kotlin に慣れていない場合は、Kotlin website の紹介情報 を読んでください。
  3. GSoC contributor guidelines を参照してください。
  4. GSoC website から応募してください。
    • 提案されたプロジェクトに関連する動作するコードサンプルを作成することをお勧めします。また、特に誇りに思っているコードサンプルがあれば見せてください。
    • Kotlin に興味を持った理由と、Kotlin に関するあなたの経験について説明してください。
    • オープンソースプロジェクトに参加している場合は、あなたの貢献履歴を参照してください。
    • GitHub、Twitter アカウント、ブログ、または技術的または科学的な出版物のポートフォリオをお持ちの場合は、それらも参照してください。
    • 試験や休暇など、GSoC のタイムラインと競合する予定がある場合は、すべて開示してください。

ありがとうございます！皆様からの応募をお待ちしております！

プロジェクトのアイデア​

Build Server Protocol: Kotlin サポートの追加 [難易度: 高, 350 時間]​

Kotlin チームは、Gradle や Maven ビルドシステムだけでなく、他のあらゆるビルドシステムに対する公式の Kotlin サポートを拡張し、最小限の労力で JetBrains IDE でネイティブにサポートしたいと考えています。 一方、JetBrains 以外の IDE でも基本的な Kotlin サポートを提供したいと考えています。そのようなサポートの一部は、Kotlin をサポートするあらゆるビルドシステムから Kotlin 固有の情報を取得できるようにすることです。

これらの要件に対するソリューションは、ビルドシステムと IDE の間に抽象化レイヤーを提供する Build Server Protocol (BSP) です。

このプロジェクトの目標は、BSP プロトコルを使用して、IntelliJ IDEA でユーザープロジェクトから必要なすべての情報を取得し、プロジェクト内の Kotlin コードを操作できるようにするプロトタイプを実装することです。 このプロトタイプの範囲を制限するために、ユーザープロジェクトは Gradle を使用して自動的にビルドされます。

推奨スキル

  • Kotlin の知識
  • Gradle プラグインの書き方についての理解
  • ボーナス: IntelliJ IDEA 用のプラグインの書き方についての理解

想定されるメンター

Yahor Berdnikau, Bálint Hegyi, and Reinhold Degenfellner

応募者向けのタスク

  • タスク #1. このプロジェクトに興味を持った理由は何ですか？

  • タスク #2. 実践課題: 特定のタスクを公開する Gradle プラグインを作成します。このタスクは、Kotlin Gradle Plugin が存在する場合に、すべての Kotlin ソースの構造を取得して出力する必要があります。 テストを含めるとボーナスになります。

Firebase の Vertex AI を使用して Gemini の Kotlin Multiplatform で Android および iOS ターゲットをサポートする [難易度: 中, 175 時間]​

このプロジェクトは、Firebase の Vertex AI を使用して Gemini をサポートするオープンソースの Kotlin Multiplatform (KMP) ライブラリを、少なくとも Android および iOS で作成することを目的としています。既存のサービス用の KMP ライブラリを作成する際のベストプラクティスを紹介し、適切な本番環境実装 (たとえば、適切な API キー管理、ユーザー管理の API キーのサポート、およびクライアントスロットリング) に焦点を当てます。

期待される成果

  • 既存の Google サービスをサポートする新しい Kotlin Multiplatform ライブラリ
  • サンプルコードとドキュメント

推奨スキル

  • Kotlin
  • Kotlin Multiplatform
  • モバイル開発 (Android および iOS)

想定されるメンター

Matt Dyor, and the Google team

Bazel での Kotlin Multiplatform サポートの追加 [難易度: 高, 350 時間]​

Bazel の Kotlin のサポートは進化していますが、適切な Kotlin Multiplatform (KMP) の統合は依然として課題です。 このプロジェクトは、依存関係解決の問題に対処し、rules_kotlin と rules_jvm_external の互換性を強化し、クロスプラットフォームビルドを有効にすることによって、Bazel の KMP サポート を改善することを目的としています。

主な改善点は、プラットフォーム固有の依存関係 (expect/actual メカニズム) の処理、Gradle メタデータサポートの改善、および Bazel での KMP のよりスムーズな開発者エクスペリエンスの確保に焦点を当てます。

期待される成果

  • Bazel での Kotlin Multiplatform の拡張された依存関係解決
  • rules_kotlin および rules_jvm_external との統合の改善
  • シームレスなマルチプラットフォーム開発のための Bazel での動作する KMP ビルドセットアップ

推奨スキル

  • Kotlin Multiplatform および Gradle
  • Bazel ビルドシステム
  • 依存関係解決戦略

想定されるメンター

Shauvik Roy Choudhary, and the Uber team

Kotlin Language Server (LSP) [難易度: 高, 350 時間]​

Language Server Protocol (LSP) は、自動補完、定義への移動、リファクタリングなどのコードインテリジェンス機能をさまざまなエディターや IDE で実現する広く採用されている標準です。現在、公式の Kotlin LSP サーバーはありませんが、コミュニティにはその需要が十分にあります。公開され、コミュニティ主導でメンテナンスされる実装は、コード移行、AI 搭載のコード支援、さまざまな開発環境へのシームレスな統合など、幅広いユースケースをサポートできます。

このプロジェクトは、主要な LSP 機能との互換性を確保し、さまざまな開発環境での Kotlin のアクセシビリティを拡大する Kotlin LSP 実装を開発することを目的としています。

期待される成果

Kotlin LSP 実装の開発

推奨スキル

  • Kotlin
  • Language Server Protocol (LSP)
  • IDE 用のプラグインまたは拡張機能の開発

想定されるメンター

Shauvik Roy Choudhary, and the Uber team

新しい API を使用した Gradle 用の Maven Central 公開プラグイン [難易度: 中, 175 時間]​

Maven Central は、JVM に焦点を当てたライブラリとプロジェクトを公開するための最も人気のある Maven リポジトリの 1 つです。Apache Maven または Gradle ベースのオープンソースプロジェクトで積極的に使用されており、Sonatype Nexus v2 に基づいており、新しいバージョンへの移行を保留中です。オープンソースプロジェクトの新しい Maven Central インスタンスへの移行が進行中であり、API の実装が大きく異なり、ビルドツールプラグインでの特別なサポートが必要です。新しい Maven Central 公開 API と互換性のある Gradle プラグインを開発すると、Gradle でビルドするライブラリの作成者は、新しいプロセスをスムーズに体験できます。

現在、Gradle には Maven Central 公開プラグインの複数の実装があります。たとえば、Maven Publish Plugin や、すでに新しい API の採用を試みている New Maven Central Publishing などです。応募またはコミュニティ結束フェーズ中に、潜在的なコントリビューターは実装を確認し、更新する既存のプラグインを提案するか、新しいプラグインを構築するかフォークするかを決定する必要があります。成果物には、Maven Central 公開用の既存のプラグインの新しいバージョン、または Gradle 用の新しいプラグインが含まれます。実装は Kotlin または Java であり、適切なテストカバレッジとドキュメントが必要です。追加の成果物には、プラグインの使用を簡素化するための Kotlin DSL 拡張機能と、Declarative Gradle 拡張機能が含まれる場合があります。

期待される成果

  • 更新された Maven Central 公開プラグインまたは新しいプラグイン

推奨スキル

  • Kotlin
  • Gradle
  • Maven Repositories

想定されるメンター

Oleg Nenashev, and the Gradle team

主要な Gradle プラグインの Configuration Cache およびロック競合の改善 [難易度: 簡単～高, 90 時間～350 時間]​

Gradle は Isolated Projects に取り組んでいます。これは、Configuration Cache を大幅に拡張して、特に Android Studio および IntelliJ IDEA 同期のパフォーマンスをさらに向上させる新機能です。開発者のエクスペリエンスの観点から、Gradle で最も期待される機能の 1 つです。

Isolated projects の問題の 1 つは、Gradle コアのロック競合です。プラグインが並列実行を妨げることがあります。特に Java、Kotlin、Android、および Kotlin Multiplatform エコシステム向けの主要な Gradle Build Tool プラグインで、ロック競合を減らしたいと考えています。コントリビューターは、自分の興味と希望するプロジェクトサイズに基づいて成果物を選択できます。

潜在的な成果物には以下が含まれますが、これらに限定されません。

  • Configuration Cache Report ツールを Gradle Profiler に埋め込む (または「その GitHub Action を実装する」)
  • Gradle といくつかの人気のある Gradle プラグインをさまざまなプロジェクトでプロファイルし、GHA でのテストスイートの自動化を行う
  • ロック競合を減らすことができる可能性のある領域とプラグインを、Configuration Cache の有無にかかわらず特定する
  • ついでに、ターゲットプラグインの Configuration Cache 互換性 の他の領域にも貢献する
  • 発見された改善点のいくつかを実装する

期待される成果

Gradle 用の Kotlin DSL での拡張機能の実装、および一般的なプロジェクト統合のサポートの改善

推奨スキル

  • Kotlin
  • Gradle
  • Java
  • パフォーマンス分析
  • プロファイリング

想定されるメンター

Oleg Nenashev, Laura Kassovic

Jenkins プラグインを開発するための Gradle convention プラグイン [難易度: 簡単～高, 90 時間～350 時間]​

Gradle で実装されている Jenkins プラグインは 50 個以上あります。 Gradle JPI plugin がありますが、 Jenkins ホスティング要件に完全には準拠しておらず、更新が必要です。 このプロジェクトのアイデアでは、Jenkins の Gradle 開発者フローを回復し、 Apache Maven フロー (Parent POM、 Plugin Compatibility Tester、 Jenkins Bill of Materials など) との機能パリティを実現し、 Gradle で Jenkins プラグインを開発する人々の開発者エクスペリエンスを向上させることを目的としています。

コントリビューターは、自分の興味と希望するプロジェクトサイズに基づいて成果物を選択できます。

潜在的な成果物には以下が含まれますが、これらに限定されません。

  • Gradle JPI プラグインを更新し、ホスティングのベストプラクティスに準拠させる
  • Gradle JPI プラグインのコードベースを Groovy から Kotlin に移行する
  • Jenkins プラグインの新しい convention プラグインを実装します。これは、Jenkins プラグイン Parent POM の主な機能を Kotlin および Kotlin DSL でカバーします。 これには、プラグインの構築だけでなく、Jenkins のベストプラクティスに従ったテストと静的分析も含まれます。
  • 更新されたプラグインおよび/または convention プラグインを、Gradle プラグイン自体を含む、最も人気のある Gradle プラグインに採用する
  • Gradle プラグインを Plugin Compatibility Tester および Bill of Materials に統合する
  • Jenkins プラグインの更新された Gradle 開発フローを文書化する

期待される成果

更新された Gradle JPI プラグインおよび/または Jenkins 用の新しい convention プラグイン。Jenkins Update Center および Gradle Plugin Portal で公開されます。

推奨スキル

  • Kotlin DSL
  • Kotlin
  • Gradle
  • Jenkins
  • Java

想定されるメンター

Oleg Nenashev, Stefan Wolf

Kotlin DSL および Declarative Gradle ドキュメントサンプルテストフレームワーク [難易度: 簡単～中, 90 時間～175 時間]​

Gradle を含む多くのプロジェクトには、Kotlin DSL サンプルとコードスニペットがたくさんあります (例については、Gradle Docs を参照してください)。 スニペットは簡潔にするために不完全なコードを表していることが多いため、複数のバージョンに対してテストするには、特定の課題があります。 GitHub Actions または TeamCity のユニットテストフレームワーク (Kotest または JUnit 5) 内でこれらのサンプルの検証を簡素化するテストフレームワークを構築したいと考えています。 後で、Declarative Gradle サンプルについても同じことを行うことに興味があります。

期待される成果

Gradle 用の Kotlin DSL での拡張機能の実装、および一般的なプロジェクト統合のサポートの改善

推奨スキル

  • Kotlin
  • Gradle
  • Java
  • 静的分析

想定されるメンター

Oleg Nenashev, Laura Kassovic

IntelliJ Platform Gradle Plugin – Gradle Reporting および並列検証 [難易度: 中, 175 時間]​

IntelliJ Platform Gradle Plugin は、Gradle ビルドシステム用のプラグインで、IntelliJ ベースの IDE 用のプラグインの構築、テスト、検証、および公開のための環境の構成を簡素化します。このプラグインは、IntelliJ Platform で導入された絶え間ない変更に対応しながら、ビルド、テスト、および検証の手順を管理します。IntelliJ Platform Gradle Plugin は、JetBrains、サードパーティの開発者、および外部企業が、JetBrains ツールとのワークフローを統合するために使用しています。

期待される成果

  • 詳細で構成可能な検証タスクレポートを提供する Gradle Reporting を導入します。
  • Gradle Worker API を利用して、複数の IntelliJ Platform バージョンに対して verifyPlugin タスクを並列実行できるようにし、タスクの実行時間を短縮します。
  • プラグイン開発ワークフローをさらに改善するために、追加の Gradle 拡張機能を検討します。

推奨スキル

  • Kotlin
  • Gradle
  • IntelliJ Platform

想定されるメンター

Jakub Chrzanowski, JetBrains

より多くの Kotlin OpenRewrite レシピを追加する [難易度: 中, 175 時間]​

OpenRewrite は、コードの移行とリファクタリングを構造化された方法で自動化するための強力なフレームワークです。OpenRewrite は Java を強力にサポートしていますが、Kotlin エコシステムは、開発者がコードベースをシームレスに移行できるようにするために、より包括的な OpenRewrite レシピセットからメリットを得ることができます。

このプロジェクトは、Java ベースの AutoValue クラスを慣用的な Kotlin データクラスに移行したり、ベストプラクティスに従って Kotlin コードを最新化したり、Kotlin バージョン間でよりシームレスな移行を可能にするなど、より多くの自動変換を追加することにより、Kotlin OpenRewrite レシピコレクションを拡張することを目的としています。これらのレシピは、Kotlin 開発者が最小限の手動作業でクリーンで最新で慣用的なコードベースを維持するのに役立ちます。

期待される成果

  • Kotlin コード移行用の新しい OpenRewrite レシピの開発

推奨スキル

  • Kotlin
  • OpenRewrite framework
  • Java から Kotlin への移行戦略

想定されるメンター

Shauvik Roy Choudhary, and the Uber team

BOM サポートを Bazel rules_jvm_external に追加する [難易度: 高, 350 時間]​

Bazel の rules_jvm_external は、外部 Java 依存関係を宣言するための構造化された方法を提供しますが、現在、Bill of Materials (BOM) ファイルの適切なサポートがありません。BOM ファイルは、開発者が個々のバージョンを指定しなくても、一貫した方法で依存関係を管理するために Maven および Gradle で広く使用されています。このプロジェクトは、BOM サポートを追加することにより rules_jvm_external を強化し、開発者が Bazel 内で BOM ベースの依存関係解決を使用できるようにすることを目的としています。このプロジェクトには、既存のオープンソースの取り組みへの貢献、または rules_jvm_external で BOM サポートを直接実装することが含まれる場合があり、広く使用されている依存関係管理アプローチとの互換性を確保します。

期待される成果

  • Bazel rules_jvm_external での BOM サポートの実装
  • Bazel ユーザー向けの依存関係解決と使いやすさの向上
  • Bazel での BOM サポートの使用に関するドキュメントと例

推奨スキル

  • Starlark (Bazel のスクリプト言語)
  • Bazel ビルドシステム
  • 依存関係解決戦略

想定されるメンター

Shauvik Roy Choudhary, and the Uber team

Kotlin 用の Gradle コード品質プラグインのクリーンで実用的なレポート [難易度: 簡単～中, 90 時間～175 時間]​

Gradle は最近、Gradle およびサードパーティのプラグインが統一された方法で問題と警告を伝播できるようにする新しい Problems API を導入しました。この API は、クリーンで実用的なエラーレポートを提供し、コンソール出力、専用の HTML レポート、および接続された監視ツールに関するより多くの洞察を提供します。IntelliJ IDEA や Android Studio などの IDE は、Gradle の API 統合ツールを介して詳細にアクセスすることもでき、コードエディターで警告を直接表示できます。いくつかのコア機能とプラグインはすでに Problems API を採用しています。Java コンパイル、依存関係解決エラー、非推奨の警告などです。Kotlin 用のコード品質プラグインにもこの API を採用してもらいたいと考えています。これにより、Gradle を使用する 100,000 人以上の Kotlin 開発者の開発者エクスペリエンスが大幅に向上します。

このプロジェクトでは、コントリビューターに Ktlint、Detekt、Diktat、ArchUnit、または Kotlin 用の Checkstyle などの Kotlin コード品質プラグインをいくつか選択し、Problems API と統合することを推奨します。KotlinDSL で定義された Gradle ビルドの同様の分析を統合することもできます。

期待される成果

  • 前述のプラグインでの Problems API 統合の実装

推奨スキル

  • Kotlin
  • Gradle

想定されるメンター

Oleg Nenashev, Balint Hegyi, Reinhold Degenfellner