オープンソース開発の流れ: ソースコード検索エンジン gonzuiの場合

本稿ではオープンソース開発の流れについて、ソースコード検索エ ンジン gonzui を例にとって紹介します。

はじめに

オープンソースのソフトウェアはどのように開発されているのでしょ うか。インターネット上には多種多様のオープンソースプロジェク トが存在しています。その中には Mozilla^*1 や、 OpenOffice.org^*2 などの巨大 なプロジェクトもあれば、1人の開発者がこつこつ行っているよう な小さなプロジェクトも無数にあります。

このように、ひとくちにオープンソースのソフトウェアといっても、 規模の異なるさまざまなプロジェクトがあり、開発形態もプロジェ クトごとに少しづつ異なるものとなっています。このため、オープ ンソース開発の流れとはこういうものである、とひとくくりにまと めて説明することはできません。

そこで、本稿では、筆者が中心となって開発を行っているプロジェ クト「ソースコード検索エンジン gonzui」を例にとって、オープ ンソース開発の実際の流れを紹介したいと思います。オープンソー ス開発の感覚をなんとなくつかんで、自分もやってみようかな、と 興味を持っていただければ幸いです。

ソースコード検索エンジン gonzui とは

開発の話に入る前に、ソースコード検索エンジン gonzui について 簡単に紹介します。

ソースコード検索エンジンは gonzui は、その名の通り、ソースコー ドの検索エンジンです。通常の検索エンジンが文書を対象とするの に対し、ソースコードを対象として特化している点が gonzui の特 徴です。

gonzuiのウェブサイト

ソースコードの検索は、他人のソースコードから API^*3 の使い方を学んだり、 再利用可能なコードを探すといった場面で使えます。インターネッ ト上に存在するオープンソースのソースコードを自由自在に検索で きるシステムを作ることが gonzui プロジェクトの目標です。 gonzui の主な特徴は以下の通りです。

• ソースコードに特有な情報 (関数名、文字列、コメントなど) を活用
• 色付けされたソースコードを表示
• 一般ユーザも管理者も簡単に使える
• マルチバイト文字に対応
• 多くのプログラミング言語に対応 (表1)

gonzui の使用例

それでは、 gonzui の使用例を見てみましょう。まず、gonzui で ソースコードの検索を行うと、次のスクリーンショットのような検 索結果が表示されます。この例では printf をキーワードに検索を 行っています。

gonzuiの検索結果

検索して見つかったソースコードは、gonzui のシステムの中から そのまま閲覧できます。ソースコードはプログラミング言語の文法 に基づいて、予約語や関数呼び出しなどの部分が色づけされて表示 されます。

ソースコードの表示

表示中のソースコードに対して、インクリメンタル検索 ^*4 を行うこと もできます。次のスクリーンショットの例では、printf を含む行 だけを検索して表示しています。この機能は JavaScript によって 実現されています。

インクリメンタル検索

gonzui のデータベースに格納されているソースコードはすべてウェ ブブラウザから簡単に閲覧できます。次のスクリーンショットは、 ディレクトリ内のファイル一覧を表示した例です。このような閲覧 機能を持つため、 gonzui は検索エンジンとしてだけではなく、ソー スコードブラウザとして利用することもできます。

ファイル一覧の表示

以上、gonzui について紹介しました。使い方や仕組みなどの詳し い情報は gonzui のウェブサイト ^*5を参照してください。

表1: gonzui の対応言語

• C
• C++
• Java
• JavaScript
• Ruby
• Python
• PHP
• Perl
• Objective Caml
• Brainfuck
• CSS
• シェルスクリプト
• プレーンテキスト

gonzui の開発の流れ

ここからは、いよいよ gonzui の開発の流れについて紹介していき ます。下の図は gonzui の開発の流れを時間軸で表したものです。

gonzui開発の流れ

プロジェクトの発端

ソースコードの検索エンジンという元々のアイディアは田中哲氏 ^*6 によって提案されました。正直に言って、田中氏か ら「ソースコードの検索エンジンがあったらいいよねー」と話しか けられたときには、一瞬何のことを言っているのかわかりませんで した。しかし、しばし間を置いてからアイディアのよさに気づいて 「それはすごい。作らないと」と話が進みました。

田中氏からアイディアを聞いたちょうどその頃、2004年度の未踏ソ フトウェア創造事業^*7のプロジェクト公の募が始まっていたため、さっそく提案 書を書いて応募しました。その結果、2004年5月下旬に採択が決定し、 いよいよ本格的な開発に着手することになりました。

初期の開発

