http://www.opendesign.com/node/514

海外CAD事情のオリジナル著者である Ralph氏は、面白がって 「ODA and Bricscad form their own “ITC”」 などと書いてますが… (汗)

ODAは本来、そのメンバー会社と協力関係にあることが前提ですよね？ 「これまで協力する気はありませんでした… ごめんなさい」 とでも言いたいのだろうか？ ODA Arnold会長からすれば、 このニュースを出すことで、他のメンバーを牽制したい意図があったのかもしれません。

Deelip氏がブログで、わりと真相に近い事を語ってくれています。

http://www.deelip.com/?p=1561

現行 BricsCAD V10は、2010-DWGを読めません… なぜか？ BricsCADが使っているDWGdirectは、 2.6 （バージョンとしてはかなり古い） より分岐した独自のもので、ODAが現在提供している 2010-DWG に対応した DWGdirect 3.x 系 とは異なるからです。 2.x 系 の最終バージョンは、2.7 であるにも関わらず 2.6 を使い続けるのは、ODAのオリジナルソースとは乖離して戻せなくなってしまったのでしょう…  BricsCAD を 2010-DWG に対応させるには、3.x 系を採用しなければなりません。 舞台が ITC (IntelliCAD) から、ODAに移っただけとも… 独自路線を進めれば、末路はいつも同じ…

• これまで同様, オリジナルから分岐した独自ライブラリのメンテナンスを継続？
• ODAと協力して, 共用ライブラリのメンテナンスに貢献？

どちらを選ぶのか？

昨年４月に, Leiden (オランダ) で開催された 「ODA World Conference 2009」 が舞台でした。

Arnold会長は, ODAとして始めて開催するカンファレンスにおいて 「Unity (団結)」を強調しておりました… Bricsys は, 自分達が行った莫大な不具合修正を, ODAへ提出することに対して難色を示していたのですが… Alliance のメンバーとしてODA規則に従う限り, 道は１つしかありません。

貢献はメンバーとしての責務です。より多くの貢献をした会社が、より多くの利益を得られるという点については、その通りだと思います… Bricsys は、紛れも無く DWG互換 ソフトウェアビジネス を牽引している会社であることは誰もが認めている事。

他のメンバーを蹴落とし1人勝ちを目指すような行動に出ることなく, コンソーシアム/アライアンスメンバーのお手本であって欲しいと願っています。

最後は、Deelip の結語を引用させて頂きましょう…

Bottom line, the ODA platform as a whole will be strengthened and the non-AutoCAD DWG community will benefit from this cooperation.

Arnold plans on getting other ODA members to follow Bricsys’ footsteps. I wish him luck. After all, strength lies in unity.

結局のところ… 団結は力なり！

http://www.melma.com/backnumber_14168/

この原文を執筆されている Ralph Grabowski 氏 は、ITC, ODA の会合などで、何度かお見かけしたことがあります。 Ralph 氏のブログ> WorldCAD Access

upFront.eZine （毎週月曜日に発行）は、英語圏で CADに関わるビジネスをされている人であれば、ほとんどの人が読んでいると思われ… 私も主たる情報源となっております。

特別に、AutoCAD関連の話題に偏っているわけでもなく、最近は、世の中の流れから… 3D CADの話題が多いのですが、このところ、AutoCAD互換CADの動きが少し活発になっており… ITCにおいても、今週は、Ralph に何を書かれるんだろ？としばしば話題にしています。

今週号 （Issue #634） は、まだ日本語に訳されておりませんが、なかなか面白かったです…

We no longer have the weird socialist-style marketplace of IntelliCAD members cooperating yet attempting to compete; we have three true capitalist competitors.

この部分（特に “weird socialist-style” ）は、どんな日本語に訳されるのだろう？ 資本主義 vs 社会主義？ 現在の世界経済における、アメリカと中国の対決を見るようです…

先週、ITCにおいて大きな規則改訂の決議がありました。

