普及が進むオープンソース

先日、OSC 2007 Tokyo/Fallでセミナーをさせていただきました。内容はOpenBSDの紹介だったのですが、参加者からライセンスについてのご質問がありました。具体的にはオープンソース（Free Software/Open Source Software、以下オープンソース）を採用するにあたって、BSDやGPLなどいろいろあるが何を基準に選択すればいいだろうか、というものでした。（⁠ただで使える）フリーウェアとオープンソースの区別が明確でなかった頃と比較して、企業での扱われ方に隔世の感があります。また、企業の成果物をOSI （⁠Open Source Initiative、オープンソースの普及を目的とした非営利組織が認定したライセンスで、オープンソースとして公開するケースも増えているようです。

オープンソースとシステム管理者

いわゆるシステム管理者であれば、なんらかのオープンソースにお世話になっていることでしょう。DNSやWWWといったインターネットサービスはもちろんのこと、バックエンドであるデータベースや社内向けのサービスでもオープンソースは珍しくない時代です。不具合や不足している機能があっても、スキルを研けばパッチを書くことだって可能です。また、常にコスト削減を求められる立場からも、オープンソースは強力な味方です。とはいえ、オープンソースであれば優れたソフトウェアなのかというと、そうではありませんし、メンテナンスのコストもゼロではありません。ここでは、自分なりのオープンソースの選び方を紹介したいと思います。

まずはライセンス

なによりもまず最初に確認するはライセンスです。「⁠オープンソース」といっても何をもって「オープンソース」とするのかについては、さまざまな解釈があるようです。ここでは「OSSが認めたライセンスを採用したソフトウェア」をオープンソースとしましょう。「⁠オープンソース」と銘打っていても、実はソースコードが公開されているだけで、その使用については条件が付いていることもあります。また、明確なライセンスが明示されていない場合もあります。この様な場合は、その条件などをよく吟味する必要がありますし、ライセンスが不明なソフトウェアは避けた方がよいでしょう。独自のライセンスの場合は、その内容を吟味する必要があります。独自ライセンスの内容について判断するのは一管理者には荷が重いので、微妙なケースでは法務部門などと相談するべきです。自分は、あとから無用なトラブルに巻き込まれるのが嫌なので、独自のライセンスは避けるようにしています。

オープンソースのライセンスで有名なのはGPLとBSDライセンスでしょう。他にもApache LicenseやMozilla Public Licenseなどがありますが、ここではGPL version 2（以下、GPL）と修正BSDライセンス（以下、BSDライセンス）についておおまかに説明します。専門家ではありませんので、厳密な解釈ではなく、オープンソースを利用するにあたって必要な部分にとどめます（OSS iPedia Q: GNU GPLとBSDライセンスの違いはなんですか?、GNUプロジェクトさまざまなライセンスとそれらについての解説⁠）⁠。

GPLを端的に説明すれば、利用者による改変の共有を保証するライセンスといえばよいでしょうか。つまり、改変した個所を共有させるのが目的のライセンスです。GPLを採用したソフトウェアにはLinux kernelがあります。商用のサービスや製品として利用するケースでは、ソースコードの開示義務などがありますから、充分に検討する必要があります。

BSDライセンスは、「⁠著作権表示さえ残してくれれば、何をしてもいいですよ」というライセンスです。改変しようが、製品として販売しようが、制限はありません。BSDライセンスを採用しているソフトウェアには、その名の通りFreeBSDやOpenBSDなどがあります。

さて、システム管理者としてどちらを選べばよいのでしょうか。自分の答えは、「⁠どちらでもあまり変わらない」です。組織内部で閉じている限りにおいて、両ライセンスが問題になるケースはあまり多くないでしょう。しいていえば、開発元にフィードバックした修正内容の行方が気になるかどうか、でしょう。GPLを採用したプロジェクトでは、取り込まれたパッチもGPLになるのと同様に、BSDライセンスの場合は、そのパッチもBSDライセンスになるでしょう。つまりBSDライセンスの場合は、フィードバックしたパッチがどうなろうと（著作権表示がある限り）文句は言えないということになります。これはソフトウェアに限らず、ソフトウェアに付随するファイル（IDSやvirus scannerのsignature）にも当てはまります。これについては、それぞれのポリシーに依存しますので、自分もしくは組織の著作物についての考え方と相談するとよいでしょう。

