OSSプロジェクトへのコントリビューションはじめの一歩を踏み出そう!（Open Source Conference 2022 Online/Spring 発表資料）

© 2022 NTT DATA Corporation
OSSプロジェクトへのコントリビューションはじめの一歩を踏み出そ
う!
- ちょいちょいApache Sparkの紹介をはさみながら -
2022/3/11
株式会社NTTデータ技術開発本部
猿田浩輔
オープンソースカンファレンス2022 Online/Spring

2
$ whoami
 猿田浩輔
 株式会社NTTデータ技術開発本部
 Apache Sparkコミッタ & PMCメンバ
 Hadoop/Sparkなど、OSSミドル関連のR&Dや技術支援
 普及活動の一環で講演や書籍執筆なども
 Twitter: @raspberry1123

3
こんなチームメンバがいるところで働いています
Apache Hadoopコミッタ
• Hadoopの継続的な品質改善
• HTrace のモジュール開発
• HDFSにトレーシング機能を追加
• Hadoop→PostgreSQL高速ロード対応
• 非同期レプリケーションの実現
• 同期レプリケーションの実現
• カスケードレプリケーションの実現
• pg_bigm(全文検索モジュール)の開発
岩崎正剛
Apache Sparkコミッタ
Apache Bahirコミッタ
• Spark内部タスクの可視化
(Timeline Viewer)
• Sparkメトリクス機能改善
• SparkとYARNの連係動作の改善
猿田浩輔
PostgreSQLコミッタ
藤井雅雄
Apache BigTop PMC コミッタ
Apache Yetus PMC/コミッタ
Apache Airflow コミッタ
Apache Thrift コミッタ
関堅吾
• JVMデバッガの改善、拡充
• JVM運用機能の改善、拡充
• JVMロギング機能の改善
• HeapStatsの開発
末永恭正
OpenJDK レビュワー
IcedTea コミッタ
阪田浩一
Java Champion
今喋ってる人

4
本日のお話 - OSS開発プロジェクトに参加してみよう! -
 OSSをただ使うだけなのはもったいない！
 開発コミュニティと関わることで、OSSのメリットをもっと享受できる。
 情報収集
 開発への参加
 これまでいくつかのOSS開発プロジェクトに関わってきた経験を基に、OSSのメリットを活かし
た、開発プロジェクトとの関わり方をご紹介

情報収集してみよう

6
情報収集
 コミュニティと関わることで得られる情報がある
 開発動向
 不具合などの情報
 使っていて困ったことを共有/質問できる
 情報収集の仕方も色々
 メーリングリストやフォーラム、Slackの活用
• コミュニティが運営しているものや、ユーザ会が運営しているものもある
• ユーザ向けのものと、開発者向けのものが分けられている場合は用途に応じて使
い分ける
• 開発者向けのものであっても、コミッタ以外でも参加できるものが多い
 イベントへの参加
 GitHubやJIRAなどから不具合の情報を収集したり、開発状況を覗いてみる

7
イベントへの参加
 メジャーなOSSだと、日本でもユーザ会があることが多く、ユーザ会主導のイベ
ントなども開催されている
 日本〜ユーザ会や日本〜ユーザグループなど
 イベントはconnpassやTECH PLAYなどで探せば色々見つかる
• https://connpass.com
• http://techplay.jp
 大きなOSSプロジェクトだと、世界規模の年次イベントが開催されるものもあ
る
 世界中のユーザや開発者と繋がりを作る機会
 昨今はオンラインかつ無料で参加できるイベントも増えてきており、参加
のハードルが下がった印象
 言語的なハードルは頑張って飛び越える必要はある・・・

8
突然の宣伝: Spark関連のイベント(Data + AI Summit)のご紹介
 Sparkコミュニティ最大のイベント
 2013年から始まるイベント。当時の名称はSpark Summit
 世界中の開発者やユーザや開発者が一堂に会して、ユースケースや最新動向などが発表
される(2020年6月からはオンラインでの実施)
 直近開催されたのはDATA + AI Summit 2021
 F2Fで開発者と議論やコネクションづくりができる機会でもある
 割と大きめの機能追加などを考えているのであれば、F2Fだと話が早かったり
 2020年からはオンライン開催になったが、コミュニケーションがとりやすいプラットフォー
ムが活用されており一方通行にならないようにイベントが運営されている
 次回は6/27 - 6/30 (PDT)開催のDATA + AI Summit 2022
 リアル / オンラインのハイブリッド開催
 https://databricks.com/dataaisummit