ITC理事会では、「ITCが会員活動へのもっと厳しい規制を行うべきである」という Ralph氏の意見 を聞くまでも無く… この数年、この問題に取り組んでおりました。今後は、IntelliCAD ソースの著作権保護を目的に、BricsCADのような派生製品に対して、厳重なる罰則が課されることになります。Bricsys 社に対する処遇は、今後、話し合われることになるでしょう…

ITCでは、特に、派生製品における 開発環境（API）の互換性について重視しており、IntelliCAD派生製品上で動作するアドオンアプリケーションは、全てのIntelliCAD派生製品で動作しなければならないことが義務つけらます。

どういうことになるかと言いますと… 近い将来、IJCAD において動作するアプリケーションは、ZwCAD においても動作しなければなりませんし、その逆もしかり… ということ… Zwsoft CEO は、「私達はITC会員として規則を遵守します」 と表明しています。

ITCとしては、「IntelliCAD」 ブランドを 「CAD Platform」として定着したい考えで、ITCが目指しているのは… IntelliCADをベースにした様々なCAD製品の上で動作する様々なプラグイン（アドオンアプリケーション）があるという状態こそが、IntelliCAD World！ITC会員(提供する側)は、均一なCADプラットホーム上で、それぞれのビジネスを構築する必要があり… 利用者からすれば、これによって様々な選択肢が可能になります。

社会主義？と言われれば、そうなのかな…
大きな資本を持った会社が勝つ資本主義とは明らかに違うことは確かです。

ITCにおける Bricsys のメンバーシップは停止されました。

ポートランド/オレゴン/米国、2010年2月10日、The IntelliCAD Technology Consortium (ITC) は、Bricsys CEO Erik de Keyser 氏より BricsCAD 10 ソースコードには一切 IntelliCAD ソフトウェアが含まれていないと記述された手紙を受け取り、ITCにおける Bricsys社 のメンバーシップを停止したことを発表しました。Bricsysは、2002年に（BricsCAD NV として）ITCに加わり、Erik de Keyser 氏は、2003年にITCの副会長を務め、2004年から2006年まではITCの議長を務めていました。

ITCは、会員企業がIntelliCADソースコードにアクセスすることができるソフトウェア共同体（コンソーシアム）です。会員企業がITCを去る場合、その会社は、ITCの知的所有権が保護されていることを保証するため、定められた方法に従います。ITCは、その知的所有権がBricsys社によって不適切に使われていないことを保証するために、いくつかの手順を踏むことになるでしょう。ITCは、IntelliCAD開発に10年以上携わっており、先日、IntelliCADベースソースコードのとても重要な更新版である IntelliCAD 7 Beta2 リリースをアナウンスしたばかりです。

40社以上のITC会員会社がIntelliCAD開発プラットホームの作成に一緒に取り組んでおり、それぞれが相当なる資源を提供しています。会員各社のIntelliCADソフトウェアに対する所有権が保護され、そのソースコードが他製品の作成に不適切に利用されないことが保障されています。

これまで、「いずれは…」いう曖昧な回答を繰り返しておりました （実際、いずれ対応することになるだろうと思っておりました） が… 最近になって、いろいろな判断材料が整ってきました。

ここ最近の OpenDesign Alliance (ODA)  と、IntelliCAD Technology Consortium (ITC) の動きを見る限り…

IntelliCADのARX対応は「ない」 と思っておいたほうが、よさそうです…

現在、書き直しが行なわれている「次世代IntelliCAD」は、その大部分がDWGdirectに依存しており、ITCとしては、DWGdirectによって提供されるAPI（DRX-API）をもって「ObjectARX対応」とする構想でした。

ですが、最近のODAは、DWGdirectライブラリを 「ObjectARX互換」 と表現することを明確に避けるようになりました。（Autodesk社との要らぬ法廷抗争を避けたいということが大きな理由の１つだと考えられます）

DWGdirect (DRX API) は、ObjectARX に非常に良く似たクラスライブラリですが、関数名はもちろんのこと、関数の使い方などがObjectARXとは異なっておりますので、ソースの互換性はありません。（AutoCAD上で動作しているARXアプリケーションの移植は、リコンパイルレベルではなく、ソースの書き直し作業が必要となります）

