プログラマの思索

デブサミ2013で最も感銘をうけたのは、GitHubによるソーシャルコーディングがとてつもなく大きな可能性を秘めていることに気づいたこと。
考えたことをラフなメモ書き。

【参考】
Twitter / iR3:ほ? アイスランドでは皆で憲法を書こうという取り組みがあるのか。大規模で、民主的な取り組み。オープンソースのしくみが政治を変えるというのは現実の流れとして動いているのね。

Twitter / tiny_mina: 昨日撮ったNHKのTED番組「スーパープレゼンテーション」を見た。Githubを使った立法ができれば、日本は官僚政治から脱却できるんだな。でもいったい何百年後だろう。アイスランドはすでに議員がこんな動きを始めてるらしい。

Twitter / iR3: しかしソフト開発には今ふたつの踏み絵があるな。ひとつはGit ふたつめはGithub まだまだGit以前のところが沢山存在する。周回遅れの自覚はあるのかな？ #devsumi #devsumiB

"翻訳" ドイツ連邦の法律がGitHubで管理される | ntcncp.net

法律はソースコードに似ている - モジログ

開発者からの強い支持、5年弱で300万ユーザーを突破：共同創業者に聞いた、GitHubは何が違ったのか？ - ＠IT

【公開】チケット駆動開発のフレームワーク～現場の経験知からパターン言語へ #devsumi #devsumiB: プログラマの思索

【1】GitHubがない時代、オープンソースのソースコードを修正するには、ソースコードの保持者であるコミッタへユーザが自分のパッチをメールで送って、承認してもらう必要があった。
コミッタがそのパッチを気に入らなければ、取り入れてもらえない。

また、パッチはメールで送られ、パッチの正当性を説明したり、更にパッチを修正するなどのやり取りは、メールの履歴で残していく。
延々とメールのやり取りが続き、後からログで探すのが面倒。

そもそも、オープンソースである限り、ユーザはコミッタに関係なく、自分でそのソースをフォークして改造してもいいはずなのに、そのようなやり方を採用するコストが高かった。

また、パッチを取り込むのは従来は手作業が多かったと思う。
つまり手作業でマージする場合が多かったのだ。

diffコマンドでパッチを作れば、patchコマンドで自動で取り込むことは出来る。
また、Subversionならば、trunk(メインライン)から派生したブランチ上で修正したパッチは、svn mergeで取り込むことはできる。
でも、Subversionの場合、trunkから派生したブランチ間でのマージは、merge trackingの機能が弱いためにあまり実用的でないから、手作業でマージするしかない場合が多い。
手作業のマージほど、危険で難しい作業はない。

でも、GitとGitHubが出現して大きく変わった。

コミッタが公開したソースコードは、ユーザが自由にCloneないしフォークして、自分のブランチ上で好きなように改造できる。
もしバグを見つけたら、バグ修正したリビジョンをコミッタに送って、Pullしてもらえばいい。
更に良いアイデアを機能として追加したならば、機能追加のリビジョンをコミッタに送ってPullしてもらえばいい。
これがPullRequestの発想であり、ややこしい手作業のマージ作業から開放される利点がある。

コミッタとユーザがフォークとPullRequestを通じて、ソーシャルな関係を通じて、コーディングしていくというソーシャルコーディングの流れ。
でも、PullRequestという自動マージは、単なるバージョン管理ツールの一機能という位置づけではない。
もっと大きな可能性を秘めている。

【2】Gitで管理できる対象はソースコードだけではない。
テキスト媒体なら何でも可能だ。

例えば、本のような出版物をレビューするフローを考えてみよう。

従来は、著者がWordなどの原稿に書き、バージョン管理もせず、PDF化してレビューアに配布していた。
そして、レビューアはメーリングリスト上で、誤字脱字の指摘を何ページの何行目、などのようにメールで書いて送りつけていた。

