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

YAPC::Kyoto

Mar 19th, 2023

Profile

songmu

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

Profile

songmu

id: Songmu (ソンムー)
♥
- OSS
- Blog / Twitter
- Agile
- Full Cycle Development

最近のOSS活動抜粋

ghq
ecschedule
tagpr
javaimports
vim-lsp-setting

ghq

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

様々なソースコードリポジトリをシンプルにローカルに取得できる
pecoやfzfと組み合わせると強力

ecschedule

https://github.com/Songmu/ecschedule

⭐ 111
ECSのスケジュールタスクを管理するツール
ECSのdeployツールecspressoにインスパイアされて作成
最近個人的にはECSを全く使っていない…

tagpr

https://github.com/Songmu/tagpr

⭐ 133
新作
GitHub上でTag requestのような振る舞いを実現
OSSリリースの民主化の実現

javaimports

https://github.com/nicolascouvrat/javaimports/pull/65

vimでJavaが書きたくて…。

vim-lsp-settings

https://github.com/mattn/vim-lsp-settings/pull/565

神様みたいな人でもこういうバグを仕込むことがある。こういうのも貢献チャンス。

この発表のゴール

「OSSに貢献する人を増やす」

ソフトウェア開発と人間

そもそも自分は人間とアレコレしたくないからコンピュータを触っているのであった（今どきこういう考えをしている人は少ないのかもしれない）。それなのになせこんなことに……。
-- motemen "ghq など、github.com/motemen 下のリポジトリを x-motemen Org に移しています" https://motemen.hatenablog.com/entry/2020/03/x-motemen-org

OSSとは何か？

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

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

私とOSS活動

OSS Development as a Hobby

自分のOSSやBlog活動が黎明期の時代に噛み合って先行者利益的に上手くいった部分があるんだろうなぁとは思ってて、そんな牧歌的な時代に運良く上手くいったやり方をあまり自慢気に話しても仕方ないよなぁ、というのを思っている。つまり来週のYAPC登壇で話すことを考えている。
— songmu (@songmu) March 12, 2023

量が質を生むと信じたい

200+ GitHub public repositories (without forked)
70+ CPAN Modules

70+ CPAN Modules

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

pull request歴

2011年に初めてのpull request
現在1437個のpublic pull request
- -org:Songmu すると837個
- さらに -org:mackerelio, -org:x-motemen すると294個
pull requestを送っている方だと思う

Launchable入社に送ったpull request

面接前に試したらGitHub Actions上で動かなかった -> チャンス!

修正はこれだけ

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

x-motemen/ghq
tokuhirom/Archer
kazuho/test-mysqld
tcnksm/ghr

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

OSS開発者として

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

OSSは楽しい

そう言いたい
OSSコミュニティに育ててもらった
幸せなOSSライフを送ってきた

疲れてしまう人もいる

OSSに過大な責任が伴わないでほしい
無責任に楽しみたい
- でも悪意は混入しないように

Just for Fun: The Story of an Accidental Revolutionary

使命感とかではない
善意や慈善活動でもない
楽しいからやる
それが革新につながる

メリットも後からついてきた

コミュニティ
- 業務上直接の利害関係がない友人関係
キャリアの依存先を増やせる
家族に自分の仕事を知ってもらえる
設計力・抽象化力
錯覚資産

何故OSS活動をするのか

業務上必要に駆られて
カッコいいから

カッコいい・好きを恥ずかしがらずに表明できる勇気

感情で動くことは愚かではない
- ただし、感情的になってはいけない(日本語難しい)
人間は感情の生き物である
感情的であることを隠そうとして、理屈をこねても仕方がない

ソフトウェアエンジニアはエモい

好きを仕事にできる / 情熱
技術選定なんてその最たるもの
- 理由なんて後付けのことも多い

技術選定

技術選定は正解が複数ある中から一つを選ぶ工程
- 選択の結果を、後で正解にする
- 選択・決断できるチャンスを掴みに行くのは大事
- 説明能力やリーダーシップは大事
好きな技術使ったやる気でて生産性上がる

好きな技術を使えないこともある

楽しもうとすること、理解しようとすることは大事
それが良いと思ってる人もいるのだから、その人から新しいことを知ることができる

楽しむ

