InfoQはAPIエバンジェリストとして著名なKin Lane氏に，オープンAPIデザインに対する氏の見解と，昨年11月にSteven Wilmott氏と共同でローンチしたAPI Commonsイニシアティブに関する動機について質問した。
自らの行動に対して肯定的な反応を得た氏は，APIデザインのオープンソース化や，すべてのAPIデザイナが利用可能な共通パターンを作り上げることの重要性への確信をさらに強めたようだ。
氏が指摘したのは，新たに登場したAPI記述言語の相互変換と相互運用性に関する問題の所在である。さらに，UDDIなど過去のイニシアティブが犯した過ちをAPI Commonが繰り返すことを防ぐために，オープンなインターネット文化が果たす役割について説明する。
InfoQ: Kinさん，こんにちは。まずは簡単に自己紹介をお願いできますでしょうか。また，昨年11月に"API Commons"をローンチされましたが，その経緯についてもご説明ください。
私はAPIエバンジェリストです。特定のAPIではなく，API全般を対象にしています。すべてのビジネスセクタや政府機関を対象としたAPIの営業的，政治的側面からの解析結果を，"API Evangelist"ブログを通じて公開しています。
3ScaleのSteven Wilmott氏とは昨年の秋，何回も打ち合わせを重ねました。その後，私は簡単な記事を書き，それがEFFによってOracle対Googleの訴訟に提出されることになりました。私たちは２人とも，API提供者がAPIデザインを公開する場所があってしかるべきだと考えていました。API Blueprint，RAML，Swaggerなど最新のAPI定義フォーマットを使って定義されたAPIデザインに対して，著作権としてCreative Commonsライセンスを選択するという，自分たちのスタンスを明確に打ち出す場所が必要だと思ったのです。
今日における最良のAPIパターンを再利用するためにも，APIデザインはオープンライセンスを維持すべきである，と私たちは強く感じています。人は自分が見たものを模倣しようとする傾向があります。共通パターンが存在しないとなれば，API提供者は，毎回同じことを繰り返さなければなりません。2014年中にはカレンダやディレクトリ，イメージ，ビデオといった，個人用アプリやビジネスアプリが日常的に依存するリソースに対して，共通的なAPIパターンを確立する必要があるでしょう。
InfoQ: 今回のローンチは，API開発者のコミュニティや業界一般からはどのように受け入れられたのでしょうか。またそこから，どのようなことを学びましたか？
ローンチは非常に好意的に受け入れられました。反応の大部分は肯定的なものでした。業界のごく一部には，正しいアプローチではないという意見もありましたが，時間が経つにつれて彼らも認めてくれました。結果として，それが重要な理由についての議論が，オンラインでも，あるいはAPI Strategy & PracticeやAPI Days，Glueconといったイベントにおいても続けられているのが現状です。
私たちが学んだのは，APIデザインに対する多様なアプローチ，選択可能な複数のフォーマット，単なるAPIの定義に留まらず，共有可能な形で公開したいと考えるさまざまなモチベーション，といった問題に対して，もっと多くの意見交換や教育の場が必要だ，ということです。
API Commonsは一夜にして成るものではありません。API界の多くのリーダたちによる努力が必要です。API Commonsの当初のビジョンを実現するには，まだ何年も必要でしょう。
InfoQ: API提供者がAPIの定義をシェアしたいと考える，そのインセンティブは何なのでしょう？競争相手がAPIを再実装できるようになって，自分たちのアドバンテージが失われる，という心配はないのでしょうか？
APIを公開したということは，すでにそのような状況に足を踏み入れているのです。APIデザインをリバースエンジニアして再利用することは，誰にでも可能です。プロバイダとしての立場を取らず，自分のデザインに誇りを持って，マシン可読な形式で公開する，ただし目的にあったオープンライセンスを添付してコントロール権は保持する，という方法が必要でしょう。
API定義は秘密のソースではなく，実装を支えるリソースなのです。あなたの知らないところでデザインを流用されるよりも，デザインを通じたパートナーシップ構築と再利用を奨励して，それらを自ら先導するようなスタンスを選択する方が望ましいことでしょう。もしかしたらすでに誰かがAPIデザインを拝借，再利用していて，単にそれを公に話していないだけかも知れません。
このようなやり取りはオープンな場所で行って，この領域のベストパターンを並べ上げた上で話し合うという，オープンソースソフトウェアで実績のある方法で進めていくべきだと思います。
InfoQ: OracleとGoogleの間では，AndroidのJava API実装を巡る法的闘争が行われている真っ最中です。APIの著作権や"フェアユース"の実践に関して，このケースからどのようなことが分かるのでしょうか？
Javaの件は，重要性を持ったインターフェースを巡って，業界とコミュニティで起こり得ることの好例です。FlickrやYouTube，Facebook，Instagram，TwitterなどのAPIを通じた写真やビデオ，決済や広告など多くのセグメントでも，これと同じようなことが見られます。
EFFの職務の一環として行った調査から，最近10年間で起きたインターネットにおける２つの主要なムーブメントであるソーシャルとクラウドにおいて，APIの再利用がいかに基本的なものであるか，ということが分かりました。どちらの領域も， 2014年の私たちの生き方やビジネスの進め方を変えています。ここではAPIの再利用が重要な役割を果たしています。最良のAPIデザインパターンがOracleのような企業にロックアップされることを許すならば，私たちはすべてを失うことになるでしょう。
InfoQ: あなたはAPI Commonsに登録するAPIのライセンスとして，Creative Commonsの採用を提唱していますね。API定義をSwaggerのようなソースコード形式で定義することを考えると，オープンソースライセンスのサポートも考慮する必要があるのではないでしょうか？
ライセンス形式は，どのようなものでも構わないと思っています。 私たちがCreative Commonsを選択したのは，直近のニーズに対して，これまで見たものの中で一番よかったからです。同じものを作り直す必要はありませんから。私たちはどのようなAPI定義やライセンスモデルでも歓迎します。APIを公開して，希望するライセンスを添付さえすれば，それでCommonsの一員なのです。
InfoQ: API Commonsのレジストリには，APIに関するライセンス情報と外部の定義ファイルへのポインタが格納されているだけですが，今後何年間にわたってこれらの定義が有効であることは，どうやって保証するのでしょう？
何年にもわたって保証できるとは思っていません。ですが，共通の場所でこれらの情報をオープンにしておくことは，APIライセンスや定義フォーマットの今後の展開に関して議論を進めるためには，非常に重要だと思います。
APIに関して絶対的なものは何もなく，すべてが急速に変化しています。それに対処する最善の方法は，共通の場所に配置して，APIを説明する共通の言語の確立を目指し，さらにAPIエコノミ全体に対してもっとも望ましい方法でライセンスすることです。
InfoQ: 既存のイニシアティブ(RAML, Blueprint, Swagger, WADLなど)を統一する共通API言語が，将来的に必要になると思いますか？API Commonsは，そのような活動を先導し，サポートしようとしているのでしょうか？
API全体を進化させ，APIデザインプラットフォーム間のコラボレーションを促進するには，各フォーマットの相互変換や相互運用性が必要になるだろうと思います。“統一”が必要になるとは思いません。それぞれの違いはそれぞれの強みになるでしょうし，完璧な変換というのはあり得ないからです。API Commonsは特定の言語やフォーマットを呼びかけることはしませんが，共同作業するグループを提案することはあるでしょう。
InfoQ: API Commonsのビジョンは，2000年頃のオンラインコンポーネントライブラリやUDDIレジストリなど，従来のソフトウェア再利用活動のビジョンとどのように違うのでしょうか。それらの活動が失敗した轍を踏まないためには，何が必要だと思われますか？
APIディレクトリはAPI Commonsの活動の副産物であって，それ自体が目標ではありません。API CommonsではAPI定義の公開と共有を重視して，全体としてのコラボレーションと最良のAPIデザインパターンの再利用を奨励しています。同時に，APIの著作権を重要な要件として - 健全なAPIエコノミに不可欠なものとして，中心的なテーマとしています。
API Commonsは，APIの空間における最良のパターンを共有するための，外部に向けて公開された，オープンなアプローチです。これまでの活動が純粋に技術的なものであったり，ビジネス上の目的で実施されたりしていたのに対して，API Commonsは，私たちがオープンなインターネットにおけるオープンソースソフトウェアから学び，クラウドコンピューティングを通じてスケールする分散型のソーシャルアプリケーション開発を進めてきた，その肯定的な要素を反映しています。
InfoQ: ローンチ以来，API Commonsのプラットフォームにはどのような機能が追加されたのでしょうか，また次は何を構築する予定ですか？
もっとも新しく追加されたのはAPIです。APIの送信と，Commons内のAPI定義の検索が可能になりました。次の開発としては，さらにAPIエンドポイントや統合ツールを追加して，Commonsへの公開をAPIの設計開発プラットフォームのデフォルトにしたいと思っています。
InfoQ: Kinさん，ご回答ありがとうございました。最後にひとつ質問があります。CommonsへのAPI公開は当然のこととして，それ以外の方法でAPI関係の開発者が貢献するにはどうすればよいでしょうか？
APIやその設計，導入とその影響についてのストーリ，開発者ではなくエンドユーザに関わるストーリを作り上げてほしいと思います。ユーザに共感されるストーリを作り上げて，APIが生み出す価値について説明してくれれば，その他の人たちがストーリを語り継いでくれるでしょう。これによって公的，私的を問わず，APIによるもっとも大きなインパクトを創出することができます。ですからどうか，ストーリを語ってください。