Railsが成功しEJB3が失敗したわけ

Railsが成功し、EJB3が失敗したわけは、イノベーションへの解にでてくる「独自仕様の製品アーキテクチャ」と「モジュール方式のオープンな業界標準」の考え方で、うまく説明できるように思えます。
ただし、この手の話は、理論にあうように現実を説明しているところがあるので、あくまでも、1つの可能性として聞いてください。
ここでの重要な考え方は、「顧客のニーズ」と「製品の性能」の力関係です。
「顧客のニーズ」が「製品の性能」を超えている場合は、顧客は、製品の性能向上に価値を認め、お金を払います。このときに企業として、成功しやすいソリューションは、「最適化された独自アーキテクチャ」で望むことです。性能を向上させるためには、独自アーキテクチャのほうが、いろいろ工夫ができるためです。
「製品の性能」が「顧客のニーズ」を超えている場合は、顧客は、製品の性能向上に価値をあまり認めません。既に、製品の性能に満足しているためです。性能が向上するよりも、入手の容易性(例えば、安くなるとか)が顧客の望みとなります。
このときに企業として、成功しやすいソリューションは、「モジュール方式のオープンな業界標準」で望むことです。モジュール式にすることで、より安いモジュールを提供する企業と組んで、コストを下げたりすることが可能になります。
上記を踏まえて、「顧客(開発者である私たち)のニーズ」と「製品(フレームワーク)の性能」を比べてみると、「顧客のニーズ」のほうが「製品の性能」を超えていることがわかります。私たちは、まだ、フレームワークの性能に満足していません。
このような状態のときは、独自アーキテクチャで少しでも性能の良いプロダクトが好まれます。だから、Railsは受け入れられたんだと思います。
一方、まだまだ、性能が足りないのに、モジュール方式に切り替えたEJB3(JSF, JPA)は、顧客の求める性能が出せず、あまり成功しなかったのです。
別に標準化そのものは、間違ったことではありません。ただし、そのタイミングが重要で、製品の性能が顧客のニーズを超えていないときに、標準化しても、失敗しやすいということです。
Javaの世界は、製品の性能が顧客のニーズを超えるまで、独自の統合型(フルスタック)アーキテクチャで望んだほうが、マーケティングの理論的には、成功しやすいと思います。