このやり方の欠点は、いくつかある。
一つは、原稿がバージョン管理されていないため推敲しにくいことや、PDFやepubのような他の形式へ変換するのが面倒なこと。
バージョン管理されていなければ、「第1章_20130311_new.doc」のようなファイル名でどんどん残してしまうため、どれが最新か分からなくなるし、修正履歴がないので後で参照する手段がない。
また、紙媒体にする時はPDFが都合がいいし、epubで出力できれば、iPhoneのようなスマートフォン上で簡単に読めるから、通勤電車や待ち時間のようなすきま時間でいくらでも原稿を読み直すことができる。
一つのテキスト媒体を複数の形式の媒体へ変換できれば、生のテキストファイルだけバージョン管理すればいい。

つまり、著者が自分の考えをテキストで書き、ツール(Sphinx、Pandoc、ReVIEWなど)で出版物(HTML, pdf, epub, docなど)へ変換すればいい。
最近は、ドキュメントを作るオープンソースのツールが揃ってきており、Kindleの自費出版のようなマーケットを考えると、重要なマーケットになってきていると思う。

Sphinx-Users.jp :: ドキュメンテーションツール スフィンクス Sphinx-users.jp

Pandoc - About pandoc

ReVIEW + Jenkinsでドキュメントを常時ビルドする | Ryuzee.com

もう一つは、レビューアから指摘された事項を逐一反映するのが面倒なこと。
もし、原稿をGitHubでバージョン管理しているならば、レビューアがその原稿をフォークして、誤字脱字の箇所はパッチとして著者に送りつけて、PullRequestしてもらえばいいのだ。
その方が手っ取り早いし、指摘箇所の反映漏れもなくなる。
しかも、PullRequestの修正履歴がmaster上に残るので、修正履歴も確実に残せる。

この手法は、著者だけでなくレビューアも含めた仲間全員でより良い出版物を作ろうとする活動になる。
つまり、より良い創作物を作るには、外部のフィードバックだけでなく、外部の力を利用して修復してもらう手法も取り入れると良いことを暗示している。

【3】GitHubに関連する記事で最も興味深いのは、ドイツやアイスランドでは、自国の憲法や法律の条文をGitHub上で自由に修正してフォークしたりPullRequestすることで、実験しながらより良いものを作っていこうという動きがあることだ。

そもそも、憲法のような条文はテキスト媒体なので、Gitのようなバージョン管理と相性が良い。
しかも、YY年にXと言う理由で法律を改正した、という内容は、バージョン管理のリビジョンのコミットログに位置づけられる。
つまり、法律というmasterのコードライン上で、条文の修正がコミット履歴として残ることに対応する。

憲法のように、その国の基本的な条文は国民自らが理解するだけでなく、現状に合うように修正したり、逆に悪い現状を正すために別の法律を修正することが大切になってくる。
その時、GitHub上で憲法や法律をフォークしておき、現状に応じて色んな状況に対応できるように、条文を変えた場合、整合性が取れるか、実現可能であるか、試せばいい。
つまり、各ブランチ上でいろんな法律の解釈を試せばいい。
そして、法律の解釈に相当する各ブランチで、これはいいと思う修正内容は、パッチをPullRequestで送りつければいいのだ。

GitHub上で法律の解釈を各ブランチ上でフォークして修正して実験する手法は、その法律の妥当性を考えさせる訓練になるだけでなく、法律が人を縛る道具ではなく、逆に人を守る道具になるように変えてくれる可能性があると思う。
特に最近は、勝間和代さんが情報主義と呼ぶように、情報を知らない人、知識に無知な人は専門的知識のある人の餌食になりやすい。
特に法律はその傾向があると思う。
だからこそ、法律のような硬いものはGitHub上のソーシャルコーディングによって、更に民主化できる余地があるように思う。

もちろん、GitHubで管理されている法律の条文はテキスト媒体だろうから、SphinxやPandocのようなツールでPDFやepubなど各種媒体で簡単に配布できる。
沢山の人に触れられるようになれば、より真剣に考える機会も増えるだろう。

GitHubによるソーシャルコーディングは、単なるツール上の一手法だけでなく、政治的影響力も秘められていると思う。