異なるツールを統合し、アプリケーション間でデータをシームレスに移動させ、 プログラミング・ライフを楽にすることを約束する戦略的な提携、オープン・アーキテクチャー、 あるいは商用の API に関する発表を、目にしたり、耳にしたりすることがあるでしょう。
それを知ると、開発者はじっとしていられなくて、 インポート / エクスポートというダクト・テープをこれでもかと使用して、真顔で「統合パッケージ」として市場に出すでしょう。
このような統合化のプレッシャーはいったいどこから来るのでしょうか? なぜ誰もが、自分たちの製品を統合パッケージに組み込もうとしたり、 オープンな統合をサポートするためのプラットフォームを構築しようとするのでしょうか? 誰がこれらのプラットフォームを必要としているのでしょうか?
エンド・ユーザーを見てみましょう。エンド・ユーザーは、 サポート担当者に電話して「私が実際に必要としているのは、オープンなツール・プラットフォームなのです」とは言いません。
エンド・ユーザーは、「あなたの製品は、なぜ私の他のツールと統合しないのか」と尋ねるのです。 エンド・ユーザーは、アプリケーションの範囲を超えたフィーチャーを要求します。 仕事ができるツールに自分たちのデータを渡すことができないからです。 エンド・ユーザーは、異なるプログラムとの間のインポートおよびエクスポートに関する問題に突き当たっているのです。 エンド・ユーザーは、なぜ自分たちのプログラムは、 同じようなタスクを行うのにそれぞれ全く異なるユーザー・インターフェースを持っているのかを疑問に思っているのです。 エンド・ユーザーの Web サイトのデザイン・ツールをエンド・ユーザーのスクリプト記述プログラムと統合すべきであることは、 明白ではないのでしょうか?
ユーザーは、タスクを行うのに最も優れたツールを自由に選びたいと願っています。 エンド・ユーザーは、ソフトウェアがその他のわずかのプログラムとしか統合しないからといって、制約を受けたくないのです。 エンド・ユーザーにはしなければならない仕事があり、 それは、ツールの間のファイルとデータのフローを管理することではありません。 エンド・ユーザーは自分自身の問題の解決で手一杯です。 ツールを正常に動作させることが開発者の仕事なのです。そしてそれらのツールを協調動作させることができれば、 さらに成功です。
一方、開発者は、次のラウンドの重要なフィーチャーをインプリメントしたり、 バグを修正したり、リリースを出荷したりすることで、自分のツールにかかり切りになっています。 さらに緊急にインポート・フィーチャーを追加するなどという事態は、開発者が最も避けたいことでしょう。
十分なフィーチャーを公開することによって、ツールとの統合を他人任せにできれば、それは開発者にとってすばらしいことではないでしょうか? 残念ながら、大企業に勤めていない限り、開発者はそれをやってのけるだけの十分な影響力を持っていないのです。