IBM®
本文へジャンプ
    Japan [変更]    ご利用条件
 
 
検索範囲検索:    
    ホーム    製品    サービス & ソリューション    サポート & ダウンロード    マイアカウント    
skip to main content

developerWorks Japan  >  Open source  >

オープンソースで行こう!: 第4回 ユーもオープンソースにジョインしちゃいなよ!

developerWorks
ページオプション

JavaScript を要するドキュメントオプションは表示されません


レベル: 初級

ITmedia, Writer

2007年 5月 11日

ソフトウェアを開発し、ライセンスを決めて公開すれば一丁上がり。言葉にすると簡単でも、具体的にやろうとすると戸惑うケースも多いでしょう。今回から2回に分けて、オープンソースソフトウェアの開発/公開における基本事項と、コミュニティーとつきあうコツを解説しましょう。

ソフトウェアを開発し、ライセンスを決めて公開すれば一丁上がり。言葉にすると簡単でも、具体的にやろうとすると戸惑うケースも多いでしょう。ソースコードをどこで公開するのか、バグ報告はどうやって受け付ければ良いのか。もちろん、こういった問題にも先人がある一定の答を出しています。今回から2回に分けて、オープンソースソフトウェアの開発/公開における基本事項と、コミュニティーとのつきあうコツを解説しましょう。

開発者になろう!

世の中にはたくさんのオープンソースプロジェクトがあり、その運営ポリシーや運用もさまざまです。うまくいくプロジェクトもあれば頓挫してしまうものもあります。ここでは、開発の基本的な流れを解説し、成功しているプロジェクトの事例を幾つか紹介していきます。




上に戻る


開発の流れ

オープンソースソフトウェア(以下、OSS)を使っていて不具合を発見した、あるいは欲しい機能があるといった場合、既存のソフトウェアプロジェクトに何らかの働きかけをすることになります。例えば、不具合報告をする、機能追加の要望を出すなどです(もちろん、自分でコードを修正しても良いでしょう)。

一般にOSSの開発プロジェクトはメーリングリスト(以下、ML)やホームページなど、幾つかの手段で連絡が取れるようになっています(表1)。もし何らかのソフトウェアプロジェクトに関心があるのなら、MLに入っておくと良いでしょう。MLに流通するメールをしばらく読んでいると、そのプロジェクトでのバグ管理方法や開発の雰囲気がつかめてくるはずです。


表1. 開発プロジェクトとの連絡手段

拡大図

不具合を自分で修正した場合は、パッチと呼ばれるソースコードの修正差分をMLに投稿するのが一般的です。パッチは、UNIX/Linuxで標準提供されているdiffコマンドを使用して実行例1のように作成します(リスト1)。

$ cp -a Hello Hello.work
$ cd Hello.work
$ vim hello.c
$ diff -c ../Hello . > ../Hello.patch
            

実行例1 パッチの作成方法

それぞれの行で何をやっているかというと、

1行目:オリジナルのソースツリーを、修正作業用ソースツリーとして丸ごとコピー

2行目:修正作業用用ソースツリーに移動する

3行目:実際にファイルを修正する

4行目:オリジナルのソースツリーと比較し、差分情報をファイルに保存


リスト1 パッチ(差分情報ファイル)

拡大図

これをMLに投稿すると、受け取った人は自分の手元にあるソースコードに対して次のようにパッチを適用し、修正部分を自分のソースツリーにマージ(統合)できるのです。

$ cd Hello.test ← テスト用ソースツリーに移動

$ cat /tmp/hello.patch | patch -p1 ← パッチを適用

パッチは差分情報を用いることでソースコードの管理を便利にするツールですが、これに加えてバージョン/日付/修正者情報を管理する機能を備えたものがバージョン管理システムになります。最近では、複数のユーザーで協調作業しやすいよう、バージョン管理システムを使ってソースコードを管理していることが多くあります。現在よく使われているのはCVS(Concurrent Versions System)で、CVSより使い勝手と機能に優れたSubversionや商用ソフトウェアを使っているプロジェクトもあります。OSS開発に参加するなら、バージョン管理システムへの習熟は必須でしょう。





上に戻る


オープンソース開発を支援するサービス

ソフトウェアの開発そのものは、エディタとコンパイラ、実行環境さえあれば始められますが、前述のようにソースコードはバージョン管理システムで管理した方が良いでしょう。また、複数の開発者がソースコードにアクセスすることを考えると、インターネットのサーバ上にバージョン管理システムを用意するのが望ましいと考えます。

そのほか、Web上にホームページを作成し、バグ報告用にMLも起ち上げる必要があるでしょう。バグトラッキングシステムは必ずしも必要ではないですが、最新情報やFAQなど、情報を一元管理できるようWikiシステムなどを起ち上げておくと重宝します。こういった要件を考えると、開発用のサーバが必須だといえます。しかも、バージョン管理システムやMLなど、比較的自由度の高い運用ができなければならず、安価なレンタルサーバは使えません。