つらいことがあったから見返りがあると認知錯誤に陥ってはいけない
- つらい体験を糧にしようとする気概は良し
楽しい方が良い
- エンジョイにまさるものなし
- 「夢中」が人を成長させる
もちろんつらいこともある

ビジネス「も」楽しい

「エンジニアもビジネス分かるべきだ」とかイキっちゃう現象
お客様に喜んでもらえる / お金を稼げる / 自分の世界が広がる / 大規模な仕事 / 社会に影響を及ぼせる
様々な人の欲望や思惑が関わり合っているのがビジネス
様々な原動力があって、多用な価値観がある
もちろんコードの楽しさを求めてもよい
優劣は無い

業務での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の例

以前の職場でつかっていたGoのWebフレームワーク
メンテナンス滞ってそうだけど送ってみたらすんなり取り込んでくれた
その後デフォルトブランチがmainになったりと案外アクティブになった

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

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

goblin

https://github.com/bmf-san/goblin

Goのフレームワーク選定時に柔軟で高速なルーターを探していて見つけた
内部構造にTrie treeを使っていて良さそうだと思った
Trie木を使ったルーターといえばPerl界ではRouter::R3
- それを知ってたからこれが良さそうだと感じた
このときは結局使わなかった
- 良いルーターだと思います

Redis::hiredis

いくつかpull requestを送っていた
shogo82148++ さんがRedis::Fastを作ったので使う必要がなくなった
- Reds::Fastってモジュールを書いた
無駄撃ちを気にしない!

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への貢献とは？

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

使うこと「だけ」でも貢献
- ただし使っていることを隠さない
可能なら問題や疑問を報告する
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 を使いたいが、ちょっと挙動が好みじゃなくて移れていない)

Minilla

https://metacpan.org/pod/Minilla
tokuhiromさんが作ったモジュール作成ツール
Perlプロジェクトの雛形をコマンド一発で作成
コマンド一発でCPANリリース
これができて明らかにCPANモジュールが作りやすくなった

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

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

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

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

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

プロダクトを引き継ぐこと

私のCPAN distの1/4がfirst authorではない
tokuhiromから多くを引き継いだ(コミット権をもらった)
Go: github.com/x-motemen/ghq
Ruby: github.com/x-motemen/git-pr-release
引き継ぐことで他者の流儀を学べる

大体 @tokuhirom にパッチを送ると「You have commit bit!」って言われてコミット権が降ってくる時期があった
— songmu (@songmu) March 17, 2020

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

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

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

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

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

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

OSS活動に関わるメリット

プロダクトマネジメント
英語
ノーリスク

OSSで学んだこと

OSSは人間同士の営みである

リポジトリ毎に個性がある

コード多様性

miyagawaさんのコードは軽妙でおしゃれ
lestrratさんのコードはパワーがある
tokuhiromさんのコードはおしゃれな部分もあるけど案外手堅い
gfxさんのコードは難しいが爆速
kazuhoさんのコードはシンプルだが緻密で抜けがない
motemenさんのコードはおしゃれでありながら、一筆書きのような勢いもある
moznionさんは異常な努力を可能にする腕力が感じられる
mattnさんはwindows

(個人の感想です)

正しいコードの先にある個性豊かな美しいコード

自然言語がそうであるように
- 正しい日本語・美しい日本語
ちゃんと読めるコードだったとしても
書き手の思想を汲み取りたい
CPANにはアバターアイコンがあったのが良かった

同じものを作るにしてもコードは異なる

何故やりたいのか、どういう問題を解決したいのか
オプションを多くして柔軟な作りにしたいのか、一つの問題をしっかり解決したいのか
クラス構成を重厚にしたいか、シンプルにしたいか

「作法」にとらわれない

最低限のルール理解はもちろん大事
- OSS提供側もセオリーに乗っておく方がスムース
- ただしルールは増えて欲しくない
- マナー講師案件
テンプレCONTRIBUTING.md が苦手
- 「形を整えておけばOK」ではない
- 「最低限これだけはやっておけ」は肥大する
- 重厚な形骸化したプロセスになるのは避けたい

相手を理解しようとする

OSSは人間同士の営みである
リポジトリを観察する
- 類似issueや作者の活動状況
相手に期待しすぎない

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 700点
「ソフトウェアエンジニアに一番大事なのは英語だ」という言説を見かけるたびにウッってなる
ソフトウェアエンジニアにとって英語は大事なのは確か