開発に貢献してみよう

10
開発者としてコミュニティに関わる意義やモチベーション
 開発に関わることで、自分たちが使うものをよりよく育てることにつながる
 日本人の感覚(品質や細かい部分の作りこみ)を自分たちが使うOSSの改善に活か
してほしい
• 安定性、運用のしやすさや、いざという時のトラブルシュートのしやすさなど
 コミュニティに向かって声を上げないと伝わらない
• 必要なものは必要だと伝えることが大事
 パッチがマージされるとリリースノートにクレジットされるプロジェクトもある

11
開発者としての参加の仕方もいろいろ
 開発に参加する方法はパッチ投稿だけじゃない！
 不具合の報告や機能追加提案、改善提案なども立派な貢献
• 自分たちでパッチを書かなくても、登録するだけでもよい
• 声を上げることが大事(ただし機能追加や改善提案の場合は必然性もセットで)
• ただし、脆弱性の報告は適切な手順を踏むべし
• 報告は必要だがいきなり公開しない
• プロジェクトごとに手順が定められていることが多い。わらなければ報告の仕方
を聞いてみるのがよい
 パッチのレビュー
 メーリングリスト/フォーラム/Slack上での議論への参加
• コミッタ以外でも議論に参加できるプロジェクトは多い
• ユーザ視点からの意見はプロダクトの改善にとって重要

12
パッチを寄贈して開発に貢献する
 バグ修正 / 機能追加 / ドキュメントの修正などを行い、パッチをコミュニティに還元しよう
 秘蔵のパッチを適用し続けたOSSを運用し続けるメリットはあまりない
 メインストリームから乖離する
• それ、全部自分たちで保守し続けるんですか？
• 秘蔵パッチを当てたバイナリでトラブルが起こっても、コミュニティの人たちは普
通は面倒を見てくれない・・・
• マージコンフリクトだらけでバージョンアップが困難になる
• いつのまにかバージョンアップ不能なほどつぎはぎだらけに・・・
 パッチの品質
• 場当たり的なパッチ (当面の問題は解決しているが、別の部分に悪影響をもた
らしているかも・・・？)
• コミッタを含む、コミュニティの人たちからレビューを受けたほうが良い

13
そうは言っても参加のハードルが高いのでは？
 でも、パッチを投稿しようにもコードとか書けないし・・・。
 ドキュメントの修正やブラッシュアップのパッチならコードが書けなくても大丈夫
 やりとりは英語なんでしょ？
 世界中で使われているOSSだと英語が共通言語なことが多い・・・。でも大丈夫。意
外と通じる！
 マサカリとか飛んでくるんじゃないかと・・・
 プロジェクトごとに厳しさの濃淡はあるかもしれませんが・・・
 コードレビューでおびただしい指摘を受けることもあるが、多くの場合は紳士的にコード
やアプローチの良し悪しについての指摘に閉じている
 間違えても大丈夫
 手順やお作法がありそれに則って進めるべきだが、間違えていたら教えてくれる
 パッチを寄贈してみたいがネタがない・・・という場合は？
 誰でも実践できる、ネタ探しのヒントを次のページからお伝えします

明日から誰でも実践できる
パッチネタの見つけかた

15
パッチを寄贈する前に
 最低限必要なこと
 対象となるOSSを自分で動かせる
• コード修正後の動作確認や、バグの再現など、色々な局面で動かす必要が出
てくる
 自分でビルドできる
• ビルドできないことには、コンパイルが通るか確認できない
• 大抵の場合、リポジトリに開発者向けのREADMEや、公式Webサイトの開発
者向けページに手順が記載されている
 パッチの投稿手順を確認しておく
 プロジェクトごとにお作法が定められていることが多いので、パッチを投稿する前に確
認しておくべし
 プロジェクトのWebサイトでコントリビュータ向けの説明されていたり、ソースツリーのトッ
プにCONTRIBUTION.mdなどわかりやすいテキストがあることが多い。

16
明日から誰でもできる、パッチネタ発見のヒント
1. ドキュメントやソースコードを読んで動かしてみる
2. オープンになっている問題に挑戦する
3. 依存ライブラリをメンテナンスする
4. 真似してみる
5. 新しい実行環境やビルド環境をサポートするタイミングで発生するタスクを手分けして解決
6. Flakyなテストに立ち向かう

