フリーソフトがソフトウェア産業を滅ぼす
フリーソフトは、浅はかである。自分でフリーソフトを公開している立場で言うことではないかもしれないが、私の考えではフリーソフトは残念ながら悪い面も多く持ち合わせている。
私がフリーソフトを公開しているのは、実は社会的に悪影響を及ぼす可能性もあることを知っていながら、やむを得ず公開しているのである。この点は、フリーで多くの人に使ってもらえること自体に喜びを感じているフリーソフトの作者とはずいぶん違うのである。
ただし、語弊の無いように言っておくが、全てのフリーソフトが無くなってもまた困りものである。
どこかでバランスを取る必要があろう。
しかし、それはかなり難しい事柄であり、簡単な解決策は見つからない。
私の考えでは、フリーソフトが氾濫すると、ソフトウェア産業界が潰れ、結局はソフト作者自身の首をしめることにも繋がると考えている。
簡単に例えるなら、1000円のラーメン屋の前で、入手先不明の安いラーメンを売っているのと似たようなものなのである。多少極端かもしれないが、この例と同様に「営業妨害」的な側面を持っているのである。
しかも、ラーメンの場合、妨害の犯人には旨みがあろうが、フリーソフトでは事情が異なる。
「共倒れ」になりかねないのである。
ここで重要なことは、一般の競争原理とフリーソフトとには違いが有ると言うことである。
競争原理が望ましい点は、競争を行うことによって、よい商品や何らかの結果が生まれてくることである。
しかしこのとき、「競争に勝ったもの」が、何らかの「利益」を受けることは、通常、暗黙の前提になっている。
フリーソフトでも（激しい）競争は行われているが、フリーソフトを公開している側に取っては、基本的に何の金銭的な収入も得られていない。つまり、どんなに競争の勝利者になったとしても、何の利益も受けない可能性も多いのである。
シェアウェアの場合でも、実際には大きな収入にはならない。
よほどヒットしたシェアウェアでない限り、通常のサラリーマンの収入の数パーセントにも及ばないのが現実である。
これは、ベクター社のソフトライブラリのホームページを注意深く読むと知ることができる。
この会社は、シェアウェア代行サービスも受け持っているが、その代行サービスがどれくらい利用されたかを把握している。シェアウェア全体を合わせても、非常に小さな額であるらしい。そういう趣旨のベクター側からの文書が見つかるだろう。
共産主義についての詳しい知識があるわけではないのであまり正確なことは議論できないが、２０世紀後半になって、共産主義は、大きなところでは事実上崩壊したと言えよう。
共産主義社会が理論上よい社会をもたらすと考えた人たちがかつては少なからずいた。
しかし、共産主義を実践した国々の国力は次第に弱体化していった。
食べるものがない、服が無い、水道・ガス・電気が満足に供給されない。そう、つい最近まで、共産主義の代表的な実践国であったソビエト連邦では、国民が餓死寸前までの苦境に陥っていた。
（しかし、面白いことに、宇宙開発などでは国際的にもすばらしい実績を残していた。腕時計が買えないのに、宇宙ステーションは作れるたのだ。）。
共産主義では、働きの出来に応じて給料が払われるシステムではない。通常、何事も人によって働きに差が出てくるが、それが生まれながらにして決まっていることも少なからずあるかもしれない。
生まれながらにして決まっていることだけで給料に差が出るのだとしたら、余り理想的な社会とはいえないかもしれない。基本的に共産主義は、そういう観点に基づいて発想されたものである。
しかし、共産主義の失敗は、実は、この「働きの出来に応じて給料が払われない」という根本的原理によっていたのであった。確かに、先天的、遺伝的な差や、親の資産などによって、個人個人の価値や将来が決まってしまうのは、余り理想的ではない。だからと言って、「同じ職業なら全ての労働者の給料が同じ」という原理は、破綻してしまうのである。
日本での身近な例で考えると、共産主義は、20世紀の伝統的な日本のサラリーマンの制度に近いのである。
つまり、年功序列制で、基本的に同世代での給料が等しいシステムである。
このシステムだけでは、労働者がやる気をなくし、よいアウトプットが生まれてこないということは、日本全体で大々的に議論されているのはご存知だろう。
実は、これが共産主義が失敗した原因なのである。
つまり、「出来高」「結果」「働きっぷり」に応じて何らかの評価が与えられなければ、人間と言う動物は、うまく機能しない。人間と言うのは、適切に評価されたときに最高の結果を出せるような生き物だったのである。
共産主義の実験からして、給料が同じままで「各人がまじめに」「最高の働きをするように」と、いくら道義的（道徳的）に促したとしても、実際にはうまく行かなかったのである。
社会で評価される指標は、もちろん給料だけではない。
しかし、研究者などは個人的に歴史に名を残せる可能性もあるが、その他多くの労働者の評価で最も大きな部分を占めるのは、世知辛いことかもしれないが、やはり給料なのである。
よい働きをすれば給料を多くもらえることで、労働者は「頑張れば評価されるのだ」と感じ、「次はもっと頑張ろう！」「もっと技術を磨こう！」と努力するものなのである。
この点は重要である。
この原動力が働いてこそ、よい商品や、価値が生まれてくるものなのである。
フリーソフトは、こういった事を阻害することと無関係であるのだろうか。
ソフトの規模が小さすぎれば、採算面から考えてメーカーが提供できない類のソフトも有るだろう。現実問題として、簡単なものであればメーカーが売る前に誰かがフリーで提供する可能性も高い。だが、もし、フリーソフトというものがこれほどまでに広がっていなかったら、規模が小さいものでももっと丁寧で品質の良いものを、有料でメーカーが提供してくれていたかもしれない。基本的に著作権問題やいわゆる「主製品を売るための過度なオマケ」や「独占禁止法」などに抵触しない限り、ただで物を提供することを禁止する法律は今の所ない。
しかし、資本主義世界では、人々が「生き生きと生きる」ためには、「物やサービスを生産して対価を得られる」ことは最低限必要なことである。
また、「生産した物やサービスの付加価値にほぼ比例して対価を得られる」ことも、不公平感を少なくするためには必要なことである。
フリーソフトはただで配られているが、それを作るのに要した時間や手間、必要な技術力や購入した資料などを考えれば決して「無価値」な分けではない。
トップメーカーが手間隙かけて作ったものと比べれば及ばないだろうが、ただと考えるには少々無理があるような優れたフリーソフトも存在する。
しかし、それを有料で売ることができるかを考えてみれば、無理と思えるケースも多い。無料だから使ってくれるが、有料にしたとたんに見放されるのが容易に想像できるものも多いのである。
しかし、この理由を考えてみると、その背後には、「別の作者がすぐフリーで提供してくれるから」という理由も存在している。もし、フリーソフトを原則禁止にしたとすれば、このような状況が打破される可能性もある。
もちろん、そのような制度を作ることは、非常に慎重になるべきである。
その制度が、フリーソフト全般を消滅させてしまうとしたら、問題は大きいだろう。
そんなに簡単なことではないことは分かっている。
フリーソフトが行なっているのと同等の分野のソフトを、企業が専門家を使って本格的に開発したとすると、多くの場合、フリーソフト以上のものが出来てしまう可能性が高い。
ただ、実際にはその分野に向いた力量を必ずしもそのプロジェクトに携わる「プログラムの専門家」が持ち合わせているわけではないので、場合によってはそうではない場合も否定は出来ない。
しかし、プロは、フリーソフトの作者が費やすよりは、はるかに長い時間を通常は費やす。また、大抵の場合、一人でマニュアルからサポートまでを全部行なうわけではない。
お金を出してもマニュアルやサポートまでのトータルな面で「良いソフト」が欲しくなるときが有るが、現状では、期待に反して、市販ソフトの種類が十分ではないように思える。フリーのソフトはやはりフリーなのである。フリーソフトの作者でも、技術レベルはプロに劣っているとは限らない。しかし、ある一線を超えると「それで食っていけるわけではないのだから」そればかりに労力を費やすわけには行かないはずなのである。それに対してプロは、その仕事に全力投球できるのである。
フリーソフトの「氾濫」は、良いソフトができる可能性を奪っていないだろうか。
深い考えも無しに「フリー化」してしまうのは私は反対である。
商用アプリケーションそっくりの、オープンソースアプリケーションが出現してきている。
今でも、Microsoft の Office 製品（Word, Excel
など）は、企業の中では事実標準になっている。
日本国内では、かつては、JUST SYSTEM
の「一太郎」がシェア第一であったが、いつのまにか、「Microsoft
Word」
がどんどんシェアを伸ばしていった。その理由を議論することはここでの本題ではないので置いておく。
この商用 Office
製品に、将来的に匹敵する可能性があると言われているのが、Open
Office である。
今現在、商用 Office
にとっての脅威にはなっていないが、もし認知度が上がったり、国別カスタマイズが進めば、商用
Office のシェアを奪っていく可能性もある。
これに対する反論として「オープンソースソフトにも負けるぐらいのソフトしか作れない、商用ソフトの方がレベルが低いのである。」などというものがある。しかし、オープンソースソフトの作者陣営には、職業プログラマも多くいるし、また、職業プログラマ予備軍も多くいるのであるから、同等の分野の商用ソフトが負けてしまうのは、何も、一概にその商用ソフトのプログラマ陣営のレベルが低いとは言えない。場合によっては、最高レベルの技術者がオープンソースソフト作成に協力している場合もありうるのだから、、、。
また、次のような反論もある。「パッケージソフトウェアのプログラマ需要を減らす可能性はあるが、カスタマイズ（ソリューション）分野は残っていくだろう。オープンソースソフトを、個々の企業にカスタマイズする仕事は減少しないだろう。」
しかし、この反論には、次の二点で再反論できる。
「お金が社会を良くする」効果をご存知だろうか。
通常、経済が正常に回転している場合、社会が求めるもの、需要が多いものは、よく売れる。
よく売れれば、研究開発に回る資金が増える。たくさんよい人材を雇えるようにもなれば、良い機材や設備、開発環境、などを用意できるようになる。
一方、社会が求めていないもの、需要が無いものは、余り売れない。
このような製品は、それ以上開発が続けられなくなり、開発自体が停止する。
上で言った「社会を良くする」と言うのは、「便利な商品が生まれやすくなる」、というのが正しい意味であるが、お金が適切に回転している社会ならば、「生活が苦しい」状態にはなりにくいものなのである。なぜなら、「生活が楽になる商品（物やサービス）」が「生活が楽にならない商品」よりも生み出されやすくなるからである。
それは、前者の方が、後者よりも、より需要が多いからである。需要が多ければ、お金が入り、多く提供されるようになる。
しかし、上のような状態にするためには、「需要が多い商品を作った企業や開発者などが、より高い収益を得られること」が前提になっている。どの企業も平均的に収益が得られるような状態では、決してこのような好循環はおきないのである。
このため、需要が多い商品を作った企業が儲かり、需要が余り無い商品を作った企業が縮小する、というのが、社会が楽に暮らせるようになるためには重要なのである。
実は、「好況」とは、「経済がうまく回転している状態」でもある。「不況」とは、「経済がなんだかよく分からない方向に動きやすくなり、不条理が生まれやすくなる状態」でもある。
しかし、一般によく言われる「不況」の本当の意味は、直接的にはこうである。
「物が売れなくなり、商品が売れ残り、在庫が大幅に残っている状態。
供給が需要を大幅に上回っている（＝供給過剰）状態」
しかし、この状態をよく分析してみて欲しい。
物を作っても売れないのである。つまりは、自分たちが一生懸命何かを作っても、ほとんど売れない状態なのである。
「なぜ売れないのか？」と人々が悩むのは当然である。なんだか分からなくなるのは当然だろう。
こういう状態になると、自殺者などが増加する。
まず、こういったことを理解した上で、フリーソフトについて再考してもらいたい。
フリーソフトは、良いものを作ったとしても、通常、基本的に収益は得られない。
また、悪いものを作ったとしても、収益が下がることも無い。
このような状態だと、良いソフトを作った作者も気が変われば、その時点で開発を終了してしまうことになる。
ただ、オープンソースであれば、誰かがその後を引き継ぐ可能性もある。
しかし、ここで、よく考えなければならないことは、引き継いだ後のソフトの出来が悪かろうが良かろうが、ユーザー（＝社会）から、ほとんど何のコントロールも効かないことには変わりが無い。
もし、良いソフトを作った企業が、きちっと、それに応じて収益を上げていたならば、そういうソフト会社に腕のいい技術屋が就職して、さらに、良いソフトを作って行く可能性が高い。良いソフトを作ったソフト会社も儲からないのであれば、そういう現象は起きないだろう。
オープンソースのソフトウェアは、最初から有志のプログラマの手によって作成されていたとは限らない。
最初は、ある企業Ａがクローズドソースの方法で、かなり商用的に競争力のある製品として作成していたものであることもある。
それが突然オープンソース（価格が無料でもある）になったとしたら、競合他社（仮にＢ社とする）はどういう影響を受けるだろうか。
その商品（仮にＭとする）は、もともと、無料にしても、競合他社が全く影響を受けない商品だったのであろうか。
いや、実際には、少なからず競争力を持っていた商品なのではないか。
こんなことをしても、Ａ社に何のメリットがあるのだろうか。実は、この行為により、Ｂ社に与えるデメリットはあっても、Ａ社がその商品Ｍから直接受けるメリットは何も無いのである。なぜなら、商品Ｍがいくら「配られても」、その商品自体からＡ社が収益を得ることは無いからである。
企業が、海外でシェアを確保するために、原価や費用を無視して、採算割れ覚悟で物を売り、その埋め合わせのために国内の商品の値段を上げることがある。しかし、これは、法律上「ダンピング行為」と言って、禁止されている。
しかし、ある商品Ａの値段を下げることによる副作用を使って、別の商品Ｂで儲けようとする行為は、この「ダンピング行為」と根本的には同じではないか。
経済が正常に回転しているならば、「お金が社会を良くする」という作用があることは既に述べた。
そして、その前提として、「商品の価値に応じて利益が得られる」ということが無ければならないことも述べた。
今述べた、「ダンピング」まがいの行為が、何となく変に思うのは正常な直感である。
この前提を崩している行為だからである。
今、あなた（がた）が、あるソフトウェアを開発していると考えて欲しい。
そしてそれが、そのまま順調にある目標まで完成すれば、一定の収益が得られることが確実だったとする。
そのとき、今まで高額だった他社の競合商品が、いきなり無料で配布されたとしたら、どういう気持ちになるだろう。
このように、突如としてフリー化するようなソフトウェアメーカーが増加すると、開発計画も立てられないのではないか。
「ソフトウェア産業」が非常に不安定になっていくのではないかと思うのは私の独り善がりなのだろうか。
プログラムの規模が大きくなった場合、一人でプログラムするのは難しくなってくる。
その場合でも、ソースをみんなで見ながら、全体を好き勝手にごちゃごちゃに作っていくと言う方法は取るべきではない。 この考え方は、私が個人的に主張している方法論ではない。多くのソフト屋が昔から経験的に知っている事柄なのである。
複数人で一つのプログラムを作る場合、「明確な分業」を行なうべきなのである。
まず、通常は、プログラム全体の構造を決めてしまう。
次に誰がどこを担当するかを決める。
そして、これは意外に忘れられがちなのだが、最も重要なことに「仕様書と実際の機能を合わせる」ということがある。
実は、各部分の担当者が、それぞれ完全に担当の部分の仕様書どおりにプログラムを実装している限り、全体を結合しても、それは正しく動作するのである。
これは、「ブラックボックス」の考え方である。
ブラックボックスとは、入力に対して定義された通りの出力が出てくる装置のことである。数学で言う、関数
y=f(x)
と全く同じ概念である。内部がどのような構造であるかは考えない。
数学の sin(x)
関数の整級数展開（テイラー展開）を知らなくても、sin(x)
関数の意味と使い方は理解できる。
これがブラックボックスの考え方である。
大きなプログラムは、全体をブラックボックスの集合で構築するべきなのである。
決して他人が作ったものの細部まで自分が理解する必要は無いのである。
プロジェクトの各人は、自分が担当した部品について細心の注意を払って、最も効率の良いコードを作る。
そして、場合によっては、設計当初では予想できなかった変更点を踏まえて仕様書も若干変更する場合もある。
ある部品の仕様が変更されれば、全体を当初の設計どおりに結合しただけでは当然正しいプログラムにはならないが、修正がある範囲内であれば、もう一度全員で「申し合わせ」を行って「連結部分」を「すり合わせ」ればちゃんと当初の予定通りに動作するプログラムは出来上がる。
ここで、大事なことは、「仕様書と実装を一致させる」ことである。もし、ブラックボックスのブロックダイアグラムが正しい場合、各ブラックボックスの実装が「正しく」行われているだけで正常な動作が行える。
そして、もし、結合後のプログラムが正しく動作しない場合、仕様書と違った実装を行っている部品を探し出せばよい。もし見つかればそれが「バグ」の原因と特定できる。
このようにしていけば、多人数のプロジェクトで、「誰が犯人か」が明確になる。
バグとバグで無いものが明確になる。
バグとは、「仕様書のバグか、または、仕様書と実装がずれていること」と定義すればよい。
仕様書のバグは、プロジェクトリーダーの責任と考えられる。
このようにすれば、バグであるのに責任逃れをすることは出来ない。
また、バグで無いのに、責任転嫁される恐れも無い。
このようにすれば、プログラマー世界に実力主義を導入できるだろう。
他にも大事なことがある。それは、
「他人のプログラムに影響を与えないようにコードを書くこと」
である。
このことは、オブジェクト指向などでも認められている。「隠蔽」とか「カプセル化」などの根底に流れている一つの理念は
「知る必要の無いことを知ってはならない。
知らせる必要の無いことは知らせてはならない。
知らせることによって、後の改良の妨げになる場合がある。」
「オブジェクトの種類が変わったときに、こちらのコードに変更しないようにするために、
オブジェクト自身がやるべきことはオブジェクト自身にやらせろ。」
などといったことなのである。
これも、私の独自理論ではない。
数多くあるオブジェクト指向の書籍をご覧いただければ、上記の事柄は詳しく解説されているはずである。
大量のソースが全部公開されていることは、むしろ、現代的なプログラミングの方法論に反していると言える。
内部構造が丸見えだからだ。
何が公開されていて、何が非公開なのかの区別が明確に出来ない。
それを全部解読するのは時間の無駄でもある。
その必要は無いのである。
プログラムの開発法には、大きく分けて二つの方法がある。
一つは、クローズドソース法であり、もう一つは、オープンソース法である。
前者は、ソースを一般には公開せず、選び抜かれた少数のプログラマだけで、プログラミングする方法である。
後者は、ソースをネットワーク上で一般に公開し、誰でも無資格で、プログラミングに参加できる手法である。
クローズドソース法では、なるべく優秀な人材を選び抜き、プログラム能力が一定の水準を越えていない人のプログラミングへの参加を許さない。ソースは、一般には非公開となるので、その開発者達が独自に研究・発見・開拓したプログラミング上の手順（アルゴリズム）や、理論、仕組みをふんだんに使いながら、しかも、競争相手からそれらの技術を隠すことが可能である。
いずれの方法も、原型がいつから始まったのかは厳密には分からないが、ほとんどの商用のプログラムは、クローズドソースで作られてきたといえる。一方、コンピュータが発明され、まだ、一部の人たちだけがコンピュータの基礎を作っている時代には、ソース公開が良く行われていたらしい。今でも、プログラムの学習のためや、サンプルプログラムを示すためにはソース公開が行われている。また、ソフトウェアの研究や、情報数学の研究を行う際には、ソース公開が好まれている。
最近話題の、Linux
は、カーネル自体は、無料であり、かつ、オープンソースである。
オープンソースと言うのは、単にソースが見れるというだけではない。
開発自体が多人数によって公開の場で行われていることを意味する。
この開発の場は、コミュニティーと言われる。
オープンソースは、クローズドソースの反対語である。
クローズドソースは、ソースを機密扱いにし、公開しない。
しかし、オープンソースとクローズドソースの違いは、単にそれだけではない。
クローズドソースのプログラムは、緻密な設計に基づいて、限られた人、選ばれた人たちだけによって開発されるプログラムである。 クローズドソースのプログラムは、一般に緻密な設計から始まる。プログラマを厳選することで、質の高いプログラマを確保する。全般に渡って各人が緻密な作業を行う。細部まで注意をし、基本的に「他人がなるべくいじらない」ようにする。そして、徹底的にテストを行って製品を販売する。
一方、オープンソースのプログラムは、プログラマは一般から公募する。資格などはいらない。
どんな質のプログラマが参入するかは予想できない。
その代わり、大量の「目」によって、ソース中のバグの監視を行うことができるとされる。
（しかし、これは、本当だろうか！？）
GPL ライセンスをご存知だろうか。
GPL とは、COPYLEFT とも言われる。COPYRIGHT
と対峙する言葉である。
GPL ライセンスは複雑であるが、基本的には、
1.GPL
のプログラムは、必ずソースプログラムを公開しなければなら無い。
2.GPL のプログラムを一部を修正しても、また、GPL
のプログラムとなる。
という数学的帰納法によって定義される。
結局のところ、上記の規則を適用すると、GPL
ライセンスのプログラムから生まれた子孫のプログラムは全て
GPL
ライセンスになってしまうことになる。そして、結局、家系図上の全てのソースプログラムを公開せねばならない。
典型的な GPL の C コンパイラに、GCC がある。
GCC
は、多数のプラットフォームに移植されている良く知られたCコンパイラである。
GCC
は、プラットフォームごとに完成度に差が有り、一概に性能を比較することは出来ない。
しかし、PC 上の典型的な GCC の評判は、
「なんとなく使えるようで使えないような気がする、、、。」
「最適化は、非常にうまくいく場合もあるのだが、実践的なプログラムでは突然妙なコードを出してしまう
場合があるようだ。」
「多くのCソースプログラムはコンパイルできるようだが、本格的に使おうとすると、なぜか不思議な場所で、
GCC
自体が落ちてしまったり、予想外なコードを出す場合があるような気がする。」
「コンパイル速度が極端に遅い場合がある。」
と言うようなものが多い。
実は、GCC
について語ると、一大議論が巻き起こることがあり、ネット上でも敢えて今まで触れたことがなかった。
実際、「GCC
は非常に良く出来ている」という事を言っている人もいる。
しかし、個人的に実際に使ってみようとすると、不思議に評判通りのよい印象を受けたことがなかった。
このように感じている方は他にもいらっしゃるだろう。
身近な知人に GCC
について語ったとき、すごい反論をされたことがある。しかし、知人の主張は、納得できなかった。
なぜなら「実際、動かなかったのだから、、、」。
私が手に入れた GCC では、本当にそうだったのである。
しかし、GCC
はオープンソースであるので、いくらでもバリエーションがあり、もっと質のよいものも中にはあるのかもしれない。
そういうことで、結局は、「探せばどこかに良いものが有るのかもしれない」ということで終わるしかない。
しかし、GCC
のソースを見たことがある方はお気づきかも知れないが、正直言って、お世辞にも美しいプログラムとは思えなかった。
ソースの場所場所で美しさが全く違うのである。
私は必ずしも、ソースの整形的な美しさを言っているわけではない。ソースの論理的な美しさについて言っているのである。ある部分では、非常に美しい論理が用いられている。しかし、他を見ると、全く回りくどくて、初心者的なプログラムがされている。
結論を言うと、これが「無管理の」オープンソースによる弊害と言うことであろう。
結局のところ、GCC
のトータル面での安定性は低いと考えられる。
ある時期のどこかでダウンロードしてきたバージョンは、非常に安定しているかもしれない。
また、ある特定のプログラムでは非常に正確で、しかも効率の良いコードを出力する。
しかし、こういった条件を取り除いた場合に、安心して使えるものだとは言いがたい。
それはある意味当然ではないか。とある系統の GCC
の開発に関与した人がこれまで 100 人だとする。
少なくとも、最初の開発者は、最後の開発者の改造までは責任を持てない。
彼は、予知能力者ではないはずだからだ。
また、最後の開発者も必ずしもそれまでの開発者の意図を全て正確に理解できているとはいえない。
しかし、他の部位を正しく理解せずに修正を施すと、思わぬときに問題が起きるかもしれない。
このような問題は簡単なテストでは分からないのだ。
何万種というソースを実際にコンパイルしてみてやっと判明するような不具合が入るかもしれないのだ。
しかし、フリーで開発している立場上、そこまでテストするわけには行かないだろうから、危ういものなのである。
非常によく設計されたプログラムは、ソースの一部を見るだけで全体を読まなくても正しい修正が行える。
どのようにすればこのような書き方ができるかは、非常に古くから非常に多くの人によって研究されてきた。
結局、ソースの部分部分の独立性を高めるということが、基本的なポイントなのである。
そして、そういう事を追求した具現の一つがオブジェクト指向であると言える。
しかし、オープンソースでは、そのようなことを踏まえている人たちだけが開発者ではないから、それに反した、
言わばその場しのぎのコーディングをしてしまう人も出てくるのだ。
そして、ある時、非常に優秀なプログラマにそういう歴史を繰り返したソースが渡ったとする。
果たして彼は、その状態のプログラムを簡単に理解できるだろうか。
おそらく経験的には、そういう優秀なプログラマは、そのまま理解するよりも、ソースを読みながら、
プログラム全体を綺麗に書き直すことを試みるだろう。
しかし、歴代のプログラマが積み重ねた「汚点」を一掃する前に、あきらめてしまうかもしれない。
それは彼に任されている、、、、。
しかも、彼がどんなに努力しても、所詮、「修正者」という立場は変わらないのだから、大して社会的
地位が向上したりすることはないだろう。
それでも、彼は慈善事業を続けるのであろうか。
答えは、現在の GCC に出ているのではないだろうか。
しかし、全てのオープンソースプロジェクトが、このように「無管理」であるとも一概には言えない。
もしかすると、優秀なプロジェクトリーダーによって、うまく管理されているプロジェクトがあるとすれば、それは、うまく行っているかもしれない（実際、Linus
はカーネルのソースをよく管理していると聞いている。）。
一概には言えないことは確かだろう。
ソフト屋はみんな、他人のソースを見るのが好きと考える風潮も有るようだが、他人のソースを見るのは私は好きではない。そういった感覚を持っているのは、私だけではないだろう。
それに、他人のソースを見ると勉強になると言う人がいるが、勉強になるくらいのソースが書ける人は意外に少ないようである。
Linux
や GNU-C
でも、原作者の腕は恐らく非常に良いのだと思う。しかし、後から手を加えた人々の腕については必ずしもそうとも言えないだろう。手を加えたとしても改良したとは限らない。後から手を加えたとしても、OSやＣ言語を作った、ということは全く違うと私は考えている。
他人のソースに手を加えたのと、自分で０から構築するのとでは必要な技術力の種類が全く違う。
これは、他人のソースを読めることが、０から構築するよりも簡単であるといっているわけではない。
両者に必要な技術が、「種類が違う」ということである。
しかし、私が経験的に感じたことの一つに、０から作った人のそのプログラムのテーマ関する理解は、一部を加筆・修正した人の理解よりも、深くて正しい場合が多い、と言うものがある。そして、深くて正しい理解に達している人の方が、間違いなく、かつ、適切、最小の修正方法を見出すことができる、ということである。
一般に、多人数の人が無秩序にソースをイジクルとろくなことが無い。
それは、先ほど GCC の例でも書いた。
ソース配布、というのは、一部の人間以外にとっては何も面白いものではないのではないか、と思うことがある。
むしろ、私などは道具としてのＯＳを必要としているのである。ＯＳは遊びで私も作ったことはある。しかし、通常は、出来上がって動作保証されているＯＳの方が必要な場面が多いのである。
例えプログラマにとっても、ＯＳのソース公開が重要な意味を持つかは疑問である。
ＯＳは、仕様を正式に公開していることが重要である。仕様書は、今現在のＯＳの機能を完全に網羅しているというものではない。ＯＳにおける仕様書と言うのは、基本的に将来にも渡って保証される事柄を書いたものである。
仕様書に書かれていないことでも、その時点のＯＳが一時的に持っている特徴や機能があるかもしれない。しかし、仕様書に書かれていない一過性の特徴に基づいたプログラムをしたり、仕様書に書かれていない機能を使ってプログラムしたものは、次のバージョンで正常に動作するとは限らない。
ソースが公開される理由には、大きく分けて次の３種類くらいあるだろう。
1.
の理由で公開することは、ハードウェアの仕様の公開のためであれば、ユーザーに取ってはメリットが大きいと言えるだろう。
しかし、ソフトウェアの技術を一般に公開することは、アマチュアユーザーにとってはメリットにはなっても、プロの同業他社への営業妨害的なマイナス面をもつだろう。
一方、2.や3.
の理由でソースを公開することは、それ以外の選択肢が存在しないからであって、ユーザーのメリットを考えてのことではない。
ターゲット環境の仕様が文書化されていないため、環境があっという間に変化してしまう。
その環境で動かすプログラムは、大まかにしか、環境を仮定できない。
せっかく、充分テストしてプログラムをデバッグしたつもりでも、環境の方が変化するために、ユーザーレベルでは不安定な挙動を示しがちになる。
もし、バイナリで公開していたら、環境が変化したときに、そのプログラムが全く動作できなくなってしまう。
環境の変化に対応するためには、ソースを公開せざるを得ない。たとえ、公開したくないほど、研究に研究を重ねたアルゴリズムや発想が使用されているプログラムであっても、ソースを公開しないことには、ユーザーの環境で動作できない。
これらは、ソフトウェア開発者が望んだところではなく、単にそうせざるを得ない状況であることを示している。
このような目的でのソース公開は、単にアプリケーションで何かをすることが目的のユーザーに取っては、面倒なだけでメリットは全く無い。
なお、ソース公開すれば、自分達がせっかく生み出した手法を簡単に盗まれてしまうことになる。
技術力を売りにしているソフトメーカーほど、ソース公開のデメリットは大きいのである。
Linux は、Linus
が開発を開始し、オープンソースの開発手法を用いて開発されている、UNIX
に互換性のある基本部分がフリーの OS である。
Linux の
カーネル（＝基本部分）は、ソースが公開されていて、かつ、無料である。
しかし、このカーネル本体に、GUI や漢字フォント、日本語FEP
などを付加したものが、多数の団体によって販売または、配布されている。このような形態のものを、「ディストリビューション」と言う。
今のところ、主要なディストリビューションでは、Linus
陣営が管理している、同一の
カーネルを用いている。ただし、用いているカーネルのバージョンは、ディストリビューションによって異なっている。
ディストリビューションには、ネットから無償でダウンロードできるもの、雑誌の付録に付いてくるもの、店頭で販売されているもの、がある。
一般人が最も安心して入手出来る店頭パッケージ版は、一万円前後から、五万円前後で販売されている。
ただし、雑誌の付録についてくるものでも、店頭パッケージと比べて機能が低いとも一概には言えないので、どの形態で入手すべきかは、ディストリビューションやバージョンによって事情が異なる。
しかし、これらの機能差を知るのは容易ではなく、何らかの情報誌に頼った方が良いようである。
なお、この作業は、非常に手間がかかる。色々なディストリビューションが出てくるのは、オープンソース手法の特徴であり、こういった手間の原因は、結局のところ、オープンソース手法が原因と考えられる。
いずれにせよ、ネットから長時間かけてダウンロードするのは時間がかかり、多忙な人には、とてもではないがお勧めできない。
一言に Linux
といっても、沢山のディストリビューションがある。代表的なものでも２０程度ある。細かい修正版などを考えると、どこで誰が作っているのかさえ把握できないほど多数ある。 しかし、こんなに多くあれば、OS
を入手する際に、どれを選ぶべきか迷ってしまう。
OS
の作者の中には生きがいや遊びで作ってい人もいるらしいが、実用面では、OS そのものと、その OS
で動く便利なアプリケーションと、優れた開発環境が重要である。また、OS
を色々試して楽しめる人間ばかりではない。
最近の OS
は、インストールして安定動作させるだけで半日も費やしてしまうことも少なくないが、OS
を道具として利用したいと考えている人は、そのようなことを楽しいとは思わないだろう。また、入れてみて、よくなかったから消す、などという作業をするのは、時間や資源の無駄である。環境破壊や地球温暖化に悪影響を及ぼすことになる。
Linux
のディストリビューション間では、アプリケーションの互換性は完全には保持できていない。また、同じディストリビューションにおいても、KDE/GNOME
などのいくつかのGUIが選択可能である。このことは、一見、ユーザーレベルでは、メリットの様に感じられるかもしれないが、実は、OS
の普及と言う観点から見たときに非常に大きなデメリットになってしまう。そして、結果的に、多様なアプリケーションが必要なユーザーにとってデメリットになる。
なぜなら、環境に互換性が無いことは、アプリケーション開発にとって、
「全ての環境で、動作保証できるアプリケーションを作るのが事実上不可能となる」
「アプリケーションが動作するプラットフォームが限定されすぎて、アプリケーションが売れない」
からである。
結局、メーカーがアプリケーションを作るとしたら、アプリケーションレベルでは共通に開発できる
Windows
用に出す方がよっぽど楽なのである。この原因も、オープンソース手法から起因している。オープンソース手法では、必然的に多くのディストリビューションの出現を許してしまうからである。
また、自分が（偶然）選んだディストリビューションが廃れていって、高い出費になってしまう可能性もある。
フリーの OS
の製作グループも、今後、ほとんどのグループが大損をすると思う。そして、そういった流れに巻き込まれて、無駄な出費やインストール作業に時間を費やされる人たちもかなり出てくると思う。
論理的に考えて、研究者には、オープンソース賛成派が自然に多くなってしまうと考えられる。
その理由を説明する。
研究者にとっての実績というのは、
「何らかの先端的な可能性を示すこと。」
なのである。
実用性重視の安定したプログラムを作ることは重要ではない。
また、あるプログラムを ０
から作ることも、研究者としての評価には必ずしも重要ではない。
仮に全体的に動作が不安定になっても、既にあるプログラムに対して追加的な記述をしたり、変更を加えて、
「『理論上』こういう方法があることが証明できる。」
と論文にまとめることが、研究者の評価を上げるためには重要なのである。
このとき、ベースとなるソースプログラムが入手できなければ、最先端にたどりつく「無駄な時間」が多くなり、研究自体が迅速に行えなくなってしまう。
よって、研究者にとっては、元となるソースプログラムの入手経路の確保のため、オープンソースのプログラムがネットで広く入手できることが望ましい。
研究者が公開するプログラムは、理論的な可能性を示すための部分的なサンプルで構わない。プログラムが全体として実際に「完動」しなくても構わないのである。
研究の典型的な考え方を示す文例として、次のようなものがある。
「これと同様の方法を、必要な全ての箇所で記述すればよい。」
研究は、理論を構築することが目的なので、この記述で問題は無い。
現実的には、全ての箇所でそういう記述を行うことを「保証」することは、不可能に近い場合がある。
むしろ、現実的には、単一の記述で、ソース全体を修正せずに済ます方法を見出すことが重要である。
このような合理的な方法を見出すことは、クローズドソースで、一定の記述ルールで少人数で作成されたプログラムソースの方が行いやすい。
仮に、研究者が公開したプログラムに対し、誰かが
「プログラムの動作が不安定だ」
と指摘しても、「大筋だけ書いただけ」と説明すれば、研究者としては全く問題ないわけである。
なお、研究者の立場からすれば、それも理解できるし、研究者本人には特に責任は無い。
研究用に公開されているプログラムの不安定さ指摘することは、目的を理解していないとも言えるであろう。
ただ、こういう世界に研究者は住んでいる、ということを、改めて知っておいたほうが良い。
研究の世界は、最終的な、実質、結果を重んじる、経済社会、消費社会、とは違う世界である。
結局のところ、「論文」を書いて「理論」を構築できればよいのである。
なお、どちらが、難しいかは、一概には言えない。
UNIX 系の OS
は、元々研究者向けのためか、「互換性の維持」を重視していないと考えられる。
研究者にとっては、OS
は、便利に「単発実験」を行う道具であるのだから、理由は理解できる。
なお、研究者は、「可能性を示せれば」良いようだ。
「こんな風にできる」
ことを立証できれば充分で、「完成」させることは重視していないようだ。
Linux も、
「こんな風にオープンソースだと、クローズドソースの大手会社に勝てる可能性がある」
という「主張」が目的なのだろうか、、、。
そう考えれば妙に納得できてしまう、、、。でも、Linux
の目的は主張ではないと思いたいのだが、、、。
こう見てくると、「フリー」のソフトは本当に「安い」のだろうか。本当に社会に「貢献」しているのだろうか。もう一度考え直してみる必要があると、私は思っている。