Firefoxの主要開発者の一人で、長年Mozillaプロジェクトに貢献してきたDavid Baron氏が、TraceMonkeyの開発が難航してFirefox 3.1のリリースが遅れていることに対し、苦言を呈している。TraceMonkeyを外せば、今頃正式版をリリースできていたと思われるのに、開発期間が延びたせいで、本来なら後のバージョン（3.1.2や3.2）に投入すべき機能が3.1のBlockerリストに上がり、さらなる遅れを招いているというのだ。
今後もTraceMonkeyのためにスケジュールが遅れるなら、はっきりした期限を設けるか、あるいはBeta版をもう一つ増やすべきだとBaron氏は主張する。期限を設けないなら、今のところFirefox 3.2に向けて開発されている新機能の投入を認めてもよいはずだし、逆にTraceMonkeyを3.2に回すことも考えられると述べる。
たしかに、当初1月中旬にはコードフリーズするはずだった3.1 Beta 3は、2月中旬に至ってもコードフリーズのメドが立たないという異常事態に陥っている。仮のスケジュールとしては、3月2日にリリースされることになっているが、実現しようと思えば次の土日にコードフリーズまで到達する必要がある。だが、それは簡単ではない。
内部からの厳しい批判だけに、Baron氏の発言は一定のインパクトをもつだろう。大幅な軌道修正は難しいと思われるが、TraceMonkeyを別格扱いしないとすれば、たとえばjavascript.options.jit.chromeはデフォルトでオフのまま正式版がリリースされるのではないだろうか。
また、jit.contentに関しても、JITの適用対象を広げるような開発はひとまず打ち切り、安定性の向上に主眼を置くようになることが考えられる。例を挙げれば、現状でV8 BenchmarkではGoogle Chromeに大差をつけられているため、JavaScriptチームは最近これを改善しようと考えているのだが、こうしたことも3.2に先送りされる可能性がある。
