Marina Novikova: 　学歴をお聞きしてもよろしいですか?　また、これまで働いた中でどこが一番気に入っていましたか?

Jim Starkey: 私がコンピュータに関わり合うようになったのはちょうど高校生になった頃のことでした。地方の大学は政府から補助金をもらって、高校の生徒達にFORTRANを教えていたのです。一番最初にパンチカード（ググッてみてね）を打ったときは、曲がってしまったことを覚えています。最初に触れたコンピュータはIBMの7040だったのですが、とても大きな部屋を専有するくらいばかでかくて、そのくせメモリは全部で32Kバイトしかなかったのです。翌年私は15歳になったのですが、その時に最初のコンピュータ言語をデザインしました。その言語は機械語とアセンブラをまねしたものでした。それ以来ずっとコンピュータと関わり続けています。　私の学位は、実は純粋数学に関するものなんです。私の公式のコンピュータ・サイエンスに関するバックグラウンドは、たった一つの特別プロジェクトコース に関するものだけです。　私の最初の「本当」のコンピュータに関する仕事は、 インターネットの先駆けであるARPAnet のためのデータベースマシンを作り上げるためのプロジェクトに関する調査でした。それは、アメリカ・コンピュータ社( 7人の有名人による会社 ) で行われました。そこにいた間、Codd博士のリレーショナル・データベースに関する初期の論文に出会ったのです。リレーショナル・データベース理論は、ばかげたほどアカデミックな言葉によって論じられていましたが、いったんその姿を現すと、じつに純粋で、単純で、エレガントだということがよくわかりました。そんなわけで、コンピュータが最初に私にとりついて、2番目はリレーショナルデータベースだったというわけなんです。 　私の第 二 の「本当」の仕事はDECでのものでした。DECはとても働きやすいところでした。それは、もうほとんど無政府状態といったほうがいいでしょうね。私は、 Datatrieve と呼ばれる非常に成功した製品を作り上げました。実はこれ、マネージャがばかげた政治的な策略のためにキャンセルしたんですが、それは何の意味も無かったんです。そこで私は次のような月次報告書を書き始めました「Problems：プロジェクトはキャンセルされた。これが元に戻せないのであれば、開発スケジュールに影響を及ぼすであろう」。やはり、それも何の役にも立ちませんでした。第 2 のバージョンは、予定どおりに出荷されました ( まだキャンセルされたままでしたが ) 。こんなにマネジメントが最善の努力をしているにもかかわらず成功する会社は賞賛に値しますよね。しかし、ゴードン・ベルが DEC を離れたので、私も辞める時がきたのを悟りました。

Marina Novikova: あなたは、非常に興味深いプロジェクト Netfrastructure にかかわってますね。こういえば当たっているのかわからないのですが、Netfrastructureは、 SMP に最適化された SQL ‐サーバで、Java サポートをビルド・インしたものなのでしょうか?

Jim Starkey: Netfrastructure の背景にある本質的アイデアは、コンテンツ、プレゼンテーション、それからロジックを分離することです。コンテンツは「コンテンツ・ストア」に存在しているのですが、それはJDBC に準拠したマルチユーザでSQL‐ベース、トランザクション‐ベースの「コンテンツ・ストア」なのです。我々はそれをデータベースとは呼んではいません、というのも私はデータベース・マーケットが大嫌いだからなのです。そういうわけで、それは「コンテンツ・ストア」なのです。コンテンツ・ストア、OK？プレゼンテーションは本当に気の利いたページ生成エンジンとJava仮想マシンに統合されたロジックによってハンドリングされています。全てのコンポーネントは共通のロール・ベースのセキュリティ・スキーマを共有しています。　データベース（えーと、コンテンツ・ストアね）のアーキテクチャーはInterbase/Firebirdとは根本的に異なるものです、それはコンピューティング・プラットフォームの根本的な変化を反映しているからです。私が最初のバージョンのInterbaseを設計してアポロ DN320に実装したとき、それは十分に速かったし、随分お金もかかったし、2メガバイトを使い切ったものでした。今では、地方の商店街で売っているような最も安価なマシンでさえ128MBのメモリを積んで、何百ドルかでギガバイトまで拡張することもできます。賢明な人でしたら、ギガバイトのメモリを2MBで利用するのと同じ使い方はしないでしょう。エンジンはシングルプロセスで、マルチ・スレッドに対応して、SMPに連動します。　Netfrastructureの別の側面で興味深いのは、アプリケーションのトポロジーが逆転するということです。アプリケーションはデータベース・エンジンの内部で実行されます。そう、あたかも巨大なストアド・プロシージャのようにね。JDBCメソッドの実行は半ダースの機械語なんだけど、実際にはスレッドスイッチ、コンテクスト・スイッチ、プロトコル・スタックを下っていって、プロトコル・スタックを上っていって、データベース・エンジンに対してサーバ・レイヤーから呼ばれ、検証されて、それから恐らく各ステップで引数が変換されて、そしてまた元に戻されているわけです。そんなわけで、我々は、 2、 3 ダースのナノセコンドと大体 10 ミリセカンドの間の差異について論じているんです。それは10の何乗にもになってしまう。どんなデータの移動に対してもこれは起きてしまう。それから、もちろんだけど、この仕事は徹底したセキュリティ環境の元で行われています。つまり、アプリケーション言語はサンドボックス の中で見事に動いて見せなくてはならないわけです、Javaである以上ね。そういうことで、自分でJava仮想マシンを書き上げてしまったのです。

