【しばらく編集不可モードで運営します】 編集(管理者用) | 差分 | 新規作成 | 一覧 | RSS | FrontPage | 検索 | 更新履歴

QualityImprovementInFreeSoftware - Free Software における品質改善: リリース管理を中心に

目次

Free Software における品質改善: リリース管理を中心に

この文書について

Free Software における品質改善: リリース管理を中心に

私の博士課程はもうすぐ終わる. その研究成果のことを書き始めたところだ. この博士課程では, free software のプロジェクトにおける品質改善について調査しようと努めた. free software の品質について少し調べてまわったあと, 私はリリース管理に話題を絞ろうと決めた. この分野には問題があって, そのプロセスは改善できると思ったからだ. その改善によって, free software のプロジェクトによる成果物の 品質水準を引き上げることができればと期待している.

リリース管理を調べるにあたり, 大きく複雑なプロジェクトをもっぱら焦点とした. そうしたプロジェクトでは, リリースの準備にあわせて 数百人のボランティアが協調しなければいけない. 私が特に注目したのは時間ベースのリリース管理だ. 予備調査によると, この種のリリース管理戦略には大きな関心が寄せられている. 私の研究が問うのは主にこういうことだ. 時間ベースのリリース管理は, どのように, なぜ, 巨大な free software のプロジェクトで役割を果たしているのだろうか.

最初の投稿では free software のプロジェクトを 7 つ紹介していく. 私は研究のなかでこれらのプロジェクトを注意深く調査した. 各プロジェクトごとにこれまでの問題を簡単にまとめ, その問題に対処すべく行われたことを示す. それから今なお解決していない問題が何かを述べていく.

Debian

Debian プロジェクトの目的は, 他のプロジェクトが作ったソフトウェアを統合して free software を基盤とする完全なオペレーティング・システムを作ることだ. 過去数年, プロジェクトは広がり続ける遅延と予測不能なリリースという問題を抱えてきた. 特筆すべきは Debian 3.1 のリリース・プロセスで, これは重大な遅延だとみなされている. 当初 2003 年 12 月 1 日リリースと発表されていたソフトウェアは, 結局 2005 年 6 月にリリースされた. 一年半に及ぶ遅延だ. それ以来, プロジェクトではリリース・プロセスに関するいくつもの改善がなされた.

VersionDateMonths
1.11996-06-17-
1.21996-12-126
1.31997-06-026
2.01998-07-2414
2.11999-03-097
2.22000-08-1417
3.02002-07-1923
3.12005-06-0635

これまでの問題

対策

残った問題

GCC

The GNU Compiler Collection (GCC) は C や C++ など複数のプログラミング言語を サポートするコンパイラ・スイートである. これは free software のプロジェクトにとって 極めて重要な開発ツールとなっている. 90 年代に EGCS プロジェクトが結成されるまで, GCC は動きのないプロジェクトだった. 1998 年 10 月, EGCS は公式の GCC 開発に乗り込み, 高度なピアレビューなどの確固たるプロセスを打ち立てた. また運営委員会を設置した. 委員会はメンテナを探したり, 重要な意思決定を行った. 計画では, プロジェクトは 6 ヶ月間隔で時間ベースのリリースを行うはずだった. 実際には, ここ数回を見るかぎり毎年ひとつの新バージョンをリリースするに留まっている.

VersionDateMonths
3.02001-06-18-
3.12002-05-1511
3.22002-08-143
3.32003-05-139
3.4.02004-04-1811
4.0.02005-04-2012
4.1.02006-02-2810

これまでの問題

対策

残った問題

GNOME

GNOME は簡単に使える完全なデスクトップ環境を提供している. このプロジェクトはいくつかの大きな問題に直面してきた. 1.x 系や 2.0 のリリースの準備に関する遅延などがそうだ. GNOME は 2.0 以降から時間ベースのリリースを採用し, リリース管理を著しく改善してきた. プロジェクトはここ数年 6 ヶ月毎に時間ベースのリリースを行っており, これは時間ベースのリリース管理の手本だと見られている.

VersionDateMonths
1.01999-03-03-
1.22000-05-2515
1.42001-04-0210
2.02002-06-2715
2.22003-02-067
2.42003-09-117
2.62004-03-317
2.82004-09-156
2.102005-03-096
2.122005-09-076
2.142006-03-156
2.162006-09-066
2.182007-03-146

これまでの問題

対策

残った問題

Linux Kernel