17
ドキュメントやソースコードを読んで動かしてみる
 対象となるOSSをよく知るという意味でも、最初のステップとしておすすめ
 動かしてみると、ドキュメントの内容と異なる挙動をしたり、Exampleが動かないというケー
スもある
 ドキュメントが追いついていないことは割とありがちな印象
 ソースコードを見てみたら、ドキュメントにない機能が実装されていることに気づくこがある
 新しい機能や、相対的にあまり使われていない機能は、不具合が見つかりやすい傾向が
ある
 まだ荒削りな部分が残っている可能性がある
 新しい機能はリリースノートなどで確認すべし
 中には実験的に追加された機能であることが明記されている場合もあるので、そう
いった情報から安定性を推し量ることもできる

18
オープンになっている問題に挑戦する
 報告されているが、誰も解決に着手していない問題(オープンな問題)を探して取り組む
 報告されている内容から、「本当に問題か」判断できるとよい
 単にユーザが使い方を間違えていたり、新しいバージョンでは解決していることもある
 報告した人物のプロファイルから、問題の確度を推し量ることもできる
• コミッタ
• 熱心なコントリビュータ
• 使い倒しているユーザ
 プライオリティはわかることが多いが、実装難易度は読み取りづらいこともある
 対象となるOSSの実装レベルでの理解が深まると、内容から難易度を読み取る「嗅
覚」が養われる
 報告されている問題を、自分の環境で再現できるスキルは必要

19
依存ライブラリをメンテナンスする
 巨大なOSSプロジェクトでは、さまざまなライブラリに依存していることが多いため、これらのメ
ンテナンスも必要
 依存ライブラリに次のようなアップデートがあった場合はバージョンアップの検討の余地がある
 プロジェクトが依存しているバージョンがEOLになっている場合
 プロジェクトに有用な新機能が追加されたバージョンがリリースされた場合
 プロジェクトが影響を受けるバグフィックスが適用されたバージョンがリリースされた場合
 依存ライブラリにCVEが報告され、対策済みのバージョンがリリースされている場合
 CVEの情報収集の仕方
 オフィシャルには各ライブラリ開発プロジェクトやMITREからのアナウンスがある
 他のOSSプロジェクトが脆弱性脆弱性対策をしているのを見て気づくこともある
 そのほかTwitterなど色々な情報ソースから把握できる

20
真似してみる
 他の人が寄贈したパッチを真似してみる
 GitHubのプルリクエストやメーリングリストに投稿されたパッチなど、日頃から観察した
り、レビューに参加するとよい
 似ている部分に対するパッチも真似しやすい
• 複数の言語バインディングやファイルフォーマット、JDBCドライバなどをサポートして
いる場合など
• 各言語でのAPIカバレッジを向上させたり、どのファイルフォーマットでも同じ
ユーザビリティを達成する
 その他、気づかなかった貢献の仕方が見つかることもある
 他の似ているプロダクトを真似してみる
 例えばSQLをサポートしているプロダクトであれば、ANSI Standardで定義されてい
る構文やビルトイン関数のサポートなど
 標準ではないものの、他のDBMSでサポートされている便利なビルトイン関数のサ
ポートなど

21
新しい実行環境やビルド環境をサポートするタイミングで発生するタスクを手分けして解決
 新しい実行環境やビルド環境をサポートするにあたっては、やることが山ほどあることが多い
 例えばHadoopではJava9でのビルドをサポートする過程で大量のタスクが発生した
 Java9からモジュール機構が導入されたり、許容されない変数名など非互換が少な
くなかったため、移行は大変だった模様
 Sparkでも、Java11やScala 2.13での実行をサポートするのは一苦労だった
 Scala 2.12から2.13にかけて、コレクションライブラリ周りで互換性を壊す変更が加
えられたため、Sparkがわも変更が必要な箇所が多かった
 今後Scala 3対応でも苦労しそうな予感
 今だとJava 17対応を進めているプロジェクトも出てきた
 Sparkでも着々と進めている
 やることが多いので、機会を見逃さなければ貢献できるチャンス
 タスクの一部を引き受けることで貢献する

22
Flakyなテストに立ち向かう
 Flakyなテストとは？
 大抵はパスするが、たまに失敗するテスト
 再実行するとパスしたりするので厄介
 CIが健全な状態にならないので、Flakyなテストが多いとプロジェクト的には困る
 GitHubでホストされているプロジェクトだと、ビルドステータスが×になっているコミットに注目
