GitHub co-founder の Tom Preston-Werner (以下もじょ先生) が お仕事のコードも大半はオープンソースにしたほうがいい という話を書いている。 (@higepon の tweet で知った。)

同じような主張は、ビジネスとしてのオープンソースが隆盛を極めた 2000 年前後にもみられた。 時は流れ、今はソフトウェアそのものよりはアプリケーションやサービスをウェブ越しに売る時代。 ハイテク企業の前線もコード自身からデータやユーザの時間といったコード以外の部分に少しづつ軸足を移しつつある。 そうした企業は十年前とは異なる文脈でコードをオープンソースにしはじめた… というだいたいの背景を踏まえつつ読むと、もじょ先生の話は感慨深い。

もじょ先生はスタートアップの founder/CTO らしい立場でオープンソースの利点を説いている。 私はスタートアップ勤務でもなければ経営者でもないけれど、なりゆきからオープンソースなコードで仕事をしている。 そこで私個人がオープンソースな仕事のコードをどう感じているか、どんな風に嬉しいのか、 ヒラ従業員からみたオープンソースの話を書いてみたい。

一応事前にあやまっておく(?)と、基本的に仕事のコードがオープンソースなのはいいですよウヘヘ という自慢話なのでそういうのが嫌いなひとは適当にスキップしてくださいね。

職探し

もじょ先生は、仕事コードをオープンソースにしておくと雇用の役に立つと主張している。 該当プロジェクトにパッチを送ってくれる開発者がいたら、その人は潜在的なヘッドハント候補になる。 プロジェクトに興味を持ってくれているし、なによりパッチをみればコード書きの腕前がわかる。 ややこしいインタビューなんて必要ないという。

雇われる側にも同じことが言える。 オープンソースのプロジェクトなら、 ある職場で働くと決める前にコードをみることができる。 これはその職場で働くかどうかの決断を後押ししてくれる。

職場を移るとき、行き先のコード品質はいつも大きな不安のもとだ。 もし仕事でさわるコードがひどいものだったら… 月曜の朝、またうんざりなコードをいじる日々がはじまるのかと絶望する自分を思い浮かべて足がすくむ。 デスマ、薄給、トンガリ頭とおなじくらいこわい。あるいはもっと。

私は今の勤め先が公開するコードをいくつか眺めていたし、 いまのプロジェクトのコードも覗いていた。 だから仕事を始めるにあたりひどいコードへの不安はなかった。 それほどすばらしくない部分があることもわかっていたから、叶わぬ過剰な期待もなかった。

良いソースコードは良いエンジニアリング、よいプログラマの証左でもある。 コード自体は良いのに周りのインフラやプロセス、 コードを書いたプログラマがダメなことは少ない。 コードのスナップショットだけでなく、 レポジトリの履歴やバグトラック, CI のダッシュボードなども公開されているなら 仕事の様子をもっと詳しく見ることができる。実際にパッチを送ってみることだってできる。 一日のコミット量やパッチの粒度、ブランチの使い方、インフラの自動化具合、 バグやパッチをめぐる議論の口調、ツリーの greenness。 自分が迎えるであろう一日を思い浮かべる材料は事欠かない。 自社のエンジニアリングに熱弁を振るう blog 記事や豪華ランチつきオフィス・ツアーもいいけれど、 個人的にはコードやバグトラック、メーリングリストのように仕事の様子が見える方が信用できる。

実際、まともなコードとクリアなワークフローの上で仕事をするのは気分がいい。 自分が正しいことをしていると思える。遠くまで視界がひらけていている。 でも私がこう書いたのを読むよりは、該当プロジェクトに パッチを書いてチェックインするまでを見届ける方がわかることは多い。 会社説明会よりインターンの方がいろいろわかるのと同じ。 良し悪しだけじゃなくて好みもあるしね。

パッチを書くなら、 3-4 個は試してみたほうがいい、 プロジェクトの規模が大きいと、最初はしきたりを理解するだけでくたびれてしまう。 そういえばプロジェクトの規模がわかるのもいいところ。

