私の GSoC の旅: Chrome 拡張機能への貢献

Harsh Singh
Harsh Singh

公開日: 2025 年 10 月 28 日

私は IIT（ISM）ダンバード校の化学工学の最終学年の B.Tech 学生である Harsh Singh です。2025 年には Google Summer of Code（GSOC）に参加しました。この投稿では、GSoC に参加するまでの経緯と、参加中に学んだことについてご紹介します。

GSoC 前: 拡張機能開発の発見

1 年生のとき、他の多くの学生と同様に、私は大学の公式テクノロジー クラブである CyberLabs に入部したいと思っていました。準備として、クラブに入るために作成した Chrome 拡張機能を教えてくれた先輩に会いに行きました。私が知っていた標準的なウェブ開発とはまったく異なっていました。スクリプトを挿入して自分のブラウザでウェブサイトを変更できるのは、とてもクールな方法だと思いました。

私は多くの拡張機能 API を試しました。Manifest V2 から V3 への移行も目の当たりにしました。それらを使って小さなプロジェクトを構築し、CyberLabs に参加しましたが、その後は大学生活に忙殺され、拡張機能の開発はしばらくお休みしていました。

最近、Google Summer of Code（GSoC）への応募を検討しているときに、Chrome 拡張機能 API のプロジェクトに出会いました。懐かしさがこみ上げてきました。「今度は、将来 2 年生が CyberLabs に入るために使う API を作ってみようかな。それが一番の自慢になるでしょう。」過去の仕事で拡張機能の用語のほとんどを理解しているので、このプロジェクトは私にぴったりだと思います。

適用する準備

ふと思いつき、Chrome 拡張機能チームのデベロッパー リレーションズ エンジニアである Oliver に連絡することにしました。Chromium の GSoC プログラムに合格するには何が必要か尋ねました。数日以内に返信が届きました。メールには、コードベースを探索して C++ を書けることを確認したいだけだと書かれており、とても励みになりました。

まず、自分のマシンに Chromium をセットアップしました。本当に苦労しました。4 日間かけて何度も試行錯誤し、ようやく大規模なコードベースをセットアップしてビルドを成功させることができました。オンラインで簡単な問題（ユーザー操作なしの sidePanel.open() に関する問題）を見つけ、修正するためのパッチを送信しました。（振り返ってみると、ほんのわずかな変更でした 🙂）。私は Oliver に進捗状況をメールで報告しました。サポートする予定はないと言われましたが、私が真剣に取り組んでいることを示すには十分な作業をしたとも言われました。その後、サイドパネルの getPosition メソッドに取り組むよう提案されました。解決策を見つけて再度メールを送ったところ、彼は非常に喜んで、私の提案はチームで話し合っていた内容と一致していると言ってくれました。これにより、コードを理解して変更できることがわかり、自信を持ってプロジェクトを進めることができました。

私の GSoC 提案

次は GSoC の提案です。最初のプロジェクトの説明「SidePanel APIs & DNR APIs」は非常に広範囲に及ぶため、提案書にどのようなタスクを記載すべきか、タイムラインをどのように作成すべきか、わかりませんでした。この件についてオリバーにメールで問い合わせたところ、プロジェクトの説明を更新したと返信がありました。嬉しいことに、彼がすでに私が取り組んでいた sidePanel.getPosition API を含むいくつかの API を追加してくれていました。

提案の主な要素は、プロジェクトの理解、設計のアイデア、提案前の作業、成果物のスケジュールでした。タスクの規模を正確に把握し、関連する作業を十分に理解していることを示しました。提案書を作成し、2 回審査を受けました。

後悔していることの 1 つは、今後申請する方への大きなヒントにもなりますが、構築を予定していた機能の適切な設計仕様を含めなかったことです。たとえば、サイドパネルを閉じる API を提案する際には、パラメータの概要を示し、選択の理由を説明し、エッジケースの処理方法を説明し、すべてのブラウザで API を標準化する方法を説明する必要がありました。これにより、より深いレベルの理解を示すことができたでしょう。

