「今年は…何か大きめのOSSにコントリビュートしたいですね」

timakin
7 min readAug 14, 2017

これはポエム。

先日、晴れてGoにContributeできまして、積年の目標であった「なんか大きめのOSSにコントリビュートする」を達成した。

これは前から本当にやってみたかったことで、Issueを立ててはCloseされ、をRubyやらGoやらで何度かやった末のコントリビュート。

割と一個のマイルストーンを経た感じがして、個人的には感慨がある。

OSSにコントリビュートしてみたい

そもそも、プログラミング初めてからというもの、「Rubyにpull-req送ってます」とか、言語そのものへのコミットにはかなりの憧れを感じていて、社会人になる前後からというもの、3年前くらいから、何か面談とかで目標を聞かれるたびに、ずっと「技術的には…言語とか有名なソフトウェアへのコミットをしてみたいですね…」と言っていた。

とはいうものの、心理的障壁が高くて、自分のような技術力でできる気がしなかったのと、ソースを読み進めようとしても、全然わからんということが多く、いつも断念していた。

その分、「やっぱり自分は技術者としては未熟なのかな」とか、「そもそも才能がなかったのでは」、「自分と同年代でバリバリ業務もOSSもやってる人間なんてたくさんいるのに何をやっているのか」、「あと数年この言語で経験を積んだらできるのかな」とか考えることが多くて、正直非常にゲンナリする、コンプレックスだった。

そのせいか、周りの優秀な友達に、「どうやったらそんなに技術そのものを突き詰めて、コミットできる機会に出会えるの」「どうやってコードを読み進めているの」という質問をすることが多くなっていた。

自作ライブラリ

言語などにはコミットできないものの、自分でソフトウェアを作ってコミュニティの反応をみれば、糸口が掴めるのかな、という想いから、ある種の言い訳のように自作ライブラリをつくるようになった。

まあ最初は上記のような考えだったものの、毎日Githubに変更をあげてると、さすがに業務でも必要だからこれも作ってみたい、などの柔軟性が効くようになってきた。

ただ、ある程度作ってみたものの、やっぱり「でかめのOSS」へのコミットは「ウッ」と胸につっかえるものがあって、二の足を踏んでいた。

イケてなさそうに見えたGoのコード

先日、同僚のとある方が、Goのデータベース周りのコードをシュッと持ってきて、よしななプーリングを実装しようとされてて、仕組み自体はよさそうだがコードのスタイルとか微妙に効率悪そうなコードがあったので、レビューがてら目を通していた。

その時自分は、そのコードが割とGoの公式のコードを流用したのを知らなくて、「ここはこうした方がよくないですか」的なコメントをしていた分、少ししてから「これはGoのコードとほぼ同一なのか」と気づいて驚いた。

というのも、「おいマジか、Goのコード実はイケてないところあるのでは?」と認識したからで、ひいてはもしやコントリビュートチャンスか?と思うに至った。(なお、当該箇所のコードは、調べた結果別に問題ではなさそうだったので、イケてないと思ったのは個人的な主観だった)

Goへのコントリビュート

Goで、自分はこういう機能があった方がいい的なIssueを立てては勢いよくCloseされる経験をすでにしていたので、今回は違うアプローチで、HelpWantedとかNeedsFix、というあからさまにコミュニティ側が求めてることを優先してやってみよう、と考えた。

Goのissues

ちょうどバージョンが上がるタイミングで急を要するFixタグが多かったので、その一個に手をつけてみた。

やってみて一番意外だったのは、こういったコミットはレビュアーの反応も超速く、すんなり通るので、個々人のかんがえたさいきょうのコミットとはハードルが全然違ったことだった。

なんか割とスッと「LGTM」的な感じだったので、逆にマジかよとなった。

また、Goに前コミットしようとしたときより、GerritというGithubの代替みたいなツールのインターフェースが格段によくなったり、Contribution Guideもわかりやすくなってて、そのまま作業をなぞって進めていけば、コードの変更に集中できた。これはかなりドキュメントに助けられた部分である。

GerritのPullreq詳細画面。慣れると結構いい気しかしない。

mergeと感想

最終的にmergeされたとき、色々と積もったモヤモヤが消えて、久しぶりに素直に嬉しくてニコニコしてた。というか本当に内心ボロボロ泣いてた。

今振り返ってみると、「何か大きめのOSSにコントリビュートしてみたい」という想いは、モチベーションはあるけど、コミュニティへの貢献に直結するかは微妙な考え方だとわかる。

もっと素直に、Goにもいい面悪い面あるし、Fixしてほしそうなところあるっぽいからちょっとやってみるか、くらいの軽い気持ちで捉えるべきだったと思う。

何はともあれ、自分の技術的なマイルストーンの一つをクリアして、もっと目標を高くしていくぞ、継続的にコミットしていくぞ、という考えが胸に出てきて、コンプレックスもだいぶ解消されたのが、実りだった。

よくOSSとかで頑張りすぎちゃって、業務で成果をあげられないとダメみたいなことをいう人がいて、それは全くその通りだとおもう。業務とか自分のサービス作るとかは、ちゃんと集中しなければならない。

ただ、だからコミュニティやソフトウェア自体に目を向けなくていいかというと、全くそんなことはなくて、少なくとも自分がこういう技術力を持った人のノウハウを全部奪いたい と思う人は、軒並みそういう実績を残してるし、実績を残してないと技術的には観測されなくて寂しい感じになる。

あとは、みんな業務の方が大事だよね、というのは玄人ならみんなわかってるはずで、声高にエンジニアに向かってそういうことをいうのは「あのチーム、余裕がないのかな」「もしかしてエンジニアがそれをわかった上でOSS開発したいとか言ってるの、理解してないのかな」という印象に繋がってしまう。変に自己肯定するのもよくないが、あまりOSS活動を軽んじるのはよろしくないなと思う。

今いる会社のチームはみんな技術力がかなりのものだけど、「スピードが一番だよね。そのためにはコードの品質の優先順位づけを低くせざるを得ない時もあるよね」というのを、全員言い切れるという観点でいいチームだと思う。でもこういう発表してきます、ソフトウェア作りました、という活動にものすごいポジティブでいてくれるので、要はビジネスの意思決定に引きずられてスピードが大事と言ってるのか、本当に自分自身で納得して言ってるかあとで挽回するぞ!と互いに信頼しあえる技術力があるか、という条件がいい感じに満たされてるんだと思う。

周りのチームやらGoのコミュニティやらに手をお借りしつつ、今回節目を迎えられたのはそれ自体嬉しいことだけど、もっとクリティカルなコミットもしてみたいし、業務においてはより一層サービスのハンドルを握る部分で貢献していきたいと思わされる、いい経験だった。

結論、どうあれ、ユーザーやコミュニティが求めることをやったほうが、話が早いし成果につながる、ということなんだと思います。

--

--