自分のものなかんじ

愛着のある仕事のコードはどんなものだろう。 これまでに書いたコードを振り返ると、自分が多くの部分を書いたものには愛着を感じた。 半分・・・は無理でも、ある規模のコードで 2-3 割を占めれば愛着がうまれる。 そんなコードを書いた職場やプロジェクトを移るときは、 もうすこし良くしてあげたかったと心残りがある。

この愛着は所有感の表れだと思う。 自分の書いたコードは自分のもの。自分自身の断片、自分のものである以上はよくしてあげたい。

もちろん厳密にいえばこの所有感はまやかしだ。 仕事で書いたコードは勤務先のものだったり、 受託開発だったら多くは発注者のものだろう。

相対的にみると、有期のプロジェクトが終わると納品されてさよならになる 受託開発のコードは愛着を感じにくい。別れがくるとわかっているから。 勤務先のために書くコードはもう少し愛着をもちやすいけれど、 終身雇用なヒトでもない限りいつかは別れがやってくる。 実際は職場を変えなくても自分がプロジェクトを離れたり。 プロジェク自体がキャンセルになればコードはいなくなる。 そうわかっていても愛着を感じてしまうのは、 投じた労力への後ろ髪、そしてコードの大半を書いた人間がもつ実質的な影響力のためだろう。 たくさんコードを書いたら、そのコードの行方に少しは口を挟める。

オープンソースのプロジェクトは愛着を持ちやすい。 コードが誰かの独占的な持ち物ではないからだと思う。 自分の意に反してどこかに消え去ってしまう心配が少ないから心を許せる。 明文化されていない「実質的な」影響力に頼らなくてすむ。

私が仕事でおじゃましているプロジェクトの中で私が書いたコードは 1% 未満だけれど、 それなりにプロジェクトへの愛着はある。 特に自分が手を入れたモジュールは良くしてあげたいと思える。

Your mind can be on it.

コードやプロジェクトへの愛着は仕事を離れても続く。 たとえば WebKit の IRC channel には、勤務時間に限らず常駐しているメンバーが多い。 真夜中に “good night” と退室していく人をよく目にする。 こうした常連にとって、 WebKit は生活の一部になっている。

私は IRC が好きではないので勤務中以外は常駐していないけれど、 それでも仕事のことはよく考えているし、プロジェクトの比較的立ち入った話を ウェブに書いたりワークショップで話したりするのは割と好きだ。 だから仕事の話をおおっぴらに書ける今の perk は私にとってだいぶ嬉しい。 コードをみながら具体的な実装の話を書けるのはいい。

Chromium 用の高速ビルドツールである Ninja はなぜか github にホストされており、 プロジェクトが余暇にうまれたことを示している。これも愛着の表れとみていい。

オープンソースな仕事でなくても、仕事のためのツールやライブラリを余暇に書いて公開しておき、 それを仕事に持ち込んで使うことはある。特に Web で仕事をする人にはそんなところがある。

仕事のプロジェクトがオープンソースになっていると、こうした仕事関係余暇ハックの敷居はさがる。 余暇のコードが本業のコードに依存しても構わないため、依存関係の制限が少なくなるからだ。 本業のコードから独立した部分をうまく抜き出し、仕事以外で使えるツールに仕立てることもできるだろう。

Twitter の Jeremy Cole は、 ある講演 の中で オープンソース仕事の良さをこんな風に説明している:

One of the main things that open-source gives us is the ability to take the work with you wherever you go, and not have to worry about being changed what you are working on, or feeling like you are just doing a day job.

You can feel like you are building something that you can keep and that lasts really long time. You are sure the company couldn’t just kill the project because the code is out there, and if they did, you could keep working on if you really liked it.

See. You can free to think about how you are building it, how new architecture it should have, and all that.

While you take a shower, while you are driving around or whatever you are doing, your mind can be on it.

