OSSの敵になるのもいいじゃない

OSSの敵になるのもいいじゃない

1. 1. OSSの敵に なっちゃうのもいいじゃない y8spring: May 27, 2017 Daisuke Maki (@lestrrat)
2. 2. • @lestrrat • Perl/Go hacker, author, father • Author of github.com/peco/peco • Organizer for builderscon
3. 3. 応募してくれ！ https://builderscon.io/tokyo/2017/cfp
4. 4. ピンチヒッターなのでお手柔らかに…
5. 5. （最近まわりの若手プログラマを 見てて思った、ふわっとした話です）
6. 6. 最近のGithubでの活動
7. 7. （全部Goです）
8. 8. github.com/lestrrat/go-slack fork of github.com/nlopes/slack
9. 9. github.com/lestrrat/go-fluent-client rewrite of github.com/fluent/fluent-logger-golang
10. 10. github.com/lestrrat/go-msgpack fork of gopkg.in/vmihailenco/msgpack.v2
11. 11. github.com/lestrrat/go-gettext fork of github.com/leonelquinteros/gotext
12. 12. github.com/lestrrat/go-packasset rewrite of github.com/jteeuwen/go-bindata
13. 13. Q: PR送らないの？
14. 14. A: 送らない
15. 15. A: 送らない
16. 16. もちつけ
17. 17. 共通する理由
18. 18. APIが気に入らねぇ
19. 19. Q: だから〜、PR送らないの？
20. 20. A: 送らない
21. 21. OSSに変更提案を送る際の 最初のルール 「APIを変えたい」は ほぼ100%却下される
22. 22. APIを変える＝影響範囲が デカい
23. 23. APIさえ変えないで すぐ済むならPRする → 既存のAPIの中身を変える → 新規APIを追加する
24. 24. エンドユーザー全員に影響： かなりの強い理由が必要
25. 25. 理由を説明する努力が必要
26. 26. 説明するには現在の 実装への理解が必要
27. 27. 「あれ、一旦自分で書いたほうが （説明するためにも）早くね？」
28. 28. そうだ、forkしよう
29. 29. fluent.Shutdown(context.Context) が欲しかった 最近の具体例(1) （アプリがexitした時点でバッファが空かどうかの保証されてないのが気持ち悪かった）
30. 30. → 「あれ、バッファのフラッシュを明示的に待てないぞ」 → 「PR書こう」 → 「あれ、これいれると他のAPIも変わるな…」 → 「あれ、これ、もう違うライブラリだよね…」 → 「forkしよ」 最近の具体例(1)
31. 31. エラーを握りつぶしてるのを どうにかしたかった 最近の具体例(2) （“func hoge()”を”func hoge() error”にしたかった）
32. 32. → 「あれ、このライブラリ、エラーがあっても全部無視してる…」 → 「あとで泣くの、おれだぞ。エラー返すPR書こう」 → 「あれ、そもそも戻り値に一切”error”が定義されてないからAPIが変 わっちゃう…」 → 「書き直ししよ」 最近の具体例(2)
33. 33. 最近の具体例(2)
34. 34. なんかもっと調整したいんだけど、 そもそもmsgpackの仕様がわからん… 最近の具体例(3)
35. 35. → 「なんか、これもっとencoding/jsonみたいにしたほうがいいのでは…」 → 「PR書こう」 → 「む、すぱげｔ… 難しいコードだな」 → 「ひょっとして実装した人じゃないとわからない深淵なる理由あるのか な？」 → 「プロトコルを知らないのにAPIについていちゃもんつけられない」 → 「forkしてプロトコルから実装しなおしてみよ」 最近の具体例(3)
36. 36. 微妙
37. 37. 気に入らない事はたくさんあるけど、 相当作り込まれてるので もっと強烈な理由がないと変更提案は 難しそうなのはわかった
38. 38. やってみて感想
39. 39. 自分で書いた事により 実装の仕組みやプロトコルを 理解した
40. 40. 一度書いたコード が存在している
41. 41. 元のプロダクトにコメント・PRを送る にも、机上の空論ではない、触れるモ ノが存在する → 議論もそれをベースに行える
42. 42. 変更提案が拒否されても、 手元にはそれを実装した 実績・経験・自信が残る
43. 43. 注意事項 * 戦略を考えてからforkしよう * 最終的にfork元に還元したいのか？ * 自分が最後まで看取るつもりで別の道を歩むのか？ * 勉強のためにやっていて、終わったら消すつもりなのか？ * それforkする必要ある？ * API 変わらないならPRを作る苦労をしたほうがいいよ！
44. 44. それでも、 forkを恐れるべきではない！
45. 45. 自分で書いてみるのを 恐れて欲しくない (特に経験の浅い人達）
46. 46. ソースコード読むのもいいけど、APIデザインは 実装しないとわからない事の方が多い ※ 個人の感想です
47. 47. 自分で入れた変更がたいした効果を生めなかったら そこから何かを学ぼう
48. 48. この職業は（天才以外）は 1行でも多く書いた人の勝ち ※ 個人の感想です
49. 49. OSSの敵に なっちゃうのもいいじゃない
50. 50. そんなことより たくさん コード書け！
51. 51. END
52. 52. 応募してくれ！ https://builderscon.io/tokyo/2017/cfp