何だか蒸し暑くて目が覚めてしまった。9月に入ったというのに，残暑は根強く残っているようである。
今日は防災の日。駿河湾で大地震が発生，という想定で防災訓練が行われるようだ。全く当事者としては胃に良くない設定である。緊急時連絡カードなるものも常時携帯するように配布されており，わしがどっかで何かの下敷きになったりしていなければ，いざその時には職場に駆けつけ，カードに書いてある連絡先に電話をし，生存が確認できるようにしておかねばいけないらしい。自身はもういつきてもおかしくない状況だそうだが，具体的な日時の予測は難しいから，全く待たされる方はもどかしい。早く来ないかな(違う？)。
今日は雑用に追われる一日であった。午後からは企業の方が来訪されて，研究話。SCOの訴訟があってから，Linuxがらみのビジネスからは一端手を引いたということであった。それなりに効果はある訳ね。ヤクザのミカジメ料みたいなもんを請求しているらしいが，はてさて判決はいかばかりか。
注文していた”Revolution OS”が届いたので，作業をしながら流してみる。音楽のセンスがイイし，インタビューしている人選もナイスである。詳細はちゃんと見てからここに書くことにしよう。
で，それを見つつ思いついたのだ。Open Sourceのビジネスってのは技術的には高いレベルを要求されるのだなあってね。
結城浩さんが書かれた固有IDのシンプルシナリオ流に単純化して，例を示してみる。
(1) 企業Aはプログラマaにあるシステムを発注する。
(2) プログラマaは，Open Sourceのパッケージαにコードを付け加えて改良し，パッケージα’として完成させて，企業Aに納品する。
(3) プログラマaはパッケージα’をOpen Source Communityにて公開する。
(4) Open Source Communityから別のプログラマbがパッケージα’を入手する。
(5) プログラマbは「私はプログラマbより安い費用でパッケージα’をメンテナンスできる」と，企業Aに自らを売り込む。
まあ実際には人が作ったものをその人以上に理解して改良できるかと言えば難しいことが多いだろうし，そんなズーズーしいことを平気で実行できる厚顔無恥な輩は少ないだろうから，(5)のようなことはあまりないと言える。んでも
(5)’ パッケージα’をサポートしてくれるプログラマを捜している企業Bが，ツテを辿ってプログラマbに依頼する。
もしくは
(5)’’ プログラマBが，パッケージα’をサポートできる旨，それを求めていた企業Bに自らを売り込む。
ことは枚挙に暇がないし，そーゆー繋がりを通じて，Open Sourceが広がったという側面は見逃せない。
ソースが公開されているってことは，それをサポートする上で，言い逃れが出来ないってことにもなる。勿論土台となるパッケージの出来が悪ければ改良にも限界はあるが，そうでなければ，不具合が直せないのはソースを読み解く力がないか，サボっているためにそれを回避する手段を見いだしていない，ということになる。しかも，ユーザ数は多いから，モタモタしていては自分以外の人間がさらなる改良を施してしまう可能性が高い。Proprietaryであれば，バイナリだけをユーザに渡し，自分の能力の及ぶ限りにおいて，差分パッチをリリースしていけばいい。勿論，あまりにヒドイ不具合があればそのうちライバルが出現して来る可能性は出てくるけど。
してみれば，Open Sourceのビジネスモデルでは，技術スキルが不可欠要素となり，言い訳の効かない世界であると言える。うーん・・・。