Marina Novikova: みんなが言っていることですが、Netfrastructureを一から作り上げることで、あなたが元々 Interbase/Firebird で使われていて、もっとも理解しているマルチ・ジェネレーション・アーキテクチャのアイデアを実装するのを助けたのでしょうか。言い換えれば、あなたは、次世代の Firebird 開発者に対して、どうやって小さくて速いサーバーを作り上げればいいのかについて、わかりやすくデモンストレーションを行ったのでしょうか。私の言っていることは当たっているかしら?

Jim Starkey: 私は、マルチ・ジェネレーション・アーキテクチャのアイデアを実装するのを助けたわけではありません、確かに私はそれを発明しました。しかし、それは私が DECにいた時のことです。そうまだ私がInterbase を始める前のことです。DEC は、私と一緒にやろうとはしなかったので、結局自分自身でそれを作り上げました。　NetfrastructureとInterbase/Firebird の間の大きな違いは、 Netfrastructure がディスク上ではなくメモリ上でのマルチ・ジェネレーション であることなのですが、Interbase/Firebird はディスク上でジェネレーションを保持しています。この変更には 2 つの主な理由があります。一番目は、メモリが安くなって豊富に使えるようになったということ。二番目は、 Interbase は共有メモリを使わないクラスタ向けに設計されていたので、ディスクを使うしかなかったのです。そんなわけで、素晴らしいことに Netfrastructure は Firebird より最低でも 10 倍速くなったのですが、実は本当に重要なものは私がスイープについて説明する必要がなくなったことなのです。

Marina Novikova: そうすると、あなたの意見によれば、Interbase/Firebird のマルチ・ジェネレーション・アーキテクチャはサーバの開発上の妨げとなるのでしょうか？非常に多くの更新があった場合、ガーベッジ・コレクションは更に遅く予測できない状態になるということでしょうか。

Jim Starkey: とんでもない。あなたが InterBase/Firebird のディスク書込みの簡潔さをを伝統的なトランザクションログと比較するなら、マルチ・ジェネレーション は、簡単に勝つでしょう、それはディスクのオーバーヘッドがより少ないという統計で現れるでしょう。ブロックヘッドだけがボトル・ネックを作り出すでしょうが、 Interbase/Firebird は競合しているシステムと比べてより少ないブロックヘッドしか発生させません。

Marina Novikova: あなたは、 Java がデータベース・ウェブ・アプリケーション開発者にとって最も良い選択であると思いますか?

Jim Starkey: 絶対的で正統的なアーキテクチャがあるので、Java はすばらしい言語です、小さくてシンプル、そして堅固です。しかし、それが何にでも向いているかと言えばそうではありません。Javaは、アプリケーションの意味を表すためには非常に良いプログラミング言語です – 小さくて、シンプルで、優雅で、堅固。サンドボックス実行モデルは、アプリケーションコードが通常ふさわしくないとされる場所での実行を許します、データベース ( えーと、コンテンツ・ストアね ) システムの内部でのようなところでね。一方、 Java における文字列の扱いに関するパフォーマンスは悲惨なほどです、それからスレッド同期化のプリミティブな部分、2つ の状態を持つMUTEX も、哀れなほど遅いのです。Netfrastructure では、アプリケーション・ロジックのために Java を使用していますが、コンテンツ・マネジメントとページ生成に関してはＣ++を残しています、そのことは実装が物語っているんですが。

Marina Novikova: どうして、Interbase/Firebird のインデックスはユニ・ディレクショナルなのでしょう？またどうして、Interbase/Firebird のインデックスはバランスド・ツリーではなくて、シンプル・ツリーなのでしょうか ( 我々が利用可能なソースがある、現在のバージョンでも確認することができるのですが )? それは、 Interbase/Firebird アーキテクチャの制限によるものなのですか ?

