builderscon2017の発表資料です。 https://builderscon.io/tokyo/2017/session/182ba13a-ccd5-4ddd-9565-c4e20df1d871

1. OSS貢献超入門
builderscon2017
2017/8/5 shigemk2

2. 自己紹介
● shigemk2
● アドテクエンジニア
● ScalaとかHadoopとかReactとか
● http://www.shigemk2.com/

3. 超結論
好きなリポジトリを
ウォッチしよう

4. 今日の流れ
1. 対象者
2. OSSとは
3. 貢献できない理由
4. 出来ない理由を片付けていく
5. ケーススタディ

5. 今日の流れ
1. 対象者
2. OSSとは
3. 貢献できない理由
4. 出来ない理由を片付けていく
5. ケーススタディ

6. 皆さん
OSS開発できてますか？

7. 今日の対象者
(いろいろ理由があって)
OSS開発したくてもできない

8. (いろいろ理由があって)
OSS開発したくてもできない
=わりと昔の自分

9. 今はわりとできてると思う
● Emacs
● cookpad/kuroko2
● rundeck
● github/hub
● なんか毎週Issueとかプルリクとか投げてる気がする

10. 今日の流れ
1. 対象者
2. OSSとは
3. 貢献できない理由
4. 出来ない理由を片付けていく
5. ケーススタディ

11. OSSとは
● 概念に基づき、ソフトウェアのソースコードが無
償で公開され、改良や再配布を行うことが誰に
対しても許可されているソフトウェアのこと
○ http://www.weblio.jp/content/オープンソースソフトウェア
● 概念(OSDが提唱する。次ページ参照)
○ http://www.opensource.jp/osd/osd-japanese.html

12. OSSの概念
● 再頒布の自由
● ソースコード
● 派生ソフトウェア
● 作者のソースコードの
完全性
● 個人やグループに対す
る差別の禁止
● 利用する分野に対する差別
の禁止
● ライセンスの分配
● 特定製品でのみ有効なライ
センスの禁止
● 他のソフトウェアを制限する
ライセンスの禁止
● ライセンスは技術中立的で
なければならない

13. なるほどわからん

14. 厳格はつらい
OSSの概念を完全に理解してなくても
パッチやバグレポートは出せる

15. GitHubなどにソースコードが
公開されているソフトウェアは
だいたいOSS

16. You Ain’t Gonna Need It!
機能は実際に必要になるまで追加しない

17. 人力YAGNI
ライセンスとかOSSの定義は
パッチやバグレポートを出した後に
勉強しよう

18. 今日の流れ
1. 対象者
2. OSSとは
3. 貢献できない理由
4. 出来ない理由を片付けていく
5. ケーススタディ

19. 言語化の試み
問題解決のためには
問題を言語化する必要が
ある

20. OSSに貢献できない理由
● どこから手を付けていいか分からない
● ソースコードを読んでも分からない
● 時間がなくて無理
● 技術的に無理

21. OSSに貢献できない理由
● どこから手を付けていいか分からない
● ソースコードを読んでも分からない
● 時間がなくて無理
● 技術的に無理

22. どこから手を付けていいか分からない
● どんなバグレポートやパッチを出せばい
いか分からない
● OSS多すぎ
● 特に意識しないと普通に使えちゃう

23. どこから手を付けていいか分からない
● どんなバグレポートやパッチを出せばい
いか分からない
● OSS多すぎ
● 特に意識しないと普通に使えちゃう

24. ケーススタディ
Play Framework

26. なんかIssueとかPull Requestがいっぱい

27. なんかIssueとかPull Requestがいっぱい

28. 次のアクションが分からない
↓
もうこのままでいいんじゃないかな

29. どこから手を付けていいか分からない
● どんなバグレポートやパッチを出せばい
いか分からない
● OSS多すぎ
● 特に意識しないと普通に使えちゃう

30. 自社プロダクトで使われているOSS
● プログラミング言語: 2
● フレームワーク: 2
● バックエンド部分のライブラリ: 55
● フロントエンド部分のライブラリ: 60
● ミドル: 10くらい
● 参照: build.sbt/package.json

31. 開発環境
● ターミナル
● エディタ/IDE
○ Vim/Emacs/IntelliJ IDEA/Atomとか
○ 付随するライブラリとかプラグインとか
● ログインシェル
○ bash/zsh/fish

32. OSSが多すぎて
どこから手を付けていいか
分からない

33. どこから手を付けていいか分からない
● どんなバグレポートやパッチを出せばい
いか分からない
● OSS多すぎ
● 特に意識しないと普通に使えちゃう

