David Sugar、GNU Bayonneを語る
NewsForge：Bayonneプロジェクトとは何か、簡単にお聞かせください。
David Sugar：音声やタッチトーンキーパッドを使い、電話網経由で人間と対話するアプリケーション――Bayonneはそういうアプリケーションの作成・配備プラットフォームとして始まりました。ですから、テレフォニーアプリケーションを書くための独自スクリプト言語を持っていて、これは、きわめて高度のポートキャパシティを要求するソリューションでも使えるように設計されています。それに、PerlやPythonなど、よく使われているスクリプト言語をテレフォニー対応にする機能も持っています。
NF：プロジェクト名”Bayonne”の由来は？
DS：もともと音声メールシステムとして世に出そうという考えがあって、大昔はUniversal Messenger Daemon（汎用メッセンジャデーモン）と呼んでいました。メインサービスデーモンがumdという名前だったのは、その名残です。1999年の初リリース時にはACSという名前でした。Adjunct Communication Server（通信補助サーバ）の略です。ところが、ACSというのは、”Al’s Circuit Simulator”という汎用回路シミュレータの名前として広く定着していたようで、苦情の電子メールが殺到しました。
そこで新しい名前を考える必要に迫られ、「コンピュータテレフォニーは橋だ」というメタファを思いつきました。いくつも考えましたよ。ブルックリン橋……いろんな含みのある名前ですよね。それからゴールデンゲート橋……でも、いろんなプロジェクトがもうその名前を使っていました。タコマ橋も考えましたが、なにしろ風で崩落したいわくつきの橋ですからね、まあ、あの州のプロプライエタリベンダにでも使ってもらうのがいいかと思いまして。で、一時、Bayonneという町の3番通り、Bayonne橋のちょうど影になる辺りに住んでいたことを思い出しまして……。
NF：プロジェクト発足の経緯、その後の足取り、ご自身とプロジェクトのかかわりなど、お話しいただけますか。
DS：いろいろと複雑です。まず、Open Source Telecom社という、GNU/Linuxベースのネットワークアプライアンスのベンダがありました。1998年、私がDBSサーバをあれこれいじっていたとき、この会社のCEOから声がかかって、音声メッセージング用のテレフォニーアプライアンスを開発するなら資金を出すと言われました。当時、私にはすでにコンピュータテレフォニーについて1つのアイデアがありました。音声アプリケーションサーバをフリーライセンスのソフトウェアとして開発し、いろいろなアプリケーションに変形して使ってもらう、という……。音声メッセージングも、もちろん含まれます。でも、開発を応援してくれるスポンサーが現れるなんて、夢にも思っていませんでした。
そこへ資金提供の約束でしたし、これ（とその他の製品）を作るための会社を1人で立ち上げるなんて、ちょっと手に余る仕事でしたし、だからコミュニティの知人を呼び集めて――Rich Bodoとかね――OSTを作りました。
初期の開発作業がほとんど終わりかけた頃、なんだかスポンサーの腰が引けはじめました。でも、まだ1999年で、シリコンバレーにはベンチャキャピタルの存在が濃かったですし、新しいスポンサー探しはそんなに難しくなかろうと思っていました。いま振り返れば、バブル崩壊の直前だったわけですけど……。
そういうわけで、私たちはCTIハードウェアを購入し、そこへACS（後のBayonne）をインストールして、アプリケーションサポート込みで、ターンキーとして再販売するという事業計画を立てました。当時のCTIハードウェアは高価で、商談を1つまとめるたびに、まずどこかから2万ドル調達してくる必要がありました。それでハードウェアを買い、お客さんにもっと高額で引き取ってもらうわけですが、引渡しと同時に支払ってもらえるわけじゃなくて、お金になるのは、カスタムアプリケーションが完成し、受け入れてもらえてからです。
そういう状況で、しかも、もともと文無しで事業を始めたわけですから、この時期は売掛金回収の悪夢でしたね。ときには、売掛金を回収できるまでクレジットカードで乗り切ったり、事業を存続させるためにありとあらゆる手段を講じました。ところがですよ、不幸なことに、税務署の目から見ると私たちは儲かっているんですよ――帳簿上は。現実は、いつも貧乏暮らしでしたけど。
初期の資金注入さえあったら、これでよかったのかもしれません。最初にある程度の資金があれば、ハードウェアの購入にも無理がなかったわけですし、引き渡して、受け入れてもらえれば、入ってくる金額は大きかったですから。でも、実際は、私たちが販売を開始した直後にバブルがはじけて、もうスポンサー探しなどジョークになりました。やがて、ハードウェアを買う資金も集められなくなり、となれば新しい顧客探しもできず、税務署には大きな借りができて、OSTは、結局、昨年畳みました。
Richは、いま、Telephonyware社という会社をやっています。テレフォニーハードウェアをカスタマイズなしで再販売するという、伝統的な商売が中心です。ほとんどがVoIP電話みたいな、小型の一般品のようです。仕入れやすいし、お客さんの気が急に変わっても、ほかに転売できますしね。物がカスタムCTIサーバで、2万ドル分ものT1カードを搭載しいるとなったらそうはいきませんけど。
Bayonneの設計は、90年代初期にもうできていました。たぶん、DBSサーバをリリースする以前にもう……。他の業界と違って、テレフォニーは当時からサービス指向の商売でした。何万というVARやインテグレータがひしめいていて、「これ一発で誰の面倒でも見ます」みたいなプロプライエタリソリューションを、顧客の個別ニーズに合わせようと必死でやっていましたから。通信分野でどのセグメントがにぎやかかと言えば、OEMじゃなく、こっちです。お金も活動もこっちに集中しています。だから、フリーソフトウェアも、サービスとしてのソフトウェアという商売上のアイデアも、まずここで試すのが理想的と思えました。
Bayonneアーキテクチャをコードに書くとき、私はC++で書くことにしました。保守が簡単だと思いましたから。いまでも正しい判断だったと思います。少なくとも私にとってはね。大型のFOSSプロジェクトにCでなくC++を使うというのは、当時としてはきわめてまれな試みでした。
ライブラリもいくつかに分けて、それぞれ別個に保守することにしました。その理由はですね、Bayonneに興味を持つ人はあまりいないだろうけれど、C++のスレッドやソケットフレームワーク（GNU Common C++）、RTPスタック（ccRTP）なんかに興味を示す人はたいへん多かろうと思ったからです。つまり、Bayonneそのものに参加する人は少なくても、これをいくつかの部分に分けて進めたら、もっと多くの人が参加してくれて、結果的にそういう本質的部分のコードの品質があっというまに高まるんじゃないか、ということです。そういうライブラリは、Bayonneみたいなプロジェクトを構築するときの中核的サービスですからね、最もレベルが低くて、最も難しい部分が広くテストされて、安定化するだろうという読みがありました。実際、あれから数年で、何百という人がGNU Common C++に触れたわけですから、正しい読みだったと言っていいんじゃないでしょうか。
2003年と2004年はOSTが難しい局面にあった時期で、私がBayonneに振り向けられる時間が減りました。とくに、2004年には入院騒ぎなんかもありましたし……。その後も、いろいろとほかのことで忙しくて、その間、将来リリースの面倒を見てくれると思っていた人が、やってくれなかったり。
今年の5月になって、突然、自由にできる時間が増えまして、それに合わせるように、昔からプロジェクトに参加してくれていた何人かの人が、今後どうすべきかについていろいろなアイデアを持ち寄ってくれました。で、あれこれ検討した結果、サーバ全体を書き直すというラディカルなアプローチがよかろうということになりました。コードを徹底的に単純化して、将来の保守を容易にしようということです。私からもコアライブラリというアイデアを提案しました。ほかのプロジェクトでも使えるようにして、Bayonneのドライバや中核的なコール処理にアクセスしてもらおうという魂胆です。
非常に大規模な書き直しでしたが、作業は6月中に急速に進んで、Bayonne 2の中核的機能とアーキテクチャはとても安定しています。今月末にリリース1.0を出したら、私はまたTycho Softworksをオープンするかもしれません。Bayonne 2を商業的にサポートすることはもちろんですが、まだ世界中で稼動しているリリース（Bayonne 1の1.2.15）もサポートしないといけません。でも、どんな形であれ、ハードウェアの再販売はもうする気がありません。
NF：サイトを拝見すると、Bayonne 2はテストリリースだとか。「安定版」まであとどれくらいと考えたらよいですか。安定版と見なせないのはどこに原因があるのでしょう。機能か、安定性か、もう少しテストしたいということなのか……。
DS：Bayonne 2は、部分的にはきわめて安定しています。中核部分のアーキテクチャ、libexec実行モジュール、基本的なIVRスクリプト言語機能……すべてです。とりあえずこの中核的機能を中心にしてBayonne 2リリース1.0を出し、並行してBayonne 2のさらなる改善を目指そうという考えもありました。
過去には、ほかのいくつかのプロジェクト同様、私たちも安定機能と実験的機能をCVS HEADにごちゃ混ぜにし、その混乱の中から自然に安定リリースが生まれてくるだろうと期待したこともありました。実際、プロジェクトが成熟すると、そういうことも起こります。とくに、明確に限定された機能ドメインがあって、ある時点でその機能ドメインが達成され、新しい実験的機能の追加もなければ、そこで既存の中核的機能は完成したと見なされます。私たちの場合も、サポート用のライブラリパッケージでは、それがすでに起こっています。
いま、現在の開発ツリーから贅肉を少し削ぎ落として、真に安定した機能セットを作ろうかと思っています。そして基本となるリリースを出して、それを厳密に管理された環境で別個に保守したらどうかな、と。この方法が成功したら、同様のやり方で将来のBayonne 2リリース（たとえば、2.0）につなげられると思うのですが……。
NF：GNU Alexandriaプロジェクトについて一言いただけますか。それがBayonneをどう利用するか、など。
DS：GNU Alexandriaは、”Daisy”というXML方言をBayonneサーバに解析させようというアイデアから生まれました。Daisyは、デジタル録音図書の出版用に考えられた新しい標準、目の不自由な人でも電子的に読めるドキュメントを作成するための標準です。非プロプライエタリなXMLドキュメントにマルチメディアコンテンツを埋め込むという点で、XML SIMPLに最も近いと思います。もっとも、Microsoft社に言わせると、そんなものは存在しないらしいですが……。
米国視覚障害者協会の後押しで、連邦レベルの業者が概念の草案をまとめて、米国メディケアサービスでフィールドテストしました。それで、タッチトーン電話を使い、メディケア制度関連のドキュメントを朗読し、案内するという電話サービスができました。これが数年前のことです。このサービスでは、PythonアプリケーションでDaisy XMLを解析していまして、そのPythonアプリケーションを動かしていたのがBayonneです。
この種のアプリケーションの扱いでは、Bayonne 2のほうがずっとすぐれていますよ。というのは、サーバの頭をはねても平気だからです。XMLパーサで直接libbayonneを使えます。つまり、libbayonneの上に新しいXMLサーバを据えれば、Daisyを直接解析できるということです。いろいろな言語で書かれたいくつものコンポーネントを繋ぎ合わせ、ようやく解析できるというのとは大違いです。ですから、私がGNU Alexandriaでやりたいことは、libbayonneのてっぺんにすわり、Daisyを直接解析できるサーバの提供です。それと、Daisyコンテンツを操作するためのスタンドアロンツールですね。
NF：テレフォニー以外に、Bayonneが適しているサービスというと何でしょうか。
DS：OSIPを保守しているAymericから、ビデオメールやビデオ音声メールというアイデアが出ています。私はRTSPを考えていました。インターネット交換機ができるのではないでしょうか。コールを受けて、それをストリーミングコンテンツとして再ブロードキャストする……。インターネットラジオやIPTVなどのアプリケーションにも働き場所がありそうです。
NF：テレフォニーハードウェア以外に、たとえばサウンドカードのようなPCハードウェアをBayonneでサポートすることはどうでしょう。
DS：ローカルPCのサウンドカードがあれば、とくに［ユーザが］コンピュータテレフォニーハードウェアを買って、セットアップしなくても、Bayonneを使ってテレフォニーアプリケーションのテストや開発ができます。Bayonne 2では、SIPとH.323も提供されますから、VoIP電話網でも使用できます。GnomeMeetingやLinphoneを使ってのアプリケーション開発やテストもできます。
NF：Bayonneの将来リリースに予定されている機能にはどんなものがありますか。
DS：交換サポート、イベントキューイング、オーディオピアリングは、もうBayonne 2で書き直されています。その延長上に、サービスバインディングの作成があります。Bayonneサーバを交換機として使い、コールを直接ルーティングするというアイデアです。音声アプリケーションの処理はもちろんですが、ゲートウェイとしてPSTNとVoIPの相互接続にもできるでしょう。そのための作業はすでに始まっていて、Bayonne 2で活発に開発されています。ですが、ごく近い将来にリリース1.0の安定部分を抽出して、安定版を出すことになると、そこにはこれらのサービスは含まれません。
もう1つ、重要な開発分野として、私はBayonneアプリケーションライブラリというものを考えています。これは、スクリプトマクロ群を提供して、既存の他FOSSアプリケーションから機能を簡単に呼べるようにしようというライブラリです。たとえば、SQL-Ledgerと連動するアプリケーションを作っていて、電話をかける人が注文番号を探せるようにしたいとしたらどうでしょう。あるいは音声メッセージを、PHPグループウェアのWebフォーム電子メールドキュメントとして送りたいとしたら？ こうした機能を実現することこそ、Bayonneアプリケーションライブラリに期待できることだと思います。
最後に、libbayonneを使うXMLサービスであれば、いかなる形式のサービスにも関心があります。GNU Alexandriaもその1つです。ほかにも、libbayonneとOpenVXIを結合したVoice XMLサーバなども考えられるのではないでしょうか。
原文