Jim Starkey: それは全て1 つの個人的な見解に還元されます ：　私は、チューニングが嫌いなんです。コンピュータやソフトウェアは、スマートであるべきだと思っています ( 最適化なんてことについて考えなくてもすむようにね ) 。　この問題は、クラスタ化インデックスと非クラスタ化インデックスの対立なのです。伝統的なデータベース・インプリメントは、インデックスページとデータベースページの間でインデックスが飛び跳ねて歩き回らなくてはなりません。開発者はそのことを非常に迅速に学んだのですが、このことはディスク・アクセスにとって大変悲観的な結果をもたらします。そのため、彼らはレコードの物理的オーダがインデックスオーダと一致するように、クラスタリングを発明したのです。しかしこのことはスペース管理の問題と、ページ・オーバーフロー、 書き戻しのストラテジー、最適化の問題、それから全般的な混乱状態へ陥らせました。データベースのユーザは、物理構造、論理構造、アクセスパス・ストラテジー、それからインデックス設計を計画しなければならなくなってしまいました。そして、それらが必然的に引き起こす悪い結果に対して、データベース開発者はユーザの設計が悪いと非難したわけです。　そんなわけで私は、代替インデックス技術を開発したんですが、 それはbtree を Datacomputerの 反転と結合したものです。全般的なアイデアは、非常にシンプルなものです。インデックスとデータページの間を渡り歩くよりむしろ、インデックスは最初にスキャンされて、スパース・ビット・ベクターにおいて選択されたレコードを示すビットをセットし、ビット・オーダーに従ってレコードを処理し、それはまたディスク上の物理的配置にしたがっているわけです。このことは、いくつかの大きな勝利の鍵を持っています。一番目は、全てのインデックスは、うまく取りまわされたクラスタ化インデックスのように動作します。二番目には、インデックスバケットは、 二相ロッキングに支配されません。三番目に、ブーリアン、つまり「ＡＮＤ」と「OR」に関する操作について、ビットマップを媒介として実質的にコストなしに実行可能となります、つまりオプティマイザーが代替インデックス間で選択をする必要性そのものを消去してしまうのです。　そんなわけで、それは全く問題とならないのです、つまり最低でもインデックスが昇順か降順かということについてはね。インデックスが最初にスキャンされ、それからレコードがその次にフェッチされます。あなたがレコードを並び替えたいと思うなら、物理的順番でレコードをフェッチしてそれを並び替えるこの方法は、ランダムアクセスと共にディスクアームを鳴らしてフェッチするよりも「いつでも」速いのです。そして更に多くのレコードが関連し、さらに多くのソートがあれば尚更です。　インデックスの中を渡り歩くことが意味をなす唯一の時間というのは、あなたが 何百万ものレコードの中で、最初のいくつかを問い合わせた時だけです。実際のところ、これはdBase エミュレーションをしていた間は、デフォルトで起こりうるケースでした。そんなわけで、我々は賢明にも、バイナリ・アクセス言語を付加し、こうしたケースを理解するオプティマイザを準備し、インデックスを渡り歩いているのです。　Interbase/Firebird は普通の btree ( 元々バランスがとれている ) です。私は、バケットを空にして再結合するためのコードを書きませんでした。なぜなら、データの統計が通常安定していて、従って、スペースは再使用されるであろうし、もっと他に私が行うべき多くの重要なことがあると思ったからなのです。いつかは、重要なことをやり尽くして、バケットの再結合に手をつけることになるだろうと、信じていますが。

Marina Novikova: Interbase/Firebird は、完全なリレーショナルDBMS ですよね? 結局のところ、Forced Writesオプションが有効でない時、各トランザクションはそれぞれのコミット後に必ずしもセーブされるとは限らないわけですが。ACID におけるD は、 Durability を意味しているので、トランザクションがコミットされるなら、それは小さなハードウェア・エラーの場合には失われないことが確実でなくてはなりません。Interbase/Firebird においてはForced Writes をしなければならないわけですが、しかし、これは、オペレーションのスピードを減少してしまいます。このことについて何かお話し頂けますか?

Jim Starkey: そうですね。Interbaseは、信頼性の高いディスクを持つ堅牢なオペレーティングシステム上で動くように設計されましたが、Unix では、これは、パフォーマンスと絶対的信頼性の間でのトレード・オフを意味しました。私は、トレード・オフが好きではないのですが、そこにはそれがあったわけです。シリアル・ライト・ログ は、トレード・オフをほとんど消去するでしょうが、クラシック・モデルにおいてはそれを実行することは不可能です。Netfrastructure は、シリアル・ライト・ログのためのアーキテクチャーになっています。しかし、バッテリバックアップを持つ Linux はこれまで決してクラッシュしたことがありませんので、私は自分のトロくさいインプリメントのおかげで、睡眠時間を削られずにすんでいます。

Marina Novikova: Interbase 6 のソースコードが公開された後で、多くの興味深いものがあることが分かりました、不幸にも実現することがなかったものですが、例えば、式に対するインデックス、 双方向のカーソル、 XNETや、その他のものです。どうして、それらの開発者がそのアイデアを完成しなかった、と思いますか?　これは、アーキテクチャの制限によるものですか、あるいは時間が足りなかったとか、または他の何かの不足のためだったのでしょうか?　それから、あなたは、 オープンソースのDBMS についてどうお考えですか?　Linux は今上昇傾向にありますが、オープンなデータベースは今後、DBMS マーケットのかなりの部分を占めると思いますか ?

