オープンソースでコスト低減はスーツの幻想にちがいない

タイトルは釣り。

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

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

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

三菱東京UFJ銀行のシステム障害と、にんげん大好き

システム統合以前に、銀行名の統合に失敗してるだろ。

派閥とか利権争いとかくだらねぇ。

結局、銀行のシステム統合が上手く行かない理由ってそこだと思う。エンジニアは技術的な問題は解決できても、政治的な問題は解決できない。

そんな事より、複雑怪奇な名前の銀行はやめにして、みんなでトマト銀行を利用すればいいと思うよ。トマト銀行は、ぼくの故郷の岡山が誇るシュール系第二地方銀行。キャッチーなテーマソングもあるからぜひ聞いてみて。きっと気に入ると思うから。

トマト銀行の歌「にんげん大好き」

親しみやすい名前とキャッチコピーって大事だよね。

ほんとにタイミングがあわない

タイミングがあわないっていうエントリを書いてすぐにGitHubの招待状が届いた。すばやい対応に感謝。

しかし、今のぼくは、エントリ書くタイミングすらはずすのか...

タイミングがあわない

Anarki Arc repositoryという、オープンなリポジトリ(wiki-style repoって斬新で超クール)があって、当たり障りの無いところから、コミットしていこうかと思ってた矢先に、GitHubに移動したっていうニュースが飛び込んで来た。

GitHubは今のところ、招待してもらわないとアカウントが作成できないみたい。OSSの世界に飛び込むのが今年の目標のひとつなんだけど、いきなりつまずくことになろうとは。

とりあえず、Arc Forumに招待してくれって書き込んでみた。こういう時、もっと積極的に英語でコミュニケーション取れるようになりたいと思う。

んー、なんだかここ最近、なにかとタイミングがあわないことが多い気がする。公開したサーバが3日で死んだりとか、gauche.nightのチケット取ろうと思ったら完売してたりとか、飲みに誘われても先に予定が入ってたりとか、そもそも、お誘いメールに気付くのがその翌日だったりとか。他にも書けない事とかね。

冬服をクリーニングに持って行くタイミングだけは逃さないようにしよう。

死んだ

なんというか、公開して、3日でサーバがお亡くなりに。

どうやら、ハードディスクが逝ったご様子。いや、ありえんだろ。とりあえず余ってたノートPCで立てたサーバだったんだけど、まさかこんなに早く死ぬとは思わなかった。もうちょっとがんばれないものか。

それとなくサーバは動いてる。たぶんメモリキャッシュのおかげだろう。だけども、Disk I/Oが発生するとエラー吐きまくり。fsck叩いてもダメ。リブートしたら、確実に死ぬだろう...っていう死亡フラグ立ちまくりのシチュエーションでのベストプラクティスを、だれかぼくに教えてはくれまいか。

開発環境としてや、日常生活を送る上では、*nixの扱いにもずいぶん慣れたけど、サーバ管理となると、また別の話だね。絶対的にノウハウが足らない。インフラからデザインまでトータルに手がけたいぼくとしては課題のひとつだ。一人でなんでもできると思うなって声が聞こえてきそうだけど、ぼくはやるよ。できる子だと思いたい。

もう余ってるマシンは無い、かといって、メインマシンのMacBookで直接公開するのも抵抗あるので、VMware Fusionで仮想サーバを立ててみた。しばらくはなんとかなるだろう。

Newer Entries »