OSS活動を細く長く続ける技術

July Tech Festa 2021 Winter

Jan 24th, 2021

Profile

• id: Songmu (ソンムー)
• Masayuki Matsuki / 松木雅幸
• Nature 株式会社 取締役CTO
• おそらくはそれさえも平凡な日々 http://www.songmu.jp/riji/
• https://metacpan.org/author/SONGMU
• 好きな言語は、PerlとGoと中国語
• 3 Times ISUCON Winner Using Perl
• 入門監視 付録C 執筆
• 「みんなのGo言語」共著者

【宣伝】Nature Remo

• 赤外線リモコン代替となるIoTスマートリモコン
  • https://nature.global
• エンジニアも絶賛募集中です
• 同時接続20万台を超えるIoTサービスの裏側を一緒に開発しませんか！
  • https://nature.global/jp/careers

アジェンダ

• 最近のOSS活動
• 私とOSS
• OSSの原体験
• 業務でのOSS開発
• OSS選定やコミュニティとの協調
• OSSの変更に関わる
• OSSへの貢献
• OSS活動を続けるコツ
• OSS活動アンチパターン
• OSS活動と英語

OSSとは何か？

「適切なライセンスの下、ソースコードが公開されているソフトウェア」とします

→ 僕しか使ってないような落書き的なものも、このトークではOSSと言い張ります

私は何者か

経歴

• 昔-2010 色々あった
• 2011-2014 カヤック
  • ソーシャルゲームのリードエンジニア
• 2014-2019 はてな
  • チーフエンジニア
  • Mackerelのプロダクトマネージャー
• 2019-現在 Nature株式会社
  • 取締役 CTO
  • Nature Remoの開発・運営

ソフトウェアエンジニアとして

• サーバーサイドからインフラにかけてが主戦場
  • いわゆるDevOps的な領域が得意分野
  • 「インフラを意識しながらコードを書く」
• Perlをかなりヘビーに書いていたが、今はGoがメイン
• 一流になりきれない
  • これもOSS活動の中で自覚させられること
  • 自分を卑下するのは良くないし、卑下しているわけでもない
  • むしろ「すごい人は僕なんかより本当にすごい」って言いたい

質より量

• 200+ GitHub Public Repositories
• 70+ CPAN Modules
• 70+ Go modules/tools
• 量が(それなりの)質を生む(と信じたい)

70+ CPAN Modules

• 74 dists
  • 量に質が伴わない特性をよく表している
• 日本人6位
  • 1位はmiyagawaさんの241 dists!
• http://acme.cpanauthors.org/for/japanese 調べ

pull request歴

• 2011年に初めてのpull request
  • ちょうど10年
• 現在1179個のpublic pull request
  • -org:Songmu すると825個
  • さらに -org:mackerelio すると432個
• pull requestを送っている方だと思う

OSSメンテナンスを引き継ぐことが多い

• x-motemen/ghq
• tokuhirom/Archer
• tcnksm/ghr
• knqyf263/utern

特にghqは多くの人に利用していただいています。

OSS開発者として

• 1000starを超えるような代表的なOSSはない
  • 100Star超えが幾つか
• 小粒なものばかり
  • 1万行を超えるようなものは無い
• 自分しか使っていないものもたくさん
  • もはや誰も使っていないものも
• 逆に幸せなOSS開発者人生を歩んできた
  • 消耗したことは少ない
• pull requestを結構たくさん送っている

最近のOSS活動

gotesplit

https://github.com/Songmu/gotesplit

• Goのテストを簡単に分割、並列実行できるようにするもの
• CircleCIやGitHub Actions上ですぐに利用可能
• 社内のテストを15分 -> 3分に

github.com/shogo82148/go-sql-proxy

今年に入ってから3つpull requestを取り込んでもらった。

• https://github.com/shogo82148/go-sql-proxy/pull/60
• https://github.com/shogo82148/go-sql-proxy/pull/61
• https://github.com/shogo82148/go-sql-proxy/pull/62

github.com/kayac/ecspresso