Jim Starkey: オープンソースプロジェクトのアキレス腱は、意思決定の方法にあると思います。コンセンサスに最も依存しているのですが、革新に関するコンセンサスは、とてもとても難しい。そんなわけで、オープンソースプロジェクトは、標準化へ向かう傾向があると思っています。Linux は、良くも悪くも、Posix と Unix に基礎を置いている。OK 、それらは20 年間の間に陳腐化してきたものだが、ふーむ、たしかにうまく動いています。一方、 SQL はテーマではあっても標準化されていません。現実の標準は、あらゆる目的に対してほとんど役に立たないもので、インタオペラビリティに沿って作成されたものにすぎないのです。確かなことは、プロジェクトを組織化するために必要なものは何もないということなのです。　データベース ( とコンテンツ・ストアね ) システムが扱うべき重要で、興味深い問題は山積みです。例えば、ウェブの基礎は検索です。どのようなデータベースシステムが、オープン・コンテクスト検索をサポートしているでしょうか?　私が知る限り、一つだけです。どのようなデータベースが、ユーザープロファイルに基づくデータを自動的にフィルタリングするでしょうか?　私が知る限り、一つだけです、それはコンテンツ・ストアと呼ばれています。　Firebirdの連中は、セキュリティ・ホールをふさぎ、システムを安定させ、バグを修正し、問題点を取り除く良い仕事をしてきました。そのシステムは、うまくマイナーチェンジすることを必要としていて、いまではそれは一つの答えを持っています。しかし、私はそういったことによって、データベース・テクノロジーにおける世界的リーダーとしての Interbase の伝統的な役割が取り戻せるとは思いません。Interbase/Firebirdは異種接続性、 二相コミット、カスケーディング・トリガ、ユーザー定義関数、イベント・アラータ、BLOBフィルタ、配列サポート、 双方向のマルチベンダーゲートウェイ等を持つ最初のデータベースでした。しかしその後、私はオープンソースプロジェクトが革新を促しているのを全く見ていないのです。　私はこれが少し難しいことだということを知っていますが、私はオープンソースプロジェクトとしての Interbase を決して開発することはないでしょう 。私は政治家ではなく技術者です。私は、自分が急進的な新しいデータベースアーキテクチャに関してコンセンサスを作らなかったということを強く確信しています。私は革新を信じ、そして革新は、一貫したビジョンを必要としています。私はオープンソースの中でそうしたビジョンを見たことがありません。しかし、私はこれだけは知っています。Firebird がクラシックとスーパー‐サーバのコードベースを分離しない限り、どちらも、どこへ行くことも出来ないでしょう。それぞれが、他方の開発を抑制してしまっているからです。

Marina Novikova: あなたは、そうした多くの発明に満足していますか?　Netfrastructure ではあなたの夢やアイデアを実現したわけですが、Interbaseと Firebird の開発をどのように評価していますか?　あなたがFirebirdの発展を見ることは興味深いことで、喜ばしいと思っていらっしゃるのでしょうか？例えば、アーキテクチャの変更のような重要な改善、メインバグの修正、 DSQL の拡張、パフォーマンスの改善等々ですが。

Jim Starkey: 私は、一群の発明をしてきましたが、それら全てを愛しています。VAX Datatrieve は、 VAX を離れて存続し、オラクルの爪から逃れ、 DECを離れて存続し、コンパックを離れて存続し、そしてHPの製品としてまだ生き続けています。私はVAX Datatrieveを気に入っています。それから、私にはとんとわかりませんが、どういうわけか PDP-11　のDatatrieve は、同じくまだ利用可能です。私はそのこと自体にとても驚いています。開発者が Firebird の様々な部分の周辺に腕を伸ばすのを見ることは、興味深いことですが、私は、誰かがFirebirdと共に走り出すのを待ち続けています。おそらく、誰かがそうするでしょうね。私が Firebird に活発にかかわっていたなら、自分がしただろうと考えているのは以下のような事です :1. シャム双生児となっているクラシックとスーパーサーバを分割すること、それによってそれぞれが生きながらえることが出来る。2. SQL をふさわしいエンジンに移動する間、レガシー・インタフェースとして BLR を維持すること。DSQL を捨てること。3. 2 レベルのネーム・スペースを導入すること4. スーパーサーバに対する知的に防御できる、有効なセキュリティを実装すること5. トリガ、ストアド・プロシージャ及びUDF のために Java バーチャル Machine を埋め込むこと6. スーパー‐サーバのためにシリアル・ライト・ログを実装すること ;書込みに注意を払わなくてもいいように

Marina Novikova: あなたは、オリジナルの Interbase アーキテクチャにおけるいくつかのあなたのアイデアが次の開発者によって不正確に理解され、もしくは誤って実現されていると思いますか?

Jim Starkey: どちらもないですね。アイデアもアーキテクチャも、最初から十年間にわたって利用可能なプラットフォームに完璧に適合していました。私が別のデータベースシステムを作らなければならなかったのでしたら、アポロ DN320 のために、マルチ・レベルなネーム・スペースを持つネイティブなSQLを作ったでしょうね、でも、他のものほとんど同じになったでしょう。　私が現代のマシン上ですべてをやり直さなければならないのであれば、再びすべての点で Netfrastructure を書くことになるでしょうね。しかしその時は、システムテーブルをケース・インセンシティブにするでしょう。それから、インデックスキーに関するアンの言うことを聞かないといけないですね。

Marina Novikova: Interbase/Firebird/Yaffilのコミュニティ全体に対して、望んでいることがあればお聞かせ下さい。

Jim Starkey: 過去から学びなさい。将来のために設計しなさい。もはや1984 年ではないのです。それにふさわしい扱いをしましょう。

Marina Novikova: 最初に、Dmitry Yemanovとはどんな人物か、InterBase Worldのコミュニティに話してくれるかな？

Dmitry Yemanov: そうだね、彼は陽気な25歳のヤングマンで、ちょっとした悪質な癖があるんだ。彼の人生は、これ全てプログラミング、その他のコンピューター関係ですら余計な時間を使う余裕もなかったりしてね。

Marina Novikova: 君がヘッドフォンをかけて騒々しい音楽を聴くことや、水曜日にロシア式スチームバス（banja）に行くこと、それに短い年次休暇にハイキングに行くのが好きだって知ってるわよ。どんな音楽が好みなのかしら？ハイキングで気に入ったルートはどこ？それから、どんなタイプのヴェニク（葉っぱの付いた小枝）をスチームバスに吊すのが一番お気に入りなのかな？ Dmitry Yemanov