And that is one of the awesome things in open-source.

愛着のある仕事コードがオープンソースであることの良さを端的に説明していると思う。 かつて MySQL に勤めていた Jeremy Cole は退職後も MySQL にパッチを書いていたというからなかなか説得力がある。 Twitter 自身にも、もじょ先生のいう積極的なオープンソース化を地でいく所があるよね。

ほしいと言ってみる

余暇ですごいコードを書きオープンソース化してプロジェクトを育て、 その実績を勤務先に認めさせて仕事に持ち込む。 そんな方法が、お仕事オープンソースの実現パターンとして知られるようになった。 スーパープログラマの努力が認められるのは素晴らしいと思うし、 これをやってのけた人々はすごいと思う。

私は自分のコードをオープンソース化するのに何も努力していない。（※仕事はがんばってます。） 昼間書いたコードが勝手に表に出ていく。 プロジェクト開始時のメンバーたちは今の状態をつくるのに何らかの労を割いたことだろう。

先に書いたとおり、仕事コードがオープンソースなのはいろいろと良いことがある。 だからできればガッツあふれるスーパープログラマ以外も オープンソースなコードの上で仕事ができた方が楽しいと思う。 根性と才能があればオープンソースを仕事に出来るというのは、 仕事と子育てを両立し出世街道を邁進するハイパーキャリア女子を 雇用機会均等の証にするみたいでやや居心地が悪い。 たぶん私には余暇で書いたコードを仕事に持ち込む実力も根性もない。

これは私個人の印象なのだけれど、 「仕事のコードがオープンソースだと嬉しい」という主張は プログラマにもプログラマ以外にもあまり認知されてない気がする。 コードの読み書きに興味がないとぴんとこない話だろうし、文句は言えない。

けれど認知が広まれば、たとえば茨の努力ルートに入る前に まず今書いてるコードをオープンソースにしたいと言ってみれば、 案外するっと話が進んだりしないだろうか。楽観的すぎるかもしれないけれど、 福利厚生としてオープンソースが喜ばれると経営者や管理職が認識すれば 願いが聞き届けられる可能性は上がると思う。

世にある景気のいいソフトウェア会社の中には、 プログラマ獲得のためにけっこうな予算を割いているところがある。 入社時にいくらか余計に現金を払ったり、高級な椅子、広い画面、おいしい食事を用意したりする。 これはどれも素晴らしいものだと思うけれど、たぶん結構高くついている。 プログラマばかり優遇するせいでプログラマ以外の同僚ににらまれたりしないか心配でもある。

コードをオープンソースにするのは、ふつうそれほど高くつかない。GitHub のホスト代くらいでいい。 プログラマ以外の人にとってコードはどうでもいいだろうから、オープンソース化で角が立つこともなかろう。 少なくともプログラマを絶賛募集中の会社にとって、 オープンソース化はプログラマを相手にした割のいいアピールになりうる。 実際、企業アカウントで細々としたコードを公開する小さな会社は東京でも見かけるようになった。

まだそうなっていないプログラマは、 試しに仕事のコードがオープンなのは自分にとって嬉しいとアピールしたり、 仕事で使える Github アカウントがほしいとねだってみればいいと思う。 そして仕事コードのうち表に出しても角が立たなそうな部分　(もじょ先生によれば “almost everything”) を少しずつ仕事用 Github に移して開発を進め、 区切りのいいところで交渉してレポジトリを private から public に flip する。 そのくらい融通の効く会社がたくさんあると、プログラマの仕事はもっと楽しくなることだろう。

ある日、よその会社で働く友達のコミットにバグをみつけた。昼休みにちょこっと直して pull request:

commit 80e62a7654637d9ed930a2818c28b20cc794fcc8 (HEAD, master)
Author: Hajime Morrita <omo@dodgson.org>
Date:   Sun Nov 27 16:30:29 2011 +0900

    エスケープ漏れを修正。グラコロ一個でどうか。

そんな日がくればいい。