自宅サーバやホスティングを利用することになりますが、セキュリティの問題もあって本格的な環境を構築・運営するのは案外大変なのが実状です。幸いにして、これらの開発環境を提供しているのが、SourceForgeというWebサイトです。オープンソースソフトウェアの開発に限って無償で利用できるサービスです。国際的なプロジェクトにしたい場合はSourceForge.net、日本語圏のコミュニティーで開発するならば、SourceForge.jpを使えば良いでしょう。

SourceForgeで提供している機能は表2のようになります。便利な機能がそろっているのでぜひ活用されることをお勧めします。


表2 SourceForgeで提供している機能

拡大図




上に戻る


開発プロジェクトの実際例

多くのソフトウェア開発プロジェクトはかなり小規模で運営されていますが、中には数千人規模で運営されているものもあります。Brooksの法則*によれば、開発者の人数が増えても、開発者間のコミュニケーションコストが増えるなどして、効率は上がらないといいます。では、世界規模で開発を行っているプロジェクトでは、どうやってプロジェクトを運営しているのでしょうか。ここでは、LinuxカーネルとDebian GNU/Linux*を例に、プロジェクト運営の実際例を見てみることにしましょう。

Linuxカーネルの場合

例えばLinuxカーネルの開発は、リーナス・トーバルズを頂点とし、機能ごとにサブリーダーをかかえるピラミッド構造になっています。Linuxカーネルに機能を追加してもらいたい場合、まずはサブリーダーを説得する必要があります。開発についての議論はLKMLと呼ばれるMLで行われているので、パッチをMLに投稿してサブリーダーや関心のある開発者と議論を行うことが基本となります。

Linuxカーネルの開発においては、リーナス・トーバルズやアラン・コックスなど一部のカリスマ開発者が非常に強い権力を持っています。彼らはそれぞれソースコードのツリーを持ち、そこで試してもらえるかどうかがパッチ作成者の努力の行方を握っているのです。一種独裁とも言える体制なのですが、この仕組みで不思議とうまくいっているのは、MLにおいて徹底的に議論していることにあるようです。

どんなに優れた機能でも、ソースコードをいきなり投げ入れただけでは採用されません。それがどのような機能を提供し、どういったメリットをもたらすのか、また、実装に問題はないのかを話し合った上で採用の可否が決められます。成果物だけでなく、作る過程やコンセンサースが重視されるのです。

Debian GNU/Linuxの場合

Debian GNU/Linuxの場合は、アプリケーションパッケージごとに、それぞれメンテナンス担当者が決まっています。中でも、http://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=wnppにリストアップされているうち(図1)、「O:」または「RFA:」がつけられているパッケージは、バグを含みながらもorphan(「O:」の付いているもの。メンテナ不在)、RFA(Request For Adoptation、引き取り手募集)の状態になっています。


図1. バグの解決待ちパッケージ一覧のページより。「O:」や「RFA:」が付けられているパッケージが確認できる

この中に興味のあるパッケージを見つけた場合は、バグを修正してから開発者に連絡を取ると良いでしょう。バグの修正は、自分にメンテナを勤めるだけの実力と意欲があることを示すためにも重要です。ただし、Debianのアーカイブに直接パッケージをアップロードするには、アカウントが必要なのですぐにはできません。この段階では、自分の代わりにアップロードしてくれる「スポンサー」と呼ばれる協力者を見つける必要があります(具体形には、debian-mentors@lists.debian.orgにメンテナを探している旨投稿する)。

このようにパッケージを更新し協力者を得るという実績を積んだ後、New Mainter(新規メンテナ)プロセスと呼ばれる選考に通ってやっとアカウントがもらえる仕組みです。非常に複雑な仕組みでメンテナを選抜していますが、逆に言えばその厳格さこそがDebian GNU/Linuxの信頼性を高めているのでしょう。





上に戻る


イベントに参加しよう!

OSS開発にたずさわるメリットの1つとして、コミュニティーでの情報交換が挙げられます。最近のシステムは、オープンシステムの流れを受けて、標準的な技術要素の組み合わせでできています。そのため、標準技術や動向を知らなければ開発できません。OSS開発では、多様なコミュニティーによって業界横断的なイベントも多数行われているため、情報のアンテナとして有効です。次回は、技術系の勉強会、会合を主宰されているお二人にインタビューし、コミュニティー活動の魅力を聞きます。





上に戻る


このページで出てきた専門用語

Brooksの法則

『人月の神話』(ISBN4-89471-665-8)という古典的名著で指摘された法則。

Debian GNU/Linux

Linuxディストリビューションの1つ。純粋に「フリー」なOS環境を構築するべく、厳格なルールを適用してディストリビューションパッケージを構成しています。



参考文献



著者について

ITmedia




記事の評価


サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。



 


 


不充分・不完全である大変素晴らしい
 


この記事を共有する

del.icio.us del.icio.us newsing newsing FC2ブックマーク FC2ブックマーク
Choix! Choix! ニフティクリップ ニフティクリップ Yahoo!ブックマーク Yahoo!ブックマーク
MM/memo MM/memo CZブックマーク CZブックマーク livedoorクリップ livedoorクリップ
はてなブックマーク はてなブックマーク Buzzurl(バザール) Buzzurl(バザール)




上に戻る


    日本IBMについて プライバシー お問い合わせ