Electron は Google Summer of Code (GSoC) 2025 のメンター組織として再び採用されました！ Google Summer of Code は、オープンソースソフトウェア開発に新たな貢献者を呼び込むことに重点を置いた国際プログラムです。

詳細については、Google の Summer of Code のホームページ をご覧ください。

私たちについて​

Electron は、ウェブ技術を用いたクロスプラットフォームのデスクトップアプリケーションを構築する JavaScript フレームワークです。 Electron フレームワークのコアは Chromium と Node.js で構築されたコンパイル済みバイナリ実行形式であり、主に C++ で書かれています。

Electron のコア リポジトリ以外では、Electron エコシステムをサポートするいくつかのプロジェクトを管理しています：

• エンドユーザの頒布ツール (例えば Electron Forge や update.electronjs.org)。
• Electron 開発者向けの学習教材 (例えば electronjs.org や Electron Fiddle)。
• 開発者の生産性を効率化する内部ツール (例えば Electron Build Tools や Sheriff)。

GSoC 貢献者となって、github.com/electron 傘下の多くのプロジェクトのうちの 1 つで Electron のコア貢献者と共同作業する機会が得られます。

応募する前に​

Electron にあまり詳しくない方は、ドキュメント を読んだり、Electron Fiddle のサンプルを試してみることをお勧めします。

Electron アプリの頒布について学びたい方は、以下のようにして Electron Forge 付きのサンプルアプリケーションを作成してみてください。

npm init electron-app@latest my-app

コードに少し慣れたら、Electron の Discord サーバー での会話にご参加ください。

プロジェクトの貢献者​

あなたが興味のあるプロジェクトのアイデアに関連するリポジトリを見てみることをお勧めします。 あなたの研究を行う一つの方法は、バグを報告したり、 既存の問題をトリアージしたり、プルリクエストを送信したりすることです。 そうすることはコードベースで実践的な練習をする効果的な方法ですが、提案の提出には必須ではありません。 よく検討された提案は、過去のコントリビューションを参照することなくコードへの理解度を実証できるものである必要があります。

Electronへの貢献を検討されている場合は、提案を提出する前に以下のヒントを参考にしてください。

1. コントリビューションを送信する際は、わかりやすいイシューやプルリクエストの説明を記入してください。 コードの中身に関わらず、貢献の執筆に力を入れると共同作業の環境で効果的なコミュニケーションを発揮できるでしょう。
2. 開かれている Issue に対する PR はいつでも歓迎します。 メンテナへその Issue にアサインしてもらうよう求めるコメントは不要です。 解決策のアイデアを洗練させる必要がある場合は、問題に対する潜在的な解決策について話し合うことを引き続き推奨します。しかし注意として、何かに取り組めるかどうかをつぶさに尋ねるコメントは冗長で、Issue トラッカーにノイズを加えることになります。
3. あまり労力されていないプロジェクト貢献 (無効な Issue 報告、リポジトリの README への些細な文言の変更、フロントエンドコードのスタイル上の小さな変更など) はあなたの最終的な提案に悪影響を及ぼします。メンテナの限られた時間を奪い、Electron プロジェクトに純粋な利益をもたらさないためです。
4. AI コーディングアシスタントはデバッグや新しい概念の理解に効果的なツールですが、AI 生成の出力を直接コピー/ペーストした貢献は強く推奨されません。 これらはしばしば品質が低く、メンテナが LLM 生成コードをきれいにする方が PR をまとめて拒否するよりも手間なことがよくあります。

提案の作成​

Electron との共同開発に興味を持てましたか? 最初に、準備されている7つのプロジェクトアイデア案をご覧ください。 リストにあるすべてのアイデアは、提案可能です。

リストにないユニークなアイデアをお持ちの場合には検討いたしましが、提案内容が詳細かつ十分に整理されていることを確認してください。 あまり自信がないのであれば、リストのアイデアに従うことをお勧めします。

応募には以下のものがあるとよいでしょう。

• 夏に達成する予定の内容をまとめた詳細な提案書。
• 開発者としての経歴。 履歴書がある場合は、コピーを添付してください。 それ以外の場合は、過去の技術経験についてお教えください。
  • 特定の分野での経験不足で不合格になることはありませんが、これはメンターがあなたを最も効果的にサポートし、サマープロジェクトが成功するよう計画を立てるのに役立ちます。

Electronアプリケーションの一部として提出する必要のある項目の詳細なガイドはこちらをご確認ください。 Google Summer of Codeポータルに直接提案を送信する。 Electron チームへ電子メールで送信された提案は、最終提出物とみなされません。

提案に関する詳細なガイダンスについては、こちらの Google Summer of Code 公式の提案作成アドバイス に従うことをお勧めします。