34. 特に意識しなくても普通に使えちゃう
ググったりQiitaを見たり知ってる人に聞い
たりしたらだいたい解決する
↓
もうこのままでいいんじゃないかな

35. 結果、どこから手を付けていいか
分からない

36. OSSに貢献できない理由
● どこから手を付けていいか分からない
● ソースコードを読んでも分からない
● 時間がなくて無理
● 技術的に無理

37. 統計
ファイル数 行数

38. ファイル数多すぎて
手をつけたらええんか分からん

39. OSSに貢献できない理由
● どこから手を付けていいか分からない
● ソースコードを読んでも分からない
● 時間がなくて無理
● 技術的に無理

40. 使える時間(と気力)は限られてる
1. 夜９時とか１０時とかに退社
2. １-２時間かけて電車で帰る(しんどい)
3. 夜１０時とか１１時とかに帰宅
4. 飯食って風呂入って
5. アニメ見たりTwitter見たり家族とか友人
とかと話をしたり

41. 気づいたら深夜！
気力もない！(体力もない！)

42. しんどい

43. OSSに貢献できない理由
● どこから手を付けていいか分からない
● ソースコードを読んでも分からない
● 時間がなくて無理
● 技術的に無理

44. そうだ!
ソースコードを読んでみよう!

46. 漫然と眺めてもわからん
● ソースコード
● Pull Request
● Issue

47. ちゅーかやっぱりこのままで
いいいんじゃね？

48. 出来ない理由は
1つ1つ潰していこう

49. 今日の流れ
1. 対象者
2. OSSとは
3. 貢献できない理由
4. 出来ない理由を片付けていく
5. ケーススタディ

50. OSSに貢献できない理由
● どこから手を付けていいか分からない
● ソースコードを読んでも分からない
● 時間がなくて無理
● 技術的に無理

51. そもそも
なぜOSSに貢献するのか
● プログラマーとしての成長のため
● バグってたりドキュメントがおかしかった
りするのを直すため
● 欲しい機能を追加するため
● パッチが取り込まれるのは嬉しい

52. オープンソースへの取り組みは
エンジニアにとって大きな「武器」
になる
https://doda.jp/engineer/it/guide/001/02b.htm
l

53. 具体的なアクションが分からん

54. キャリアアップを考えるのは
副次的なものであってゴールじゃない
↓
自分の思う通りにOSSを
作り変えていく

55. 具体的なアクションの一例
● 機能追加
● バグ修正
● リファクタリング
● ドキュメント編集
● ドキュメント翻訳

56. 必要にかられないと人は動かない
↓
必然性を高めていこう

57. 必要にかられないと人は動かない
↓
必然性を高めていこう

58. 必要にかられないと人は動かない
↓
必然性を高めていこう
↓
使っているOSSの中身を
積極的に見る

59. OSS開発の必然性を高めていくために
● 公式ドキュメント/ソースコードを読む
● StackOverflowやQiitaは使わない
○ マイナス検索を使う
○ 副読書程度で

60. Google検索 -stackoverflow -qiitaの理由
● 最新性
● 正確性
● 本家で今何が問題となっているか分か
らない

61. 公式が間違っている説と自分が間違ってい
る説を半々ぐらいで持ちながら開発する
心構え

62. OSSに貢献できない理由
● どこから手を付けていいか分からない
● ソースコードを読んでも分からない
● 時間がなくて無理
● 技術的に無理

63. なんかいろいろ実装されてて
分からない
↓
雰囲気をつかもう

64. なぜ雰囲気をつかむ
必要があるのか
↓
他の人が何をやっているか
分かるから

65. OSS開発の
雰囲気をつかむ
ためにとても
参考になる本

66. さまざまなアセ
ンブリ言語を
フィーリングで読
む本

67. 熱血バイナリアン十訓(P1)
● まずは読め
● 楽しんで読め
● 無理やり読め
● 勘で読め
● 暇を見つけて読め
● 思うままに読め
● 納得行くまで読め
● 明日も読め
● 飽きたら次のを読め
● わからなくても気にせず
読め

68. その十戒はOSS開発にも適用できる
● まずは読め
● 楽しんで読め
● 無理やり読め
● 勘で読め
● 暇を見つけて読め
● 思うままに読め
● 納得行くまで読め
● 明日も読め
● 飽きたら次のを読め
● わからなくても気にせず
読め

69. 何を読むべきか

70. GitHubリポジトリのチャットツールGitter
https://gitter.im/

71. READMEの
on gitterをクリック(あれば)
https://github.com/playframework/playframework

72. アプリもあるで
https://gitter.im/apps

73. 気になるリポジトリはwatch!
https://github.com/notifications

74. アプリもいろいろ(一長一短)
CodeHub GHFeed

