生き残らなかったオープンソースは犬死にか

　といったあたりを指しています。激しい競争の末，これらを十分に備えていないと判断されたソフトウエアが，結果として生き残れなかったわけです。

　ここで注目するべきことは，これらの評価は基本的には「使いものになるかどうか」というモノサシで評価されているということです。

　美しいコードは直接的にはどうでも良さそうなことですが，いろいろな意味での品質も良いでしょうし，メンテ性もいいことが期待できます。また，拡張するのにも良いでしょう。だから，多少未熟なものであっても美しいコードであるなら生き残るチャンスがあります。

　バグの量は言うまでもないことです。どんなに「いい」ソフトウエアであっても，バグが多くて実用に耐えないようでは使いたくありませんね。まぁ多少バグがあっても，他が圧倒的に優れていたなら生き残るチャンスはありますが，やはり実用ソフトウエアの基本は「安心して使える」ということです。またバグではなくても，途中で妙に重くなったりするソフトウエアはあまり使いたくありませんから，そういったことがないということも大事です。

　完成度が高いというのは，例えば必要そうな機能が過不足なく，自然な使用感と共に使えると言えば良いでしょうか。「こういった機能があって当然だよね」「ここでは当然こうしたよね」といったことが自然であればある程好まれます。まぁ機能が十分あれば使用感が多少悪いものは「奥が深い*2」という言い訳もあるでしょうが，それでも必要な機能が揃っていないと使いものになりませんね。

　また，「パッケージ的に使いやすい」というのも完成度に含まれます。これにはドキュメントが揃っているとか，インストールが楽だとかということも含まれます。あるいはコミュニティがちゃんとしているかということも大事な要素であることは少なくありません。

　これを見るとわかりますが，ここには技術者好みの軸，例えば，

　というようなものはありません。これは「使いものになるかどうかということに，これらは実は関係ない」という意味ですが，これはひっくり返せば「使いものにならないと評価されたからと言って，これらの要素が否定されたわけではない」という意味でもあります。

　「実用」という観点に立てば，前者の見方は大切です。実用品を作るということは，妙にとんがったものを作るよりは，堅実にバランスの良いものを作らなければならないということです。つまり，どんどん先進的なものを目指すよりは，安心して使えるものが求められる。途中でこの辺をはき違えると，せっかく着いてくれたユーザーにそっぽを向かれることにもなりかねません*3。

　しかし，そういった「実用」一辺倒なものだけがオープンソースではありません。

　新しい技術を試してみたり，新しいアイディアを実現してみたりという要素がなければ，そもそもやっていて楽しくありませんし，進歩がありません。技術的な「チャレンジ」がなければ，退屈なソフトウエアを業務命令で書いているのと同じです。既に確立した地位のある定番ソフトウエアであれば，「チャレンジ」なんかよりは「実用品としての安定性」の方が大事だと言えますが，「これから」の世界には「チャレンジ」は必要です。

　このことは「使いものになるかどうか」とは別の軸のことです。「技術的開拓を目指すソフトウエア」は「使いものになるかどうか」の軸では良い評価がされるとは限りません。作業に向けられるエネルギーは有限だということを考えれば，大抵は「カス」と評価されてしまうでしょう。ですから，実用品として否定されたということが，すべてを否定されていると考えるのは早計です。

*2 バッドノウハウと「奥が深い症候群」
http://0xcc.net/misc/bad-knowhow.html

*3 この例についてのいずれ盛大なdisりを書きたいと思っています。書かないで済めばいいのですが。