Dmitry Yemanov: 最初に言うと、別にうるさい音楽だけが好きなわけじゃないし、ヘッドフォンで聞くことだけが好きなわけじゃないよ。いいアンプとスピーカーを持っているんだったら、グッドなロックが最高だよ。うーん、でも僕の同僚達はどうやら僕の音楽の趣味を気に入ってくれていないようなんだ。そんなわけで、ヘッドフォンを使っているのさ。こう言えば、僕がどんな音楽が好きなのかはわかっちゃうとは思うけどね。ただ、僕のお気に入りのバンドは数え切れないくらいあるからね。頭から言うと（順番は適当ね）、キングクリムゾン、ピンクフロイド、ブラックサバス、RHCP、O’Funk’illo、ナイトウィッシュ、アポカリプティカ、ジョー・サトリアニ、それから誰でも知ってると思うけどレディオヘッドだね。
スチームバスについて言うと、あなたの言っていることは正解、僕はあれが大好きだね。もう、何年も前から定期的に通っているよ。時間が全然ないときもあるんだけどね。ヴェニクのタイプについては、樺材がいいと思うな（自分で作るならこれがいいね）。時々は、オークやジュニパーのヴェニクも利用するよ。Banjaは心と体の疲れを癒してくれるね、それに最近は仕事の後の精神的、肉体的な緊張をリラックスさせてくれる。
ハイキングについて言うと、ずっと前からハイキングのファンなんだよ。今は全然時間を取ることが出来ないのが残念なんだけど、表向きは、僕はハイキングが大好きということになってるんだよ。僕は未踏の荒野を旅するのがとっても好きなんだ。何キロも何キロも歩いて、ボートで、カヌーで踏破してきたよ。二年前には、夢がかなって、西コーカサスの山岳へ行くことが出来て、征服してきたんだ。その感じを話すのは難しいなぁ、一度行ってみてほしいな。だけど、僕はちょっと太ってきちゃったし、体を全然使って仕事をしてないので、今行けと言われてもきついかもなあ。でも、いいフィットネスとしてこれをすすめたいなぁ、なにしろ僕は2週間で7キログラムもやせたんだから。その頃の僕は肉体的に健康だったし、清く正しい生活を送っていたんだよね。特に好きなルートっていうのはないし、持ちたいとも思わないな、なにしろ僕は新しいもの全てから受ける印象を楽しみたいからね。

Marina Novikova: 他に、なにか趣味はあるのかな？

Dmitry Yemanov: 読書だろうね。いつでも読書することが好きで、よく本を読んでるよ。好きなものはフィクション（クリフォード・シマック、ロバート・ハインライン、アラン・フォスター、ロシアの作家としては、古いものでバシリー・ゴロバチェフ、サージェィ・ルキヤネンコのいくつか）、ファンタジー（ロジャー・ゼラズニィ、トールキン）、旅行記や歴史のドキュメンタリー小説（特に古代に関するもの）だね。

Marina Novikova: 好きなビールの銘柄は？他にどんなお酒が好きかな？

Dmitry Yemanov: ライト・ラガーが好きだね。例えば（また適当に挙げるけど）、ラクプレシス、ネフスコー、オボロン、バドワイザー、スタロプラメン。時々、黒ビールも飲むね。それから、他に選択肢がなければだけど、ペンザビールでもOKだね。 僕はラトビアで生まれたので、ビールは国民的飲料だったんだ（とはいってもチェコ共和国やババリア地方ほどじゃないけどね）、この愛着は生まれつきなのかもしれないね。
他に好きなアルコール飲料で言うと、ジョージアン赤ワインで、ソフトドリンクについて言うと、ミルクシェークとフレッシュ・ジュースが好きだな。

Marina Novikova: いやだなあと思うことと、他の人にいらいらすることはどんなこと？

Dmitry Yemanov: 相手が嫌いだと思っても、しなくちゃならないことってたくさんあるでしょ。どれか一つに決めるというのは難しいなぁ。そうだ、一つはっきりしてること、金を借りるのは大嫌いだね。それから、人々が二枚舌を使ったり不誠実だったりするといやな気持ちになるね。

Marina Novikova: 大きな夢っていうのはなにかある？

Dmitry Yemanov: うーん、一つだけ？わからないなぁ。僕は人生の全ての喜びと困難を経験して生きていきたいと思っているんだ。遠い先を見ることは好きじゃないんだ、先のことばかり考えていると幸運が逃げちゃうからね。
Firebirdについて言うと、多くの人がこのサーバーに興味を持ってほしいと思うし、もっと広めたいと思う。オープンソースの製品の間でさえ、本当にいい製品はそんなには多くないから、Firebirdは大穴だと思うよ。Firebirdの将来についての夢というのはなんとも言えなくて、僕らはただ仕事を進めるのみだね。それに、それ自体僕らに多くを負っているからね。

Marina Novikova: 料理はするの？一番好きな食べ物はなにかな？

Dmitry Yemanov: 料理はそんなにはしないなぁ、でも料理の腕を上げたいとは思ってる。ただ時間が全然ないんだよね。外食するときは、カツレツと野菜とかスモークした魚を頼むね。それとビールね、忘れちゃいけないよ。

Marina Novikova: 通りで女の子にウィンクされたりしたら、どうするー？

Dmitry Yemanov: 少なくとも、ウィンクし返すね。そこから先は、彼女にどんな印象を受けたかによるなぁ。

Marina Novikova: 学歴はどうだったかな？職歴も聞いていい？