Linux Kernel のプロジェクトは, 過去数年でそのリリース戦略を大きく変えてきた. 2003 年 12 月, 2.6 系の最初の安定版のリリース以降は特に違っている. この 2.6 系は, 2001 年 1 月に 2.4 系がリリースされてから 3 年近く開発が続いた. 多くの人がこれを長過ぎると感じていた. メジャーリリースの間隔の長さから来る弊害の一つは, ベンダがバックポートやフォワードポートを大量にパッチしなければいけない点にある. カーネルの新しい開発モデルは多数の非難を受けている. 人によっては, 特にカーネル開発者はこの方法でうまく言っていると主張するが, 利用者の中にはカーネルに対する大改造の多さと安定性の欠如に不安を感じている人もいる. 開発者のリードである Andrew Morton は, カーネルがバギーになりつつある旨を数回に渡り表明している.

VersionDateMonths
1.01994-03-14-
1.21995-03-0712
2.01996-06-0915
2.21999-01-2531
2.42001-01-0423
2.62003-12-1735

これまでの問題

対策

残った問題

OpenOffice?

OpenOffice?.org は複数のアプリケーションを統合して提供するオフィス・スイートだ. ワード・プロセッサや表計算などがある. もともと StarDivision? 社によって開発された StarOffice? は Sun に買収された. 2000 年 7 月, Sun はそれを OpenOffice?.org という free software としてリリースした. OpenOffice? の開発では, 今も Sun が強い権限を維持している. とはいえ他のベンダ, 特に Novell はプロジェクトの有力な貢献者となっている. Sun の商用製品である StarOffice? として, かつてのプロジェクトは 18 ヶ月という長いリリース間隔をかけていた. 遅延は多く, ベンダがどのバージョンを含めるべきか判断するのは難しかった. 長い遅延を経た 2.0 のリリース以降, OpenOffice? は 3 ヶ月のリリース間隔へ移行した. 2.0 のリリースは 1.1 以来 26 ヶ月ぶりのものだった. 新しいリリース間隔は前向きに受け止められた. 貢献者からすれば, 機能や修正がより早くユーザに届くようになる. そんな中, 2006 年の終わりに議論があり, 6 ヶ月間隔のリリースがもちあがる. ユーザは 3 ヶ月毎の新機能を望むほどに見えず, また間隔が短かいことで QA チームに多大な圧力がかかってしまうためだ.

VersionDateMonths
1.02002-05-01-
1.12003-09-0216
2.02005-10-2026
2.0.12005-12-212
2.0.22006-03-083
2.0.32006-06-294
2.0.42006-10-133
2.1.02006-12-122

これまでの問題

対策

残った問題

Plone

Plone は Zope という強力なアプリケーション・サーバを使って作られた コンテンツ管理システムである. プロジェクトは 2.1 のリリースに際して大きな遅れをもった. Plone コンサルタントは古いリリースを使うか新しいのを待つかの選択に苦しんだ. ようやく 2.1 がリリースされた時も, 多くのユーザはアップグレードに問題を抱え, 多数の変更を迫られた. これらの問題を解決するため, また Zope のリリースと足並みを揃えたいこともあって, プロジェクトは 2005 年から 6 ヶ月毎の時間ベースのリリースに移行した.

VersionDateMonths
1.02003-02-06-
2.02004-03-2313
2.12005-09-0617
2.52006-06-169

これまでの問題

対策

残った問題

X.org

かつて, 大半の Linux ディストリビューションやその他の free software のプロジェクトは XFree86 システムに依存していた. 時間が経つにつれ XFree86 プロジェクトの構造は硬直化が進み, 進歩を続けて他の free software コミュニティと歩調を合わせることができなくなってしまった. 2004 年の 2 月に XFree86 がライセンスを変更したとき, 活発なコミュニティや大半のベンダは即座に X.org へ移っていった. X.org は非常に活発なコミュニティだ. 彼らはモノリシックなコードベースの分割と, よりモダンなビルド・システムへの移行を決めた. X.org 7.0 からプロジェクトはモジュール化されたシステムとなり, 各コンポーネントは別個に開発, リリースされている. プロジェトは二段構成のリリース機構を備える開発の仕組みをうまくとりいれた: まず各コンポーネントは必要に応じてリリースされる. 加えて X.org 全体でのリリースがある. そのリリースでは各コンポーネントの安定版がまとめられる. この全体リリースは 6 ヶ月毎に行なわれる.

VersionDateMonths
7.02005-12-21-
7.12006-05-225
7.22007-02-159

これまでの問題

対策

残った問題