本格的なコーディングに入る前に、2か月ほどを費やして、調査と 設計を行いました。調査としては、関連するソフトウェアとしてど のようなものが存在するかを調べたり、使用するライブラリのテス トなどを行いました。gonzui では Berkeley DB というライブラリ を用いているのですが、この期間に Berkeley DB を使ったテスト プログラムを書いて使い方や性能を調べました。Berkeley DB につ いては後述します。

設計の点では、どのプログラミング言語とライブラリを使うか、ク ラスやデータベースの構成をどんな感じにするかなどを大ざっぱに 検討しました。設計の詳細は実際にプログラムを書き始めてから、 ああでもないこうでもないといって決めていきました。

2004年の7月末にコーディングを開始し、まず土台となる部分を薄 く作りました。その上で少しづつ機能とユニットテスト^*8を増やしながら開発を進めました。 1か月ほどで、 ウェブインタフェースが動くようになり、それ以降は「とりあえず 使える状態」を保ちつつ、地道に改良を行いました。

gonzui の開発は本体部分を筆者が担当し、プログラミング言語ご とのソースコードを解析する部分は田中哲氏が担当、性能改善を西 田圭介氏^*9が開発を担当しまし た。ソースコードはバージョン管理システム CVS^*10 を用いて共有しました。

バージョン 0.1 の公開

2004年 11月29日に最初のバージョンである 0.1 を公開しました。 「とりあえず使える状態」を保ちながら開発を進めていたため、い つでも公開できる状態ではあったのですが、これなら公開してもい いかと思える出来になるまで、公開を先送りしていました。

バージョン 0.1 の公開時点では、筆者の個人のウェブサイト ^*11 内に最低限のページを作成 して、gonzui のソースコードを gonzui-0.1.tar.gz というアーカ イブ^*12に固めて置いただけで、 メーリングリストの開設は行いませんでした。これは、完成度が低 い段階でメーリングリストを開設すると、要望やバグ報告などのコ ミュニケーションの負荷が増大して、開発の進行が遅れることを危 惧したためです。しかし、これは後から考えてみると、杞憂に過ぎ なかったように思えます。

SourceForge への移行

0.1 の公開後は毎月 29日に公開 ^*13 に公 開することを目標として、12月29日に 0.2 を、1月29日に 0.3を公 開しました。この頃になると、十分に完成度が高まってきたため、 2005年2月6日に公開した 0.4 に合わせて、 SourceForge にウェブ サイトの移行を行いました。

SourceForge^*14 はオープンソースプ ロジェクトのホスティングサービスです。ウェブサイト、メーリン グリスト、CVS といった、オープンソース開発に必要なサービスを 一通り提供しています。

gonzui では SourceForge にウェブサイトを移行するとともに、メー リングリストの開設を行いました。メーリングリストを開設すると すぐに Python のソースコードに対応するためのコードが投稿され るなど、gonzui の開発が活発化しました。

バージョン 1.0 の公開

その後も、 PHP, Perl, JavaScript といった言語への対応がメー リングリストに参加した開発者によって行われ、2005年3月27日に バージョン 1.0 の公開となりました。バージョン 1.0 の公開後も、 Objective Caml^*15 など、より多くの 言語への対応が進んでいます。

本稿の執筆時点では、gonzui の開発者用メーリングリストに 69 人が参加し、gonzui の AUTHORS ファイル (コードを提供した開発 者の名前を記録したファイル) には 11人が含まれています。

まとめ

開発の流れを振り返ってみると、コーディングを開始してからバー ジョン 0.1 を公開するまでに 4か月かかっていることがわかりま す。今から考えると、「これなら公開してもいいかと思える出来に なるまで、公開を先送り」する方針で、やや慎重になりすぎていた ような気がします。

バージョン 1.0 の公開は 0.1 から 4か月後になりました。新しい バージョンを出すたびに 0.1づつバージョンをあげる、という方法 をとっていたため、1.0 という数字は単に 10回目のリリースとい うだけの意味しかないのですが、ブログなどでの反響を見ると、 「ついに 1.0 が出たので試してみよう」というコメントがいくつ か見受けられたのが印象的です。謙虚に 0.01, 0.02, ... とバー ジョンを上げていくのはこの点で少し損かもしれません。

gonzui のソースコードの規模の変遷を表2 にまとめます。行数で ソフトウェアの規模を測ることの賛否はありますが、同じプロジェ クトがどのように成長しているかを測る目安としてはそれなりに使 えるのではないかと思います。

表2: gonzui のソースコードの規模の変遷