Dmitry Yemanov: ペンザ州立大学でコンピューター・エンジニアリングの学位を取ったんだ、それから長いことコンピューターに関わってきた。その頃から、国防省向けの専用システム用のプログラムから、地方市場向けのERPシステムまでを企画・開発してきたんだ。

Marina Novikova: 最初に書いたプログラムはどんなものだった？いつ頃からプログラミングを始めたの？

Dmitry Yemanov: たぶん、大学で暗号化/復号化プログラムを書いたのが最初だね。僕は、暗号化に利用される有限要素法に興味があったので、かなり勉強したんだ。そのために、アセンブラでユーティリティを書いたよ。そのちょっと後で、アンチノイズ暗号化に興味を持つようになって（同じように数学理論に基礎を置いてるものだね）、別のプログラムをCで書いたんだ。僕はそういったプログラムを研究目的で書いたんだけど、思った以上にプロフェッショナルな出来だったね。
僕が初めて本格的な結果を出したのは、ネット越しに機能するオブジェクトを転送するために、DCOMテクノロジーに対して暴虐（この厄介なハックと非公式の機能について他にいい言葉が見つからない）を働いたことだね。僕はそれをモバイル・オブジェクト・テクノロジーと呼んだんだけど、作ったものは動作中のCOMオブジェクト（コードとデータの両方）をネットワークノード間でクライアントに対して透過的に移動することを可能にするメカニズムだったんだ（例：クライアントと対話中のサーバーを、それと感知されないまま別のノードへと移すことが出来る）。これによって、ダイナミックな設定と異なったプログラム・エージェントによる分散システムを構築することが出来るようになるんだ。

Marina Novikova: Firebirdプロジェクトに参加したのはいつ頃から？最初の頃に手助けしてくれた人は誰かな？

Dmitry Yemanov: その話は長くなっちゃうんだよなぁ。最初は、僕はFirebirdを使っていただけなんだけど、それがなかったら開発に参加することにはならなかっただろうね・・・。
1999年に僕らは新しい製品の開発のために安いRDBMSを必要としていたんだ。要件の一つはローカルでのシングル・ユーザアクセスではフリーでなければならなかった。僕は、経営陣がInterBaseがその条件にぴったりだと考えていたかどうかはわからない。まあ、そんな些細なことは誰も気にしてなかった。結果としては、僕がこのことを知ったのは開発の最終段階になってからで、プロジェクトはもはや崩壊寸前だったんだ。僕らはいろんな方法について議論を重ねて、そのどれもが最低でもプロジェクトのデッドラインを2ヶ月かそれ以上越えてしまうということがわかったんだ。ちょうどその時に、ボーランドがIB6.0Betaのソースコードを公開したんだ（ちょうど僕らのプロジェクトはこのバージョンを採用していた）。僕らにとってはたった一つのチャンスだった。この直後から僕は全てのInterBaseに関するイベント、Firebirdプロジェクトの開発、開発者の移りかわりなどをきっちりとウォッチしはじめたんだ。僕はこのことを「強制された依存関係」と呼んだんだ。
そんな訳で、僕は自然とコードに興味を持つようになって、そこかしこで変更したり追加したりしたいなあと思うようになったんだ。僕はほとんど1年間にわたってコードをいじり倒して、firebird-develから有益な情報全てを学んだんだ。その時には、Dmitry Kuzmenkoが唯一のロシア人だった。一度全部に目を通したので、自分でもいろいろと出来るようになって、初めてのパッチをリリースしたんだ。それが始まりだったんだね。Cluaudio氏とMark氏、Ann氏にはとても感謝しているよ、出来の悪いコードだったのにとても暖かく迎えてくれたからね。これは本当に簡単な事じゃないと思うんだよ、どこへ行っても、いつでも新しいことに対してはみんな保守的だったからね。Claudioのアドバイスで、Alexander Peshkovに紹介されてdynamic SQLの最初のバージョンのサポートを手伝うことになったんだ（こいつは今ではEXECUTE STATEMENTとして知られているね）。幸運にも、僕らがやろうとしていたことは全てうまくいって、チームの中でのどうあるべきかについて侃々諤々（かんかんがくがく）の議論の結果が出たんだよね。

Marina Novikova: Firebird Foundationからの助成を受け取るというニュースについては、どうやって知ったのかな？

Dmitry Yemanov: FFについては知っていたし、その一番重要な仕事と目的についてはよく知っていたので、僕にとっては「ニュース」とは呼べなかったね。

Marina Novikova: これまでにどこか外国へ行ったことはある？

Dmitry Yemanov: いや、外国へは行ったことはないなぁ。以前のソビエト連邦共和国を別にするなら、トルコだけがそのうちリストに入るんじゃないかな。そのうちたくさん旅行をしたいなぁ。

Marina Novikova: Firebird Foundationのメンバーで会ったことのある人は誰と誰かな？

Dmitry Yemanov: おかしな話なんだけど、誰とも会ってないんだ。 僕はインターネットを通して仕事をしているだけなので、これってインターネットの悪い点だよね。出来れば、ヨーロッパのFirebirdカンファレンスに行って、みんなと会ってみたいなぁ。

Marina Novikova: カンファレンスには参加するの？カンファレンスには何を期待する？どんな報告に一番興味がある？