一昨日。バグを見つけてから15分でpull request送信。

https://github.com/kayac/ecspresso/pull/229

私とOSS

幸せなOSS開発者人生

• 変な政治に巻き込まれたことはない
• 一人で見切れくるらいのものを細々とメンテナンスしている
• 緩くOSS活動を続けている
  • 趣味と実益を兼ねている
• 楽しくOSS活動をする人を増やしたい

OSS開発が趣味

• 自分の中で生き残っている数少ない趣味
• ある意味強制的にコードを書く機会を得られているとも言える
• 盆栽活動

OSS趣味活動と業務

• 業務と切り離せない部分もある
• 実際に使われているものに価値があり質が高いのは事実
• 業務と趣味を完全に切り離すのは難しい
  • 趣味の技術を完全に別の技術スタックでやっている人もいるけど、僕にはできない

自分の普段使いの道具をOSSにする

• Text::Markdown::Slidy
  • このSlide作っているツール
  • 世界で多分僕しか使っていない
• Riji
  • 僕の個人Blog(https://songmu.jp/riji/)はこれで構築
  • 以前は世界で20人くらいは利用者がいたけど今は多分僕だけ

GitHubはエンジニアにとってのお絵かきサービスくらいの感覚

• 落書きを上げている様な気持ちもある
• 試しに書いてみたものとかもバンバン上げている

小粒なモジュールを組み合わせてソフトウェアをつくる

• そういう文化圏で育った
  • Perlの影響
• 小さなモジュールは一見さんでも貢献しやすいというメリット
• Goも標準パッケージ + 軽量ライブラリを幾つか、というスタイルが多いので性に合っている

OSSの原体験

PSGI/Plack

• https://metacpan.org/release/PSGI
• https://metacpan.org/pod/Plack
• miyagawaさん中心に作られたPerlのWeb AppとApp serverの間の標準抽象化レイヤの仕様と実装
  • pythonのWSGI, RubyのRack
• 多くのPerl界のフレームワークやサーバーに適用され、スタンダードとなった
• 世界標準の技術を「作る」側の人たち、車輪の再発明ができる人たちとの出会い
  • 「使う」側じゃなくて「作る」側

h2o

• https://h2o.examp1e.net/
• https://github.com/h2o/h2o
• kazuhoさんが突然世界最速のHTTPサーバーを作り始めた

Our Free Software Runs Your Company

旧CPANの中にあったページ。

http://web.archive.org/web/20150308210439/http://hexten.net/cpan-faces/

業務でのOSS開発

自社の共通ライブラリをOSSにする

• 実はOSSにしてしまうのが一番社内でも再利用しやすい
• 本質であるサービス開発に集中する
• ここ10年はそれがやりやすい会社で働けているので恵まれていると言える

OSSにできるものはOSSにしてしまう

• 自分から公開すれば、主体的にコントロールする側に立てる
  • コミュニティの力をうまく活用できると嬉しい
  • 多くの場合大して話題にもならない(のでダメージも少ない)
• 抽象化でき、HackishなコードはGitHubに上げてしまう
  • プロジェクトのコードベースを読みやすく、ミニマムに保つ
  • 余計なリファクタループを避ける
  • そこのテストコードを毎回CIで回す必要もなくなる
• 社内横断的に利用する上でもGitHubに上げてしまうのが最適解なことも多い
  • 社内モジュール化は管理コストや暗黙知の増大につながる可能性も
  • 場合によっては社内モジュールと言う選択もありだとは思う

テスト駆動とオープンソース駆動の類似

• テストを書くことを前提にプログラムを書くと設計が綺麗になる
  • テストの書きやすさを考えると、変な結合を減らせる
• 同様にオープンソースにすることを前提にプログラムを書くと上手いこと抽象化できる
  • 「これもうちょっと社内の事情に密結合した部分を消せばOSSにできるんじゃないか」

→きれいな設計になる

現職でOSSに切り出した例

• https://github.com/natureglobal/firequeue
  • Amazon firehoseのリトライ制御とかやってくれる君
• https://github.com/natureglobal/realip
  • Nginxのrealipモジュール相当のことをGoのhttpでやる君

良くも悪くも話題になっていない。

OSS選定やコミュニティとの協調

• 実際に使われているか
• 協調可能か

モジュールの採用基準とオープンソース戦略

• ref. もうひとつの知られざるオープンソース 〜 ウェブ企業のOSS戦略
• 自分がソースが読めるもの
• なるべくコントロール(協調)可能なもの
  • 外部の開発者との連携
• 主体的、中心的にOSSに関わることで上手く利用する側に立てる
  • ← 使わされている側にならない
• とりあえずpull requestを送ってみる
  • 協調可能かどうか

協調可能か

• ソフトウェアは思想が大事
  • 自分と思想がマッチしていそうか
• メンテナンスがアクティブか

pull requestを送って探りを入れるという手も。

hitchの例

• Nature社内で利用しているGoのWebフレームワーク
• メンテナンス滞ってそうだけど送ってみたらすんなり取り込んでくれた
• その後デフォルトブランチがmainになったりと案外アクティブになった

自分もpull requestもらったらやる気出して追加でメンテナンスしたりすることもあるので気持ちはわかる

https://github.com/nbio/hitch/pull/11

OSSの変更に関わる

• pull requestなど

ソフトウェアにはバグがある。OSSにも当然ある

• ちょっとした修正入れる余地は結構ある
• とは言え、おかしいと思った時はだいたい自分が間違えているというのもある

pull requestを送る際には

• 相手の流儀に従う
  • コーディングスタイルなど
• 過去のissueやpull requestを眺めて雰囲気を掴む
  • 類似issueがないか調べる

go-yamlへのpull reuqest

• 1文字修正(+テストコード)
• マルチバイト文字列の文字幅計算の誤り
  • 割とありがちなケアレスミス

https://github.com/go-yaml/yaml/pull/102

h2oへのpull request

• CではなくてなんとPerlの修正

https://github.com/h2o/h2o/pull/872

機能追加提案

• bugfixよりハードルは高い
• 事前に過去のissueを見て、却下されてないか確認する
• 思想がマッチしているかのすり合わせとも言える
  • 自分のユースケースがあってるのかの確認
  • 機能拡張の方向性が作者とマッチしているかの確認
• 自分の思想と相手の思想がマッチしてなさそうだったら、無理して使わないのが吉
  • 変に独自forkして拡張して使うとかもしないほうが良い
  • ベースの思想が異なるものをカスタマイズしても破綻する

カルマモデル

• OSS活動の積み重ねが信用につながる
• 信用が高いOSS開発者の方が、pull requestにもすぐに反応してもらえるのは否めない
  • OSS開発者も人間である
  • 信用できる人のほうが質の期待値が高いのも事実
• メンテナンス権くださいって言ったらすぐもらえる
• → 開発スピードが上がる
• → 独自forkを避けられる

OSSへの貢献

• ハードルを上げない
• 「貢献していない」と萎縮しない・させない

OSSへの貢献とは？

別に堅苦しくないし敷居も高くない。いくつかの段階がある。

1. 使うこと「だけ」でも貢献
   • ただし使っていることを隠さない
2. 可能なら問題や疑問を報告する
3. pull requestやパッチを送る

OSSフリーライダー問題

• 「OSSを使うだけで貢献していない」とかいう人は無視して良い
• OSSは貢献すればするほどうまく使える
  • 間違った使い方を避けられる
  • 互換性を崩されて突然死んだりしない
• 意思決定プロセスに関われる方が有利
• 「貢献していない」と萎縮させてしまうことが問題

OSS活動を続けるコツ

• ドッグフーディングする
• やる気になったらすぐ始められるようにする
• ライブラリは常に最新版を使う
• メンテナンス権をもらう

ドッグフーディングする

• 普段使い
• 仕事で使う

やる気になったらすぐ始められるようにする

継続力が無い僕自身の戦略とも言える。やる気になったときの勢いを殺さない。

• コードリーディング環境を整える
• ghqを使ってすぐにpull requestを送れるように
• godzilを使ってすぐに新しいプロジェクトを始められるように
• ghやhubコマンドを使ってGitHub操作を素早くできるように
  • (まだghに乗り換えきれていない)

コードリーディング環境を整える

• 最近はエディタで十分読めるので僕はそこまで整えてない…
• バンバンコードジャンプして奥底まで潜っていけるように
• なにかおかしいな、と思ったらライブラリのコードまで読みにいくことがバグ発見につながる

ghqを使ってコードをすぐ手元に持ってこられるようにする

https://github.com/x-motemen/ghq

手元にOSSのソースを持ってきて、修正作って、pull request出すところを簡素化する。

• ghq get ownew/repo で手元にソースを持ってきて読む
• バグを見つけたら修正作って hub fork して、pull requestを送る
  • (gh repo fork を使いたいが、ちょっと挙動が好みじゃなくて移れていない)

godzilを使ってすぐに新しいプロジェクトを始められるように

アイデアが思いついたらすぐに新しいrepositoryを作れるようにする。

• https://github.com/Songmu/godzil というGo用のオレオレオーサリングツールを作って使っています
• gh repo create でrepo作ってすぐにpush

ライブラリは常に最新版を使う

• 「バグを見つけた」と思っても最新版では直ってるなんてことはあるある
  • ちゃんと最新版でバグを見つけたい
• 何にせよ最新版に追随し続けるのは良いプラクティス
  • 最近はrenovateやdependabotなどの依存追随システムも整ってきて楽になった
• ライブラリを古いバージョンに固定し続ける理由はない
  • 新しいバージョンに追随が困難なのであれば、それもまた思想の不一致かもしれないので無理に利用を続けないほうが良いかも

メンテナンス権をもらう話

• OSSにpull request送りまくってるとcommit権を渡されることがある
• 慣れてくると自分から「メンテしましょうか？」と提案することも
• 自分が普段使ってない技術や流儀を知れるメリット
• 実は相手としても嬉しい
  • 実際に使っている人がメンテするのがソフトウェアのためでもある

自分が普段使ってない技術や流儀を知れる

• ghqの場合
  • READMEにasciidocが使われていた
• uternの場合
  • goreleaserが使われていた

OSSをメンテナンスするメリット

• pull requestがやってくると刺激になる
• 強制的に外部からコードを読み書きする機会がやってくる
• それを機に他のところもメンテナンスする
• 重く受け止めすぎないのも大事
• たまにOSSメンテナンス日を作って、溜まったpull requestを消化するなど
• 盆栽活動

メンテナンスが好きだと気づいた

• これは個人的な話
• 業務の上でも0->1よりも1->10が得意だと気付かされるきっかけに

OSS活動アンチパターン

車輪の再発明を恐れない

• 案外同じ車輪は無い
• ちょっと探して見つからないってことはあまり良くないか古い
• みんな「やりたいな」と思っててやってないことある
• そういうのやったら賞賛される
• 古い車輪をありがたがりすぎるのも良くない
  • 既存の車輪も古くなる・再発明が必要になる
  • リニアモーターカーに車輪は必要ない

良くない車輪の再発明

• 「あのモジュールよくわからないから自分が別のものをGitHubに上げる」はあまり良くない
  • 「スクラッチアンチパターン」に近い
  • 既存のやつを理解していないと同じ罠を絶対踏む
  • 練習としての再発明としては良い
• 同様にパッチを送るのが怖いから別実装作るとかも良くない
  • バグフィクスならともかく、モジュールに機能追加の要望を送るのはたしかにしりごむがissueとかで相談しよう
  • 新たな知見が得られることがある(「〇〇でできるよ」「それはこのライブラリの責務じゃない」とか)
• オレオレじゃなくてすでにある仕組みに「乗る」ことも大事

独自forkを避ける

• 短期的には良いアイデアのように思えてしまう
  • しかし追随地獄になる
• 「怖いから, めんどくさいから独自fork」は良くない
• そのソフトウェアにふさわしい機能なのであれば取り込んでもらって一緒にメンテするのが吉
• 思想がマッチしないものを独自拡張しても多くの場合うまくいかない

無視されてもショックを受けない

• OSSがメインの仕事じゃない多くの人は後回しになってしまうこともどうしてもある
• めげずにpingしたり、別のルートでコミュニケーション取る
  • その人のタイムゾーンだったりTwitterしている時間をみてアクティブそうな時間帯にコメントするとか
  • 同僚の人を知ってたらその人経由でつついてもらったり
  • メールやTwitter DM送ったり
• のんびり待ちましょう
• 諦めるのも一つの手ではある

github.com/pkg/errors のとあるpull request

• Goでかなり使われているエラー処理パッケージ
• 2019-07-04に起票され、取り込まれたのが2019-11-09
  • Goの標準ライブラリに挙動を揃えるための大事な提案だった
  • しばらく反応が無かったが、10月にやっとメインの作者が反応
• こんなにすごい人でもデスマることがある

https://github.com/pkg/errors/pull/206

github.com/blang/semver

• Goの代表的なsemverライブラリの一つ
• 1.2.0-alpha のようにパッチバージョンが0でprereleaseがついている場合にparseできないデグレがあった
• 2019-05-28に起票して取り込まれたのが2020-05-24と丸一年
  • もうメンテ止まったかなーと個人的には諦めていた
  • 実際このメンテ停滞が影響して一番メジャーなsemverライブラリとは言えなくなった

https://github.com/blang/semver/pull/56

OSSと英語

僕はそんなに英語はできない

• TOEIC 600点に届かないくらい (大昔に一回受験)
• 「ソフトウェアエンジニアに一番大事なのは英語だ」という言説を見かけるたびにウッってなる
  • 一理ある
• とは言え、ソフトウェアエンジニアにとって英語は大事なのは確か
• OSSを練習の場と前向きに捉える

英語での発信

• hacker newsとかredditとかmediumとかでの自分のOSSの宣伝とかやればいいと思う
  • 僕は怠っている

僕と英語

• 去年ほんの少しできるようになった
• 日本語を喋らない海外のエンジニアが入社したのがキッカケ
  • 焦ってオンライン英会話始めた
• 喚き散らすことはできるようになった
  • やっと「恥じらい」を捨てられるようになってきた
  • 恥じらいを捨てるの、OSSでも大事なことだけど、難しいことだと改めて感じた

大事なこと

• 外国人だからといって技術力が高いわけではない！
• 英語できる人がすごい人に見えるけど、別にそんなことはない。同じソフトウェアエンジニア
• 実は英語ネイティブも多いわけじゃないのでOSS界はBroken Englishに寛容だとも感じる
  • 英語圏じゃない海外での英語登壇してみるのオススメです

ツールを活用しましょう

良い世の中になりました。

• Google翻訳
• DeepL (有料)
• Grammary (有料)

まとめ

推し技術

• PSGI/Plack
• h2o
• ghq
• renovate

OSS活動を始める上で大事なこと

• まずは踏み出してみる
  • 怖がらない
  • 恥じらいを捨てる
  • 失敗を恐れない
  • 最初から完璧を目指さない
• そんなに怖くもないし肩肘張らなくても良い
• 楽しいよ
• 感謝の気持があればそこまで怖いことにならないのではないか

宣伝

僕のOSS活動を支援してくれると嬉しいです。

• GitHub Sponsor
  • https://github.com/sponsors/Songmu
• ghq handbook
  • https://leanpub.com/ghq-handbook

We are hiring!

• Natureではエンジニアを絶賛募集中です
  • バックエンドエンジニア (Go)
  • iOS/Androidエンジニア (React Native/TypeScript)
  • フロントエンドエンジニア (React)
• 同時接続20万台を超えるIoTサービスの裏側や電力関係の新規事業を一緒に開発しませんか！
  • 現状ソフトウェアエンジニアは8名の少人数チームです
  • 業務上の言語は日本語ですが、英語比率を高めていきたいと考えています
  • https://nature.global/jp/careers