オープンソースソフトウェア開発ことはじめ

はじめに

  • v1: 2016/2/1: この記事は カーネル/VMアドベントカレンダー2011 のために書いたものを2016/2/1に編集したものです。
  • v2: 2019/8/31: プロジェクトからフェードアウトした現状を追記しました。それにあわせて内容を一部修正しました

本記事の目的は、筆者が初めて実際にオープンソースソフトウェア(以下OSS)活動に参加した体験をもとに、OSS開発に参加する魅力、およびその具体的な手順について説明することです。これをきっかけに多少なりともOSS開発者の裾野が広がって未来ある若者を同じ道に引きずり込…もとい同じ趣味の人が増えればよいなと思っています。

主たる対象読者はソフトウェア開発に興味があり、かつ、次のような理由で現在はOSS開発の参加者ではないかたがたです。

  • OSS開発に参加する利点がわからない
  • OSS開発に参加してみたいが、まず何をすればいいのかわからない。あるいは以前挑戦したが挫折した

見ての通り、すでにバリバリ活動しているようなかたは対象外で、そのような方々にとっては当たり前のことばかり書いてあるかもしれませんが、その点ご了承ください。

本記事の流れは次のようになっています。

  • まず、まだ興味が無いかたがたに興味を持ってもらうために、OSS開発を通して筆者が何を得たのかについて簡単に記述する
  • 続いて 興味があるが参加はしていないかたがたに向けて、OSS開発に参加するきっかけから継続的な活動までの流れを具体例を使って記述する。

本記事の題材に選んだのは、既存かつ小規模なOSS開発プロジェクトへの参加体験です。なぜこれを選んだかというと、それは次のような利点によります。

  • 既存プロジェクトの利点: 新規に何かを立ち上げるより、既存のものを改善するほうが手間が少ないです。また、せっかく新規に立ち上げてもユーザが一人もつかないと得られる利点が半減するし、モチベーションも保ちにくいです
  • 小規模プロジェクトの利点: OSS活動をしようとして、いきなりlinuxなどの大規模プロジェクトに参加して挫折し、そのままあきらめる人が多々います。未経験の状態から誰の助けもなく大規模プロジェクトに参加するのはやや敷居が高いです

では本題に移ります。

OSS活動の利点

私がOSS開発活動を通じて得たのは次のようなものです。

  • 自分が使うソフトウェアを改善することにより、自分が楽になった: 職業プログラマは意外にもこの経験が乏しかったりします。なぜなら、業務で作るソフトウェアは主に顧客向けのものだからです。
  • 改善したソフトウェアを公開することにより、ほかの人も楽になった: 上記と同じく、職業プログラマであってもこの経験が乏しい場合があります。なぜなら、とくに大規模な組織の場合は開発者と顧客が直接やりとりすることは少なく、ユーザの反応が間接的にしかわからないことが多々あるからです。OSS開発の場合、「ありがとう」や「どうにかしろ」の声が幸か不幸か直接あなたのもとに届きます
  • 実用的なソフトウェア開発を通じて技術的に成長できた
  • 管理、保守作業を経験できた: この経験は、とくに就業経験の無い学生さんなどによいと思います。学生のうちに開発するソフトウェアはユーザ=開発者=自分であることがほとんどです。保守性の良いソフトウェアを作るという観点を早めに身につけられるのはよいことです。
  • 他人(ユーザや共同開発者)の視点からの意見を得られた: 上記と同じく、とくに学生さんにおすすめ。多様な意見を聞き、議論して、広い視野を身につけると人間は大きく成長できます。
  • 英語を実践を通して学習できた: 外国語を、自分が好きなことをしながら学べるのは大きな利点です。楽しいほうが、そして必要に迫られる方が覚えは早いのです。メールベースなのでそれほど急ぐ必要もありませんん。

このうちどれが利益と感じるかは人それぞれでしょうが、どれかひとつでも魅力的だと思ってもらえたかたは、引き続き記事を読み進めてもらいたいと思います。なぜ、どうやって上記のものが得られたのかについては追って説明します。

参加したプロジェクト

私が開発に参加したOSSはquilt-elといいます。ソースコードバージョン管理システム(以下VCS)のひとつにquiltというものがあり、quilt-elはそれをemacsというテキストエディタから楽に使うためのスクリプトです。

VCSと言えばgitやCVS, Subversionなどが有名ですが、quiltはそれらに比べると極めて原始的な機能しか提供していません。しかし、それゆえに使い方を学ぶのが極めて楽だという利点があります。

quiltがどこに使われているかというと、私の知っている範囲では、linux kernel 開発の No.2 であるAndrew Morton 氏が開発ツリーの管理に使っていたり(彼はquiltの開発者でもあります)、debianの一部パッケージの管理に使われたりています。

これ以降、私がquilt-elのユーザになってから、その開発者となり、メンテナになるまで、そしてその後の展開についての流れを紹介してゆきます。

quiltやquilt-elの詳細については本筋から外れるため、説明を割愛します。興味のあるかたはそれぞれのソフトウェアのマニュアルをごらんください。