ソースコードの開示

ソースコードが公開されているといっても、いろいろなケースが考えられます。CVSやSubversionリポジトリが公開されている、リリースごとのソースコードがダウンロードできる、ソースコードのダウンロードに個人情報を要求する、ソースコードの取得には特殊な手段が要求されるなど、ライセンスに関わらずいろいろなケースがあります。後述するパッケージ管理システムとの親和性という観点からも、HTTPやFTPによって容易にダウンロードできるほうが好ましいでしょう。

もっとも望ましいのは、ソースコードリポジトリが公開されている場合です。ソフトウェアの品質を見極めるのに、それぞれのcommit logが公開されていることは重要ですし、どのような目的のためにどのような修正がなされたのか検証できるのも重要です。利用する前にそのソフトウェアを評価するのに、リポジトリが公開されていることはとても役立ちます。リリースごとにしかソースコードを公開しないプロジェクトの場合、前のリリースからどのような修正がどのように行われたのかを検証するのが困難です。

サポートのメーリングリストや掲示板があるか

オープンソースでは、サポートが利用者からなるコミュニティによって行われることが多いです。もちろん、開発元が直接サポートすることもありますが、メーリングリストや掲示板によって、ユーザ同士のコミュニケーションが計れるようになっている方が、サポートを受けられる機会も増えるでしょう。また、どのような問題が報告され、どのように解決がされているのか、開発者がどのようなポリシーで開発しているのかを知ることもできます。現時点で足りない機能があったとしても、それを開発者が問題として認識しているかどうか、どのように解決するつもりなのか、こうしたユーザとのコミュニケーションから学べることはたくさんあります。

BTSがあるか

BTSとはBug Tracking Systemの略で、不具合や機能追加の要望を報告できる場所です。有名なものには、BugzillaやTracがあります。ユーザのbug報告や機能要望をきちんと管理するには不可欠なシステムです。ただし、ユーザの規模によってはメーリングリストや掲示板などで代用されることもありますので、必ずしも必須というわけではあません。ですが、ある程度の規模のプロジェクトでは必須といってもいいですし、ユーザの声を適切に管理するにはやはり必要なシステムです。また、BTSの利用状況も確認します。具体的には、ユーザからどのような不具合が報告され、どのように対応されているかなどです。つまらない不具合がたくさん報告されていないか、深刻な不具合が長期間に渡って放置されていないかなどを確認します。

ドキュメントがあるか

どんなすばらしいソフトウェアも、どう使うのかわからなければ使えません。インストールのための文書があるか、設定するための文書があるか、manはあるのか、それぞれ確認します。経験上、長く愛用される優れたソフトウェアは文書が充実しています。自分はソフトウェアの品質と文書の充実度は比例すると考えています。最低でも、INSTALL、READMEとmanが配布物に含まれているかを確認します。

加えて、開発者向けの文書が用意されているかという点にも注目します。開発者向けの文書とは、ソフトウェアのアーキテクチャの解説、コーディング規約、プラグインなどの仕組みを記述した文書を指します。こうした文書が整備されていると、第三者が開発に貢献しやすくなり、開発が活発に行われることが期待できます。

開発は活発か

ものにもよりますが一般的に、開発が活発なプロジェクトのほうが不具合の修正も迅速ですし、新機能の追加も見込めます。必要十分な機能がある枯れたソフトウェアの場合は、開発が停止していても問題は少ないですが、多くのプロジェクトは未完成であり改善の余地は常にあるものです。リリース間隔が長すぎないか、定期的にリリースできているかなどを確認します。アーキテクチャの大幅な改善を伴う修正に取り組んでいることもありますから、ソースコードリポジトリのログを確認するなどして、なぜリリースに時間がかかっているのか見極めることもあります。