Dmitry Yemanov: もちろん、このカンファレンスには絶対参加したいよね。でも、まだ参加できるかどうかわからないんだ（「お仕事」の方の状況によりけりなんだよね）、でも万難を排して参加するつもりだよ。カンファレンスに期待することはたった一つ、2年以上にわたって知り合ってきた人々と、コミュニケーションを持つ機会だってことだね。それから、参加者に僕らのFB1.5の結果を報告して、今後のプランを話す絶好の機会だよね。

Marina Novikova: あなたの考えでは、現在のプロジェクトの中で何が一番難しい問題だと思う？

Dmitry Yemanov: 開発者として言えば、僕はバージョン2.0～3.0の開発に対処しなくちゃならないだろうね。新しいODSはたくさんの変更が必要で、セキュリティを一新し、SSとCSの対立という問題を解決し、C++へのコードの移植を続けて、それ以外にもまだまだたくさん解決しなくちゃいけない問題があるんだ。プロジェクトの全てのモジュール上で作業して、人目に付かないところを全部手を入れて、ということはとっても大変なんだ。
プロジェクトの管理者としては、開発者としての希望や興味とプロジェクトの開発ロードマップとの間での妥協点を見つけなくちゃならない、開発のプロセスがアナーキーにならないようにしつつ、コード・ベースが混乱しないようにして、開発期間をきちんと管理していかないといけないよね。

Marina Novikova: プロジェクトの中で、あなたの最大の業績はなんになるのかな？それから人生においてはどう？

Dmitry Yemanov: 僕は、昨年の春に最初のリリース後にプロジェクトが沈滞してしまうのを防いだんだけど、それがそうかな。その時は、John Bellardoと僕だけがコード上での作業をしていて、新しいコード・ベース(firebird2)はまだ不安定でたくさんのバグがあったんだ。それらを修正することは大変困難で、同時に新機能を追加していたからなおさらだった。Johnが別の仕事を始めるのでプロジェクトを離れたときは、本当にびびったよ。幸運にも継続は力なりで、夏の終わり頃にはArno BrinkmanとNikolay Samofatovが参加してくれて、大いに助けてもらったよ。彼ら無しではFirebird 1.5は無かっただろうね。それから、他にも大勢の開発者がプロジェクトに参加して一緒に作業を進めてくれていて、みんなに感謝したいな。
人生における最大の功績は、まだこれからなんじゃないかな。

Marina Novikova: いつもEメールにすぐ返事をくれるよね。一日に最高どれくらいメールのやりとりをしたことがある？それは誰と？

Dmitry Yemanov: 仕事メールを除外すべきだと思うんだけどいい？そうでないと、とんでもなく莫大な数になっちゃうからね。 まじめに考えると、数えたことはないよね、でもとっても多くの時間を割いてるのは間違いない。本当にたくさん時間をかけてるね。僕のメールボックスを見てみよう、どれどれ、今日は22通のEメールを出してるなぁ。全部Firebirdに関するものばかりだ。大体平均してこんなものだと思うよ。

Marina Novikova: バグは再生するものだと信じている？

Dmitry Yemanov: 確かに、僕自身そのプロセスにどっぷりつかっているよ。

Marina Novikova: 新しいアイデアやインスピレーションをどこから得てるの？

Dmitry Yemanov: さっき、ビールと音楽の話をしたと思うんだけど、そうだよね？実際のところ、僕はそういうものをどこからでも得ているんだ、ちょっとリラックスして自分の注意を他のところへ向けたりしてね。僕はたくさんのアイデアやいい考えを持っていて、それは寝ているときだったり、眠りにつくときだったり、仕事の行き帰りや、休憩中に思いついたものなんだ。

Marina Novikova: えーとねディマ、どうしてWindows版のクラシックバージョンをリリースしたの？Jim StarkeyとAnnとその他大勢の人たちは、一度に二つのサーバーを分岐して開発するのはナンセンスだと考えているし、一般的に考えてもそのことが開発を遅らせるだろうし、人々を待ちくたびれさせてしまうんじゃないの？どうして、SuperServerをもっと良いモノにするだけじゃだめなの？

Dmitry Yemanov: この質問に対する答えはいくつかに分けて答えないといけないなぁ。
1)僕は彼らの意見にもちろん賛成なんだけど、統合されたアーキテクチャ（キャッシュを共有した「正しい」SSやCSのどちらであっても）は将来の課題だと思ってる、ただそれはすごく近い将来というわけではないんだ。恐らくそれまでにまだ1年以上の時間がかかると思う。そうだとすると人々は今どうするべきだろうか？
2)現在のClassi版はUNIXプラットフォーム向けになっているので、win32のユーザーはそのために困っているんじゃないだろうか？それに加えて、ここにはボーランドから引き継いだモノがあるので、問題無くwin32向けのClassic版を作成することが可能なんだ。もっと込み入っていたとしたら、多分僕はClassic版に取りかからなかったと思う。
3)ボーランドがInterBase 7でSMPのサポートを宣伝して、Yaffilが彼らのwin32向けClassic版を作成した、僕らとしては取り組まざるを得ない状況になったんだ。特に、僕らはパワフルなマルチユーザ・アプリケーションをSMPマシン上で利用することについて話し合っていたんでね。
僕としてはwin32向けのClassic版は過渡的なソリューションだと思っているので、まあこれで満足するクライアントは少ないだろうと思っているし、両方のタイプのアーキテクチャーを全てのプラットフォームでテストする機会を得て、今後のサーバー開発の情報を得ることが出来ればいいなと思ってるんだ。
「正しい」SuperServerのためには、決してつまらない作業というわけではないと思うよ。IB 7.0を見た限りでは、特に何の刺激も受けなかった。強いて言えば、Charlie Caroは素晴らしいコーダーでアーキテクトだっていうことかな。そういう意味では、何でもそうだけど、外から見てるほど簡単じゃないんだよね。

