0047 号 巻頭言

初稿：2014-06-30

GitHub と自由なソフトウェアをめぐって

Rubyist Magazine 第 47 号をお届けする。

今号は、Rubyで権限管理を行うための gem である Pundit を鈴木雄大さんが紹介する 権限管理のgem、Punditの紹介、 Ruby で NES エミュレータ上で動くゲームを簡単に作成することができる burn をその作者の remore さんが解説する 8-bit風ゲームをつくるフレームワークburnの紹介、 さらに内外の Ruby イベントのレポートとして、 RegionalRubyKaigi レポート (43) 札幌市中央区 Ruby 会議 01、 RegionalRubyKaigi レポート (44) 沖縄 Ruby 会議 01、 RubyConf.PH 2014 参加レポート、 RubyConf 台湾 2014 参加・発表レポート と、やや少なめのボリュームとなった。

RubyKaigi 2014 の開催が近づいている。 現在は CFP が終わり発表者の選考とチケット販売準備を進めているところだが、 予定よりも少し遅れている。お待たせしている方々には大変申し訳ないのだが、 近々に発表者の決定とチケット販売開始を行う予定なので、 RubyKaigi のサイトや Twitter などでのアナウンスをお待ちいただきたい。

ところで、RubyKaigi とは関係ないが、似た名前を持つカンファレンスである 「GitHub Kaigi」が先日開催された（RubyKaigiはKaigiの前にスペースを入れないのが正式名称ですが、 GitHub Kaigiはスペースを入れるらしいです）。 最近は仕事の開発でも趣味の開発でもコードの管理に GitHub を使うことが多い。 Ruby 界隈でも、様々なライブラリや Ruby on Rails などは当然として、 www.ruby-lang.org の管理や mruby の開発でもGitHubをマスターレポジトリにし、 GitHub Issues と Pull Request ベースでコミュニケーションが行われている。

なお、CRuby の開発には GitHub も使われてはいるが、基本的にはミラーであり、 メインは Subversion と Redmine（とそれに連携した ML）上で行われている。 これには様々な理由と経緯があるようだが、 最近は特に GitHub がダメという積極的な理由が残っているわけではなさそうで、 結局は Ruby 開発用にカスタマイズされた Redmine+Subversion から GitHub への移行作業を引き受ける人がいないだけのように見える （もちろん、単純にレポジトリ等を移動させれば済むわけではなく、 これまでの開発ワークフローや便利機能をどう Git+GitHub 上で実現するかを 新たに設計しなおし、足りないところは補う必要がある）。 もし Ruby の開発を GitHub に移行させるために頑張りたいという方がいれば、 ruby-dev ML 辺りで名乗りを上げると良いかもしれない。

ところで、GitHub に移行しない理由の一つとして、 他ならぬ GitHub Kaigi で、他ならぬ松田さんが発表した際のスライドの中で挙げていた一文がある。

「自由なソフトウェアの開発プロセスが特定企業のプロダクトに依存するのはNGなのでは？」

というのがそれだ。

「特定企業のプロダクト」というのは少々気を使った言い方なのかもしれない。 別に特定企業のプロダクトやサービスであっても、それが自由なソフトウェアで あれば特に問題はないからだ。 GitHub についての懸念点は、GitHub が特定企業のサービスであることではない。 GitHub が自由なソフトウェアではなく、 その権利を持つ GitHub 社が利用者の思惑とは無関係にソフトウェアの機能を変更してしまう可能性があり、 そしてその利用者がソフトウェアのソースコードにアクセスできず、 好きなようにサービスをカスタマイズして利用することができない、といったところにある。 要するにロックインのリスクである。

もっとも、GitHub に関しては、それ自体が自由なソフトウェアではなくてもロックインの危険性は比較的少ない。 それはそもそもの Git が分散管理を可能とするための仕組みで、全履歴がサーバのみではなく 各開発者のローカル環境に残ること、そして API による Issue や Pull Request などへのアクセスを 可能としているため、なにかあった場合に別アプリ・別サービスに移行を 比較的容易に行うための仕組みが整っているためである（こういった技術的な観点とは別に GitHub 社への信頼についての議論もあるのだが、それは客観的な評価が難しいこともあり、 ここでは肯定的にも否定的にも触れないでおく）。 もちろん、それでもクローズドなソフトウェアの常として、 将来にわたって仕様が変更されないことを保証してくれるものではないし、 そういった機能を落とすような変更の前にも移行の判断をする猶予期間はあるだろう。

そして話はこれだけでは終わらない。 自由な GitHub の代替ソフトウェアが欲しい、という要望は実際に数知れずあり、 実際にそういったソフトウェアはいくつも開発されている。 GitLab や GitBucket などの GitHub を強く意識したソフトウェアもあるし、 Gitorious もその一つに含めてもいいかもしれない。 しかしながら、それらの自由なソフトウェアが利用される場面となると、 実際には圧倒的にクローズドなソフトウェアの開発で使われることが多いのではないだろうか。 自由なソフトウェアに対して強いこだわりを持つとか、 自由ではないソフトウェアに対してリスクを強く感じる人を除けば、 GitHub を使うことで特に困ることはあまりない。 むしろ GitHub に集約される利便性や、コミュニティをまたがった個人の評価やブランディングの面など、 積極的に GitHub に集約させたくなる動機付けは強力である。 そのため、オープンなソフトウェアを開発するのは GitHub が使われ、 GitHub の代替となるはずの自由なソフトウェアは、 クローズドなソフトウェア開発を支えるために使われてしまう、という構図ができあがる。

もちろん、「いかなる目的に対しても、プログラムを望むままに実行する自由」 ということは自由なソフトウェアの重要な性質である。 その「目的」が「クローズドなソフトウェア開発」であることは何の問題もない。 ある意味、だから自由なソフトウェアは素晴らしいのだ、と胸を張って言うことも可能である。 しかしながら、全く何のひっかかりも感じない、と言ってしまうと嘘になってしまう。

GitHub の持つ「OSS を開発する分には無償で使ってもよいが、クローズドなソフトウェアを 開発する分にはコストを負担せよ」というスタンスは、 言い換えれば「クローズドなソフトウェアを維持するために得た金で OSS 開発を支援する」という、 自由なソフトウェアの開発を支えようとする強い意思のあらわれでもあると言える。 それを成り立たせるために GitHub Enterprise のような有償のサービスがあるという以上、 ビジネスモデルの中に自由なソフトウェアとクローズドなソフトウェアがどちらも 根深く埋め込まれている。そこを切り離すのは難しいだろう。

付け加えて言うと、GitHub 社は自身ではクローズドなソフトウェアしかリリースしないわけではない。 最近では GitHub Atom が OSS として公開されたことは意義深いことだと思う。 「A hackable text editor for the 21st Century」は OSS であるべき、という GitHub 社が下した判断は （ある意味では当然とも言えるかもしれないが）、やはり尊重し応援したい。

今回の話に結論はない。自由なソフトウェアを開発するために GitHub を使うことが良いとか悪いとか単純に言えるわけでもない。 自由なソフトウェアを支えるソフトウェアやサービスのあり方はどうあるべきなのか、 どうすればよいのか、正直なところまだよく分からない。 けれど、当たり前にクラウドサービスとも呼ばれるクローズドなソフトウェアを利用することが当然視されつつある現在、自由なソフトウェアの重要性は逆に増しているように思われる。 今後もっと真剣に考え、判断を下さなければいけない機会も出てくるのではないか、という不安もある。 今のうちから思考を深めておくのも望まない未来を防ぐためには必要なことではないかと思っている。