Chromium 拡張機能プロジェクトのコンテキストでは、新しい API 設計が正式に議論される WECG（WebExtensions Community Group、ウィーシージーと発音）が重要な組織です。GSoC の期間中、コントリビューターはこのグループに API の提案をプレゼンする必要がある場合があります。そのため、GSoC の提案で設計アイデアを準備しておくことは大きなメリットになります。メンターに、この重要なステップの準備ができており、GSoC 期間中にうまくやっていけることを示すことができるからです。

5 月初旬にメールが届き、合格したことがわかりました。🙂

GSoC での貢献

GSoC の期間は素晴らしいものでした。メンターの Solomon はとても親切で、毎週のミーティングは有益で、常に軌道に乗せてくれました。また、同じ投稿者の Amit P さんとも知り合うことができました。彼は、私が困ったときにいつも助けてくれました。WECG の会議に参加して、そのレベルでの業務の進め方を目の当たりにし、経験が非常に重要である理由を理解しました。そこで API の提案について話し合い、別のブラウザ ベンダーから承認を得ました。

最初はいくつかの CL（変更リスト）を開きました。コードレビューのやり取りで進捗が遅れることもありましたが、私は喜んで取り組みました。私が主にマージした貢献は、サイドパネル API です。

Commands API の他の CL はまだ作成中です（GSoC 後にどれだけアクティブに活動するかによって変わります 🙂）。詳細については、GSoC プロジェクト ページの [コードを表示] リンクからアクセスできる最終レポートをご覧ください。

ほとんどすべての CL をレビューしてくれた Oliver Dunk、Solomon Kinard、Kelvin Jiang、Devlin Cronin、Tom Lukaszewicz、Andrea Orru に感謝します。自分のコードが Chrome の一部になるのは、素晴らしいことです。メンターからは「オーナーシップが強い」と言われ、とても嬉しかったです。

まとめ

GSoC で得たものは、技術的な知識だけではありません。重要な議論が行われる場に身を置くことができ、その議論は多くの拡張機能デベロッパーに影響を与えるものでした。これが、現実世界のアプリケーションに初めて導入された私の作品でした。患者メンターに出会い、多くのことを教えてもらい、非常に有意義な経験をすることができました。

私の経験が、Chromium への貢献や Google Summer of Code への参加を希望する方々の参考になれば幸いです。

GSoC に応募する際のヒント

  1. 本当に好きなアイデアを選びましょう。関心事を最優先にしてください。スキルは常に向上させることができますが、困難に直面したときにモチベーションを維持できるのは情熱です。私は両方の立場を経験しましたが、興味のないことに取り組んでいると、うまくいかなかったときに他人のせいにしたくなります。しかし、その仕事を愛していれば、それを克服すべき課題と捉えるでしょう。
  2. 競争を恐れない。コミュニティ チャンネルで他の応募者を確認した後、モチベーションが下がったという人がたくさんいました。優れたプロジェクトには必ず競合他社が存在します。自分の強みに集中する。以前にライブラリを扱ったことがある場合は、そのライブラリを使用するプロジェクトを見つけます。独自の経験を活かせるため、有利になります。
  3. 運を認め、コミュニケーションに集中する。GSoC には運も必要です。人気のプロジェクトでは、1 ～ 2 個のスロットに対して 300 件を超える提案が寄せられることもあります。メンターがすべての質問に詳細に回答することは難しいと思います。そのため、早期のコミュニケーションが重要になります。事前にプロジェクトに参加し、提案が確実で要点を押さえていることを確認します。
  4. 選ばれなかった場合でも、これで終わりではありません。これで、履歴書に貴重なオープンソースの貢献を記載できるようになりました。この結果を使用して、他の夏の機会に応募してください。難しい作業はすでに完了しています。

最後に、

「人は皆、ある特定の仕事のために作られており、その仕事への欲求はすべての人の心に植え付けられている。」— ルーミー

ご精読ありがとうございました。