応募開始は 2025 年 3 月 24 日、締め切りは 2025 年 4 月 8 日 です。

質問?​

ブログ記事で取り上げられていない質問や提案の執筆に関するお問い合わせは、summer-of-code@electronjs.org までメールしていただくか、GSoC FAQ をご確認ください。 メールを送る前に、 コントリビューターガイダンスをお読みください。

リソース​

• Electron の Google Summer of Code 2025 アイデアリスト
• Electron Google Summer of Code 2025 貢献者ガイダンス
• Google Summer of Code 学生/貢献者ガイド

2025 年初頭に、Electron の npm エコシステムリポジトリ (@electron/ および @electron-forge/ 名前空間の下) は、最小サポートバージョンを Node.js 22 へ移行します。

どういう意味ですか？​

これまで、Electron の npm エコシステム (Forge、Packager など) のパッケージは、その Node バージョンのサポート終了 (EOL) 日が過ぎた後でも、可能な限りそのバージョンをサポートしてきました。 これは、エコシステムが断片化されないようにするためです。多くのプロジェクトが古いバージョンの Node に依存していることを理解していますが、アップグレードする緊急の理由がなかっただけでそれらのプロジェクトが取り残されるリスクを冒したくありません。

時間の経過とともに、Node.js 14 を最小バージョンとして使用することが、以下の理由によりますます困難になってきました。

• 公式の Node.js 14 は macOS ARM64 ビルドがないため、完全なテストカバレッジを提供するために CI インフラストラクチャでの回避策をメンテンナンスする必要があります。
• 上流パッケージの依存関係に対する engines の要件が進み、依存関係の増加によるサプライ チェーンのセキュリティ問題を解決することがますます困難になっています。

さらに、Node.js の新しいバージョンには、ランタイムネイティブの共通ユーティリティ (例: fs.glob や util.parseArgs) や、付属の新規モジュール (例: node:test、node:sqlite) など、活用したい多くの改善点が含まれています。

なぜ今アップグレードするのですか？​

