企業のオープンソースコンポーネント利用を正しく管理するサービス（スタートアップ）が必要
編集者注記: このゲスト記事を書いたJason van Zylは、Apache Mavenプロジェクト、Plexus IoCフレームワーク、そしてApache Velocityプロジェクトのファウンダだ。彼はまた、オープンソースプロジェクトのためのインキュベータとして広く尊敬されているCodehausの創設を支援した。現在の彼はEclipse Foundationの理事でSonatypeのCTOだ。Twitter上では、@jvanzylで彼に到達できる。
今日のソフトウェアが昔と大きく異なることは、誰もが知っている。今ではソフトウェアはクラウドから提供されることが多く、ソーシャルな機能があり、使用するデバイスのタイプを問わず誰もがどこにいても使える。しかしわれわれの多くが気がつかないのは、違いが表面だけではないことだ。今日のソフトウェアは、その作られ方と配布のされ方が、昔とはまったく違う。
今日のソフトウェアアプリケーションはその多くが、ソフトウェアコンポーネントを組み合わせて作られる。コンポーネントはその多くがオープンソースであり、最終製品を作る企業や組織の外からやってくる。典型的なJavaアプリケーションの80%以上が、今日では公開の場で入手できるオープンソースのコンポーネントやフレームワークから組み立てられている。これは、組織内部の技術者が一行々々そのソフトウェアのコードを書いていた過去との、劇的な決別だ。ソフトウェア制作のこの新しい工程により、デベロッパの行動がはるかに機敏になり、製品の配布が連続的持続的になり、そしてスクラッチでコードを書くのはそれが絶対的に必要な場合だけになってきた。企業にとってこのことは、製品を短期間かつ低コストで市場に出せることを意味する。
プログラマのためのコード共有とソーシャルネットワーキングサイトであるGitHubが、Andreessen-Horowitzから1億ドルという歴史に残る額の投資を得たことは、協力的でオープンソースな開発が今いかに人気があるかを物語っている。GitHubなどのリポジトリはオープンソース開発を民主化し、若いプロジェクトを育て、活気に満ち協力的で非中央集権的なコミュニティを育（はぐく）んでいる。そしてそれらのコミュニティが、かつてなかったほどに大量のソフトウェアを、かつてなかったほど短期間で作っている。
つまりGitHubはソフトウェアのプロデューサ、すなわちコンポーネントを作るデベロッパを助けている。しかし、それらのコンポーネントの消費者、すなわちオープンソースのコンポーネントを使ってアプリケーションを構築しているエンドユーザデベロッパや組織はどうか？ コードが完成して大量採用が可能になると、プロジェクトのチームはその最終製品をたとえば中央的リポジトリ(Central Repository, セントラルリポジトリ)から配布する。その無料で誰にでも利用できるクラウド上のリポジトリでデベロッパたちは、自分のソフトウェアを世界の何百万ものユーザに配布する。SonatypeのCentral Repositoryは急速に、オープンソースコンポーネントの保存庫として愛用されるようになり、今では6万の企業/組織からの年間75億以上のリクエストに応じ、40万あまりのコンポーネントの住処（すみか）になっている。私の会社であるSonatypeが運用しているそのCentral Repositoryは、コミュニティに奉仕し、ソフトウェアデベロッパたちが自分たちの消費するコンポーネントをより良く利用できるための、製品や情報サービスを製作提供している。
なぜソフトウェアは車に似ているのか、そしてそのことの意味は？
今日のソフトウェアは迅速に組み立てられるが、そこには車のメーカーにも似た複雑な“サプライチェーン”が存在する。車と同じく最終製品（アプリケーション）には、何十何百もの供給源からの、何十万もの外部コンポーネントが含まれている。これらのコンポーネントの一つ一つに独自のライフサイクルがあり、独自のバグフィクスや機能強化が行われ、独自の潜在的リスクを抱える。
車と同じく、一つのコンポーネントの欠陥がユーザにとって重大な問題をもたらすことがある。最悪の場合には、それらの問題がセキュリティの破綻やデータのリーク、あるいは安定性やパフォーマンスの問題に導き、知財関連の法的問題に結びついたりもする。
すなわちわれわれが仕事の基盤として日常使っているアプリケーションの多くが、企業にリスクをもたらしかねないコンポーネントを使って構築されている。
この問題がいちばん分かりやすいのは、セキュリティの領域だろう。Aspect Securityによる最近の分析によると、Central Repositoryでもっとも頻繁に利用されているオープンソースコンポーネントの多くが、セキュリティの脆弱性を抱えている。
[ダウンロード数: 縦軸目盛りの幅は対数的量]
コンポーネントの欠陥は不幸なアイロニーを抱えており、それが修復された場合でもユーザの企業はそのこと（欠陥がある・あったこと、それが修復されたこと）を知らない場合が多い。ひとつのアプリケーションに使われているコンポーネントは、それらの起源がきわめて多様で、しかもバージョンの更改が1年に何度も行われる。エンドユーザがそれらに対応していくことは、非常に難しい。
コンポーネントの正しいメンテナンス手法とは？
ソフトウェアのコンポーネントは、企業のそのほかの資産と同じく、“管理”が必要である。分析と監視と評価を定常的に行い、最高品質で最低リスクのコンポーネントだけでアプリケーションが構成されている状態を確保する必要がある。今日ではそれを、Component Lifecycle Management（CLM, コンポーネントライフサイクル管理）という手法により、比較的容易に達成できる。それは、デベロッパが自分たちのアプリケーションのバックボーンとなるコンポーネントを選び、使用し、監視する作業を支援する新しい方式であり、考え方だ。
CLMはまず、それによってデベロッパが最良のコンポーネントを選べるようにし、さらにその後の開発工程においては個々のコンポーネントの持続的な監視や評価を容易にし、また完成〜引き渡し後にはバージョン更改やバグフィクス、セキュリティ問題の露呈などを常時看視していく。それにより、これまでは暗闇のトンネルをひたすら盲目状態で歩んでいたエンドユーザのコンポーネント利用に、光が当たるようになる。
ソフトウェアの開発ライフサイクルにおいてオープンソースコンポーネントの利用を正しく管理することにより、可能な限り最良のアプリケーションを構築し配布することができるようになる。正しい管理の下では、使われるコンポーネントのすべてが、堅牢で安全でしかも最新である。デベロッパにもエンドユーザにも心の安寧がもたらされ、イノベーションに取り組む十分な余力が生まれる。だからそれは、今日のソフトウェア開発と利用における緊要の課題なのだ。
〔余計な訳注: CLM(Component Lifecycle Management)はまだGoogleにもWikipediaにも有意に引っかからない新語のようだ（Googleでは“千葉ロッテマリーンズ”が浮上する）。手がかり的なサイトとしては、これ、これ、これなど。〕
近日開催のイベント
