InfoQ: 2011年は WebSharper にとって重要な年でしたね。その成果の中で，もっとも満足しているものは何ですか。
本当にそうですね！ 2011年は WebSharper の周りでいろいろなことが起こりました。一番よかったと思っているのは，プロジェクト自体をオープンソースにしたことです。それに合わせて，コンパイラの大規模なオーバーホールを行いました。さらに変換パスを合理的なものにして，JavaScript の出力をより良く，読みやすく，デバッグしやすいものにしました。HTML5 サポートの拡大や，さまざまな WebShaper エクステンションの開発保守など，ツーリングのサポートにも力を入れてきました。現在では，先進的な可視化やグラフ作成，ユーザインターフェース管理，GIS といったものから，HTML5 Web ベースのモバイルアプリケーションに至るまで，２ダースを越える数の主要な JavaScript ライブラリがブリッジされています。
Web ベースのモバイルアプリは今，モバイル開発者にとって魅力的な選択肢になっています。比較的容易な手順で，確立した標準とマルチターゲットを念頭に開発することが可能なためです。WebShaper を使えば，Android と Windows Phone アプリケーションを同一の F# コードベースから開発することができます。さらに，その他のパッケージング技術にフックすることで，適用プラットフォームの範囲をさらに拡大することも簡単です。
全体として WebShaper は，F# ウェブプログラミングにおける No.1 の立場を確立すると同時に，Web ベースの F# モバイルアプリ開発への道筋を示したと言えます。このような方向に進んでいることをとても嬉しく思っています。
InfoQ: ツーリングのサポートについて説明してください。この方面では，どのようなものが提供されているのでしょう？
WebSharper のツーリングは以前から非常に強力でした。Visual Studio との密接な結合によるシームレスな統合的ビルド環境の提供，シングルクリックのデプロイ機能，プロジェクトの起点となるさまざまなテンプレートなどです。最近になって，サーバとクライアントの両方のコードに対応する，ハンディな機能テストフレームワークも追加されました。単にサーバ側のコードを既存のさまざまなユニットテストフレームワークでテストできるだけではなく，生成された JavaScript コードを F# テスト仕様に対してテストしたり，それらのテストをさまざまなクライアント上で実行したりすることが可能なものです。他の JavaScript ライブラリ用の新たなエクステンションの開発や，より複雑なクライアント側機能やユーザ対話機能をテストする場合には特に便利です。
さらに今回から，さまざまなクラウドにホストされた .NET 環境や，AppHarbor のような自動デプロイ機能がサポートされたことによって，WebSharper アプリケーションのクラウドへのスケールも非常に簡単になりました。これは重要な機能強化です。WebSharper の Web アプリとモバイルアプリをシームレスにクラウドへと移行する上での，まさにすべての障害を取り除くものだからです。この領域には今後も，重点的に力を注いでいくつもりです。現在はクラウドベースの WebSharper IDE に取り組んでいます。これは開発チームがさまざまな WebSharper プロジェクトにおいて，ソフトウェアをインストールすることなくすべて Web 上で共同開発を行うことを可能にするものです。2012 年の第３四半期には，WebSharper IDE の最初のベータリリースが予定されています。
InfoQ: HTML5 のサポートは，WebSharper の初期バージョンに比べてどのように変わっているのでしょう。
WebSharper バインディングは事実上，すべての JavaScript ライブラリに対応可能です。HTML5 JavaScript API も例外ではありません。最新リリースでは HTML コンビネータ言語を強化して，HTML5 DOM 構築 (データ属性など) に対応しました。また HTML5 バインディングについても，最新の API 使用に適応するようにアップデートしています。中でも注目してほしいのは，WebSocket が更新されたことです。これによって，最新の HTML5 仕様に準拠したサポートを提供できるようになりました。
InfoQ: F# から JavaScript への変換は，どのように動作するのでしょう。
WebSharper では F# の生成するアセンブリ以外に，F# コンパイラが埋め込む特殊なメタデータを以前から使用していました。このメタデータは型付きの AST (Abstract Syntax Tree) のようなもので，各アセンブリのさまざまな情報を保持しています。この情報が，クライアント側のコンテントを反映した JavaScript コードモジュール出力に使用されます。サイト単位でスクリプトを生成するのではなく，アセンブルを変換することによって，ライブラリを共有したり，クライアント側の機能を他の WebSharper アプリケーションに配布することが簡単になります。実際にこのような部品やコンポーネントを.NET アセンブリとして配布して，互換性のある WebSharper プロジェクトでそれを直接参照するようなことも，特別な操作の必要なく実現できるのです。
間もなく発表される 3.0 バージョンではこの F# メタデータに代わって，.NET IL コードをベースとした新たなコンパイル方法も提供する予定です。これによって WebSharper アプリの一部あるいは全体を C# などの .NET 言語で開発することも可能になりますが，F# もクライアントとサーバ両方に対応する強力で有力な選択肢として継続する予定です。
InfoQ: F# から JavaScript へのコンバータは，独立して使用可能な API にはならないのでしょうか。
現時点ではできませんが，WebSharper 開発プロジェクト外でも利用できるように，より汎用的なツールにするための作業は行っています。.NET アセンブリ，あるいはネームスペースやクラス，関数のようなさまざまな .NET 言語のより小さなコード単位，さらには任意のソーステキストといったものから，JavaScript コードに変換する機能には，明らかな利点があります。WebSharper の変換処理は，単純なコード間変換に留まるものではありません。外部リソース (スタイルシートや外部 JavaScript ファイルなど) への依存性や，その他言語スケールでの変換シナリオでは，非常に重要なメタ情報を算出するための大規模な分析処理を伴うものなのです。スタンドアロンの API の一部として，このようなメリットが手に入るようになるのは，それほど遠い先のことではありません。次回のリリースではこの種の API だけでなく，メタプログラム機能も合わせて提供できるものと思います。
InfoQ: WebSharper をオープンソースとしてリリースした理由は何でしょう。
本質的には，これまで私たちが行ってきた，プロジェクトの可視性を向上する活動を反映したものです。私たちには大きな課題があります – F# は急速に成長し，安定した開発者ベースを持っています。しかしその中に Web 開発者の数は比較的少なく，高価な製品を購入する意思を持つ人はさらに少ないのです。オープンソース化することで，オーサリングオープンソースソフトウェアを無償にして新たな Web 開発者を F# に取り込み，より多くの F# 開発者を Web 開発者にすることによって，増加する F# 開発者の多くをユーザとして獲得したいと思っています。さらに WebSharper には，関連するトレーニングや基本およびカスタムレベルのサポートプラン，他の革新的なサブスクリプションベースのサービスなど，単なる製品販売から脱却するだけの価値と利便性を持ったビジネスチャンスもたくさんあります。
オープンソースへの移行は，WebSharper が小さな企業の閉鎖的な製品であることの限界を越える手段でもあります。小さな企業が比較的新しい製品の開発に採用するような革新的開発アプローチに伴うリスクは，より経営的な発想を持つフォーチュン 500 に入るような大企業にとっては，かつて懸念材料でした。オープンソース化されて透明性が確保された今，WebSharper には，投資した製品が消滅してしまうかも知れないという懸念はもはやありません。このため，より相乗的な発展やさまざまな方法による技術革新，新たな関連サービスの構築なども可能になるのです。
InfoQ: WebSharper で AGPL ライセンスを改変して採用している理由を聞かせてください。変更部分にはどのような意味があるのしょう。
WebSharper はフレームワークであると同時に，Web ベースのモバイルアプリの開発を容易にする SDK であり，さらにそれらのアプリにソースファイルの一部が含まれるという意味においては，一般的なライブラリと同じでもあるのです。
WebSharper を利用する開発者の大部分は，それをツールおよびライブラリとして使用しています。F# コードから Web あるいは Web ベースのモバイルアプリをコンパイルおよびビルドするためのツールとして，それらアプリに内包されるライブラリとして，です。このように WebSharper アプリには，WebSharper のコードとメリットが直接組み込まれているのです。ここで開発者には，２つの選択肢があります – 自分たちのアプリケーションソース全体を GNU AGPL v3 などのオープンソースライセンスに基づいて公開するか，あるいはクローズドにしたまま，アプリケーションの開発に参加する開発者向けの開発ライセンスを用意するか，のいずれかです。
このようなデュアルライセンスモデルは，オープンソースとクローズドソース開発者どちらのニーズにも応えることができるため，同種のプロジェクトは広く採用されています。AGPL では，クライアント-サーバ Web アプリケーションのようなサーバ側シナリオで GPL の持つ，重大な欠陥が埋められています。もし AGPL が組織として非推奨，あるいは明確に対象外とされていたとしても，アプリケーションコード全体に WebSharper AGPL ライセンス例外に記載された中から選択した任意のライセンスタイプを適用して，WebSharper のコードと関連ライブラリコンポーネントのみ AGPL 下に置く，という選択もあります。
唯一の大きな例外は，WebSharper をベースに別の開発フレームワークを構築する場合です。これまで述べたデュアルライセンスではカバーされないので，特別なライセンスが必要になります。これもまた，さほど珍しいことではありません。他のオープンソースプロジェクトでも，非倫理的な利益を取得されることのないように，同様な制限が適用されているものです。
InfoQ: 最近では，オープンソースとオープン開発の違いに関して，多数の議論がされるようになっています。後者は一般からのソースコード貢献を受け付けているプロジェクトを指すのですが，WebShaper はオープン開発モデルを目指しているのでしょうか。
長期的にはそう考えています。WebSharper にはフォークや新たな WebSharper エクステンション，ライブラリなどのプロジェクトが多数あり，さらに増えています。多くの webSharper ファンが，さまざまな機能拡張と新機能開発に取り組んでいるのです。その範囲は，jQuery など既存の組み込みエクステンションを基盤 JavaScript ライブラリに対応してアップデートするような保守作業から始まり，.NET カバレッジの拡張，さらには Web サービスとの連動やORM のサポート，その他クライアントに対するデータ抽象化といった，さまざまなシナリオにおけるトランザクション機能の拡張にまで広がっています。
このようなコミュニティの取り組みの多くには感動を覚えます。まさにこのプラットフォームに注ぎ込まれている，巨大なエネルギーを象徴するものと言えます。 例えば WebSharper アプリケーションを新たな Web コンテナで実行させる取り組みは，OWIN や Web.API など，今後の標準にも取り入れられています。
私たちが徐々にオープン開発モデルに移行して，コントロールされた方法でコントリビューションを受け入れることができるようになれば，ある時点で，彼らの開発成果をメインの WebSharper コードベースに統合することができるでしょう。