quiltユーザからquilt-elユーザへ

私はソフトウェアの開発が趣味(であり仕事)です。そして、ソフトウェアを開発するにはVCSの利用は必須です。私は面倒なことが嫌いなので、使いかたがもっとも簡単なVCSをもとめてさまよった結果、quiltにたどり着き、常用することになりました。

ところが、使っているうちにひとつの問題に突き当たりました。私はemacsを愛しており、とくに開発作業ではemacs環境の外には絶対に出たくいないのですが、emacs上でquiltをそのまま使うのはやや面倒くさく、作業ミスも多々発生していたのです。

そこで、「自分が困るならほかの誰かも困っているだろう」と思ってemacsからquiltを便利に使えるツールがあるかどうか調査をしました。すると Matt Mackall というかたが私の望みどおりの quilt-elというソフトウェアを公開していることがわかりました。そこから私はquilt-elの愛用者になりました。

TIPS:
何かのソフトウェアが欲しいと思ったら、
まずはwebを検索して目的のものを探してみましょう。
そこで目的のものか、それに似たようなものが見つかることはけっこうあります。
何も全部一からやる必要はありません(一から開発すること自体が目的なら話は別です)。

開発者になる

quilt-el はわたしの開発作業を大いに楽にしてくれました。ですが、実装がバグだらけでしょっちゅう動かなくなるという大きな問題がありました。さすがにストレスがたまるのでどうにか直せないかとソースをざっとながめると(これが簡単にできるのもOSSの利点です)、このスクリプトの規模は小さく、かつ、開発言語の emacs lisp にはなじみがあったので簡単に修正ができました。

そして以前より何らかのOSS活動に参加してみたかったこともあり、自分用に直すだけでなく、試しに筆者にバグ修正パッチを投げてみました。私のOSS開発参加のきっかけはこのような簡単なものです。

運良くメンテナの Matt からはすぐ返事が帰ってきて、バグ修正がただちに取り込まれました。これによって、私だけでなく他のユーザも以後当該バグに二度と悩まされなくなりましたわけです。ほんの少しフィードバックすることによって成果が何倍にもなりました。

理屈としてはわかっていましたが、この感覚がこの時には言いようの無い喜びがあったことを覚えています。これはその後の大きな活動の原動力になり、その後いくつものバグ修正パッチを投稿し、次々と受け入れられてゆきました。

TIPS:
OSSの中には、開発コミュニティが過疎化しており、
パッチを送っても反応が全く無いことがしばしばあります。
そのようなプロジェクトところは無駄に疲れるだけなので、避けるか、
あるいは既存のコードをもとにしてプロジェクトを分岐するのが賢明でしょう(分岐については後述の記述も参照)。
過疎化しているプロジェクトは、
バージョンアップがなかなか無い、
あるいは開発MLがSPAMメールだらけなどの特徴があります。

ディストリビューションのパッケージ化

自分が関わったソフトウェアには愛着が出てきます。また、バグが無くなって、機能も充実してくると、もっと多くの人に使ってもらいたくなってきます。そこで考えたのがquilt-elのディストリビューションパッケージ化です。

linuxを使っている人の多くはOSSをそのまま使うことはなく、各ディストリビューション用にパッケージ化されたものを使います。裏を返せばパッケージ化されていないOSSは見向きもされないことが多いということです。実際quilt-elはパッケージ化されていなかったので当時はユーザがそれほどいませんでした。。

私はdebian使いなので、debianパッケージを作ることにしました。そして、ドキュメントを読み漁り、パッケージを作ろうとしている人がほかにいないことを確認すると、すぐに行動に移りました。

幸いパッケージ化を助けてくれるかたにも恵まれ、そのかたの助言に従って事はスムーズに進み、quilt-elは無事debianの公式パッケージ化されました。自分の作ったものが自分がずっと使ってきたOSのパッケージ一覧に入ったというのはとてもうれしいことでした。

パッケージ管理者になるとすぐに、debianのバグ報告システムを介してユーザから不定期にバグ報告が来るようになりました。この際は、ユーザ対応、本家ソフトウェア(quilt-el)への修正パッチ投稿、そして本家の修正版が出るとパッケージを作り直して公式debianパッケージをアップデートをするという作業が毎回必要です。作業量は大したことはないのですが、めんどくさくてやりたくないこともよくありました。

なので、テストの自動化など、いかに楽してそれら作業を実施できるかに全力を尽くしたことを記憶しています。その結果、保守のしやすいソフトウェアを作ろうという意識が強くなりました。これも実際に体験してみないとなかなか身につきません。

TIPS:
それなりに大規模なプロジェクトでは開発スタイルがきちんと決まっています。
debianのように明文化されているものもあれば、MLをしばらく眺めて感覚をつかむ必要があるものもあります。
まずは参加する前にマニュアルなりMLなりに目を通しましょう。
でないと礼儀を知らない変な奴が来たと無視されるのがオチです。

そしてメンテナへ