2024 年 7 月、Electron のエコシステムワーキンググループは、そのバージョンが LTS の日付に達した後の将来、同期的な ESM グラフの require() がサポートされる最初の Node バージョンで全パッケージをアップグレードすることを決定しました (nodejs/node#51977 および nodejs/node#53500 を参照)。

このアップデート時期は 2025 年 1 月 / 2 月に設定しました。 このアップグレードが行われると、Node 22 が既存のエコシステムパッケージでサポートされる最小バージョンになります。

自分に必要なアクションは何ですか？​

私たちは可能な限り互換性を維持するよう努めています。 しかし、最適なサポートを確実に受けるためにアプリを Node 22 以降へアップグレードすることを推奨します。

注意として、プロジェクトを実行している Node のバージョンは現在の Electron バージョンに組み込まれている Node のバージョンと無関係です。

今後の予定​

ご質問やご不明な点がありましたら、info@electronjs.org まで気軽にお問い合わせください。 公式の Electron の Discord でコミュニティのサポートも得られるでしょう。

BrowserView は Electron 30 から非推奨となり、WebContentView に置き換えられます。 ありがたいことに、移行は比較的簡単です。

Electron は、Chromium の UI フレームワークである Views API に合わせて、BrowserView から WebContentsView へ移行しています。 WebContentsView は、Chromium のレンダリングパイプラインに直接結び付けられた再利用可能なビューを提供し、将来のアップグレードを簡素化し、開発者が Electron アプリに非ウェブ UI 要素を統合する可能性を広げます。 WebContentsView を採用することで、アプリケーションは今後のアップデートに備えることができるだけでなく、長期的にはコードの複雑さが軽減され、潜在的なバグも減少するというメリットも得られます。

BrowserWindow と BrowserView に精通している開発者は、BrowserWindow と WebContentsView がそれぞれ BaseWindow と View の基底クラスから派生したサブクラスであることに注意するとよいでしょう。 利用可能なインスタンス変数とメソッドを完全に理解するには、これら基底クラスのドキュメントを参照するようにしてください。

移行ステップ​

1. Electron 30.0.0 以降へアップグレード​

2. あなたのアプリケーションが BrowserView を使う場所を把握する​

1 つ方法は、あなたのコードベースで new BrowserView( を検索することです。 これにより、アプリケーションが BrowserView をどのように使用しているか、および移行する必要がある呼び出し箇所の数がわかります。

3. BrowserView の使用それぞれを移行する​

1. それぞれのインスタンス化を移行します。 WebContentsView と BrowserView のコンストラクターは本質的に同じ形状なので、これはかなり簡単なはずです。 どちらも webPreferences 引数を介して WebPreferences を受け入れます。

   - this.tabBar = new BrowserView({
   + this.tabBar = new WebContentsView({
   

   info

   デフォルトでは、WebContentsView は白い背景でインスタンス化され、BrowserView は透明な背景でインスタンス化されます。 WebContentsView で透明な背景にするには、以下のように背景色をアルファ (不透明度) チャンネルが 00 の RGBA 16 進値に設定します。

   + this.webContentsView.setBackgroundColor("#00000000");
   

2. BrowserView を親ウインドウへ追加する場所を移行します。

   - this.browserWindow.addBrowserView(this.tabBar)
   + this.browserWindow.contentView.addChildView(this.tabBar);
   

3. 親ウインドウの BrowserView インスタンスメソッドの呼び出しを移行します。

   旧メソッド	新メソッド	注釈
   win.setBrowserView	win.contentView.removeChildView + win.contentView.addChildView
   win.getBrowserView	win.contentView.children
   win.removeBrowserView	win.contentView.removeChildView
   win.setTopBrowserView	win.contentView.addChildView	既存のビューで addChildView を呼び出すと、そのビューが最上位に並べ替えられます。
   win.getBrowserViews	win.contentView.children

4. setAutoResize インスタンスメソッドをサイズ変更のリスナーへ移行します。

   - this.browserView.setAutoResize({
   -   vertical: true,
   - })
   
   + this.browserWindow.on('resize', () => {
   +   if (!this.browserWindow || !this.webContentsView) {
   +     return;
   +   }
   +   const bounds = this.browserWindow.getBounds();
   +   this.webContentsView.setBounds({
   +     x: 0,
   +     y: 0,
   +     width: bounds.width,
   +     height: bounds.height,
   +    });
   +  });
   

   ヒント

   browserView.webContents とインスタンスメソッド browserView.setBounds、browserView.getBounds、browserView.setBackgroundColor の既存の使用法はすべて移行不要で、そのままの WebContentsView インスタンスで動作するはずです！

4) テストして変更をコミットする​

問題が発生しましたか？ Electron の Issue トラッカーの WebContentsView タグを確認して、発生している問題が報告済かどうかご確認ください。 ここで Issue が見つからない場合は、お気軽に新しいバグレポートを追加してください。 テストケースの要点を含めてもらえると、Issue のより適切なトリアージに役立ちます！

おめでとうございます。WebContentsView への移行が完了しました！ 🎉

Electron API の履歴がドキュメント内で詳解されるようになります。

こんにちは 👋、2024 年 Google Summer of Code (GSoC) の Electron のコントリビューターの、Peter です。

GSoC プログラムの過程で、Electron ドキュメントとその関数、クラスなどに API の履歴の機能を実装しました。これは、Node.js ドキュメント と同様の方法で、API ドキュメントの Markdown ファイルにシンプルかつ強力な YAML スキーマを使用できるようにし、Electron ドキュメントのウェブサイトでわかりやすく表示することで実現しました。

Electron が第 20 回 Google Summer of Code (GSoC) 2024 のメンター組織として承認されたことをお知らせします! Google Summer of Code は、オープンソースソフトウェア開発に新たな貢献者を呼び込むことに重点を置いた国際プログラムです。

プログラムの詳細については、Google の Summer of Code のホームページ をご覧ください。

私たちについて​

Electron は、ウェブ技術を用いたクロスプラットフォームのデスクトップアプリケーションを構築する JavaScript フレームワークです。 Electron フレームワークのコアは Chromium と Node.js で構築されたコンパイル済みバイナリ実行形式であり、主に C++ で書かれています。

Electron のコア以外にも以下のように、Electron 組織の維持に役立つ様々なプロジェクトに取り組んでいます。

• エンドユーザの頒布ツール (例えば Electron Forge や update.electronjs.org)。
• Electron 開発者向けの学習教材 (例えば electronjs.org や Electron Fiddle)。
• 開発者の生産性を効率化する内部ツール (例えば Electron Build Tools や Sheriff)。

Summer of Code の貢献者の方は、github.com/electron 傘下の多くのプロジェクトのうちの 1 つで、Electron のコアの貢献者の一部と協力して頂きます。

応募する前に​

Electron にあまり詳しくない方は、ドキュメント を読んだり、Electron Fiddle のサンプルを試してみることをお勧めします。

Electron アプリの頒布形式の詳細について学ぶには、サンプルアプリケーションを作成して Electron Forge を試すのもよいでしょう。

npm init electron-app@latest my-app

コードに少し慣れたら、Electron の Discord サーバー での会話にご参加ください。

計画書の執筆​

Electron との共同開発に興味を持てましたか? まずは、私たちが用意した 7 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。

この他に検討して欲しいアイデアをお持ちですか? 提案プロジェクトのリストにない新しいアイデアも歓迎しますが、アプローチを十分に概説し、かつ詳細に説明するようにしてください。 あまり自信がないのであれば、リストのアイデアに従うことをお勧めします。

応募には以下のものがあるとよいでしょう。

• 計画書: この夏のプログラムの間に達成する目標の計画を詳細に記した文書。
• 開発者としての経歴。 履歴書がある場合は、コピーを添付してください。 なければ、過去の技術経験についてお教えください。
  • 特定の分野での経験不足で不合格となることはありませんが、私たちメンターがあなたを最大限にサポートし、あなたの夏のプロジェクトが成功するよう計画を立てるのに役立ちます。

Electron の応募で提出する一式の詳細なガイドはこちらです。 計画書は Google Summer of Code ポータルに直接提出してください。 注意として、申請ポータルから送信せずに Electron チームへ電子メールで送信した計画書は、最終提出物とみなされません。

計画書についてさらに詳しいガイダンスが必要な場合や、何を書き込めばよいかわからない場合は、Google Summer of Code 公式の計画書作成アドバイス に従うこともお勧めします。

応募開始は 2024 年 3 月 18 日、締め切りは 2024 年 4 月 2 日 です。

質問?​

ブログ記事で取り上げられていない質問や計画書の執筆に関するお問い合わせは、summer-of-code@electronjs.org までメールしていただくか、GSoC FAQ をご確認ください。

リソース​

• Electron の Google Summer of Code 2024 アイデアリスト
• Electron Google Summer of Code 2024 貢献者ガイダンス
• Google Summer of Code 学生/貢献者ガイド

Electron の API ワーキング グループ は、Electron のコアへのより大きな変更を支援するために、オープンな Requests for Comments (RFC) プロセスを採用しようとしています。

なぜ RFC なのでしょうか?​

要するに、Electron のコアへの重要な変更を実装するプロセスをスムーズにしたいのです。

現在、新しいコードの変更は主に GitHub の Issue とプルリクエストを通じて議論されています。 Electron のほとんどの変更においては、これは良いシステムです。 多くのバグ修正、ドキュメントの変更、さらには新機能も、標準の GitHub フローを介せば非同期的にレビューおよびマージできるほど簡単です。

より重大な変更—たとえば大規模な API サーフェスや、Electron アプリの大部分に影響する重大な変更などの場合、コードの大部分が記述される前のアイデア段階でレビューを行うほうが合理的です。

このプロセスは一般公開されるように設計すべきです。そうすることで、Electron に導入される前に、オープンソースコミュニティ全体が潜在的な変更についてフィードバックを提供しやすくなります。

どのように動作するのですか?​

RFC 全体のプロセスは、GitHub 上の electron/rfcs リポジトリに保管されます。 プロセスの手順は、リポジトリの README で詳しく説明しています。

簡単に言うと、electron/rfcs リポジトリに PR が作成されると、RFC は 提唱 になります。 提唱の RFC は次のように遷移します。

• アクティブ は、PR がリポジトリの main ブランチにマージされた場合になります。つまり、Electron のメンテナが electron/electron での実装に同意できることを意味します。
• 拒絶 は PR が最終的に拒否された場合になります。

実装が electron/electron にマージされたとき、アクティブな RFC は 完了 になります。

誰が参加できますか?​

Electron コミュニティの誰もが、RFC を提出したり、electron/rfcs リポジトリにフィードバックを残したりできます!

• アクティブな RFC を一覧する場合は、リポジトリ内の text フォルダ を参照してください。
• 提唱状態の RFC にフィードバックを残す場合は、開かれている PR のリスト を確認してください。
• 新しい RFC を提出する場合は、レポジトリの README と RFC テンプレート を確認してください。

私たちは、このプロセスを双方向の対話にして、コミュニティの参加を奨励し、将来これらの API を使用する可能性のある Electron アプリからの多様な意見を得たいと考えていました。 現在提唱状態の RFC にフィードバックを残したい方向けに、Electron のメンテナが既に作成したいくつかの RFC を下記します。

• Electron の C API
• サービスワーカー向けのプリロードレルム

クレジット​

Electron の RFC プロセスは、多くの確立されたオープンソースの RFC プロセスに基づいてモデル化されました。 多くのアイデアやコピーライティングの主要部分のインスピレーションは、以下から得ました。

• emberjs/rfcs
• reactjs/rfcs
• rust-lang/rfcs
• tauri-apps/rfcs
• vuejs/rfcs
• yarnpkg/rfcs

electron/electron リポジトリへの最初のコミットは 2013 年 3 月 13 日でした¹。

その後、10 年の歳月と 1192 人の貢献者による 27,147 以上のコミットを経て、今日 Electron はデスクトップアプリケーションを構築する最も人気のフレームワークの 1 つとなっています。 この節目は、これまでの歩みを祝って振り返り、その過程で学んだことを共有する絶好の機会です。

今があるのは、このプロジェクトへ貢献しようと時間に労力を捧げてくださった皆さまのおかげです。 ソースコードのコミットは最も目立つ貢献ですが、バグ報告、ユーザーランドモジュールのメンテナンス、ドキュメントや翻訳の提供、サイバースペースでの Electron コミュニティへの参加など、人々のそういった努力も認めなければなりません。 すべての貢献は私たちメンテナーにとってかけがえのないものです。

記事の続きの前に一言、御礼申し上げます。 ❤️

ここまでどうやって到達できたのでしょうか？​

Atom Shell は、2014 年 4 月にパブリックベータを開始した GitHub の Atom エディタ の基盤として作られました。 当時利用可能だったウェブベースのデスクトップフレームワーク (node-webkit や Chromium Embedded Framework) に代わるものとして、ゼロから構築されたものです。 驚くべき機能としては、Node.js と Chromium を組み込むことでウェブ技術向けの強力なデスクトップランタイムを提供していました。

1 年も経たないうちに、Atom Shell の性能と人気は絶大なものになりました。 大企業、スタートアップ、そして個人開発者たちがこぞって Electron でアプリを作り始め (初期の採用企業は Slack、GitKraken、WebTorrent など)、このプロジェクトは Electron という適切な名前に変更されました。

それ以来、Electron は本格的に活動してきました。 週間ダウンロード数の変化は、こちらの npmtrends.com のご好意によってご覧いただけます。

Electron v1 は 2016 年にリリースされ、API の安定性の向上とドキュメントやツールの充実を約束しました。 2018 年にリリースされた Electron v2 は、セマンティックバージョニングを導入し、Electron の開発者がリリースサイクルを把握しやすくなりました。

Electron v6 では、Chromium と同じ 12 週間の定期メジャーリリースケジュールに移行しました。 この決定はプロジェクトの考え方において「Chromium のバージョンを最新にする」ということを必須事項から優先事項に変えました。 これによりアップグレード間の技術的負債が減り、Electron の更新と堅牢性の維持が容易になりました。

それ以来、Electron の新バージョンを Chromium の安定版と同じ日にリリースするという、よくできた仕組みになっています。 2021 年に Chromium がリリーススケジュールを 4 週間に早めた時には、私たちは肩をすくめて、それに合わせてリリースケーデンスを8週間に増やすことにしました。

Electron は現在 v23 であり (そしてこれからも増え続ける)、クロスプラットフォームのデスクトップアプリケーションを構築するための最高のランタイムを構築することに専念しています。 近年、JavaScript の開発ツールがブームになっていますが、Electron はデスクトップアプリケーションのフレームワークとして、安定しており実戦投入され頑丈であり続けています。 Electron アプリは今やどこにでもあります。Visual Studio Code でプログラミング、Figma でデザイン、Slack でコミュニケーション、Notion でメモ (他にも多くの使用例があります)。 私たちはこの業績を非常に誇りに思うと同時に、助力して頂いたすべての人に感謝しています。

この過程で何を学んだのでしょうか？​

10 年という節目を迎えるまでの道のりは、長いものでした。 ここでは、持続可能な大規模オープンソースプロジェクトの運営に役立った主なものを紹介します。

ガバナンスモデルで分散された意思決定をスケールする​

Electron が爆発的に普及した後、私たちの克服すべき課題はプロジェクトの長期的な方向性をどうするかでした。 会社や国、タイムゾーンを越えて分散している数十人のエンジニアのチームを、どのように指揮すればよいのでしょうか。

初期の頃、Electron のメンテナーグループはインフォーマルな調整に頼っていました。小規模なプロジェクトでは高速かつ軽量ですが、より広範な協働作業にはスケールしません。 2019 年には、異なるワーキンググループがフォーマルな責任領域を担うガバナンスモデルに移行しました。 これは、プロセスを効率化し、プロジェクトの所有権の一部を特定のメンテナーに割り当てるのに役立っています。 それぞれのワーキンググループ (WG) は、今日ではどのような役割を担っているのでしょうか？

• Electron のリリースの広報 (Releases WG)
• Chromium と Node.js のアップグレード (Upgrades WG)
• 公開 API のデザインの管理 (API WG)
• Electron の堅牢性の維持 (Security WG)
• ウェブサイトの運営、ドキュメント化、ツール作成 (Ecosystem WG)
• コミュニティと企業への働きかけ (Outreach WG)
• コミュニティのモデレーション (Community & Safety WG)
• ビルドインフラ、メンテナーのツール、クラウドサービスの維持管理 (Infrastructure WG)

ガバナンスモデルに移行したのと同じ頃、Electron の所有権も GitHub から OpenJS Foundation に 移行しました。 元々のコアチームは現在もMicrosoftで働いていますが、彼らはElectronの管理体制を形成する、より大きな協力者のグループの一部に過ぎません。²

このモデルは完璧ではありませんが、世界的パンデミックやマクロ経済の逆風が続く中で、私たちによく適していました。 今後は、Electron を次の 10 年に繋げるために、ガバナンス憲章を改訂していく予定です。

コミュニティ​

オープンソースにおけるコミュニティの分野は難しいです。アウトリーチのチームが「コミュニティマネージャー」と書かれたトレンチコートを着た十数人のエンジニアである場合は特に難しくなります。 とはいえ、大規模なオープンソースプロジェクトであるということは、多くのユーザーを抱えているということであり、彼らの Electron に対するエネルギーを活用してユーザーランドのエコシステムを構築することは、プロジェクトの健全性を維持する上で極めて重要な要素です。

コミュニティの活気を高めるために、どのようなことを行ってきたのでしょうか。

バーチャルコミュニティの構築​

• 2020 年に、コミュニティ Discord サーバーを立ち上げました。 以前は Atom のフォーラム欄がありましたが、よりインフォーマルなメッセージングプラットフォームを用意し、メンテナと Electron 開発者間の議論や一般的なデバッグのヘルプのためのスペースを用意することにしました。
• 2021 年には、@BlackHole1 の協力で Electon China というユーザーグループを設立しました。 このグループは、Electron の英語スペースの外でアイデアを出し合ったり Electron について議論したりする場を提供し、中国の活気ある技術市場からのユーザー増加に貢献しています。 また、npm の中国語ミラーである cnpm で Electron のナイトリーのリリースをサポートして頂いたことにも感謝します。

注目度の高いオープンソースプログラムへの参加​

• 2019 年から毎年、Hacktoberfest に参加しています。 Hacktoberfest は、DigitalOcean が毎年開催しているオープンソースの祭典で、オープンソースソフトウェアに自分の足跡を残そうとする熱心な貢献者が毎年何十人も集まっています。
• 2020 年には、Google Season of Docs の初期のイテレーションに参加し、@bandantonio の協力の下で Electron の新しいユーザーチュートリアルのフローを作り直しました。
• 2022 年には、初めて Google Summer of Code の学生のメンターをしました。 @aryanshridhar は、Electron Fiddle のコアのバージョン読み込みロジックをリファクタリングし、そのバンドラを webpack に移行する、素晴らしい働きをしてくださいました。

あらゆるものの自動化！​

現在、Electron のガバナンスには約 30 人のアクティブなメンテナがいます。 フルタイムで貢献している人は半分以下なので、あれもこれもと仕事が多いことになります。 すべてを円滑に進めるコツは何でしょうか？ 私たちのモットーは、コンピュータは安い、人の時間は高い、です。 典型的なエンジニアの活動において、より活動を快適にするための自動化サポートツール群を開発しました。

Not Goma​

Electron のコアとなるコードベースは巨大な C++ コードの塊であり、そのビルド時間はバグ修正や新機能をいかに早く送り出せるかの制限要因となっていました。 2020 年には、Google の分散コンパイラサービス Goma の Electron 専用カスタムバックエンドである Not Goma をデプロイしています。 Not Goma は、認可されたユーザーのマシンからのコンパイル要求を処理し、バックエンドの数百のコアに処理を分散させます。 また、コンパイル結果をキャッシュしておくことで、同じファイルをコンパイルする他の人はそのコンパイル済み結果をダウンロードするだけでよくなります。

Not Goma の立ち上げ以降、メンテナのコンパイル時間が数時間の規模から数分に短縮されました。 安定したインターネット接続さえあれば、Electron をコンパイルできるようになりました！

Continuous Factor Authentication​

Continuous Factor Authentication (CFA) は npm の二要素認証 (2FA) システムの自動化レイヤーで、semantic-release と組み合わせて様々な @electron/ npm パッケージの安全な自動リリースを管理します。

semantic-release でも npm パッケージの公開プロセスは自動できますが、これだけでは二要素認証をオフにするか制限を回避するシークレットトークンを渡す必要があります。

私たちは npm の 2FA の時間ベースのワンタイムパスワード (TOTP) を任意の CI ジョブに配信する CFA を構築し、二要素認証の追加セキュリティを維持しながら semantic-release の自動化を活用できるようにしました。

これには Slack での統合フロントエンドを備えた CFA を使用しています。これによりメンテナは、TOTP ジェネレータが手元にあれば Slack のあるどのデバイスからでもパッケージの公開を検証できます。

Sheriff​

Sheriff は、GitHub、Slack、Google Workspace 全体での権限管理を自動化するために私たちが書いたオープンソースのツールです。

Sheriff の重要な価値提案は、権限管理は透明性のあるプロセスであるべきだということです。 これは上記のすべてのサービスにまたがって権限を指定するために、単一の YAML 設定ファイルを使用します。 Sheriff を使えば、PR を承認してマージするのと同じくらい簡単に、レポジトリのコラボレーターの状況を取得したり、新しいメーリングリストを作成したりできます。

Sheriff には Slack に投稿される監査ログもあり、Electron の組織内のどこかで不審な動きがあったときに管理者へ警告できます。

…そしてすべての GitHub ボット​

GitHub は豊富な API 拡張性を持つプラットフォームであり、Probot というファーストパーティのボットアプリケーションフレームワークを提供しています。 私たちがより創造的な仕事に集中できるよう、私たちの代わりに単純作業をこなしてくれる小さいボット群を構築しています。 以下にいくつかの例を示します。

• Sudowoodo は Electron のリリースプロセスの最初から最後まで、ビルドのキックオフから GitHub と npm へのリリースアセットのアップロードまでを自動化します。
• Trop は、GitHub の PR ラベルに基づいて以前のリリースブランチへのパッチの cherry-pick を試みることで、Electron のバックポートプロセスを自動化します。
• Roller は、Electron の Chromium と Node.js の依存関係のローリングアップグレードを自動化します。
• Cation は、electron/electron の PR のステータスを確認するボットです。

このような小さなボット家族のおかげで、開発者の生産性が大幅に向上しました！

今後の予定は?​

プロジェクトとして次の 10 年を迎えるにあたって、疑問に思われることでしょう。Electron はこれからどうなるのでしょうか？

私たちは、Chromium のリリースケイデンスに同期して 8 週間ごとに Electron の新しいメジャーバージョンをリリースし、エンタープライズ級のアプリケーションの安定性と堅牢性を維持しながら、ウェブプラットフォームと Node.js による最新で最高のフレームワークを保ち続けます。

今後の取り組みについては基本的に、具体的になった時点でお知らせします。 今後のリリース、機能、一般的なプロジェクトの更新について知りたい方は、ブログ をご覧頂くか、ソーシャルメディアのプロフィール (Twitter や Mastodon) をフォローしてください!

Electron チームは、今年初めて Google Summer of Code に参加することをお知らせします!

Google Summer of Code とは何ですか?​

Google Summer of Code (GSoC) は、オープンソースソフトウェアプロジェクトと潜在的な貢献者をつなぐ、年に一回のメンタリングプログラムです。 以前は学生だけでしたが、現在は 18 歳以上であれば誰でも GSoC に登録できます。

詳しい情報については Summer of Code のホームページ をご確認ください。

登録方法は何ですか?​

Electron との共同開発に興味はありますか? オープンソースのコントリビューターを始めたばかり方や初心者であれば、ぜひご応募ください!

Google Summer of Code の Electron コントリビューターとして選ばれるためには、ご応募していただく必要があります。 応募開始は 2022 年 4 月 4 日、締め切りは 2022 年 4 月 19 日 となります。 Google Summer of Code の応募要項はこちらで更新しています。

応募をご希望ですか? まずは、私たちがご用意した 5 つのプロジェクトアイデア案 をご覧ください。 掲載されているアイデアは、すべて企画のために現在公開中のものです。 また、企画プロジェクトのリストにない新規アイデアも受け付けています。

応募には以下のものがあるとよいでしょう。

• 企画書。この夏のプログラムの間に達成する目標の計画を詳細に記した文書です。
• 開発者としての経歴。 レジュメをお持ちの方はコピーを添付してください。または、関連する技術的な経験を中心に、これまでの経験をお聞かせください。

Electron への応募にかかる提出物の詳細は、こちらをご覧ください。

また GSoC 学生/コントリビューター公式ガイド には、企画書を作成する際の重要なヒントが記載されていますので、ぜひご覧ください。

プロジェクトの企画について議論したい方や質問がある方は、#gsoc-general Discord チャンネル にぜひいらしてください!

リファレンス​

• Electron 企画ガイド
• Electron GitHub
• プロジェクトアイデアのドキュメント
• Google Summer of Code 学生/コントリビューターガイド

コミュニティの絆とオープンソースの1ヶ月間のお祝いのために私たちに参加してください。

Electron コミュニティの Discord の立ち上げ

Electronの Outreach ワーキンググループ は、 公式コミュニティ Discord サーバーの立ち上げを発表することを楽しみにしています！

なぜ新しいDiscordサーバーなのか？​

Atom テキスト エディタののバックボーンとして、Electron フレームワークに関するコミュニティでのディスカッションは、Atom の Slack ワークスペースの1チャネルで行われていました。 時間が経ち、2つのプロジェクトが分離していくにつれて、AtomワークスペースとElectronプロジェクトとの関連性は低下し、Slackチャンネルへのメンテナンの参加者も同様に低下しました。

これまで、招待を受け取るのに苦労したと多く人からの報告を受けました。コアメンテナンス担当者のほとんどがチャンネルを頻繁に行なっていたにもかかわらず、より広範なコミュニティをAtom Slackワークスペースにリダイレクトしていました。

この新しいサーバーは、Electron に関する最新情報を得ることができる、コミュニティの中心的な議論の場となるようにしています。

ぜひお越しください!​

今のところ、サーバーのメンバーシップは数人のメンターが協力して立ち上げていますが、皆さんとお話しできることをとても楽しみにしています。 助けを求めたり、Electron の最新情報を得たり、他の開発者と交流したりできます。 サーバーにアクセスできる便利な 招待リンク をご用意しました!

Hacktoberfest 2020

大規模で長期間実行されているオープンソースプロジェクトとして、Electronはコミュニティからの貢献なしにはほとんど成功しませんでした。 コードの提出からバグレポート、ドキュメントの変更まで様々です。 だからこそ、Hacktoberfest に参加することで、あらゆるスキルレベルの開発者たちがより広いコミュニティでプロジェクトに参加できるようになることが重要だと考えています。

寄せ集め物​

今年は、あなたにすべてを与えるより広いプロジェクトを持っていません。しかし、Electron JavaScript エコシステム全体に貢献する機会に焦点を当てたいと思います。

私達のさまざまリポジトリで hacktoberfest のタグのある課題をみてください。メインの electron/electron リポジトリ、electron/electronjs.org ウェブサイト、electron/fiddle、それに electron-userland/electron-forgeもあります。

P.S. 特に冒険したい方向けに、help wanted タグが付けられた Issue のバックログも用意しています。

つまづきましたか? 一緒にチャットしてみましょう!​

さらに、私たちの Discord サーバーのグランドオープンが、今年最大のオープンソースソフトウェアの祭典と重なったのも偶然ではありません。 Hacktoberfest の PR に協力してもらうためにも、#hacktoberfest チャンネルをチェックしてみましょう。 見逃した方のために、招待リンクをこちらに再びご用意しました!

Google Season of Docs 第 2 段に参加させていただき、Electron としては大変光栄です。このイニシアティブでは、オープンソース組織のメンターとテクニカルライターがペアを組み、プロジェクトのドキュメントを改善していきます。

Season of Docs とは何ですか?

Season of Docs は、テクニカルライターとオープンソースコミュニティのコラボレーションを促進し、両者の利益に貢献するプログラムです。 オープンソースのメンテナーは、ライターのテクニカルライティングの専門知識を活用して、ドキュメントの構造と内容を改善します。テクニカルライターは、指導者の指導のもとオープンソースのコミュニティへ派遣されます。 詳細は Google の Season of Docs ウェブサイト で解説しています。

このプログラムに初めて参加した弊社では、テクニカルライター 1 名をメンターとして迎え、Electron の エコシステム作業グループ と協力しドキュメントの大部分を再構築していきます。 プロジェクト全体のタイムラインについては、こちら をご覧ください。

登録方法は何ですか?

テクニカルライターとして弊社とのコラボレーションに興味がございますか? まずは、今年のプログラムのために Google の テクニカルライターガイド を把握し、用意した 2 つの プロジェクトのアイデア草稿 をご確認ください。

Season of Docs のテクニカルライターとして採用されるには、6 月 8 日から 7 月 9 日までの期間中に Google Season of Docs のウェブサイトから応募する必要があります。

応募書類には、3 ヶ月間 Electron ドキュメントで何を成し遂げようとしているのかを詳細に記述した提案書を添付してください。 この提案書は、プロジェクトのアイデア草稿に記載した出発点のいずれかを発展させた内容か、全く新しいものにして頂いて構いません。 どこから手を付ければいいのかわかりませんか? 昨年の 受理された提案書のリスト を閲覧して、知見を得ることもできますよ。

提案書とは別に、テクニカルライターとしての経歴も審査されます。 履歴書には、テクニカルライティングのサンプル (既存のドキュメント、チュートリアル、ブログ記事など) と、加えて関連するライティング経験を強調したコピーを添付してください。

プロジェクトの提案を議論したい場合は、season-of-docs@electronjs.org までメールでお問い合わせください。そこからお話しましょう!

リファレンス

• Electron ドキュメント
• Project のアイデアドキュメント
• Season of Docs テックライターガイド