Comments
Description
Transcript
なぜ企業はオープンソースを使わないのか（2）
第46回 Prowise Business Forum
なぜ企業はオープンソースを使わないのか（２）
～導入におけるメリットと安心・安全に活用するポイント～
2010/11/18
株式会社 日立ソリューションズ
OSSソリューションビジネス推進センタ
吉田 行男
© Hitachi Solutions, Ltd. 2010. All rights reserved.
０ 自己紹介
２０００～
２００３／４
２００５／１
Linuxを活用したビジネス企画に着手
OSSサポートサービスを開始
OSSミドル評価プロジェクトに参画
(JBoss,Tomcatクラスタ評価)
２００５／７
２００６～
Linuxコンソーシアム参画
Linux Foundation SI Forum に参画
(OSSミドルウェア／ツール調査)
２００８／６
オープンソースビジネス推進協議会（OBCI)
立上げに参画
２００９／７
OSSコンソーシアム立上げに参画
→ ２０１０より副会長
© Hitachi Solutions, Ltd. 2010. All rights reserved.
1
なぜ企業はオープンソースを使わないのか（２）
～導入におけるメリットと安心・安全に活用するポイント～
Contents
１. 章 OSSを取り巻く状況
２. 章 安全・安心に活用するポイント
３. 章 まとめ
© Hitachi Solutions, Ltd. 2010. All rights reserved.
なぜ企業はオープンソースを使わないのか（２）
～導入におけるメリットと安心・安全に活用するポイント～
１.章 OSSを取り巻く状況
© Hitachi Solutions, Ltd. 2010. All rights reserved.
１-１ OSSを取り巻く状況
Linux Foundation SI Forumが実施した
2009年度オープンソースソフトウェア導入実績調査から
① 調査概要
調査期間：2010/3 ～ 2010/4
調査対象期間：2009年度(2009/4～2010/3)
参加企業(９社) ：
•
•
•
•
•
•
•
•
•
ＮＥＣソフト株式会社
エヌ・ティ・ティ・コムウェア株式会社
株式会社シーイーシー
株式会社日立製作所
株式会社日立システムアンドサービス
東芝ソリューション株式会社
日本アイ･ビー･エム株式会社
富士通株式会社
レッドハット株式会社
© Hitachi Solutions, Ltd. 2010. All rights reserved.
4
１-１ OSSを取り巻く状況
② 結果
さらに活用範囲が広がるオープンソースソフトウェア
•
『導入実績多数(４社以上)』：４５件 → ６６件へ
運用・管理、開発環境、Web/APサーバでは多くのＯＳＳの
導入実績がアップ
•
「定番化」 及び 「検証」から「導入」への道筋
商用ソフトとの連携がさらに重要に
•
シングルサインオン等
業務アプリ、デスクトップアプリは今後も動きに注目
•
未だ「定番」なし。
ハイアベーラビリティへの期待も膨らむ
•
DRBDやUltraMonkey等の活用頻度の高まり。
着実に使用実績が増えるRuby、Ruby on Rails
•
Ruby関連ビジネスは、完全にテイクオフした！
© Hitachi Solutions, Ltd. 2010. All rights reserved.
5
１-２ 企業が考えるOSS のメリット
各企業が考えるOSS のメリット
・コスト削減
・ベンダーロックイン回避
・柔軟性
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査)
© Hitachi Solutions, Ltd. 2010. All rights reserved.
6
１-３ OSS 普及の阻害要因
OSS 普及の阻害要因
サポートに対する不安
［OSS のコミュニティにどのように接触してよいかがわからない］
ライセンスに対する懸念
大企業ではライセンスが複雑で扱いを誤ると訴訟に発展するリスク
中小企業では社内にライセンスを把握できる人材が不足
人財及び経験の不足
OSS に総合的に精通した上級技術者の不足
体系的な学習教材不足
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査)
© Hitachi Solutions, Ltd. 2010. All rights reserved.
7
１-４ OSS 利用のサポート面の課題
OSS 利用のサポート面の課題(2009年度）
コミュニティとの
付き合い方
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査)
© Hitachi Solutions, Ltd. 2010. All rights reserved.
8
１-５ OSS 利用のライセンス面の課題
OSS 利用のライセンス面の課題（2009年度）
ライセンスの
わかりにくさと
訴訟リスク
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査)
© Hitachi Solutions, Ltd. 2010. All rights reserved.
9
１-６ OSS 利用のその他の課題
OSS 利用のその他の課題（2009年度）
OSS選定基準
必要？
出典：IPA 第３回オープンソースソフトウェア活用ビジネス実態調査(2009年度調査)
© Hitachi Solutions, Ltd. 2010. All rights reserved.
10
なぜ企業はオープンソースを使わないのか（２）
～導入におけるメリットと安心・安全に活用するポイント～
２.章 安全・安心に活用するポイント
© Hitachi Solutions, Ltd. 2010. All rights reserved.
２-１ オープンソースのメリット
オープンソースのメリット
安価にシステムを構築できる
機能追加、バグ修正が速い
マルチプラットフォームに対応している
機能追加・バグ修正を自分で行うことも可能
サポートが打ち切られてもお手上げにならない
メリットを最大限
に活かすポイント
OSSの特性の理解
適切なOSSの選定
ライセンスへの適切な対処
© Hitachi Solutions, Ltd. 2010. All rights reserved.
12
２-２ OSSの特性の理解(1)
関連組織・団体の全体像
開発コミュニティ
アプリケーション
・ソフトウェア
ディストリビュータ
商用ソフトウェア
ユーザ
運用管理ソフトなどの
構築システム
商用ソフトウェア
SIer
業務アプリ
ケーション
日本語フォント/オィ
ススイートなどの
ハードウェア
ISV
インスト
ーラ・他
Linuxカーネル
、ドライバ
PFベンダ
動作確認済マシン
GNUソフト
ライブラリ
コマンド
ディストリビューション
ApacheなどのOSS
非Linuxマシン
動作確認済
商用ソフトウェア
総合ベンダ
(出典：日本OSS推進フォーラム「オープンソースソフトウェアが開発コミュニティからユーザに届くまでの仕組み」より
© Hitachi Solutions, Ltd. 2010. All rights reserved.
13
２-２ OSSの特性の理解(2)
開発コミュニティ以外のベンダがサポートを提供
ユーザの自己責任の範囲を選択可能
作業役割(例)
①
②
③
④
⑤
ディストリビュー
ションの作成
ユーザ
ディスト
リ
ビュータ
ディストリ
ビュータ
ディストリ
ビュータ
ディストリ
ビュータ
ターゲットマシン
へのインストール
ユーザ
ユーザ
PFベンダ
(ディストリ
ビュータ)
PFベンダ
(SIer)
総合ベンダ
ユーザ
ユーザ
ユーザ
PFベンダ
(SIer)
総合ベンダ
PFベンダ
ターゲットマシン
での動作確認
ユーザ
ユーザ
ユーザ
SIer
総合ベンダ
ディストリビュータ
様々な機器やソ
フトウェアを利用
したシステムの提
案
システム構築・
評価
ユーザ
ユーザ
ユーザ
SIer
総合ベンダ
運用時の問題切
り分け等
ユーザ
ユーザ
ユーザ
SIer
(ユーザ)
総合ベンダ
(ユーザ)
ユーザ
① ② ③
④
⑤
総合ベンダ
SIer
開発コミュニティ/開発企業
(出典：日本OSS推進フォーラム「オープンソースソフトウェアが開発コミュニティからユーザに届くまでの仕組み」より
© Hitachi Solutions, Ltd. 2010. All rights reserved.
14
２-３ 適切なOSSの選定(1)
適用するOSSを選定するために
（１）オープンソースの機能/性能評価
（２）選定における考慮点
技術者/ベンダサポートの有無
プロジェクトの継続性
① 最新バージョンのリリース時期
② コミュニティの設立からの期間
③ リリース計画
④ サポートポリシー
ソースコードの確保
問題解決ソースの確保
①
②
③
④
⑤
インストール手順
各種環境を構築するための手順
サービスなどの起動／停止手順
ライブラリ/APIのリファレンス
FAQ
© Hitachi Solutions, Ltd. 2010. All rights reserved.
15
２-３ 適切なOSSの選定(2)
（１）オープンソースの機能/性能評価
異常処理に注意
負荷テストは必須。
評価情報の有効利用
【ソフトウェア評価】
QualiPSo Open Source Maturity Model (OMM)
http://www.qualipso.org/
Qualification and Selection of Open Source Software (QSOS)
http://www.qsos.org/
Business Readines Rating (BRR) for Open Source
http://www.openbrr.org/
© Hitachi Solutions, Ltd. 2010. All rights reserved.
16
２-３ 適切なOSSの選定(3)
（２）選定における考慮点
技術者/ベンダサポートの有無
プロジェクトの継続性
ソースコードの確保
問題解決ソースの確保
© Hitachi Solutions, Ltd. 2010. All rights reserved.
17
２-３ 適切なOSSの選定(4)
（２）選定における考慮点
①技術者/ベンダサポートの有無
社内に技術者は？
サポートサービスを提供している会社は？
サポートのないものを
使うことは危険！
© Hitachi Solutions, Ltd. 2010. All rights reserved.
18
２-３ 適切なOSSの選定(5)
②プロジェクトの継続性チェック
コミュニティがプロジェクトを継続して活動させていく意思があることを確認。
項目
指標
最新バージョンのリリース時期
6ヶ月前
コミュニティの設立からの期間
１年以上
設立時期が不明な場合、初期バージョンの
リリース時期等を参考に
リリース計画及び
サポートポリシー
終了予定日の明示
平均的なサポートサービス
期間の明示
© Hitachi Solutions, Ltd. 2010. All rights reserved.
19
２-３ 適切なOSSの選定(6)
プロジェクトの継続性チェック 例１
© Hitachi Solutions, Ltd. 2010. All rights reserved.
20
２-３ 選定における考慮点(7)
プロジェクトの継続性チェック 例2
© Hitachi Solutions, Ltd. 2010. All rights reserved.
21
２-３ 選定における考慮点(8)
②ソースコードの確保
ソースコードの明確な一次配布先の確保
•コミュニティーのサイト(FTP,HTTP)に存在することが多い。コミュニ
ティーが活動を停止しない限り、確実にソースコードを入手可能。
ソースコードの正当性の確認
•第三者により改ざんされていないことをPGPまたはMD5により
確認する。(2002年に事例あり)
米CERT/CCは米国時間の10月8日、電子メールサーバソフトウェ
ア「Sendmail」のソースコードが改ざんされ、トロイの木馬が仕込
まれている可能性があると警告し、ソースコードの正当性を、PGP
署名やMD5チェックサムを用いて検証すべきとしている。
(http://www.itmedia.co.jp/enterprise/0210/09/n10.html)
© Hitachi Solutions, Ltd. 2010. All rights reserved.
22
２-３ 選定における考慮点(9)
③問題解決ソースの確保
システム構築・運用に必要な手順
①
②
③
④
⑤
インストール手順
各種環境を構築するための手順
サービスなどの起動／停止手順
ライブラリ/APIのリファレンス
FAQ
システムの安定稼働に関わる情報
①
②
③
④
情報の主な供給元：
コミュニティーのWebサイト、
メーリングリスト、
ニュースグループ等。
バグ/セキュリティ関連情報、サポート情報
リリース情報
開発者向け情報
更新履歴(修正内容の明記も含む
© Hitachi Solutions, Ltd. 2010. All rights reserved.
23
２-４ ライセンスへの適切な対処(1)
(1)どんなライセンスがあるのか？
ライセンス類型
複製・
再頒布可能
改変可能
改変部分の
ソース公開要
他のコードと組合せた
場合、他のコードの
ソース公開要
GPL
○
○
○
○
MPL
○
○
○
×
BSDライセンス
○
○
×
×
フリーウェア(*)
／シェアウェア
○
×
－
－
商用ソフト
×
×
－
－
注意！OSSの利用、改造、再配布の方法などが、
ライセンスにより異なる。
(出典：<日本ＯＳＳ推進フォーラム ビジネス推進ＷＧ監修>
ビジネスユースにおけるオープンソースソフトウェアの法的リスクに関する調査」)
© Hitachi Solutions, Ltd. 2010. All rights reserved.
24
２-４ ライセンスへの適切な対処(2)
(2) ライセンス違反とは？(CISCO社の事例)
一括請負発注
納品
GPLコードを利用して
Broadcom’sの標準Linux
コンポーネントをカスタマイズ
コードを組み込み
チップセットの一つに
製品組込
M&A
ブロードコムのチップセット を
利用してiWRT54G 無線ルータを開発
が
FSFがCiscoを提訴
ライセンス違
反
を２００３年に$５00Mで買収
ライセンス違反で
全てのソースコード
を開示
The story
continues...
開発者がファームウェアを変更し
低価格のルータ ($60) がハイエンド
マシンに生まれ変わった。
© Hitachi Solutions, Ltd. 2010. All rights reserved.
25
２-４ ライセンスへの適切な対処(3)
(2) ライセンス違反を起こさないために
・外部コンサルの導入
・BlackDuck社、Palamida社等がソリューション提供
・ツール等活用による自己評価
・Linux Foundationが、自己診断チェックリストを提供
© Hitachi Solutions, Ltd. 2010. All rights reserved.
26
２-４ ライセンスへの適切な対処(4)
The Linux Foundation オープン コンプライアンスプログラム
① トレーニング、教育
② ツール
③
④
⑤
⑥
Dependency Checker
動的、静的リンクのレベルでコードの混在を確認する
ツール
Bill of Material (BoM)
Difference Checker
BoM（部品表）の差分確認ツール。
The Code Janitor
不適切なコメントを残していないか確認ツール。
自己診断チェックリスト
The SPDX™ Standardワークグループ
コンプライアンス ディレクトリーおよび即時警告システム
コミュニティ
© Hitachi Solutions, Ltd. 2010. All rights reserved.
27
２-４ ライセンスへの適切な対処(5)
・自己診断チェックリストの考え方
© Hitachi Solutions, Ltd. 2010. All rights reserved.
28
２-４ ライセンスへの適切な対処(6)
The Linux Foundation オープン コンプライアンスプログラム
コアコンプライアンスの構成要素
検出と開示
出荷予定の製品に含まれているサードパーティ ライセンス ソフトウェ
ア (オープン ソース ソフトウェアを含む) の識別に関わるプロセス
調査と承認
社外に提供する自社製品のオープンソース使用計画の調査、及び企
業ポリシーによって義務付けられる場合は、社内プロジェクトについ
ても調査を実施。
義務の履行
OSS ライセンス義務を履行するために必要なコンプライアンス プラ
クティス。
コミュニティへの 従業員によるコミュニティ プロジェクトへの貢献、および企業によるコ
貢献
ミュニティ プロジェクトへのコードやその他リソースの貢献について、
調査および承認。
© Hitachi Solutions, Ltd. 2010. All rights reserved.
29
２-４ ライセンスへの適切な対処(7)
サポート項目
ポリシー
事業利益を確保すると同時に、OSS の利用を促進するよう、企業の方針を検討
コンプライアンス要員
の適正配置
コンプライアンス プログラムの履行に必要なスキルを持つ人材を集める
ビジネス プロセスの
適応
既存のビジネス プロセスの文脈に OSS コンプライアンスの諸事項をうまく組み込む
トレーニング
OSS コンプライアンスを履行するために行うべきことを、企業全体が確実に理解するた
めに必要な活動
コンプライアンス プロ
セス管理
「コンプライアンス プロセス管理」は、OSS コンプライアンスを履行するためのプロセス
機能の確立、保守、および改善
OSS インベントリ / 記
録管理
「OSS インベントリ / 記録管理」は、組織のニーズに沿って、OSS コンテンツと OSS コン
プライアンス作業の正確な記録を保持することにより、コンプライアンス照会に対する応
答や、コンプライアンス環境の変化に対応
自動化 / ツール サ
ポート
「自動化 / ツール サポート」は、コンプライアンス作業を支援するために、組織による
ツールの利用や考慮点について分析します。
検証
「検証」は、OSS に関する義務が正しく履行されていることを確認するために、OSS コン
プライアンス チームによって実行される独立した保証措置です。
プロセス順守の監査
「プロセス順守の監査」は、組織がチェックした項目を参照し、定義されたコンプライアン
ス プロセスを利用しているか、および、その利用により、期待した結果が得られている
かを確認します。
© Hitachi Solutions, Ltd. 2010. All rights reserved.
30
２-４ ライセンスへの適切な対処(８)
チェックリストサンプル
© Hitachi Solutions, Ltd. 2010. All rights reserved.
31
なぜ企業はオープンソースを使わないのか（２）
～導入におけるメリットと安心・安全に活用するポイント～
３.章 まとめ
© Hitachi Solutions, Ltd. 2010. All rights reserved.
３．まとめ
OSSを安全・安心に使うためには
コミュニティの理解
OSSの適切な選定
ライセンスに注意
© Hitachi Solutions, Ltd. 2010. All rights reserved.
33
ご清聴ありがとうございました。
END
なぜ企業はオープンソースを使わないのか（２）
～導入におけるメリットと安心・安全に活用するポイント～
2010/11/18
株式会社 日立ソリューションズ
OSSソリューションビジネス推進センタ
吉田 行男
© Hitachi Solutions, Ltd. 2010. All rights reserved.
付録
© Hitachi Solutions, Ltd. 2010. All rights reserved.
35
オープンソースソフトウェアで公開されている情報
公開されているのはソースコードだけではありません
ソースコード
各種ドキュメント
#include <stdio.h>
int#include <stdio.h>
<stdio.h>
int#include
main(
int argc,
char
<stdio.h>
int#include
main(
int argc,
char
*argv[])
<stdio.h>
int#include
main(
int
argc,
char
*argv[])
<stdio.h>
{
int#include
main(
int argc, char
*argv[])
{int
intz,int
x,main(
y,
i, argc,
j;
char
*argv[])
x,main(
y, z,int
i, argc,
j;
char
for{int
(i=0;
i<MAXPATH;i++)
{
*argv[])
x, i<MAXPATH;i++)
y, z, i, j;
for{int
(i=0;
{
*argv[])
{
x, i<MAXPATH;i++)
y, z, i, j;
for int
(i=0;
{
{
x, :i<MAXPATH;i++)
y, z, i, j;
for int
(i=0;
{
:
x, i<MAXPATH;i++)
y, z, i, j;
}
for int
(i=0;
{
}
for (i=0; :i<MAXPATH;i++) {
:
}
:
}
:
}
}
マニュアル
ＦＡＱ
+
変更履歴
(リポジトリ)
利用者参加情報
バグ情報
メーリングリスト
(アーカイブ)
サポートフォーラム
© Hitachi Solutions, Ltd. 2010. All rights reserved.
36
バグ情報って何だろう
バグはプログラムの問題点
• バグ情報はプログラムをより良くしていくため、主に開発者が利用する情
報です
• 問題点の情報を開発者間や利用者との間で共有します
• 修正方法の提案や修正内容についての議論も含みます
• 多くのOSSプロジェクトでは一般利用者からの報告も受け付けています
• 修正方法の議論や修正結果も公開されています
具体的には修正が必要な事象に関する以下の情報の集まりです
•
•
•
•
発生現象
重要度(深刻度)
発生条件・環境(OS, ハードウェア)
対象モジュール・機能
•
•
•
•
再現手順
回避方法
修正方法案
修正結果
他
© Hitachi Solutions, Ltd. 2010. All rights reserved.
37
バグトラッキングシステム
バグ報告方法
• E-mail
• バグ情報を管理する専用のバグトラッキングシステム
バグトラッキングシステムとは
• プログラムのバグ発見時に登録し、修正状況を管理するための専用シ
ステムです
• 最近はWebインターフェースを採用するものが主流です
• プロジェクトの進捗管理が可能な機能もあります
• ToDo管理やリリース予定
• バグ情報の分析、未修正一覧
• 定期的なフォローメール
© Hitachi Solutions, Ltd. 2010. All rights reserved.
38
主なバグトラッキングシステム
Bugzilla
http://www.bugzilla.org/
Mozilla Foundationが開発しているOSS
主な採用プロジェクト
•Mozilla project
•Linux Kernel
•Apache Project (httpd, Tomcat他)
•Samba Project
JIRA
http://www.atlassian.com/software/jira/
豪 アトラシアン社が開発したプロプライエタ
リ・ソフトウェア
OSSプロジェクト等には無償で提供される
主な採用プロジェクト
• JBoss
• Spring Framework
• Apache Project (Geronimo, Struts他, 今後の主流)
引用: Mozilla Project Bugzilla (https://bugzilla.mozilla.org/ )より
そのほか
•GNU GNATS
•独自系
•他
引用: Apache Project ASF JIRＡ (https://issues.apache.org/jira/ )より
© Hitachi Solutions, Ltd. 2010. All rights reserved.
39
バグトラッキングシステムの利用場面
既存事例の調査
• 誰かが同じことをやってるかも
• 既に直っているかも
• 回避方法があるかも
問題発生
バグ情報
回避策
使用者
検索
コメント投稿
メーリングリスト
＆
過去検索
投稿して会話
やっぱり新しいバグだ
バグかもしれない
• マニュアルと動きが違う
• core dumpした
• ソースの間違いを見つけた
注意
新しいバグを見つけたので報告
•修正方法がわからなくても（わかればBest)
•開発者に伝える、会話ができる
•今後の開発に活かしてもらえるかも
•記録として残る
バグトラックはあくまでもバグ修正を管理するためのツールです
一般利用者のためのお助けフォーラムではありません
「単なる問い合わせ」のためにバグトラック投稿を行うと開発者に無用な作業を
増やしてしまいます
よくわからない場合は、まずユーザメーリングリスト等を活用しましょう
© Hitachi Solutions, Ltd. 2010. All rights reserved.
40
バグ情報の活用
バグトラックは開発者のためのシステムです
ソースコードがわからないと利用価値がない?
開発者以外では活用できない?
もちろん開発者にとって非常に重要な情報ですが
それだけではありません
© Hitachi Solutions, Ltd. 2010. All rights reserved.
41
活用例
© Hitachi Solutions, Ltd. 2010. All rights reserved.
42
活用例(1)定期観測
定期的に参照
障害発生防止に役立てる
予め知っていれば顕在化(実際に問題となること)を防ぐこともできる
使用中のＯＳＳにどれくらい問題が残っているのか把握できる
問題調査時とは異なる条件でバグを検索
例えば
•
•
•
•
利用しているバージョン
特定のコンポーネントだけ参照
クローズになった物も検索対象
更新された期間を指定(この1ヶ月)
「今月のバグ一覧」を取得できる
引用: Apache Projecct Bugzilla ( https://issues.apache.org/bugzilla/ )より
© Hitachi Solutions, Ltd. 2010. All rights reserved.
43
バグ情報の見方
毎月バグ一覧を見ていると…
「修正されたバグ」を分類
•ドキュメントバグ
機能変更に伴う変更漏れ
単なるTypo
•コンパイルできない
特定のOSや環境、コンパイラの場合
新バージョンリリース直後に多い
•機能追加/改善
バグではないが、こうしたほうがいい
•動作上の問題解決
動作不良発生に伴う修正
実際には起きそうもないが論理的に好ましくない
修正がたくさん…
引用: Apache Projecct Bugzilla (https://issues.apache.org/bugzilla/)より
• 本当に問題となるのは多くの場合一部のみ
• 機能名や設定情報を自身のシステムと比べてみましょう
• 設定変更で影響を受けなくできることも多くあります
修正されたバグは全てが今すぐ適用すべきものとは限りません
影響しそうなバグがあっても判断ができない場合は専門家に相談しましょう
• ユーザメーリングリストで相談
• サポートを行っている事業者
© Hitachi Solutions, Ltd. 2010. All rights reserved.
44
バグ情報取得の工夫
バグトラッキングシステムではＣＳＶ等で一覧を取得できるので再利用し
やすくすることも可能です
Apache (Bugzilla)
MySQL Bugs
検索画面も結果一覧
もバラバラ
別プロジェクトだから当然だが…
CSVでローカルDBに自動取り込み
今月Closeになったものを強調
独自フォーマットでHTML表示
引用: Apache Projecct Bugzilla (https://issues.apache.org/bugzilla/)より
ローカル
バグDB
引用: MySQL Bugs (http://bigs.mysql.org/ )より
今月のバグが一目瞭然
「とりあえずこれだけはチェックしておこうか」
© Hitachi Solutions, Ltd. 2010. All rights reserved.
45
活用例(2)統計分析
バグ情報の統計
バグ報告や修正の件数を見てみることで開発の活発さやプログラムの成
熟度の一端を知ることが出来ます
バグ報告が多いということは…
バグ報告
バグ報告
バグ報告
バグ報告
バグ報告
バグ報告
修正が多いということは…
バグ
•問題が多いかも?
バグ
バグ
バグ
バグ
バグ
バグ
バグ
•利用者も多い
•メンテナンスが
活発に行われて
いる
利用者
利用者
利用者
利用者
利用者利用者
•実際に問題が
多かった
開発者 開発者 開発者
© Hitachi Solutions, Ltd. 2010. All rights reserved.
46
統計の実例
実際にＯＳＳで毎日報告される新規バグ報告と修正されたバ
グの件数を月別に集計したものを他の情報と合わせて見てみ
ます
注意
以後の図のコメントは個人的な見解です。
プロジェクトやプログラムの客観的な評価
を示すものではありません
© Hitachi Solutions, Ltd. 2010. All rights reserved.
47
Apache HTTP 2.0のバグトラック集計
Apache 2.0.x
40
2.0.58
FIXED
2.0.61
2.0.59
35
新規報告
2.0.63
• 報告も修正もほとんどなくなってきている
• リリース間隔が非常に長く最近リリースが
ない
• 2.2に移行を考えるか…
30
25
20
15
10
5
2009.06
2009.04
2009.02
2008.12
2008.10
2008.08
2008.06
2008.04
2008.02
2007.12
2007.10
2007.08
2007.06
2007.04
2007.02
2006.12
2006.10
2006.08
2006.06
2006.04
2006.02
2005.12
0
Apache Projecct Bugzilla ( https://issues.apache.org/bugzilla/ )より集計
© Hitachi Solutions, Ltd. 2010. All rights reserved.
48
Apache HTTP 2.2のバグトラック集計
Apache 2.2.x
40
2.2.6
2.2.4
2.2.0
2.2.12
2.2.10
2.2.3
30
FIXED
2.2.9
2.2.8
2.2.2
35
新規報告
2.2.11
• 報告件数増加傾向。ユーザ増加中?
• 修正も多いが頻繁にリリースされている
• 今まさに旬?
25
20
15
10
5
2009.06
2009.04
2009.02
2008.12
2008.10
2008.08
2008.06
2008.04
2008.02
2007.12
2007.10
2007.08
2007.06
2007.04
2007.02
2006.12
2006.10
2006.08
2006.06
2006.04
2006.02
2005.12
0
Apache Projecct Bugzilla ( https://issues.apache.org/bugzilla/ )より集計
© Hitachi Solutions, Ltd. 2010. All rights reserved.
49
MySQL server 5のバグトラック集計
MySQL 5 (5.0.x, 5.1.xを含む)
200
5.０.１５GA
５.０.３３
５.０..37
5.０.18
180
160
５.０.６７
５.０.５１
５.０.51a
５.０..41
５.０..24
５.０..19
新規報告
５.０.４５
５.０..27
FIXED
５.０.７５
５.０.７７
５.０.８2
5.1.30GA
５.０.８３
５.０..20
140
５.０.８４
• 報告件数も修正件数も減少し現在は
ほぼ一定
• 定期的かつ非常に頻繁なリリース
５.０..22
120
100
80
60
40
20
2009.07
2009.05
2009.03
2009.01
2008.11
2008.09
2008.07
2008.05
2008.03
2008.01
2007.11
2007.09
2007.07
2007.05
2007.03
2007.01
2006.11
2006.09
2006.07
2006.05
2006.03
2006.01
2005.11
0
MySQL Bugs ( http://bugs.mysql.org/ )より集計
© Hitachi Solutions, Ltd. 2010. All rights reserved.
50
まとめ
• バグ情報は開発者にとって非常に重要なものです
• OSSではバグ情報管理も公開されています
• 利用者にとっては問題発生時の調査情報源となります
• 個別のバグ情報以外にも活用方法があります
• 運用上の障害予防に活用することができます
• バージョンの選択、バージョンアップ時期の目安など運用に役
立てることもできます
• 使用しているＯＳＳの現状を理解するための重要な情報源の
一つとなります
バグ情報も活用してＯＳＳを効果的に利用しましょう
© Hitachi Solutions, Ltd. 2010. All rights reserved.
51