公開日     | バージョン | コードの行数
-----------+------------+-------------
2004-11-29 |    0.1     |     6,321
2004-12-29 |    0.2     |     8,052
2005-01-29 |    0.3     |     9,867
2005-02-06 |    0.4     |    11,461
2005-02-15 |    0.5     |    12,992
2005-02-23 |    0.6     |    12,642
2005-03-04 |    0.7     |    13,207
2005-03-17 |    0.8     |    13,517
2005-03-22 |    0.9     |    13,609
2005-03-29 |    1.0     |    13,678

※編集部様: この部分はグラフも作っていただけると助かります

さまざまな取捨選択

ソフトウェアを開発する上では、使用するプログラミング言語の決 定など、さまざまな取捨選択を行う必要があります。ここでは、 gonzui を例に取りながら、オープンソース開発における取捨選択 のポイントについて紹介します。

開発テーマ

開発テーマの決定は、もっとも基本的な決定事項です。何を作るか を決めなければ、実際のところ何もはじまりません。オープンソー スの開発では、楽しむことが大きな動機のひとつですから、自分が 楽しいと思えるテーマを選ぶことが大切です (コラム参照)。作っ ていて楽しくて、技術も磨けて、しかも人の役に立つ、というテー マが理想的でしょう。

前述の通り、gonzui の場合は田中哲氏のアイディアに基づいてテー マを決めたため、何を作ろうか悩むということはありませんでした。 何か始めてみたいけど何を作ったらいいかわからない、という場合 は、ひとつの発想法として、日頃自分が面倒くさいと感じている作 業を自動化するようなツールを考えてみるといいかもしれません。 日頃使っているソフトウェアに自分の欲しい機能を追加することを 検討してみるのもいいと思います。

プログラミング言語

どのプログラミング言語を使うかは、プロジェクトの方向性を決め る上で重要な選択です。プログラミング言語を選択する上では、次 のような点が検討要素になります。

• 性能 - プログラムは速く動くか、メモリは食い過ぎないか、な ど
• 生産性 - コードを書きやすいか、ライブラリは充実している か、コードの保守はしやすいか、など
• 開発者の習熟度・好み - どのくらいその言語の経験があるか、 どのくらい好きか、など
• 言語の成熟度・将来性 - どのくらい枯れているか、将来に渡っ て安心して使えるか、など

gonzui では、上記の点について検討した結果、オブジェクト指向 スクリプト言語 Ruby^*16 を採用 することに決めました。性能という点では Ruby はベストの言語で はありませんが、生産性など、その他の点については非常に優れた 言語です。特に、プログラムを書くのが楽しいという点で、多くの プログラマに支持されています。

gonzui のようなウェブベースのアプリケーションの開発には Perl, PHP, Python, Ruby といったスクリプト言語が広く用いられ ています。一方、膨大な数値計算などの高速な処理が必要とされる ソフトウェアの開発には、 C や C++ を選ぶ方がよいでしょう。プ ロジェクトにあった言語を選ぶことが大切です。

ライブラリ・ミドルウェア

プログラミング言語と同様に、どのライブラリ (あるいはミドルウェ ア) を使うかも重要な選択です。ライブラリを選択する上では、自 分のプロジェクトに必要な機能が提供されているか、という点をま ず検討する必要があります。どんなに速くても、必要とする機能が 欠けていたら (それを補わない限りは) 使えません。

gonzui では、使用するデータベースに必要な機能を検討した結果、

• 前方一致検索を行えること ^*17
• ライブラリとして組み込めること

という条件を満たす Berkeley DB ^*18 を採用しました。

Berkeley DB は B木というデータ構造を扱えるという特徴がありま す。B木は、ハッシュと同様にキーと値をペアにしたデータ構造で すが、ハッシュと違って、ソートされた順にキーにアクセスできる ところがポイントです。この性質を用いると、キーワードの前方一 致検索 を行うことができます。また、ライブラリとして組み込め るという点も特徴です。MySQL などのサーバ型のデータベースは別 プロセスを必要とするため、採用を見送りました。gonzui では設 計方針として、できるだけ簡単に使えることを重視しており、単独 のプロセスで動く構成にまとめたかったためです。

Berkeley DB の他にも、gonzui では Ruby 用のライブラリを多数 利用しています。中でもWEBrick^*19 というライブラリを採用したのは大きな選択です。WEBrick を用い ると、 Apache などのウェブサーバを使わずに、単独でウェブサー バとして動作するアプリケーションを実現することができます。 WEBrick の採用も、単独のプロセスで動く構成にしたかったという ことが主な理由です。

ライセンス