75. メーリングリスト

76. 今挙げたやつを
とりあえず適当な時間を見つけて読む

77. いつ読むべきか
● 休憩時間
● 通勤時間
● 寝る前
● ビルド時間
● その他あいてる時間

78. ポイント
● 雰囲気で読む
● 分からなくても気にせず読む
● 飽きたら別のリポジトリをwatchする
● 毎日読む

79. 注意点
● Linux/Emacsのメーリングリストは毎日数百数
千とかメールが来てやばい
○ メーリス購読してたらGmailの容量が死にか
けた
● PrestoとかElasticSearchとかは毎日すごい数
のIssueやPull Requestが飛んでてやばい
● 通知をオンにすると通知がしんどいけど通知を
オンにしましょう

80. これをやることで得られる雰囲気
● 他の人がどんなIssueを出しているか
● 他の人がどんなPull Requestを出してい
るか
● 他の人がどんな文章を書いているか
● 他の人がどんなコードを書いているか

81. http://xuwei-k.hatenablog.com/entry/20150930/1443641775
すごく参考になったブログ

82. OSSに貢献できない理由
● どこから手を付けていいか分からない
● ソースコードを読んでも分からない
● 時間がなくて無理
● 技術的に無理

83. 使える時間(と気力)は限られてる
1. 夜９時とか１０時とかに退社
2. １-２時間かけて電車で帰る(しんどい)
3. 夜１０時とか１１時とかに帰宅
4. 飯食って風呂入って
5. アニメ見たりTwitter見たり家族とか友人
とかと話をしたり

84. 時間がない問題の解決方法
1. 帰ったらすぐやる
2. 寝る時間を削って時間とやる気を捻出
する
3. 仕事の時間や昼の休憩時間を使う

85. OSSに貢献できない理由
● どこから手を付けていいか分からない
● ソースコードを読んでも分からない
● 時間がなくて無理
● 技術的に無理

86. 技術的に無理
● 全てを理解しようと思わなくていい
○ 修正したい箇所だけを重点的に
● find-grep/検索

87. 技術的に無理
● 最低限CONTRIBUTEページは読もう
○ IssueやPull Requestを投げるときの
ガイドラインが記載されている
○ ここをクリアしないとそもそも見てもら
えない
○ contribute xxxでググろう

88. 技術的に無理
● どういうふうに書いていいか分からない
○ 他の人が書いたソースコードを参考に
しよう
○ 分からない関数や処理が分かる
○ 純粋にすごく参考になる

89. 技術的に無理
● テストコードを読んで挙動を知る
○ どういう動きになっているかはテスト
コードを読めば分かる

90. 今日の流れ
1. 対象者
2. OSSとは
3. 貢献できない理由
4. 出来ない理由を片付けていく
5. ケーススタディ

91. ケーススタディ
● 歴史と伝統のある大きなOSS
● 最近出来た新興のOSS
● 全然開発されていないOSS

92. ケーススタディ
● 歴史と伝統のある大きなOSS
● 最近出来た新興のOSS
● 全然開発されていないOSS

94. https://github.com/rundeck/rundeck
高機能cron

95. https://github.com/rundeck/rundeck/pull/1836
リンク切れ修正

96. ポイント
● cronまわりのドキュメントを読み漁った
結果
● 必要な箇所だけでいいので公式ドキュメ
ントをちゃんと読みましょう
● ドキュメント修正も貢献です

98. https://github.com/cookpad/kuroko2
GUIベースのジョブスケジューラ

99. いろいろ便利な
ワークフローエンジン
● Webの管理画面がある
● Webの管理画面でリトライできる
● DBはMySQL
● timeoutの値を設定できる
● Slack通知が簡単にできる

100. 問題点
● ドキュメントにない機能の存在
● kuroko2にはないDSLがある(echoとか
retryとかif-elseとか)
● ドキュメントをなぞっても環境構築できな
い

101. 問題点
● ドキュメントにない機能の存在
● kuroko2にはないDSLがある(echoとか
retryとかif-elseとか)
● ドキュメントをなぞっても環境構築できな
い

102. https://github.com/cookpad/kuroko2/pull/59

103. ドキュメントにない機能の存在
● GUIではなくAPIからジョブを実行する
○ incoming webhook
● 当初この機能はドキュメントになかった
ので、ドキュメント追加のプルリクエスト
を投げた

104. ドキュメント追加の流れ
1. 機能が存在するかどうかググる
2. Issueやドキュメントを読む
3. ソースコードを読む
4. 実装されているけどドキュメントにない場
合は、該当機能のドキュメントを追加す
る

