【コラム】オープンソースとオープン標準の統合を再評価しよう

編集部注：本稿の著者Guy Martin（ガイ・マーティン）氏は、世界で最も尊敬されている非営利標準化団体の1つOASIS Openの事務局長。ソフトウェアエンジニアおよびオープンソースストラテジストとして25年以上の経験をOASIS Openにもたらした。

ーーー

この世には解決すべき大きな問題があるが、是が非でも必要なのはオープンソース（open source）コミュニティとオープン標準（open standard）コミュニティの提携だ。

2020年の厳しい現実からの例を挙げよう。米国は2020年、およそ6万件におよぶ山火事が発生し、1000万エーカー（約4万500平方キロメートル）以上が焼き尽くされ、9500棟以上の家屋が全焼して、43人の命が失われた。

私は10年間カリフォルニア州でボランティアの消防士をしており、消防士が効果的かつ迅速にセーフティクリティカルな情報をやり取りできる技術の決定的な重要性をじかに感じた。通常は複数の消防機関が火事現場に向かうのだが、それぞれさまざまなメーカーのラジオを携帯している。これらのラジオは専用ソフトウェアで周波数が設定されているので、チームがお互いにコミュニケーションを図れるようにするには、ラジオを再プログラミングする必要が生じる。このプロセスは不必要な遅延を生み、命を危険にさらす可能性もある。

すべてのラジオメーカーが標準に沿ったオープンソースの実装を採用すれば、ラジオはすぐに同じ周波数に調整できるだろう。ラジオメーカーは時間の無駄になる障壁ではなく、貴重な人命救助ツールを提供でき、そうしたソフトウェアの開発コストを共有できる。この状況では、他の多くの場合と同様に、独自の無線プログラミングソフトウェアから得られる競合上の利点や標準化によって得られる多くの貴重な利点はない。

一貫した標準とそれに相応するオープンソースの実装による利点は、山火事などのセーフティクリティカルな状況に特化したものではない。標準とオープンソースのより良い統合から多大なメリットを得られる分野は数多く存在する。

オープンソースとオープン標準の違い

「オープンソース」とは公的にアクセスでき、誰もが自由に使用、変更、共有できるソフトウェアを指す。またオープンなアイデアの交換、オープンな参加、ラピッドプロトタイピング、オープンなガバナンスと透明性を備えた、共同的なコミュニティ指向のソフトウェア開発哲学を指す。

それとは対照に「標準（standard）」という言葉は、取り決められた機能の定義を指す。要件、仕様、ガイドラインにより、製品やサービス、システムが品質、安全性、効率性を実現する相互運用可能な方法で実行されるようにする。

標準を制定し、管理するための組織は数多く存在する。例えば国際標準化機構（International Organization for Standardization、ISO）、欧州電気通信標準化機構（European Telecommunications Standards Institute、ETSI）、ワールドワイド・ウェブ・コンソーシアム（World Wide Web Consortium、W3C）がある。OASIS Open（OASISオープン）もこのカテゴリーに属する。標準はオープンかつ公平で透明性の高い組織が指導する、合意形成プロセスを介して開発される場合「オープン」となる。ほとんどの人は標準作成プロセスは慎重かつ計画的であり、妥協を通じた合意を得て、長期的な仕様と技術的な境界に達していることに同意するだろう。

合意点について

オープンソースとオープン標準は明らかに異なるが、これらのコミュニティの目的は同じ「相互運用性、イノベーション、選択」だ。主な違いは目標の達成方法で、私がここで主に言及するのは、文化とペースについてだ。

IBMフェローであり、Open Technology（オープンテクノロジー）のCTOであるChris Ferris（クリス・フェリス）氏は、標準化機構では、物事を遅くすることが重要だと考えているように見えることが多いと話してくれた。時には正当な理由がある場合もあるだろうが、競合によって出し抜かれているようにも見える。オープンソースの場合は、より共同的で、論争や競合は少なく見える。だかこれは同じ分野で取り組まれる競合的なプロジェクトがないということではない。

