なんとなく始めるOSSへの貢献〜お前らのマサカリ待ってるぜ！〜

この記事はCyberAgent Developers Advent Calendar 2016の最後の記事です。

皆さんこんにちは。クリスマスはいかがお過ごしでしょうか。去年クリスマスにStackOverflowに質問を投げたところ クリスマスに質問してくるんじゃねえよ と怒られたScalaエンジニアの id:shigemk2 です*1。世間一般におかれましてはクリスマスというのは非常に大切な日のようです。

まえがき

プログラマをやっているからには誰でも一生に一度は夢見るOSSへの貢献(個人の感想です)。でも時間がないとか、ソースコードを読んでも分からないとか、そもそも興味がないとか、色々な理由があって、やろうと思ってもなかなか出来ないってあると思います。でもそんなのただの言い訳じゃん、とにかくやればいいんだよやればって言う人も中にはいるでしょう。が、具体的にどういうステップを踏めばいいかが分からないと何も出来ないのも事実です。

大学生に「どうやったら勉強出来るようになりますか？」
と聞いて「勉強すりゃあいい」
と言われてもなんの意味もないわけですよね。そんなこたあわかってんですよｗｗｗ
#０から絵師になる方法論 #ダラダラと絵師になる方法
— 鐘の音@三日目マ２３‐a (@kanenooto7248) November 26, 2015

ですので、OSSに貢献するためには具体的に何をしたらいいかをなんとなく書こうと思います。

自分もそんなに頻繁にOSSに貢献しているわけでもないですし、ましてや有名OSSのコミッタでもないです。でも、OSSへの貢献はなんとなくからでも始められるよっていうところをなんとなく証明したいと思います。

今年貢献したOSS活動一覧(一部)

なんとなくOSSを見つける

いちばん重要なのはどのOSSにどのようなIssue/Pull Requestを投げるかを考えて決めることですが、ここの部分がなかなか決まらないのが最大の難関です。ではどうするのが良いのでしょうか。

仕事/プライベート問わず、普段から使っているライブラリ/ツール/言語から当たってみましょう。いきなりエディタ/IDE本体や言語本体は無理でも、それに付随するツール、ライブラリ、プラグインなど、あなたの身の回りはOSSに溢れています。しかも、言語→フレームワーク→エディタ/IDE→ライブラリ/プラグインと、コードのサイズもどんどん小さくなっていくのでライブラリやプラグインはとっかかりやすいです。

なんとなく改善したいポイントを見つける

改善したいポイントは大きく分けて2つになると思います。

ソースコード
ドキュメント

開発をやっていると、ツールやライブラリについて「ここ使いづらいなー」とか「ここ動かないんだけど」とか「ここのドキュメントリンク切れあるんだけど」など、不便なところや不具合が見つかると思います。明確に言語化出来ないまでも違和感があるということは多いので、感じた違和感はメモするなりツイートするなりして文章に残すといいです。そうしたちょっとの違和感が、IssueやPull Requestにつながることも多いので。

わからないことがあったら、 まず公式サイトを見ましょう 。ググって二次情報に頼るより、そっちのほうが確実です。検索順位はいったん無視して公式サイトへアクセスしましょう。公式サイトにはだいたいダウンロード方法の他にドキュメント、ソースコードの場所、わからないときの質問の場所が記載されています(それらしい情報が見当たらなかったらそれを報告しましょう)。

あと、結構な数のOSSのソースコードはGitHubで管理されているので、直接ソースコードを追いたいときは名前 + githubでググると良いでしょう(GitHubで管理していないOSSもそれなりにありますが)。Issueの報告や開発は名前 + contributeでググるといいです。

ちなみに、oh-my-zshのようにプラグインをPull RequestするOSSとか、ドキュメントが足りていないところとかが貢献しやすいです。あと、OSのバージョンが上がったらかなりの高確率で何がしかの不具合が出るので、それを報告すると良いでしょう。

なんとなくIssueを出す

Issueを出すのも立派な貢献だと思っています。気づいたことをIssueなどに残すのもたぶん立派な貢献です。統計がないので別に日本人だから全然Issueを出さないとか海外ではもっとIssueを出しまくっているとは言えませんが、不具合や不便なところはどんどんIssueを出せばいいと思います。ただ、最低限 何をしたら 何が起きたのか はできるだけ詳細に書きましょう。ちなみに、Homebrewのように質問の投げ方や作法を明記しているところもあります。

最近感じたのは規格決めたり実装する側もフィードバックほしがってて拙くてもいいからガンガン報告した方がいい。仕様策定中の機能に対してバッドノウハウで解決するのやめろ。
— 現場の声 (@mizchi) March 14, 2015

ただし、使い方に関する質問はIssueに出すべきではありません。メーリングリストやフォーラムがあればそちらを使いましょう。また、Stack OverflowやGitterに質問を投げれば、有識者が優しく答えてくれると思います。

「issueに質問立てるより，先にmailing listで質問してね」って書いてもまぁガン無視されるよなぁという．issue templateもどれだけ効果あるのか分からんな…
— 君の名は。ヒッセン (@repeatedly) February 24, 2016

なお、バグ報告はほとんどすべてが英語です。最初にIssueを出すときは全然良くわからなくて、「本当にこれでいいんだろうか」と何度も頭の中をぐるぐるします。推敲に推敲を重ねた結果時間だけが徒に過ぎていくのはつらいので、最初は本当になんとなく書いてエイヤで送信ボタンを押すといいと思います。

なんとなくPull Requestを出す

プルリクを出すのにもそれなりの礼儀と流儀が必要です。以前自分のブログには書きましたが、こういう機能を追加したい旨をIssueを通して予め作者に聞くことで、開発しなくて良い機能を開発してしまうリスクを低減出来ますが、まずは書いて出してみるのも一つの手ではないでしょうか。Just code it up and create a pull と、cheatの作者に以前言われました。

typoやリンク切れならたった1行です。たったの1行でOSSの貢献と言えるんでしょうか。言えるんです。胸を張って生きていけばいいんじゃないでしょうか。

Issueの項でも書きましたが、最初にPullRequestを出すとき/パッチを投げるときは全然良くわからなくて、「本当にこれでいいんだろうか」と何度も頭の中をぐるぐるします。推敲に推敲を重ねた結果時間だけが徒に過ぎていくのはつらいので、最初は本当になんとなく書いてエイヤで送信ボタンを押すといいと思います。