オープンソースと名乗るには、オープンソースイニシアティブ (OSI) による定義 ^*20を満た すライセンスで公開する必要があります。ソースさえ公開されてい ればオープンソースと呼んでもいいのではないか、という意見もあ りますが、不要な混乱を防ぐためにも、「オープンソース = OSI の定義」と捉えた方がいいでしょう。OSI の定義を簡単にまとめる と次のようになります。ぜひ原典に当たってみてください。

• 再配布を自由に行えること
• ソースコードを自由に入手できること
• 派生ソフトウェアの開発を許すこと
• 個人やグループ、分野、製品などによる差別をしないこと

OSI が承認したライセンスの一覧はネット上で閲覧できます ^*21。特に大きな理由が ない限り、 GPL や BSD ライセンスといった有名なものを好みで選 ぶといいでしょう。マイナーなライセンスを選ぶと、ユーザや開発 者に敬遠されるおそれがあります。gonzui では GPL を採用してい ます。

ビルド・パッケージング・テスト

ソフトウェアをどのようにビルド ^*22 し、パッケージング、テス トするかは、なかなか頭の痛い問題です。小さなプロジェクトであ れば、簡単な Makefile を書けば済みますが、ソフトウェアの規模 が大きくなってくると、素のMakefile を保守するのは難しくなり ます。

gonzui の場合は、Ruby で書かれた部分についてはビルドは不要で すが、C言語の部分についてはビルドが必要な構成となっています。 パッケージングは、ソフトウェアのビルドと動作に必要なすべてソー スコードと関連ファイルをひとまとめにして gonzui-1.2.tar.gz といったアーカイブにまとめる処理です。

gonzui では autoconf^*23 と automake^*24 という ツールを用いて、ビルドおよびパッケージング、テストの処理を行っ ています。autoconf/automake を用いると、 Unix 関連のソフトウェ アで一般的な

% ./configure && make 

によるビルドが実現できます。アーカイブの作成は次のコマンド一 発でできます。

% make dist

automake はテストを自動化する機能も提供しており、コマンドラ インから make check と実行すると、登録しておいたテストがひと つづつ実行されます。問題なく通ったテストには PASS と表示され、 FAIL と表示されます。以下に make check の実行例を示します。

% make check
PASS: apt.rb
PASS: bdbdbm.rb
PASS: cmdapp-app.rb
PASS: cmdapp-search.rb
PASS: command.sh
PASS: config.rb
PASS: content.rb
PASS: dbm.rb
PASS: deindexer.rb
PASS: delta.rb
PASS: easyscanner.rb
PASS: extractor.rb
PASS: fetcher.rb
PASS: gettext.rb
PASS: importer.rb
PASS: indexer.rb
PASS: info.rb
PASS: monitor.rb
PASS: langscan.rb
PASS: license.rb
PASS: logger.rb
PASS: searcher.rb
PASS: searchquery.rb
PASS: searchresult.rb
PASS: texttokenizer.rb
PASS: updater.rb
PASS: util.rb
PASS: vcs.rb
PASS: webapp-markup.rb
PASS: webapp-xmlformatter.rb
===================
All 30 tests passed
===================

テストを自動化することにより、バグの発見を容易にできます。あ る部分のコードを修正して、その直後に make check ですべてのテ ストが通らなかった場合は、修正した部分のコードがバグを含んで いることがすぐにわかります。テストを十分に用意して make check をまめに実行する習慣をつけることは、開発の生産性を上げ るひとつの秘訣です。

autoconf/automake については『GNU Autoconf/Automake/Libtool』 ^*25 という書籍が参考になります。また、検索エ ンジンで autoconf, automake を検索すると、ネット上のたくさん の情報が見つかるはずです。ソフトウェア開発におけるテストの重 要性については『達人プログラマ』^*26が参考になります。

開発環境

プログラムのコードを実際に書く方法には、汎用のテキストエディ タを用いてソースコードを記述するものと、 Eclipse^*27 に代表されるような統 合開発環境を用いるものがあります。

筆者の場合は前者の方法を取り、Debian GNU/Linux ^*28 上の Emacs^*29 で開発を行っ ています。普段は主に Windows のノート PC で作業しているため、 開発用 Linux サーバには PuTTY ^*30 でログインして Emacs を使っています。Emacs は PuTTY の上で 問題なく使えます。

putty 上の Emacs

公開方法

ソフトウェアを公開する際には、ウェブサイトを作るのが一般的で す。ウェブサイトの主な内容は次のようなものになります。