ペースに影響を及ぼすもう1つの文化的特徴として、オープンソースはコードの記述に関するもので、標準化機構は散文の記述に関するものである。長期的な相互運用可能性に関しては言葉がコードを上回るため、標準の文化は標準を定義する散文を作成することからさらに計画的で考え込まれたものである。標準は技術的に静的ではないが、標準における意図は、長期的に重大な変更をせずに機能することに到達することだ。逆にオープンソースコミュニティでは反復的な考え方でコードを記述し、コードは基本的に継続的な進化の状態にある。この2つの文化はコミュニティが協調的に動こうとすると、衝突することがある。

もしそうなら、どうして調和しようとするのであろうか？

オープンソースとオープン標準の協調により、イノベーションに拍車がかかる

インターネットはオープンソースコミュニティとオープン標準コミュニティ間の調和により達成できることの最適な例だ。インターネットがARPANET（アーパネット）として始まったとき、TCP/IPより前の一般的な共有通信標準に依存していた。時間の経過、標準、オープンソースの実装とともに、TCP/IP、HTTP、NTP、XML、SAML、JSONなどが採用され、災害警報（OASIS CAP）や標準化されたグローバル取引インボイス（OASIS UBL）などのオープン標準とコードで実装される、主要グローバルシステムが作成できるようになった。

インターネットは完全に世界を変えた。オープン標準コミュニティとオープンソースコミュニティ間の協調精神を活性化できるのであれば、今後もこのレベルの技術的イノベーションや変化を遂げられる力はあるだろう。

調和と統合の自然な道を見つける

現在、リポジトリにはすべての重要なオープンソースプロジェクトがあり、そのソフトウェアの長期的な運用可能性を実現するには関連する標準で協力する機会が数多くある。OASIS Openのミッションの一部は、そのようなオープンソースプロジェクトを特定し、共同的な環境と、困難なプロセスにならずに標準が作成できるすべての足場を提供することである。

フェリス氏はこの統合への道の成長の必要性についても話してくれた。例えば、この必要性はアジアで技術を使用したい場合に顕著である。国際標準がなければ、アジアの企業は話も聞かないだろう。欧州共同体も標準に対して強い選好を主張しているように見える。これは確実にエコシステムで手強い相手と応戦できるオープンソースプロジェクトの推進力になる。

オープンソースプロジェクトがそれ自体よりも大きくなる場合も、統合の必要性が増していることが認識できる。つまりオープンソースプロジェクトが他のさまざまなシステムに影響を及ぼし始め、そうしたシステム間で調整が必要になる場合である。例えば遠隔測定データの標準がある。遠隔測定データは現在、可観測性からセキュリティまでさまざまな目的で使用されている。ソフトウェア部品表（SBOM）もまた別の例として挙げられる。ソフトウェアの出所を追跡する課題に対処するためにオープンソースの世界でなんらかのことが行われていることは分かっているが、これは成功するためには標準が必要になるまた別のケースだ。

チームとしての協力が必須

幸いなことに、オープンソースコミュニティとオープン標準コミュニティの最終的な目標は同じ「相互運用性、イノベーション、選択」だ。またインターネットからTopology and Orchestration Specification for Cloud Applications（TOSCA）などに至るまで、提携すべき方法とその理由は見事に証明されている。さらに主な利害関係者は特定のオープンソースプロジェクトでは戦略的な長期的観点が必要で、それには標準が含まれることを支持し、認識している。

これはチームとして協力する上で大切な開始点であり、各団体は進んでお互いや利害関係者と協力するときが来ている。

カテゴリー：その他

タグ：オープンソース、オープン標準、コラム

画像クレジット：David Malan / Getty Images

［原文へ］

（文：Guy Martin、翻訳：Dragonfly）