パッケージ管理システムに取り込まれているか

パッケージ管理システムとは、distributionに付属し、サードパーティによるソフトウェアをインストールしたり、アンインストールするための仕組みです。FreeBSDやOpenBSDではports、Linux distributionではrpm、yum、apt-get、GentooではPortageなどがあります。ソフトウェアのインストールや設定するためのコストは無視できませんし、アップデートの有無を確認する手間もあります。このコストをパッケージ管理システムは肩代わりしてくれます。パッケージ管理システムに含まれていることは、ある程度の利用者が存在することが期待できますし、distribution固有の問題もメンテナーによって解決されていることも期待できます。パッケージ管理システムに取り込まれたパッケージは、そのdistributionのセキュリティアドバイザリの対象になるのが一般的です。つまり、そのパッケージに脆弱性があった場合、distributionからアナウンスと修正が行われます。これにより、セキュリティ情報を一元的に管理できますので、これも管理コストの低減につながります。このように、あるソフトウェアが使用しているdistributionのパッケージ管理システムに取り込まれているかどうかは、重要な指標になります。

もし採用されていなければ、portやebuildを書いてdistoributionに提出するという手もあります。うまい具合にメンテナンスをdistributionで引き受けてくれれば、管理コストを削減できますし、他の利用者もそのソフトウェアの恩恵にあずかることができて、一石二鳥です。正式に採用されなくても、独自にパッケージ管理システムに取り込めば、他のパッケージと同様に管理できますし、サイト固有のパッチの管理も容易になりますから、おすすめです。最低でも、もっとも使用頻度の高いOSのパッケージ管理システムは理解しておきたいところです。

開発者に直接尋ねる

ここまでは公開された情報だけで判断していましたが、それでも不明な点があれば、開発者に直接聞いてみるのもよいでしょう。とりわけ、新機能のロードマップ、リリースが遅れている理由などの文書化されていない事柄は直接たずねるのが一番です。メーリングリストでもよいですし、専用のIRCチャンネルがあれば気軽に声をかけてみましょう。

オープンソースプロジェクトが成功するには

ここまででは、利用する側からの視点でオープンソースの評価をしてみました。この見方を反対にしてみると、オープンソースプロジェクトが広く利用されるにはどうしたらよいのか、という疑問の回答になります。

ライセンス

ライセンスを明示しましょう。また、「⁠オープンソース」を名乗るのであれば、OSIによって認められたライセンスから選ぶことをおすすめします。利用する側からすると、ライセンスの解釈はややこしいので、これ以上独自ライセンスは増えてほしくないところです（個人的には、ややこしい独自ライセンスは避けます⁠）⁠。これは、どのようなライセンスが適切か否かということではありません。ライセンスの優劣はつけられませんし、採用できるライセンスも組織によって異なるでしょうから、どのライセンスがよいとは一概に言えません。ただし、利用者としてはできる限り広く利用されているライセンスを採用するか、一般的ではないライセンスを採用した理由を明記してほしいところです。

ユーザのサポート体制

オープンソースの最大のメリットは、ユーザコミュニティによる支援です。それは、コードの寄贈や、ユーザ同士の互助体制、開発へのフィードバックであったりします。そのためのインフラを開発側が提供するのが重要です。

メーリングリスト、掲示板、blogやwikiなど、何らかのコミュニケーション手段を提供し、ユーザコミュニティで相互にサポートできるようにしましょう。特に開発者によるblogは、プロジェクトの現状を把握したり、その今後を占う上でとても有益です。「⁠できる/できない」の一言を得るのに数ヵ月かかる商用製品ではないのですから、開発者と利用者の距離が近いオープンソースならではのコミュニケーション方法として、blogは有効なツールではないでしょうか。顔の見える開発体制は、透明性の確保だけでなく、ユーザから直接フィードバックを得られるという点で、開発者のモチベーション向上にもつながるのではないでしょうか。

ソースコードの公開