• ソフトウェアの紹介 - ページの一番最初に簡単な説明文がある と親切です。
• ダウンロードページ - ソースコードやバイナリパッケージ ^*31 をダウン ロードするためのページです。目立つところにあるといいでしょ う。CVS などのバージョン管理システムへのアクセス方法も同じ ページに載っていることがよくあります。
• マニュアル - インストールの方法や、使い方の詳細を載せます。
• チュートリアル - 典型的な使い方を例を中心に紹介した入門文書です。
• スクリーンショット・動画 - GUI のソフトウェアであれば、 スクリーンショットを載せましょう。サイトを訪れた人に「試し てみようかな」と思わせるのに効果的です。
• メーリングリストの案内 - メーリングリストがある場合は、 参加方法やアーカイブのページなどの情報を載せましょう。

ある程度、本格的なプロジェクトになると、ウェブサイトだけでな く、メーリングリストを用いた情報交換や、バージョン管理システ ムを使っての共同開発環境が必要になります。このような場合は、 SourceForge のホスティングサービスを利用するのが便利です。ブ ラウザから必要な情報を入力して、 SourceForge からの承認が得 られればプロジェクトの登録は完了です。

SourceForge には英語のサイト http://sourceforge.net/ と日本 語のサイトhttp://sourceforge.jp/ があります。世界に向けての プロジェクトであれば、sourceforge.net 、国内向けのプロジェク トであれば sourceforge.jp と使い分けるといいでしょう。

ただし、gonzui では sourceforge.net にウェブサイトと CVS を 置き、sourceforge.jp にメーリングリストを置くという変則的な 構成を取っています。これは、sourceforge.net のメーリングリス トを利用すると、日本語のアーカイブが文字化けするという問題が あるからです。

一方、小さなプログラムであれば、わざわざ専用のウェブサイトを 作らずに、ブログ上で手早く公開するという方法もあります。筆者 もたまに JavaScript などの小さなプログラムを自分のブログ ^*32 で公開しています。こ の方法の方が手間がかからないので、最初の取り掛かりとしてお勧 めです。

まとめ

以上、オープンソース開発におけるさまざまな取捨選択のポイント について紹介しました。開発テーマにはじまり、いろいろなことを 決めなければならず、なんだか大変そうに思えるかもしれません。

筆者のお勧めは、何から何まで自分で考えて決めるのではなく、既 存のプロジェクトを参考にして、真似できる部分はどんどん真似し てく、というやり方です。自分の興味のあるプロジェクトのソース コードを入手して、どんな言語やライブラリを使っているか、どん な風にパッケージングされているか、などを調べると非常に参考に なります。

gonzui では手軽に使えることを重視して、Berkeley DB や WEBrick といったライブラリを採用しましたが、手軽さが実現され た分、性能とスケーラビリティが犠牲になっているという面もあり ます。このようなトレードオフはソフトウェアを開発する上で常に つきまう悩みです。さまざまなトレードオフの中で、どこに重点を 置いてバランスを取るか、そういったところに開発者の個性が出る のではないかと思います。

おわりに

本稿ではオープンソース開発について、ソースコード検索エンジン gonzui を例にとりながら紹介しました。gonzui の例が読者のみな さんにとってどのくらい参考になるか少々自信がありませんが、オー プンソース開発の一例として、なんとなく感覚をつかんでいただけ れば幸いです。

オープンソース開発には、本稿で紹介した他にもいろいろな関わり 方があります。メーリングリストに参加して情報交換したり、ソフ トウェアの使い方のコツをブログで紹介したり、といった活動はそ の一例です。オープンソース開発には誰でも参加できます。ぜひ気 軽に参加して楽しんでください。本稿がそのきっかけになれば望外 の喜びです。

コラム: オープンソース開発の動機

オープンソース開発はなぜ人を惹きつけるのでしょうか。人によっ てさまざまな動機があると思いますが、オープンソース開発に参加 する動機としては次のようなものがあると思います。

1. 作りたい・おもしろいから
2. 社会に認められたい・役に立ちたい
3. 腕を試したい・腕を磨きたい
4. 既存のソフトウェアに機能が欠けていたので
5. オープンソースコミュニティに貢献したい
6. 仕事でオープンソース開発を行っている

この中で、筆者にとって一番大きな動機は1番の「作りたい・おも しろいから」というものですが、2番や3番の動機もあります。社会 に認められるというとちょっと大げさですが、オープンソースの活 動を通じて、他の開発者とのネットワークができたことは筆者にとっ て非常に大きな収穫となっています。

ところで、これらの動機は特にオープンソース開発に限らず、ブロ グやウェブサイトを運営することにもおおむね当てはまりそうです。 自分が楽しめることをいろいろな形でアウトプットできるところが インターネットのおもしろさではないでしょうか。