今日から始める OpenSearch OSS コントリビューションのススメ

OpenSearch Meetup #2 登壇資料です

Transcript

1. 今日から始める OpenSearch OSS コントリビューションのススメ Sotaro Hikita Specialist SA, OpenSearch Amazon Web Services
2. ⾃⼰紹介 ⽦⽥ 宗太郎 (ひきた そうたろう) AWS で主に OpenSearch を中⼼に活動しています 本⽇は野⽣の OSS 開発者としてお話します 趣味 • ビッグデータに関わるオープンソース コミュニティへの貢献 (Apache Iceberg, OpenSearch etc) • opensearch-hadoop メンテナ • 最近は Lance が気になる
3. 本セッションのねらい OpenSearch に向けた OSS 開発の魅⼒と最初のステップを解説する ねらい • OSS / OpenSearch を開発する楽しさや魅⼒を伝えたい • OpenSearch へのコントリビューションの具体的な流れを解説したい 留意点 • コードを開発する、狭い意味での「OSS 貢献」を扱います • 広い意味では、ブログ記事やバグ報告、Issue の起票や議論、 コミュニティイベントへの参加、登壇など、貢献の在り⽅は多様です 3
4. ⽦⽥ / lawofcycles の OpenSearch 向け OSS 活動 2026/1 – 2026/10 で 48 件の PR をマージ リポジトリ opensearch-hadoop data-prepper documentation-website OpenSearch index-management project-website opensearch-java neural-search Issue 起票 19 17 3 6 2 2 0 1 マージ済 PR 22 12 6 3 2 1 2 0 レビュー対応 31 1 1 1 0 0 0 0 合計 67 48 34 https://github.com/lawofcycles
5. ⽦⽥ / lawofcycles の OpenSearch 向け OSS 活動 2026/1 – 2026/10 で 48 件の PR をマージ ジャンル別の件数 主な活動 ジャンル 件数 • opensearch-hadoop の OpenSearch 3系, Spark 4系 機能追加 15 対応と v2 リリース バグ修正 12 • opensearch-hadoop メンテナ業 ビルド / CI 整備 11 ドキュメント 8 • Data Prepper Iceberg source, テスト基盤 1 JDBC coordination store 開発 リファクタリング 1 • Pull Based Ingestion Hive Source 開発 合計 48 ほか、Flaky テスト修正など地味な作業も https://github.com/lawofcycles
6. OSS 開発は仕事でやっている︖ Yes and No • ほぼ全ての作業を⼟⽇、夜間に⾏っている • 仕事の過程でユーザーのニーズや課題に気づくことはよくある • OSS 活動が巡り巡って仕事に繋がることも⼀応はある - 間接的、中⻑期的なことも多いが… • 上⼿く公私混同する⽅法を⽇々探っている - OpenSearch 担当に社内異動するなど - 仕事と⾔い張ってカンファレンスへ海外出張したり (⾃社に感謝)
7. OSS 開発のモチベーション︓楽しいから! • 興味のある技術/ソフトウェアに打ち込める - 仕事に関係ないからこそ、好きなことができる - ソフトウェアを作り、育て、価値を提供する までのライフサイクルを思い通りに進められる • 世界が広がる - いつも使っているサービスの中の⼈から 機能要望が来たり… - 世界に名だたる企業で働く開発者のコードを レビューしたり、レビューされたり、 ブログを書いたり… OpenSearch メンテナの Michael Froh ⽒と、 OpenSearchCon NA にて
8. OSS 開発のモチベーション︓仕事の役に⽴つ…こともある • OpenSearch の機能不⾜やバグで困った時に、 ⾃分で直すことで解決できる場合がある - このパターンは状況によっては完全に仕事として取り組める • キャリアの役に⽴つ…かもしれない（︖） - 今のところあまり実感はないが… 楽しいことをした上で、仕事やキャリアの役にも⽴つかも?ぐらいの モチベーションがちょうど良さそう (楽しくないと、続きづらいかも)
9. OSS 活動をする舞台として OpenSearch がオススメな理由 OpenSearch は成⻑期のソフトウェア 様々な可能性を秘め、⽇々進化しているが故に不完全な部分がある 様々な可能性︓新しいアイデアをオープンに議論する⾵⼟がある Data Prepper のソースに Iceberg を追加するという斜め上な提案をしたら、 メンテナやユーザーがとても前向きに興味を持ってくれた https://github.com/opensearch-project/data-prepper/issues/6552
10. OSS 活動をする舞台として OpenSearch がオススメな理由 様々な可能性︓新しいアイデアをオープンに議論する⾵⼟がある コミュニティSlack での⼀幕 (要約) ⽦⽥「OpenSearch が gRPC 対応して indexing めちゃ速くなったらしいね。 os-hadoop も gRPC やらないとな」 メンテナ「いいね︕ところで、Pull Based Ingestion で Hive テーブルから直接 Ingestion できたら便利だと思うんだよね」 ⽦⽥「まじでか」 → PBI Hive Table Source 実装へ https://opensearch.slack.com/archives/C038PDJ14JZ/p177431 5402239909 https://github.com/opensearch-project/OpenSearch/pull/21700
11. OSS 活動をする舞台として OpenSearch がオススメな理由 ⽇々進化しているが故に不完全: 多様な貢献のチャンスがある ドキュメント追加 既存機能のレベルアップ バグ修正 Flaky テストの修正
12. OSS 活動をする舞台として OpenSearch がオススメな理由 OpenSearch の開発には多様な領域の専⾨知を結集する必要がある = それぞれの得意分野に応じた活躍の場がある︕ Skills, MCP Server ⾔語別クライアン トライブラリ (Java, Go, Rust, Python, hadoop etc) 地理空間検索 検索品質評価(SRW) o11y ISM ベンチマークツール セキュリティ分析 セキュリティ 統合 API 仕様 Stream Base ETL エンジン (data-prepper) 機械学習モデル (Sparse vector, Semantic Highlig など) SQL / PPL Timeseries DB 全⽂検索 ベクトル検索 Analytics エンジン OpenSearch Dashboard / UI 分散処理エンジン (OpenSearch Core) インフラ (k8s operator,helm-chart) IaC (terraform-provider, Ansible など) and more !
13. OpenSearch Foundation の開発体制 コンポーネント / リポジトリ別の分権的な開発体制 Governing Board 役割: Foundation の予算管理・運営を監督 構成: Premier/General メンバー企業の代表 + TSC の議⻑ 技術的監督には関与しない コンポーネント別の 154 個のリポジトリ群 OpenSearch Core Dashboards knn opensearch-py Data Prepper opensearch-hadoop Public と Maintainer の間に第三の 「Member」 ロールを置く計画が進⾏中 Technical Steering Committee 役割: OpenSearch プロジェクトの 技術的⽅向性のリード 構成: 全リポジトリ横断での メンテナによる⽴候補、投票で選出 リポジトリごとに 2 階層のロールが存在 Public： GitHubアカウントを持つ全員が対象。 Issueの作成・コメント、プルリクエストの提出・ 重複マーキング）、Issueへの直接アサイン。 Maintainer： 他のメンテナによる推薦と投票で任 命されるリーダー。技術戦略の策定、開発の⽅向 付け、プルリクエストのマージ最終承認を担う。 https://opensearch.org/blog/climbing-the-ladderunderstanding-opensearchs-contribution-ladder-policy/
14. 開発の⼤まかな流れ ① 関連するリポジトリを⾒つける ② Issue を起票する。起票前に重複する Issue がないかを探してお く。開発までやりたい場合は、Issue 内で PR を送る意思を表明 するとスムーズ（報告のみしたい場合は、ここまででOK） ③ 対象のリポジトリをフォークする ④ フォークしたリポジトリをクローンして適宜修正、テストを⾏う （spotlessの実施などは各リポジトリの流儀に従う） ⑤ コミットしてプッシュする ⑥ PRを作成する。CI が正常に完了することを確認する
15. https://zenn.dev/opensearch/articles/b6ea3f0d8b596c
16. AI と OSS 開発 • AI を使った OSS への PR とどう向き合うべきか (AI Slop問題) はホットなテーマ • OpenSearch プロジェクトは今のところ AI を使った開発に関する ポリシーを設けていない • ⽦⽥の個⼈的な意⾒としては、以下が重要と思っている - ⼈間が PR のコアとなるアイデアと実装を E2E で理解すること - ⼈間がコミュニケーションの責任を持つこと - AI の利⽤をオープンに開⽰して、不安な点はきちんと相談すること
17. Apache Iceberg の ガイドライン (抜粋 & 参考訳) • 実装を⾃分で理解する PRの設計・コードについて、レビュー時に⾃分の⾔葉で説明・根拠を⽰せること • スタイルを合わせる タイトル・コミットメッセージ・コードは、既存コードベースのスタイルに沿うこと • AIは加速に使い、必ず⾃分で検証する AI出⼒はあくまでドラフトとして扱い、リンター・テストの実⾏とロジックの確認を⾃分で⾏うこと • AI使⽤と不確かな点を開⽰する AIを使⽤した箇所（ドラフト作成・リファクタリング・テスト雛形など）と、複雑なロジックや内部 APIに関する前提・不確実な点をコメントに明⽰し、レビュアーが重点的に確認できるようにすること • ASFポリシーを遵守する ⽣成コンテンツがライセンス違反や第三者コードの無断混⼊につながらないよう確認し、疑わしい場 合はASFのガイダンスを参照すること • セキュリティ報告は再現確認を必須とする AIスキャン結果を元にしたセキュリティ報告は、問題の再現可能性を確認し、再現⼿順を明確に記載 してから提出すること（トリアージに要する⼿間を減らすため） https://iceberg.apache.org/contribute/#guidelines-for-ai-assisted-contributions
18. Apache Lucene の ガイドライン (抜粋 & 参考訳) • AIツールの使⽤は認める、ただし責任は⼈間が 負う コーディングへのAI活⽤は⽀持するが、公開す るコードへの責任は投稿者に、マージ・リリー スへの責任はメンテナーにある。貢献物の品質 基準は⾼く維持する。 • コミュニケーションへのAI使⽤は禁⽌ コメントはAIで⽣成しないこと。AI⽣成と判断 されたコメントは⾮表⽰にする場合がある。 • Issueは⾃分の⾔葉で 問題の説明は⾃分⾃⾝の⾔葉で記述すること。 • PRも⾃分の⾔葉で説明できること PR本⽂やメンテナーへの返答を含め、変更内容 を⾃分の⾔葉で説明できること。返答にAIの回 答をそのままコピーしないこと。 • ⾃律エージェントによる貢献は不可 プロジェクトの重要性から、AIが⽣み出した 成果物を理解する⼈間の関与を必須とする。 ⾃律エージェントによるPRは閉じる。 • AIとのやり取りを引⽤する場合のルール コメントにAIとの会話内容を含める場合は、引 ⽤ブロック（>）で明⽰すること。その内容の意 義と関連性について、⾃分⾃⾝のコメントを添 えること。⻑い引⽤は不可。 • ⾮⺟語話者のAI活⽤について 英語が⺟語でない場合のコメント編集へのAI活 ⽤は理解するが、⾃分の⾔葉・考えが反映され ているか確認すること。翻訳に使う場合は⺟国 語で書いたものをAI翻訳し、引⽤ブロックとし て添付することを推奨。 https://github.com/apache/lucene/blob/main/AI_POLICY.md
19. 「とはいえ、何から始めれば…?」への Tips OSS 貢献に興味を持ってすぐの頃は、 やる気があるのに何をしていいのかわからない状態になりがち • ⾝近なユースケースから、提案、改善できることがないか考える - 普段の仕事で接する課題が⼀番の近道 • 新機能を隅から隅まで触って、提案、改善できることがないか考える - 新しい取り組みにはいつも何かしら課題があるもの • (発展編)業界やプロジェクトの中⻑期的な⽅向性から、 提案、改善できることがないか考える
20. まとめ • OSS 開発を通じて、興味のある技術やソフトウェアへの 理解を深め、コミュニティと共に発展させる楽しさが味わえる - もしかすると、仕事やキャリアの役にも⽴つかもしれない • OpenSearch は幅広い⼈々が活発に取り組む成⻑期のプロジェクト で、関係する技術スタックの広さからも、OSS 活動におすすめ • 開発に AI を利⽤する上では、⼈間が開発内容とコミュニケーショ ンに責任を持つべき（と⽦⽥は考えている） • 最初は⾝近なユースケースや、新機能を試すところから始めてみる のがオススメ 今⽇から皆さんも楽しい OSS ライフを︕︕︕︕