105. 問題点
● ドキュメントにない機能の存在
● kuroko2にはないDSLがある(echoとか
retryとかif-elseとか)
● ドキュメントをなぞっても環境構築できな
い

106. https://github.com/cookpad/kuroko2/pull/65

107. DSL追加
● 今まで
○ execute: echo “hello, world”
● 今回のプルリクエスト
○ echo: “hello, world”

108. 機能追加の流れ
1. IssueやPull Requestを見て、既知のも
のか確認する
2. 作りたい機能のイメージを固める
a. digdagのechoを流用したかった結果
3. 既存のプロダクトコード/テストコードを読
み、書き方と挙動を知る
4. 真似る

109. 問題点
● ドキュメントにない機能の存在
● kuroko2にはないDSLがある(echoとか
retryとかif-elseとか)
● ドキュメントをなぞっても環境構築できな
い

110. ドキュメントを
なぞっても環境構築
できない

111. ≠何もしてないのに
壊れた

112. 参考: メーリングリスト サ
ポートセンターではなく互
助会です
http://www.hyuki.com/writing/techask.html

113. 確認事項

114. 下準備
1. ドキュメント側で指定している
バージョンで試す
2. エラーログを読み、期待している
動作と実際の動作を確認する
3. ソースコードを読む

115. バグかどうかの確認
1. ドキュメント側で指定している
バージョンである
2. エラーログとソースコードを読ん
で、ソースコード側に起因するも
のならそれはバグ

116. https://github.com/cookpad/kuroko2/issues/57

117. ドキュメント通りに環境構築
しようとしてエラーになる
● インストールコマンド実行後
○ rails new -m app_template.rb
● Directly inheriting from
ActiveRecord::Migration is not
supported

118. Rails5にアップデートす
るときに起きるアレ
class CreateUsers < ActiveRecord::Migration[4.2]
って書けよ
http://tech.grooves.com/entry/2016/07/01/184458

119. https://github.com/cookpad/kuroko2/pull/63

120. Missing dependency commonmarker
● ジョブ登録時に起きた
○ GUIのところどころで起きる
● html-pipelineのバージョンアップデート
で記載されていたgemspecの
github-markdownが使われなくなった
○ https://github.com/jch/html-pipeline/pull/274

121. おまけ
開発前にソースコードを読んだら
typoが見つかったのでプルリクを出した
↓
IDEさまさま！

122. 新しめのOSSはcontribution
pointが割と多い

123. ケーススタディ
● 歴史と伝統のある大きなOSS
● 最近出来た新興のOSS
● 全然開発されていないOSS

125. Emacsにパッチを投げた
● zshファイルのsh-modeが起動しない
● sh-mode自体にはzshに対応してた
https://www.emacswiki.org/emacs/ShMode
● 以前は自前のinit fileに書く→書きたくな
いと思った結果
http://emacs.1067599.n8.nabble.com/bug-25217-PATCH-Enable-sh-mode-zshrc-td416040.html

126. 修正は1行

127. パッチを投げる前に
● contribute emacsでググる
● sh-modeのwikiを調べる
● るびきち氏にメルマガ経由で確認した

128. 苦しいポイント
● GitHubにプルリクエストを投げるスタイ
ルではない
○ パッチファイルを作る
○ git send-email
● やり取り自体が少し面倒
● GitHubみたいにGUIでレビューされない

129. 紆余曲折を経て

130. パッチが
取り込まれたときの
無上の喜び

131. ケーススタディ
● 歴史と伝統のある大きなOSS
● 最近出来た新興のOSS
● 全然開発されていないOSS

133. google-translate

134. Google翻訳をEmacs上で使う

135. Pull Requestを投げました

136. やりたかったこと
● Google翻訳の結果を出力
○ ポップアップ
○ エコー領域
○ 現在のバッファ
● 今の作業領域に翻訳結果を出力して欲
しいと考えた結果

137. 問題点

138. プルリクを出す前の最後のコミットが
半年前

139. プルリクを投げても
放置されるパターン

140. アプローチの必要性
1. @作者でGitHubにコメントする
2. @ツイートする
3. メールアドレスに直接メールを送る
4. 何もしない
5. forkして自前で開発をすすめる

141. 実際にやったこと
1. @作者でGitHubにコメントする
2. @ツイートする
3. メールアドレスに直接メールを送る
4. 何もしない
5. forkして自前で開発をすすめる

142. 無事マージされました

143. おまけ
● プルリク出すときにCIがコケてたのでCI
で動かすテストコードを修正するプルリ
クを投げました

144. まとめ
● 雰囲気をつかむのはとても重要
● 毎日続けること
● ドキュメントとソースコードを読むこと
● 他人のコードを知ること

145. このセッションの後から
アクションを始めよう