しばらくはパッチをメンテナに投稿するとすぐに取り込まれるという好ましい循環ができていましたが、次第にメンテナの反応が鈍くなってきました。おかげでdebianパッケージで修正されているバグが本家に残っていたり、機能拡張をしたくてもできないといった状況がしばらく続きました。そこで、メンテナはquilt-elを管理する時間と情熱が無くなってきているのではないかと推測しました。

なぜかというと、メンテナの Matt 氏は git と双璧を成すVCSであるmercurialのメイン開発者であり、当時は分散VCSの二大巨塔として(今でも?)gitとが機能拡張にしのぎを削っていた時期だったからです。

その中で同種のソフトウェアであるquiltの、しかもその補助スクリプトの開発に興味がなくなるというのはいたしかたないことです。興味は時とともに移りゆくものなのです。

quilt-elの更新が止まるのは困る、メンテナはやる気が無くなっている、自分は中身を知っている、自分にはこのソフトウェアを開発する情熱がある…そうなると答えは一つです。私はMatt氏に上記の事情を説明して、 できればわたしをメンテナにしてもらえないかと連絡しました。

Matt氏はたしかにそうだと快諾してくれて、晴れて私はquilt-elのメンテナになりました。その後は本家ソフトウェアとdebianパッケージとの同期がしっかりとれるようになり、また、開発速度も向上したため、この決断により事態をよい方向に進められました。

メンテナになってからは開発者のひとりにすぎなかったころに比べてまた少し考え方が変わりました。それまで自分は提案するだけでよかったのですが、メンテナはプロジェクトの舵取り役です。次の事柄ががすべて自分の立ち振る舞い次第で決まります。

  • バグ修正を速やかにする、あるいは修正が滞る
  • 良い機能を追加してユーザが喜ぶ、あるいは変な機能を入れたり非互換を出してユーザが困る
  • 上記によりユーザ数、およびその満足度が増減する。
TIPS:
quilt-elはOSSなので、更新がなくなったらプロジェクトを分岐させてそれを自分で管理するという方法もありました。
ただ、メンテナの真意がわからない時点でそれをするのは得策ではありません。
たまたま今時間が無いのかもしれません。
開発リソースを有効に使うためにも、ユーザを混乱させないためにも、
よほどの理由が無い限り二重管理は避けるほうがよいです。
また、メンテナがやる気満々なのに「俺をメンテナにしろ」とか言うと煙たがられるだけなのでやめましょう。
ソフトウェアは人間ではありませんが、ソフトウェア開発は人間相手の作業です。
相手の立場になって考えるのを忘れないようにしましょう。
これはパッチを投げるときも同じです

上位ソフトウェアへのマージ

quilt-elに欲しい機能をほとんど取り込んでバグも無くなってきたころ、ふと思い立って親プロジェクトであるquiltにリリースアナウンスを出してみました。quiltの開発者だから興味がある人もいるだろうとかいう軽いノリだったと記憶しています。すると、メンテナの一人からただちに次のような返信がありました。

「それはいい、便利そうだね。ところでこれは小さいスクリプトだし、君がquilt開発者になって、
quilt本体と一緒にこれを管理したほうがいいと思うんだけど、どうだい。
quiltの開発コミュニティにはquiltのdebianパッケージのメンテナもいるし、
ちょうどいいんじゃないの」

確かにquiltとquilt-elを一緒に管理すると、quiltをダウンロードした人は余計な手間をかけずにquilt-elを使えますし、debianパッケージを作るのも楽になります。渡りに船とばかりに快諾し、ついに予期せずquiltのメンテナになりました。

フェードアウト

前節までで終わればなかなか格好よかったのですが、この話には続きがあります。この後わたしは次第にquiltを使わなくなり、ソースコードはすべてgitで管理するようになりました。このためquilt、およびquilt-elを使う動機が無くなりました。現在ではquiltのメンテナとしての活動は数年間なにもしておらず、幽霊部員のようになっていたので2019/8/31に開発MLにメンテナから外してほしいというメールを投げました。それに加えてquilt-elのdebianパッケージのメンテナも他の人がやっています。メンテナ(quiltについてはメンテナのうちの一人)がいなくなったとしても、メンテナをやってもいいと思うほどにこれらが大事だと思っている人がいる限りOSSは継続するというわけです。

おわりに

自分が楽するためにたった数行のelispを書いたところから始まり、ついには親プロジェクトのメンテナにまでなりました。わらしべ長者みたいな話ですが、小さなことの積み重ねで次第に大きなことができるようになってゆくというという非常に貴重な体験ができました。その後フェードアウトしたことについても、自分で使っていないソフトに責任を持ち続けて疲弊したり何もしないまま放置したりするよりは、自分にとってもユーザにとってもはるかに良かったと思います。

ここまで読んでくれたみなさんに上記の体験談が何らかのお役に立てれば幸いです。OSSコミュニティへの参加は大変ではありますが楽しいものですよ。興味があればぜひ参加してみてください。

それでは、Happy Hacking!