大企業のサポートあるいはバックアップが得られないと難しい気はしています。
日本で中規模以上のシステム開発となると大概、大企業あるいはその関連会社が元請けです。
使われるフレームワークやライブラリも元請けから指定される場合が多いのが現状。
元請けの内部で選定する場合には自社独自のモノか海外・国内で既に実績の多数あるモノ
を選考対象にしているはず。
また、大企業やその関連会社にとって実装技術はそれほど重要ではなく、顧客の要望を
満足できるモノであれば何でもよく、新しいモノに飛びつく必要性も感じないという感じ
だと思います。
元請けは構築したシステムが問題を起こした場合、顧客に対して責任を負う立場に
あるので、実績があり且つ自分たちで面倒をみれるモノを選んで当然です。
元請けによる選定でなくとも既に自社内でフレームワークを構築している場合、余程の
メリットがなければ学習コストを掛けてまで乗り換えは行わないのが現実です。
日本で巷のJava技術者と交流して自分たちで作ったJava系OSSプロダクトを宣伝しても
それが利用の拡大に繋がるかは上記の点からみて疑問です。
OSSプロダクト関連のイベントに参加するエンジニアは若手が多いので、システムに
利用するフレームワークの最終決定に関与できない場合も多々あると思います。
海外と日本では事情が異なると思うので、海外での普及を優先して日本での普及は
後回しにするというのもありかもしれません。
日本での普及を優先するなら巷のJava技術者よりはシステムに利用するフレームワーク
の決定権を握る層へのアタックが必要な気がします、アタック方法はわかりませんが...。
Ruby、Perl、Python等のLL言語のOSSプロダクトはそのほとんどがエンドユーザを
対象にしたモノであり、無料のレンタルサーバ等に設置して簡単に利用できます。
企業向けシステムの実装に使われる事の多いJavaとユーザサイドに近いLL言語の
OSSプロダクトでは領域が異なるので普及においてあまり参考にはなりません。
文章推敲中...。
「こちらがGiveする以上、Takeしてもらう必要がある」とは対人間関係で思っている
わけではありません。ただ、相手にこちらへお返ししようという姿勢(相手にとっての
Give、こちらにとってのTake)がなく、こちらがGiveするばかりではこちらからの
Giveは長続きしませんし、そんな相手にGiveし続ける気はありません。
対人間関係では「こちらがGiveする以上、相手にこちらへお返ししようという姿勢を
望む」ということです。
メモメモφ。