ただのにっき

■ GitHub時代のオープンソース・プロジェクトとの付き合い方

GitHubへpull requestする際のベストプラクティスからmaster ブランチで pull request していいのは小学生までってこともないの流れを読んでいて、先日ruby-listであったRedmineのRuby1.9,Rails3対応の話を思い出した。あのときは投稿者は納得して、「GitHub時代のコントリビューションの仕方」みたいなものを理解してくれたようなのだけど、その上で「masterでパッチ作るな」的なお作法を生真面目に受け取りすぎて敷居を高く感じてしまわれても困るよなぁと思った。

そこで、「GitHub時代にフリー/オープンソース・ソフトウェア(以下FOSS)プロジェクトと付き合うための五ヶ条」的なものをまとめてみた。まぁ、そんな大それたものでもないけど。

1. 貢献しようと意気込まない

FOSSに関わろうとすると必ずついてまわる「貢献」の二文字。重いよねぇ。はっきりいって、貢献なんて別にしなくていい。そもそも「貢献」はされる側が評価に使う言葉だよ。する側が声高に宣言するもんじゃない。

最初から「FOSSに貢献しよう」なんて考えないこと。まずは「このバグが直らないと自分が困る」くらいの自己中でいいから気軽に接しよう。

2. ナイショにしない

自分のためにFOSSに関わるとなると、「別に自分の成果を公にする必要はないのでは?」と思うかも知れない。ごもっとも。でも、自分と同じことで困っている人は必ずいるものだ。その人にも同じ苦労をさせる非効率は、エンジニアとして許せなくない?

少し前なら、自分の成果を公開するのは少々面倒だった。だからローカルでちょちょっと修正したパッチを隠し持っている人も多かったと思う。そのハードルをぐっと引き下げてしまったのがGitHubを始めとする現代のリポジトリサービスだ。そのあたりは別項に譲るとして、面倒がほとんどないなら、成果を公開しておいても誰も損はしない。

3. forkすることを厭わない

FOSSプロジェクトにとって従来、「フォーク」は忌み嫌われるものだった。最近でもHudsonとJenkinsの不幸な事件があったばかり。FOSSプロジェクトの分裂はあまり良い結果をもたらさない。

ただ、GitHubのforkはプロジェクトの分裂を意味しない。単にソースツリーの個人用コピーを作るだけの作業だからだ。さらにgitにはツリー間の統合が非常にやりやすいという特性があるため、ソースツリーがたくさんあることは混乱を意味しないのだ。

「ちょっとこのツールのソースをいじりながら読んでみたい」。そんな動機でもいいので、GitHubのforkボタンは気軽にどんどん押そう。そしてそのツリー上に、自分だけの成果をどんどん公開しよう。

4. パッチを送るのを躊躇しない

こうやってGithub上には同じプロジェクトから派生したたくさんのソースツリーが存在している。日々本家に追従するのはもちろん、他の人が作ったパッチを自分だけのソースツリーに取り込んでもいい。一方で、自分が作ったパッチを本家に取り込んでもらいたいこともあるだろう。

そんな時は、遠慮なくpull requestを送ろう。従来パッチを取り込んでもらうためにクリアしなければいけなかったハードルのかなりの部分を、GitHubはボタンひとつの気軽な行為にしてしまった(ただし、パッチが受け入れられるかどうかは別の話)。

冒頭に出てきた「masterでパッチ作るな」というのはこのあたりで初めて効いてくるテクニックだ。実際、master上で作られたパッチでも、受け取る側はそんなに苦労はしない。リジェクトされたパッチの処分に「自分が」困るからトピックブランチで作業した方がいいよという話なのだ。だからgitのブランチ・テクニックはこのあたりで身につけても遅くはないよ。

5. つらくなるまで続けない

最後は、多くを語る必要はないだろう。無理することはない、楽しくやろう。これが一番大事。

実際、こんなことを書いているおれだって、そんなにたくさんのプロジェクトをforkしているわけじゃない。あんまり手を出しすぎると続かないのが自分でもわかっているからね。

Enjoy!