松村技研

タイトルは釣り。

Das Tagebuch von Judith über Technologie: Tomcat 6.0.18 重大な変更

なにやら、Tomcatの最新バージョンで下位互換の無い仕様変更があったんだとさ。いや、興味ないんだけどね。

それはそうと、商用のアプリケーションサーバ製品ではこんなことしないとか、以前も現場じゃ大ブーイングだったとかおかしくないか?

そもそも、なぜオープンソースを導入したの?Javaのアプリケーションサーバなんて、それこそ商用のやつが沢山あるだろうに。それでも敢えて、オープンソースを選択する理由ってのはなに?

オープンソースで人材の確保とコスト低減、いかにもスーツな奴らが言いそうだ。

バグ、仕様変更、開発中止、サポート打ち切り、バス問題とかも含めて、企業でオープンソース製品を導入することのリスクをちゃんと考えてる人ってどれくらい居るんだろうか?

実際、開発中止なんかはマイナーなプロジェクトでは良くある話。一人で開発してて、ある程度実装したところで飽きちゃったとかね。え?ぼくのことだって?放っておいてくれ。

まあ、Tomcatくらいの大きなプロジェクトだと、その辺の問題もちゃんと考えられてるだろう。今回の問題もシステムプロパティで設定できるような、救済措置も用意されてるみたいだしね。

今さら持ち出すような話ではないんだけど、オープンソースって正しく理解していないと、逆にコストが高くつくよねって話。それに見合うメリットも大きいけどね。ソースが公開されてること。手元にはいつでもソースがある。

例えば、今回の問題で、救済措置が用意されなかったとしたら、どういう対処法が考えられるだろうか?

1. バージョンアップしない
2. 不満を言いながら、既存のコードを修正する(手作業で!)
3. コンバートプログラムを書く
4. Tomcatをハックして元の仕様に戻す

ぼくは真っ先に、4番目のTomcatをハックすることを思い浮かべた。必要であればソースコードを直接修正できるってのはすばらしいことだ。もちろん、開発もオープンだから、仕様に関して意見があるなら、直接開発者とコンタクトを取る事もできるし、その気があれば、コミッターになって仕様策定に関わることすら可能だ。

えーと、ここからは、ぼくの主観だけど、4番目の考えが思い浮かぶ人ってのは、プログラミングの楽しさを知ってる人なんじゃないかな。3番目のコンバートプログラムを書くってのは、プログラマとしては一番正しい判断だろう。

だけど、今のIT業界(SI業界)で一番選ばれる可能性が高いのは、この中だと1番目の選択肢なんじゃなかろうか?もしくは、2番目の考えしか思いつかないような頭数合わせの人材で溢れかえってるとか。そんなだから、この業界のイメージが(ry

いや、興味ないんだけどね。話もまとまらないし、まとめる気もなくなったし。

結局、何が言いたいかというと、しばらく更新サボってたけどブログ再開するよってこと。