Marina Novikova: InterBase 6のオープンソース版についてはどう思う？それってボーランドの手違いだったのかな？

Dmitry Yemanov: それについてはイエスだね。ボーランドは、製品の開発戦略を選択して、それに従ってきちんと仕事をすることができないということを、まあやって見せたんだよね。InterBase部門の経営方針を変更して、VARパートナー（訳注：付加価値再販業者の意、代理店のことですね）とこっそりとした陰謀を行って、漠然とした「オープンソース思想」を持ち出して、それで結局ユーザーの信頼を得られなかったんだ。今となっては、あらゆる事が良い方へ変わったんだけど、その産みの痛みが残ってしまっているんだよ。それに加えて、ボーランドはかなりの数のユーザーを失って、それらのユーザーはFirebirdとYaffilを代わりに使っている訳なんだ。
後の残りは全部幸運だったとしか言いようがないね、幸運がIB/FB/YAファミリー全部の開発を早めてくれたんだなぁ。

Marina Novikova: Firebirdの将来についてどう考えてるの？

Dmitry Yemanov: もちろん考えてるよ。まず絶対に成功を収めるだろうということ。僕は思うんだけど（自分がオプティミストだって言わなかったっけ？）ここ数年に起きたことから考えて、プロジェクトはより強固になっているし、ユーザーはその結果を見てるよね。これは僕にとってとてもハッピーなことだね。僕らはいろんな問題に取り組んでいるにはちがいないけど、かならず最後までやり遂げると思っているよ。

Marina Novikova: Firebirdをエンド・ユーザー向けの製品にしようと思ってるのかしら？私の言っている意味は、パッケージにサーバーとドキュメントとクライアント・アプリケーションと管理ツール、その他を全部含めるつもりなのかなということなんだけど。さもなければ、Firebirdを普通のオープンソース・プロジェクトと同程度のものにしておこうということなのかしら、それっていうのはユーザーがあらゆる必要なことを自分達自身で解決しなくてはならないというようなモノってことなんだけど？

Dmitry Yemanov: 僕らは前者のようになることを望んでいるんだけど、現在の政治状況から全ての対応するドキュメントとプログラムを全てオープン/フリーにする必要があるんだよね・・・。それらが形作られて作成されたとしたらね、まあやってみようとは思ってる。問題があるとしたら、とてもたくさんのプログラムがIB/FB/YA向けにありすぎて、どれかを一つ選んでパッケージに組み込むのが難しいということだろうね。そんなわけで、近い将来に僕らはサード・パーティの製品についてその概要とリンクを示すリストだけでもパッケージに含めたいと思ってるんだ。

Marina Novikova: もしあなたがボーランドのInterBaseセクションにいたとしたら、最初に何をやりたいと思う？

Dmitry Yemanov: すぐに辞めてFBのチームに合流するよ。

Marina Novikova: どうしてYaffilに行かなかったの？

Dmitry Yemanov: それは良い質問だね。最初にFBプロジェクトのメンバーになって、Olegが新しいクローンを作ろうと思っているとはわからなかったんだ。Yaffilプロジェクトが独立して、活発に活動を開始した後で、僕らはとても困難な時期を迎えたんだ。僕にもプライドや意地もあったので、自分自身で結果を出したかったんだ、プロジェクトが危機を乗り越えたとしても、あるいは破綻してしまったとしてもね。状況が悪い方へいってしまっていたら、今頃僕はYaffilに関わっていただろうね。でも、僕はFirebirdを去らなかったし、失敗もたくさんあったけど、それと同じくらいたくさんの努力をしてきんだ。

Marina Novikova: FB1.5の新しいメモリマネージャーは1.0のモノより良くなっていると考えてる？それから、どうしてそれを変更しようと思ったの？

Dmitry Yemanov: 間違いなく良くなっているよ、テストの結果もそう出ているしね。そもそもそれが理由で、僕らはメモリマネージャーを変更したんだ。 以前のメモリマネージャーは、すでに多くのブロックを配置した後では、新しく解放されたブロックの配置に関して制限があったんだ。標準的な例を挙げると、複雑なデータベースのリストアや、データに対する多数の操作、その他で発生してしまうんだ。今、僕らはこういった問題を解決してパフォーマンスを向上させることに成功したんだ。

Marina Novikova: 将来の優先事項はどうなってるのかな？最初に何を変更/作成したいと思ってる？

Dmitry Yemanov: そのリストは膨大なんだよ、最低でも1ページになっちゃうよ。 僕らはすでに将来のプランを作成しているんだけど（それはカンファレンスの参加者には手渡せるようになっているんだけど）、その中に大事なことは全部組み込まれているんだよ。要するに、既にわかっている問題を解決するだけで十分なんだ。
最後になるけど、Firebirdを選んで使ってくれているInterBase Worldのコミュニティの皆さんを決してがっかりさせたりしないように頑張りますよ！