する
 当該コミットでの修正とは関係のないテストが失敗している場合はflakyな臭い
 (いつもそうとは限らないが)マルチスレッド/マルチプロセス絡みの競合に起因していることが
多い印象
 Flakyな挙動の原因になっているのはテストそのものの場合もあれば、本体のコード
の場合もある。
 どのようなメカニズムでテストが失敗するのか把握し、適切なツールの活用を活用して
粘り強く解決する

23
より円滑に進めるために
 開発に関わっている人たちを知る
 コミッタ
 アクティブなコントリビュータ
 使い倒しているユーザ
 粘り強さも重要
 議論が長期化す場合や、バグの再現に苦労する場合もあるが、「考えながら」粘り
強くやり遂げる
 バグフィックスや機能開発をするのであれば、デバッグ手段は色々持っておくと便利
 デバッガ
 パケットキャプチャ
 リソース統計収集ツール

コミュニケーションの仕方や
コミュニティでのふるまい方

25
英語でのコミュニケーション
 メジャーなOSS開発プロジェクトでの公用語は英語であることが多いが、意外と簡単な英
語でも通じる！
 私も英語は苦手だが、なんとか(?)やれている・・・。
 語順と時制が合っていれば大体通じる
 時制の間違いも、特に混乱をきたさない場合は大体空気を読んでくれる
 複雑なことを説明する際無理に長い文章にせず、箇条書きに
すると伝わりやすい
 他人が使っているフレーズをまねるのもよし
 GitHubや上での議論やメーリングリストでのやりとり
 もし自分の理解が怪しい時には、素直に確認すればOK
 You mean 〜 right? (〜ってこと？)
 Could you elaborate on that? (詳しく説明してもらえますか？)
 とはいえ、英語上達の努力を怠ってはいけない・・・

26
(余談) GitHubやJIRA上でよく見かける略語
略語元々の表現意味シチュエーション
LGTM / SGTM Looks / Seems good
to me
よさそうですパッチやアイディアなどに
ついてのコメント。主にレ
ビュアーやコミッタが使う
IMO / IMHO In my (humble)
opinion
私の考えでは〜議論の中で使われる。
意見が対立した時など
FYI For your information 補足情報など
AFAIK As far as I know 知る限り〜わりとどこでも
BTW By the way ところで話題転換
a.k.a Also known as 〜としても知られていま
す
わりとどこでも
更に知りたい方はこちら(Spark界隈ではお目にかかったことが無いものもありますが・・・)
http://qiita.com/uasi/items/86c3a09d17792ab62dfe

27
コミュニティと関わる上で気をつけた方が良いこと
 いきなり巨大なパッチを投稿しない
 レビューする人も大変
 分割できるものは分割したり、大きな機能は事前にMLで議論するのが良い
 実効的な影響のない変更を加えるパッチは避ける(意外とある)
 例えば変数名のタイポや無駄なimport文の除去など・・・
 何かの修正のついでに一緒に直したりするのがよい
 ユーザの目に触れるような、ドキュメントのタイポ修正は受け入れられるはず
 他人を罵倒しない
 粗悪なコードを憎んで人を憎まず。客観的に、コードのどの部分がどうよくないのか、ど
う修正した方が良いのか指摘するとOK
 あまり見たことないが・・・

まとめ

29
まとめ
 OSSは使うだけでなく、コミュニティに参加することでさらにメリットを享受できる
 情報収集
 開発への参加
 情報収集の手段としてコミュニティに関わることもできる
 メーリングリスト/フォーラム/Slack
 イベントの参加
 開発への参加の仕方もいろいろある
 不具合の報告や要望の提案
 開発の議論への参加
 パッチの寄贈
 誰でも明日から実践できる、パッチネタの見つけ方もある
 日本からもっとOSSへのコントリビューションを・・・！

本資料に記載されている会社名、商品名、又はサービス名は、各社の登録商標又は商標です。

OSSプロジェクトへのコントリビューションはじめの一歩を踏み出そう!（Open Source Conference 2022 Online/Spring 発表資料）

More Related Content

What's hot (20)

Similar to OSSプロジェクトへのコントリビューションはじめの一歩を踏み出そう!（Open Source Conference 2022 Online/Spring 発表資料） (20)

More from NTT DATA Technology & Innovation (20)

Recently uploaded (11)