オープンソースですから、ソースコードを公開するのは当たり前ですが、ダウンロードに無用な条件を課すのは、ユーザにとってもわずらわしく、なによりパッケージ管理システムに取り込みにくいため、利用のハードルを高くするだけです。

単純にソースコードを配布するだけではなく、CVSやSubversionのリポジトリも公開するとよいでしょう。すでに書いた通り、開発者によるコードの寄贈が見込めるという理由だけでなく、ソフトウェアの評価やトラブルシューティングにも役立つからです。常に最新のコードを公開することで、bugの早期発見にもつながります。成功しているプロジェクトでは、ヘビーユーザが開発版のコードをテストして、そのフィードバックを開発側が受け取り、その結果としてリリースの品質が向上する、という良いサイクルができあがっています。

文書の整備

ユーザが最初に目を通す文書のREADME、インストールの方法を書いたINSTALLおよびmanは必ず用意しましょう。よくできた文書はプロジェクトの成功への第一歩です。ユーザが最初につまづくのはインストールですし、インストールできなければ使ってもらえませんから、なかでもINSTALLは重要です。インストールを確認したdistribution名、ソースコードのコンパイルに必要なパッケージ、インストールに必要なパッケージなどを明記します。READMEには、ソフトウェアの説明、開発に至る経緯、既存のソフトウェアとの比較などを書きます。実際にインストールして評価する作業は手間がかかりますから、どのような目的で作成され、どういった特徴があるのかを簡潔にわかりやすく記述するのが重要です。

インストールされるコマンドすべてについてmanは必要です。より親しみやすい記法で書かれたファイルをroffフォーマットに変換するツール（pod2man）を利用するという手もあります。HTMLやPDFでしか読めないマニュアルは論外です（緊急時には、HTMLやPDFが読めない環境だったりすることも珍しくありません⁠）⁠。

開発者向けの文書はあると望ましいですし、プラグインなどにより拡張するソフトウェアであれば必須です。開発者であればソースコードを読めると期待できるので、ユーザ向けの文書ほど懇切丁寧である必要はありません。ソースコードのコメントとあわせて理解できる程度でかまわないでしょう。

パッケージ管理システム

パッケージ管理システムに取り込まれることによるメリットは多いですから、取り込まれるための努力は惜しむべきではありません。コマンドひとつでインストールできるため、ユーザは導入しやすいですし、配布元はインストーラの再発明をせずに済み、またメンテナンスのコストの一部をユーザコミュニティに転化できます。

同じように見えるdistributionも、ポリシーも違えば、内部の仕組みも異なります。各distribution固有の事情を熟知しているのは、そのdistributionのユーザであり、さまざまなノウハウや経験を持つパッケージメンテナーですから、これを利用しない手はありません。また、不具合がdistribution固有の問題なのか、本来のbugなのかのふるいわけもしてくれます。メンテナーと良好な関係を築けば、おのずと利用者も増えることでしょう。

パッケージ管理システムに取り込んでもらいやすくするには、適切なインストール文書を用意し、インストールオプションをあとから変更しやすいような仕組みを用意することです。独自にインストーラを用意しても、すべてのdistributionをサポートするのは困難ですから、必ずしもインストーラは必要ではありません。必要な要件を明示することのほうが重要です。独自のインストーラを用意するくらいなら、コンパイルが必要なソフトウェアであれば、autoconfや、automakeを利用するとよいでしょう。ただし、Webアプリケーションは統一的なインストール方法が確立されていません。必要なモジュールやオプション、パス、パーミッションを明確にしましょう。

最後に

優れたシステムを導入して、現状を改善するのもシステム管理者の仕事のひとつです。システムの構築や運用には多大なコストがかかりますから、しっかりとした評価は重要です。今回は、自分なりの評価のしかたを紹介してみました。

オープンソースのプロジェクトといっても、成功しているものもあれば、見向きもされず消えていくプロジェクトもあります。ここであげた項目を満たせば、優れたプロジェクトというわけではありませんが、優れたプロジェクトのほとんどはこうした項目を満たしていると言えるでしょう。この記事がオープンソースプロジェクトとの付き合い方の参考になれば幸いです。