* CMSのチェックアウトの仕様に強く依存していて、画像ファイルが出力フォルダにある前提でビルドファイルが作られている．CMSの配下でデバッグするなら良いかもしれないが、自分のPCでは画像をいちいち出力フォルダにコピーしなければならず、DITA-OTのビルドでも画像がないのエラーで満載．
* 特にHTMLではスタイルシートのオーバーライドの嵐のような状態．oXygenで関係するフォルダをプロジェクトに入れても、該当するテンプレートを探すのに一苦労する．つまり「何が」どこで処理されているか非常にわかりづらい．
* 昔のSaxon6.5の頃から使用されているスタイルシートらしく、XSLTのバージョンが1.1というワーキングドラフトで終わったものを使用している．Saxon 6や少し古いSaxonならエラーは出ないが最新のSaxonでは警告となる．あとXSLTのバージョンはこの1.1と2,0のごちゃ混ぜという状態（良く動くな～）
XSLTのバージョンという点では、私も昔DITA Open ToolkitがまだSaxon 6.5で動いていた時代に作ったプラグインがあったのですが、DITA-OTにバンドルされたのがSaxon-B 9.1に代わった時点でスタイルシートはすべてXSLT 2.0で書き直しました．あまりその分の工数はもらえなかったのですが、一応顧客も納得してくれてXSLT 1.0⇒XSLT 2.0への書き換えを許してくれました．今考えると、これがどれほど後に良い結果を残したかがわかります．
何故かというと、私が見たスタイルシートはオーバーライドの嵐なので、一部が2.0だがオーバーライドする元は1.0か1.1という惨憺たる状態だったからです．DITA-OTでもその後XSLT 1.0のコードをXSLT 2.0で書き直す作業が進んだのですが、このプラグインはそのような機会を失ったのでしょう．このような結果、スタイルシートはもはやメンテナンスが作った本人しかできない．作った本人もたぶん向き合うのはイヤと感じるであろう状態になってしまっていました．
結論的に言えることは、CMSのバージョンアップがあってDITA-OTのバージョンも上げようという事になったらもはや動かなくなってしまうことはまず確かではないか？ということです．つまり動くに動けない化石状態になってしまっています．
こういう状態のプラグインをメンテナンスし続けてきたプログラマのうめきが聞こえるような気がしました．幸いにも私のお客様ではそのような事態にはなっていません．提供しているプラグインは、オーバーライドがあってもせいぜい1段で、すべてXSLT 2,0でコーディングされており、XSLT 1.0に比べればはるかにメンテナンスは楽だからです．またDITA-OTの提供する標準的なプラグインに依存していないので、DITA-OTのバージョンが変わってもあまり心配をしなくとも済みます．
まあお客様は一回開発してしまえばあとは使い続けられると考えるのかもしれませんが、上記のようなことも現実にあることを知っていただいた方が良いと思います．適切なメンテナンス契約をしていただいて、開発者が安心してサービスを提供できるようにしないと、恐ろしくて直したくても直すことすらできないシステムを抱えていていることになりかねません．
開発者も良心を持っていますから、自分の書いたコードがお客様の役に立つよううまく動いてくれることを望んでいます．しかしそのような良心が、人日単位の工数の値切りや身勝手な納期の強制ではうまく発揮されないのも事実です．
