Kandoの日記： オープンソースの得失についての文献は？ 7
日記 by
Kando
オープンソース化の得失について調べるように言われたので、取り敢えず
「オープンソースワールド」、川崎和哉、翔泳社、1999
を見ながらE.S.レイモンドの3部作（下記URLに日本語訳）についてまとめたプレゼン資料を作った。
が、最近の動きとして何かいい文献はあったりするのだろうか？
オープンソース化の得失について調べるように言われたので、取り敢えず
「オープンソースワールド」、川崎和哉、翔泳社、1999
を見ながらE.S.レイモンドの3部作（下記URLに日本語訳）についてまとめたプレゼン資料を作った。
が、最近の動きとして何かいい文献はあったりするのだろうか？
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
その辺は古すぎるし楽観過ぎ… (スコア:1)
ベースとなるデータとしては、この辺はどうでしょう?
http://www.linuxfoundation.org/publications/ [linuxfoundation.org]
特に
http://www.linuxfoundation.org/publications/linuxkerneldevelopment.php [linuxfoundation.org]
これは Ottawa Linux Symposium 2007 の発表原稿と同じ内容になっています。
「オープンソースの得失」というテーマが、「自分の会社が持っている製品をオープンソース化することで得られるポイントと失うポイント」と言う意味ならばあまり役には立ちませんが、
「オープンソースを利用するならばどのようなメリットとデメリットがあるのか」
という意味ならば参考にはなるでしょう。
ちなみに、私が個人的に持っている結論はこうです。
Linuxをはじめとする、オープンソースプロダクトの多くは、非常に高速に進化を続けている。たとえばLinuxの場合、1100日の間にコードの行数は 6.5M行から 9M行へと 2.5M行増えているが、追加コード量の 1/2 が消去されていることを考えると、実際には3.75M行が追加され、1.25M行が削除されていることになる。また、Modify(変更のために追加と削除がセットになったもの)は削除量にほぼ匹敵するので、1.25M行が変更されていることになる。つまり、コード変更総量で見ると、6.25M行が 1100日で変化したことになる。ようするに3年で「ソースコードが丸ごと書き直された」に匹敵するコード量が投入されたことになる。
この結果、多くのバグが非常に短期間に除去され、また追加されている。これは次のような得失を持つことを意味する:
メリット
- 非常に高速に機能が向上する。この中には新規ハードウェアへの対応速度も含まれる
- 非常に高速にバグが修正される
デメリット
- 「安定する」と言うことがない。永久に追従し続ける必要があり、その分量は非常に多い
- 非常に高速にバグが埋め込まれる(変更量が多いと言うことは、バグの存在密度が一定ならば、たくさんのバグが入り込むことになる)
従って、オープンソース製品を利用する場合、最も重要になるのは自分たちにとって必要な機能の確定と、それらの機能を自分たちが利用しているハードウェア上で動作させた場合にどうなるか、テストし続ける環境の確保が絶対必要と言うことである。
RHELなどのディストリビューションによる違いはあまり大きくない。むしろ問題は、一旦あるバージョンをリリースした後、Updateの名で数多くの機能がバックポートされたり、追加されたりした場合、ディストリビューション固有のパッチのせいでエンバグされる可能性がむしろ高くなる事に注意が必要である。このためにも、テスト環境の確保は絶対命題となる。
また、テストの頻度は従来の何十倍にもなる。常時テストし、必要機能として問題の無いバージョンを探り、発見された安全なバージョンから安全なバージョンへと常時移動し続ける事が重要である。このためにもテストの自動化は重要な命題になる。従来、企業製品であればこれは「製品を売る企業側の問題」だったが、オープンソースの場合は「利用する側の問題」となる。
いくつかの標準的なテストに関しては、機械的にテストを行い、その結果を報告してくれる企業が存在する。しかし、それらのテストが必要なテスト内容の50%以上を満たすことは、まずない(電源断などのハードウェア障害ケースのテストをまったく考慮しないことで、テストを自動化しているからだ)。
ソフトウェア更新頻度が頻繁になるため、ソフトウェア更新をしながらでもサービスを続けられるように、システム構成を組む必要があり、またそのように評価する必要がある。旧来であれば、ハードウェア・ソフトウェアは購入時からサービス終了時まで一貫して動作し続けるのがもっともよい、という評価であったが、むしろ定期的に Active/Standby を切替え、切替による障害が発生せず、サービス継続性が維持されることをこそ、第一義に考えるべきである。
# 運用においては、Active/Standby/HW Maintenance の3つのフェーズを持つ Triplet モデルがお勧め。
# 停止中のハードウェアにはハードウェアのチェックを行って障害発病前に交換するべきである。
・テスト環境と実環境の、ハードウェアの二重化
・高速に変化し続けるソフトウェアに追従し続けるために生じるメンテナンスコストの上昇
・ハードウェアの連続運転性から、システムとしてのサービス持続性へと評価を変更し、むしろハードウェア/ソフトウェアは定期的に停止・交換・更新できる事を優先したシステム構成
の3つのポイントを考慮したシステム作りを行った場合のコストが高くつくのであれば、オープンソースは使うべきではない。
また、オープンソースを用いた商売を考える場合は、上記の点を考慮した製品作りを考えるべきである。
面白いのは、上記の点を全部念頭に置くと、Scale Out モデルしか使えなくなると言う点です。Scale Up システムは、ハードウェアが提供するサービスが all or nothing で効いてくるので、停止したときにシステム全体に与える「衝撃」がでかくなりすぎます。
fjの教祖様
Re:その辺は古すぎるし楽観過ぎ… (スコア:1)
ご丁寧にありがとうございます。
でも実は開発ツールを公開する側としての検討でして。
ちなみにウチの場合ユーザとしてはトラブっても私ども研究員各人が「ギャー」と悲鳴を上げる程度のものであり、
そこまでの高度なディペンダビリティはなくてもいい（多分、ご家庭用に毛の生えた程度の要求）かなと。
というわけで、ユーザとしてはオープンソース・ソフトウェアには既にいろいろお世話になっています。
Re:その辺は古すぎるし楽観過ぎ… (スコア:2, 興味深い)
公開するときの場合は…
管理コストは下がりません。もちろん、ディスクスペースぐらいは SourceForge のものを使うことになるので安いでしょうが、その程度です。
誰にも使ってもらえないならばともかく、誰かが使い出すとすぐバグレポートが上がってきます。それを相手にするためには、プロジェクトマネージャをはじめとして、今いる技術者は全員巻き込まれると思っていいです。
これは自分が他のオープンソースプロジェクトに参加して、自分の都合に合わせたfixを入れて2年ぐらい経つとすぐわかります。あなたが入れたコードはぼろぼろになり、あるいは新版では消され、あるいはインターフェースが勝手に変更されてしまい、自分が用意している外部ユニットとうまくつながらなくなります(特に多国語対応コードをアメリカ人やオーストラリア人が管理するプロジェクトに入れるとすぐわかる)。
ようするに「コードは常に、それを管理している人の自由にしかならない」のです。
オープンソースにしたとしても、そのコードに対する制御権を握っていないのなら「ゴミ箱に捨てるよりはまし」という程度でしかありません。と言うわけで管理権限は絶対手放してはいけません。プロダクト・マネージャは絶対必要です。
コードを公開すると、最初の内はバグフィックスばかりやってきます。それに対応できるのは、コードを書いた人たちです。つまり今いる技術者は減らせませんし、別のプロジェクトに割くこともできません。
そのうちコードを提供してくれる人も出てくるでしょうが、それをマージする・しないを管理するためにも技術者は必要です。
最後に、プロジェクトを魅力的に見せるのは、そのプロダクトではなく、関与している人です。関与している人が魅力的だと外部から協力者が現れます。が、ここでいう「関与している人」とは 100% 「コードを書いている人」です。つまりトップエンジニアを別のプロジェクトに裂く事はできないのです。
じゃぁ、何がうれしいのさ
今いる人数で、今いる人数よりも多くの人数がいないとできないことができるようになるかもしれないという部分がうれしい。外部からのコード、外部のコード開発者などが提供したコード分が加算されるわけですから。ただし、増幅率は博打になります。また、増幅「率」なので母数を0にすると、結局0になります。
「一人当たりの生産性」のような「割合」系の値はよくなりますが、コストダウンには全くつながらない、というのがオープンソースの基本です。
.
もちろん、自社の技術力を外部に公開することになるわけですから、社外へのアピールにはなります。またその過程で社員の中に有名人が出てくる可能性は高いでしょうし、そういう人たちはセールスやプリセールスなどで大きな力となるでしょう(営業がそれらの人を連れて行くだけで、売り上げが何パーセントか違う、という状態にはなる)。
また、非常に、非常に、非常にまれですが、大成功するとデファクトスタンダードを決定する権利を手に入れられる可能性もあります。
.
弱点としては、自分たちがコストをかけた製品で、他社が商売をし、あまつさえ成功する危険性があります。昔の Cygnus Solutions に対する RedHat や SuSEのようなものですね。しかし、うまくすると、それらの中の会社のひとつが、自社を買ってくれるかもしれません。昔の Cygnus Solutions が RedHat に買われて、cygwin.com で商売を続けているのと同じですね。この辺は塞翁が馬になります。
fjの教祖様
Re:その辺は古すぎるし楽観過ぎ… (スコア:1)
バグ対応の件はツールを外部提供する場合一般の問題で、ソース秘密にしたときでも来るんじゃないかという気がするんですけど、そうでもないですか？
オープンソースだと配布対象を絞りにくいというのはあるかもしれませんが。
でもユーザ数に関して言えば逆に新規の開発ツールを公開しても、ユーザなんて大して/全くいないという可能性も結構ある気はしますが…。
Re:その辺は古すぎるし楽観過ぎ… (スコア:1)
プロプライエタリの場合、バイナリを提供するのは基本的に金銭の授受を必ず伴うはずです。技術者をバグ対応のために確保するコストは、その一部を割り当てることができます(というか、ソフトウェアの「料金」には一般に維持管理費用が含まれる)。オープンソースの場合はそのような金銭の授受がないまま、バグレポートだのパッチだのが飛んできて、対応しないと一方的に悪者扱いされます。その意味では「出費はある」わけです。
しかも、技術者の確保は「バグのレポートがあってから」と言うわけには行きません。何よりも、オープンソースプロジェクトに飛んできたバグレポートが「ないことを確認する」ためのコストでさえ無料ではありません。そういう意味ではコストはジリジリとかかっていきます。たとえユーザがいない場合でも。
.
あ、あともう1つ忘れていました。「既存のソースコードを公開する」場合には2つ、非技術的な問題があります。
1) コードの中にある技術的優位点(特許などの権利をも含めて)を放棄していること
2) 株式会社の場合 1 は「資産の放棄」なので、株主に対して事前に許可を取っておく必要があること
fjの教祖様
Re:その辺は古すぎるし楽観過ぎ… (スコア:1)
いろいろどうもでした。
取りあえず予想外の横槍が入らなければOSS化する方向になりそうです。
サポート大変そうですが、まぁそんな大量のユーザが見込める代物でもないのでなんとかなるかなと。（サポートが大変なくらいユーザがつくならむしろ幸せかもｗ）
まぁ、個人的にはプロジェクトが不幸にも継続しそこなってチームレベルで開発者が散逸した時に権利関係にトラブルを抱えず開発が継続できるようにするための保険的な意味合いが大きいんじゃないかと思わないでもないですが。（ぶっちゃけ私はユーザでもあるのでD論書くまでの間に使えなくなると困る。）
特許は、現状とりにくい見込みの上に、仮に苦労の末取れても旨く使えない体制（会社組織でも営利企業でもないし、資産価値を見積もるスタッフもいない）なので、もう自前でとるのは断念してよそに取らせないために公知にしておこうという方向のようです。
Re:その辺は古すぎるし楽観過ぎ… (スコア:1)
ところで、ウチの場合、費用は基本的に委託研究費名目でくるので本格的な開発やサポートを求められるとどっちみち桁一つ足りないケースが多くて…。