英語は別にマストじゃない

できたらより面白いことができる可能性があるという話
- 有力な"オプション"である
他のハイクラスな職種は、英語が"マスト"であることも多い
英語がそれほどできなくても海外や近い環境で働けるチャンスがある
ソフトウェアエンジニアは恵まれている

OSSは英語練習の場に使える

コードという共通の話題がある!
いざとなればコードを見せて「How about it?」で良い
ノーリスク

大事なこと

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

テクノロジーと英語

英語に対する敷居は下がっている
テクノロジーの力は素晴らしい
- DeepL, Grammarly, ChatGPT
学習アプリも充実している
- ELSAが最近気に入っています
殆どが機械翻訳で成り立つ未来は来る
でも全ては置き換えられないし、置き換えて欲しくはない
- 言語の多様性が文化を生む
- 正しいコード・個性のあるコード・美しいコード
- 正しい文章・個性のある文章・美しい文章

OSSと課題

過剰な期待
サプライチェーンアタック
SaaS
ビッグテック主導

OSSに対する過度な期待

OSSにしたらうまくいく
- はずがない
過剰な機能提供やサポートを求めること

Linusは特別

Linux / Git はうまくいきすぎた
- この2つ以上に、業界の依存性が高く長続きしているOSSがあるか?
OSSは全員の力で改善するからうまくいく？
- 合議制の落とし穴

リーダーシップの大事さ

「優しい終身の独裁者」
プロダクトを推進する力
Noと言える力
良い経験にもなる

無駄撃ちを気にしない

作り捨てみたいなのもっとやって良い、許容されてほしい
OSSに対する過度な期待が、トライの回数を減らしていないか

悪意の混入

サプライチェーンアタック
OSSエコシステムを壊される、更には加害に利用する
悲しい
性悪説前提にすると面白くなくなるしスピードも遅くなる
信頼性のモデルを改善していく
- 信頼は大事とは言ったが、新規参入のブロッカーになると困る

CPANのアカウント申請

今でも申請と審査がある
- ある程度自動化されてるぽい？
申請で意気込みを書くのでモメンタムが生まれる部分もあった

OSSとSaaS

SaaSは強い
- お金がある
- デザイナーが雇える
- 最新バージョンだけをメンテすればいい
- ユーザーの利用状況もデータがある
  - 要らない機能を削れる
OSSは結局インストール型と同様のリスクを持っている
- 複数バージョンの混在
- コードをダウンロードしないと動かせない

OSSはどのように向き合うか

利用者はOSSに過剰な運用プロセスを求めない
- 複数バージョンのメンテナンスを求める等
作成者側はいくつかの戦略がある
- 隙間家具戦略
- エコシステムを作って協調できるようにする

隙間家具戦略

隙間はいたるところにある。

https://speakerdeck.com/fujiwara3/aws-devday-tokyo-2019

エコシステム

仕様を作ってOSSで実装することにより、ベンダー側がサポートするインセンティブが生まれる
- Open Telemetryの例
- 各ベンダーの思惑が絡み合って、仕様策定は大変そうではある
ある領域が飽和してシェアを食い合う競争になってくると相互運用性が求められるようになる

ビッグテック主導のケースが増えてきた

スポンサー問題
お金が流れることは良い事
多くのOSSもビッグテック発が中心になりつつある

インディーなOSS開発

インディーゲームは作られ続ける
Honoはすごい
Envoyが好き
OSSからビジネスに
- Next.js -> Vercel
- Varnish -> Fastly

まとめ

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

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

ソフトウェア開発と人間

そもそも自分は人間とアレコレしたくないからコンピュータを触っているのであった（今どきこういう考えをしている人は少ないのかもしれない）。それなのになせこんなことに……。
-- motemen "ghq など、github.com/motemen 下のリポジトリを x-motemen Org に移しています" https://motemen.hatenablog.com/entry/2020/03/x-motemen-org

OSSコミュニティで仲間ができて人間関係を楽しめるようになった。

自分が続けたいこと

コードを書き続けること
情報を発信すること
- blogを書き続けること
- OSSを作ること
英語

アンラーニングできていない？と思うことはあるが原体験なので大事にしたい。「死ぬまで続けるかも」という感覚を持つようになってきた。

宣伝

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

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