オープンソース？ - I 慣性という名の惰性 I

ようは構造設計のデータを公開しろ、ということか。あんまりオープンソースとは関係ないような気もする。

bewaad氏のところでコスト面から見たフィージビリティを考えており、この結論でほぼ言い尽くされている感じもある。
⇒http://bewaad.com/20051201.html#p01

誰かが見破るかもというリスクを大きくするのは事実ですから、ある程度の抑制効果という「微益」は考えられなくはない

ただまあオープンソースといっているので､とりあえずEric Raymondの「魔法のおなべ」を読み返してみた。

で、ここね。

まとめると、オープンソースをすすめる差別化要因としては次のようなものがある。
(a) 信頼性、安定性、スケーラビリティがとても重要な場合。
(b) デザインや実装の正しさが、独立ピアレビュー以外の方法ではきちんと検証できない場合。
(c) そのソフトがその利用者のビジネス展開を決定的に左右するような場合。
(d) そのソフトが、共通のコンピュータ・通信インフラを確立するか可能にする場合。
(e) その核となるメソッド（あるいは機能的にそれと等価なもの）が、よく知られた工学的な知識の一部であるとき。

これらの条件を当てはめてみるとどうなるか。

(a) 信頼性、安定性、スケーラビリティがとても重要な場合。: 信頼性、安定性は重要ではあるんだけど、スケーラビリティは関係ないな。
(b) デザインや実装の正しさが、独立ピアレビュー以外の方法ではきちんと検証できない場合。: これはそれ以外の方法がすでに存在するからなあ。とはいえ、既存の検査方式の無謬性は担保できないことが今回明らかになったわけだから､あとはコストの問題ですかという感じか。
(c) そのソフトがその利用者のビジネス展開を決定的に左右するような場合。: 欠陥がばれれば左右するんだろうけど、そもそもの構造設計自体は独占的なノウハウはあまりなさそう。優秀な構造設計屋さんはいるんだろうけど、独占的なノウハウをためこんでおける業界とも思えない。
(d) そのソフトが、共通のコンピュータ・通信インフラを確立するか可能にする場合。: そもそも建築物は個別物件だし、その個別の物件に関わる人たちって多くても数百人くらいだから、インフラ的な扱いはやりにくいのではないかと思う。
(e) その核となるメソッド（あるいは機能的にそれと等価なもの）が、よく知られた工学的な知識の一部であるとき。: これはそのまんま当てはまるな。

で、結論としては個別の構造設計をオープンソースにするというよりは、今回偽装にも使われていた構造設計の強度計算をやるソフトをオープンソース（というかただでダウンロードできるようになってればいいのかも）にすることのほうがこの議論には適当な気がする。当然、構造設計のデータ自体は公開してもらわないといけないわけで、この点は賛成。

ただこの構造設計データって、その建築物に住もうかって人だけが関心を持つデータなので､このデータを広く一般に公開しても恐らくほとんど意味ないだろうと思う。まして、そのデータをオープンソース的にいじる人が出てくるとは考えにくい。

構造設計のデータ自体をいじれるのは一級建築士でも構造設計を専門としている限られた人たちだろうから、ここにリソースがふんだんにあまってるという状況も想像しづらい。Linuxとかとは意味が違うよな。ただ、強度計算のソフト自体はオープンソースにしてもいいんじゃね？ソースコードをいじるというよりは、自宅のPCで数値入力して安心するという使われ方という意味で。当然インタフェースとかは素人にもわかる感じになってもらわないと困るんだろうから、そのへんはオープンソース的に誰か作ってくれないかなと期待するということでw

(12/2 追記）
ソフトをダウンロードさせるというよりは、ASPにしといたほうがいいような気もしてきました。