BricsCADなど、InteliCADより派生した製品の中には「ARX対応」 を宣伝しているものがありますが… ObjectARXが膨大なクラスライブラリでかつ、基本的には、対応するAutoCADバージョンに依存するライブラリとなっていますので、どこまで互換性があるのか？という点では、かなり疑問…  多大な期待はしないほうが賢明という気がします。

実は、BricsysのCTO(開発責任者)とは面識がありまして… 先日、オランダのODAカンファレンズで再会しました。 「実際、どうなの？」 と、尋ねたところ、「優先順位が高いと思われる関数から順次実装しています。単純に今のペースで作業を進めていけば、数年後には作業を完了できます」 ということだったのですが、その間もAutoCAD(ObjectARX)は、進化しているわけで…

その「優先順位」がどうやって決まるのか？というのは、Bricsysが１企業であることを考えれば、容易に想像できますよね… （お金を積めば、優先的に対応してくれるかもれません (汗;）

彼は、「AutoCADアドオンソフトメーカーの皆様から送られてくるソースコードは、酷いものが多くて…. そもそも、何でこれがAutoCADで動作しているのかが不思議！というものが少なくない」 とも言っておりました。判る気がする… 大いに納得。

IntelliCADのLISP関数群も同じで… マニュアル(関数リファレンス)の記述通りに100%互換性のある関数ライブラリを作ったとしても、それが、どのようにプログラム側から呼び出されるのか？について想定できないケースが多いので、「実際に動作するかどうか？」は別問題。

安価なAutoCAD互換CADを使いたい…  ARXを使いたい…  というのは、残念ながら、両立しそうにありません。Bricsysのアプローチは、AutoCADアプリケーションを取り込むという点で、素晴らしいアイディアだとは思いますが… 実際には、それほど簡単ではないでしょう。

ObjectARXのソースコードに固執する限り、現実的には、AutoCAD以外の選択肢は 「ない」 と考えたほうが賢明かもしれません。

なぜなら、仮に、Bricsysが 「ARX互換」 で成功したら？今度は、LT-Extenderと同じ運命を辿るのではないか？という心配が出てきます…

ARX に固執しなければ、様々な選択肢があるのですが、 「AutoCAD互換CADを使う」 と決意するには、 「ARXを諦める」というのが条件になるのかもしれません。

「ARXで開発を続けたい」という開発者の皆様には、 「AutoCAD を使い続けてください」 と提案したほうが親切なんだろうな… と思うようになりました。

LT-Extender が終焉宣言をしました。
http://www.lt-extender.com/LT-Extender/englisch/default.htm
詳細は不明ですが… 写真（墓石）の文字がとても意味深です。

LT-EXTENDER 2000 KILLED BY A LAWYER
（LT-Extender 2000 は、とある弁護士によって殺されました）

最近、Autodesk社 まわりでは、法廷抗争が絶えません。先日、ODA と Autodesk 間の係争は示談で終わりましたが… SolidWorksとAutodeskは、まだ係争中と聞いています。

上記サイトでは、LT-Extenderの後継は、BricsCADで… と書かれています。

数年前… BricsysはITCを脱退して独自路線で行くことを表明しました。ITCを脱退するのであれば、ITCより得たIntelliCADソースソードを全て置き換えなくてはなりません。そこで、LISPインタプリタエンジンは、LT-Extenderの作者にお願いした… ということだそうです。 ですから… Bricsysが、ARX互換環境を提言した時、この流れ（LT-Extenderの作者がBricsysに合流）は、ある程度、予測できましたが…. Autodesk社より目をつけられている開発者を受け入れた、Bricsysの判断は？

確かに、ARXソースがそのままビルドできる! というのは、魅力的なのですが… 過去、ACE-LTとか、LTcomとか… 痛い目に会っておりますので、企業で採用するには、ちょっと勇気が要りますね。

現在、ITCでは、法廷抗争に巻き込まれないよう様々な予防線を張っていて… 先日、「規則を守らないメンバーを理事会の決議によって退会させることが出来る」という規則が議決されました。

一部の無法な会員の行為によって、ITC そのものが危険にさらされてしまっては、真面目にビジネスを展開している会員企業が大変… 世界恐慌によって窮地に追い込まれた会員が、なりふり構わない行動に出る恐れも危惧されています。

ITCは、会員が適切なビジネスを展開してるのか？監視し、違反者に対しては書面で警告するなどして、「健全に運営されている組織である」ということを強調したい考えでおります。

http://www.intellicad.net/profiles/blogs/mesh-to-solid-for-bricscad

訳文

本日 SYCODE は Bricscad 向けの「Mesh->Solid変換」をリリースしました。Bricscadにて、多角形メッシュを3Dソリッドに変換する機能を加える DRX プラグインです。

今まで、このブログを読んでいたのであれば、私が、ずっとDRXアプリケーションの開発に躍起になっていることを知っているかと思います。

皆様の何人かは、私達が何故 BRX-SDK（ObjectARXとソース互換性がある）を使って、AutoCADプラグインを再コンパイルするというアプローチを取らなかったのか？と不思議に思っているかもしれません。確かにそれは、DRX-SDK を使って大部分を書き直す方法よりも、もっと短期間に Bricscad プラグインを作成できたのかもしれません。

一番の理由は、IntelliCAD７がリリースされれば、それをサポートするためにいずれにせよ DRX-APIで書き直す必要があったことです。加えて、他のDWGdirect ホストアプリケーションで動作させることも視野に入れていることと、私たち自身もまた真面目に私達自身の DWGdirect ホストアプリケーションを開発することを考えているということもあって、DRX-APIによるアプローチを取ることにしました。 心配しないでくださいね… さらに別のAutoCADクローンを開発するつもりではありません。 私たちは、プラグイン開発とともに、スタンドアローンで動作するアプリケーションも開発しておりますので、これらをDWGdirect SDK を使って書き直すことを考えています。そうすれば、Bricscad用に開発したDRXプラグインは無駄になりませんし、自分達のスタンドアローン製品上でも動作させることが出来るでしょう。

ODA が CAD 業界において最も重要な組織になるであろう… という Ralph Grabowski の最近のコメントは私にとって大いに意味をなします。私は常に ODAは、単に DWGファイルを読み書きするライブラリを提供しているわけではない！と提言してきました。彼らは、それよりも遥かに多くのものを提供していて、今や、プロフェッショナルアプリケーションを書くデベロッパーがCADソフトウェアを開発するための、ほぼ完全なコンポーネントになりつつあります。

想像してみてください… ODA会員が DWGdirect SDK を使ってCAD製品(ホストアプリケーション)を作成します。私のようなプロのサードパーティーデベロッパー、企業内のプログラマー、フリーランスのプログラマー、学生たちは誰でも、それら全ての DWGdirect ホストアプリケーションで働く DRX プラグインを無料の DRX SDK を使って作成することができるのです。

私の会社では、たくさんのCADシステム向けのプラグインを開発していますが、サポートするホスト(CAD製品)によって、その開発方法とソースコードが大幅に変わります。例えば… 私たちは SketchUp SKP ファイルのインポート機能を 11の異なるCAD向けに提供していますが、そのソースコードは全く違うものです。なので、もし私たちが 異なるCADで動作する１つのプラグインを作ることができるのなら、それは、とても素晴らしい事です。もちろん、現在は１つの標準的な CAD プラットホームがないので、それはできません… ですが、DWGdirect SDK はこのような理想的な状況になりそうなのです。

CADプラットホームを開発するリソースも時間もお金もない私のような小さな会社が、DWGdirect プラットホームをベースとして、自分達のプロダクトを構築するために使うことができます。会社で自社システムを開発している場合も同様です。そして、さらにDWGdirectホストアプリケーションで開発されたDRXプラグインは、他の様々なホストアプリケーションと共有できるのです。

私がずっと思い描いている理想像と同じ… 図面を扱うソフトウェアを作成している皆様に 「このような環境を提供したい」… と活動を続けております。 どのCADでも動けば, 開発者の皆様が作成したソフトウェアがより多くの方に利用して頂けるようになりますし、プラットホームの選択においても選択の幅が広がります。

どこか１社独占… というのは、結果的には、歴史を繰り返すだけという気がします…

市場には、既に V8 とか、2008 という、IntelliCAD派生製品が出回っている状況で、本部 ITC からは、いつ出てくるのか？

IntelliCAD 7 の開発は、ITC本部で秘密裏に行われており、メンバーにすらソースは非公開となっています。 ですから、私も推測でしか語ることができませんでしたが… 最近になって、かなり状況（真相）が判ってきました。

ITC がメンバーに Ver.7のソースを開示しない理由は…

Ver.7 の開発ポリシーは、既存ソースの完全リライト！DWGdrect を利用した、完全無比なる 「DRX ホストアプリケーション」を開発することとしています。 ODA の DWGdirect と非常に深く関わっているので、IntelliCADの開発には、DWGdirectのソースコードが不可欠となります。

しかしながら、 DWGdirectのソースコードは、ODAの最上位のメンバーにしか開示が許可されていませんから…  ODAの最上位メンバーであるITC本部 （に所属する開発メンバー） はDWGdirectのソースにアクセスできたとしても、ITCのメンバーにまでアクセスを許可することはできません。 さもなければ、ITC会員（ODA最上位メンバーよりも会費が安い）になれば、DWGdirect のソースコードを入手できてしまうからだ。

ごもっともである…

なぜ ITCは、V7 をいつまでも出せないのか？

一番大きな理由は、良くも悪くも ITCは非営利団体であるということ…一言で言えば… 理想を追求しすぎ！という事になるかと思います。

インテリジャパンは、馬鹿正直に ITC に付き合いすぎていたのかもしれない。もっとズル賢くても良かったのかもしれません…

コマーシャル（商用）ベースを最優先で考えれば、別の方法があったはずで… 実際に、それを実践したのが、ITCの同朋？（ライバル？）が作った BricsCAD、ZwCAD などのIntelliCAD派生製品。

本家が、分家に遅れを取ってしまったような格好です…

技術的な側面からすれば、B社の手法が一番賢い（ずるい？）と いえる。 B社は、IntelliCAD 5 から独自路線を歩み始め分岐していきました。 現行の V8は、プログラムを構成するモジュールが IntelliCADのそれとは、かなり異なっているので、既存の ITCソースのかなりの部分を既に置換したと思われます。 それから、B社は、単なる他人の真似ではなく、新しい技術を生み出すのが、実に上手い会社です。ITCの進捗次第では、AutocAD互換CAD市場における最有力候補となるかもしれません。

一方で、Z社の 2008は、その外観からしても AutoCAD利用者には最もウケが良いと思いますが、「著作権」という側面からは、かなり危ない製品と言わざるをえません。 加えて、技術的な側面からは、実はあまり見るものが無く.. マンパワーによって実現できた、実にZ社のお国柄 「らしい」 製品。プログラムを構成するモジュールは、IntelliCAD V6と、ほとんど変わらないので、B社のように賢く置換した…というよりは、力ずくで修正した…という代物です。 なので、ITC V7ソースが開示されれば、もう一回作り直す必要があるはず… ですが、その作業は全く問題ないほどのマンパワーを持っているようなので… この点については、実に羨ましい限りです。

いずれにせよ、現時点では、V8 , 2008 ともに、AutoCAD ARXに対抗するべく開発が進められている DRXホストアプリケーションとは言いがたく… いかにして早く市場に出すか？ということを優先した製品で、 ITCが目指しているところとは、やや着眼点が異なるのですが、「商用」としては、実に正しい判断といえるかと思います。

でも、最終的には、やっぱり ITC V7 が本命？ という事なんでしょうが…

残念ながら… 現在のDWGdirect には、CADを構築する上で、致命的な欠陥があり… インテリジャパンは、ITCと足並みを合わせている限り、当面 V7 をリリースすることは出来ないと思われます。