気が付いている人もいるかもしれないけれど、 私は微妙に「オープンソース」と「フリーソフトウェア」を使い分けている。
私の気持ちとしてはRubyはあくまでもフリーソフトウェアであり、 オープンソースソフトウェアはフリーソフトウェアを含むので *1、 オープンソースソフトウェアと呼ばれることを受け入れるというのが私のスタンスだ。
では、そんな私がなぜオープンソースという言葉の定義にこだわるか、といえば、それは実利のためである。
残念なことに企業はプログラマの自由には関心がない。 企業が一番に関心を持つのは、それは儲かるのか、ということだ。 これは事実で、Richard Stallmanの長年の闘争がビジネス的にはあまり成功していないことからも分かる。
しかし、フリーソフトウェアの開発スタイル(の一部)は実は企業にとってもメリットがあることを、 Eric Raymondは『伽藍とバザール』と続く論文で示すことに成功し、 それとともに「オープンソース」という単語も導入した。
これによって「オープンソースはビジネスになる(なりえる)」というコンセプトが生まれたのだ。
このコンセプトはほとんど武器を持たない我々フリーソフトウェア開発者にとって 「中間層」を刺激し、取り込むための重要な「道具」である。 しかも、その効力は(少なくとも日本では)まだ消え去ってはいない。 まだ使える道具なのだ。
この道具を手放すのは愚かだ。
私は、オープンソースというキーワードを利用して、 今以上にフリーソフトウェアに対する支援を引き出せると考えている。 また、フリーソフトウェアによるソフトウェアの自由がより豊かな社会を実現できるとも考えている。 そのためには、この道具にまだまだ効果的に働いてもらう必要があるのだ。
あくまでも推測だが、オープンソースはソース公開の意味しかないとする人は
のいずれかではないだろうか。
不勉強の人たちには教えれば良い。 なんか逆ギレしてる人たちもいるようだが、あきらめずに紹介し続けよう。 彼らは知らないだけなのだ。 オープンソースという言葉を正しく使う時にはメリットがあり、 そうでない時にはデメリットがあることを知らせよう。
あきらめている人たちには「あきらめるな」と伝えよう。 日本ではコンピュータ関係の層が薄いせいもあって 「オープンソース」という単語が一般社会には知られていない。 知られているにしても「なんか今までにないやり方」くらいのレベルでしかない。 少なくとも私の近くの非業界人は「全然知らない」か 「単語を聞いたことはある(が意味は知らない)」のいずれかであった。 どちらも(彼らが知りたいと思えば)正しい知識を教えるのは容易である。 一方、業界人にはオープンソースを正しく理解している人が一杯いる。 実はうるさいだけで「オープンソース＝ソース公開」だと頑固に考えている人こそ少数派なのではないか。 統計をとっていない以上そうでないと誰が言えよう。
言葉の「新しい意味」の導入を謀る人は、 その意味が本当に「もっとも良く使われている」ことを示す必要がある。 そうでなければ単なるFUDだ。我々は古い意味を守る側なのでその義務はない。
オープンソースという手法に反対し、破壊しようとしている人たちは、 決してその意図を明らかにしようとしないだろう。それは「陰謀」なのだから。 そういう人はいないかもしれない。でも、いるとしたら すでに「あきらめている人」のフリをして、我々もあきらめさせようとするだろう。 あきらめてはいけない。
最後に。「オープンソース」という言葉すべてについて言葉狩りをするのは意味がない。 「ケータイ」がPHSを含む時もあり、そうでない時もあるように、会話の中での オープンソースも文脈によって単なるソース公開を意味する時もあり、OSD準拠の時もあるだろう。 しかし、「オープンソース＝ソース公開だけ」という誤解を再生産するような記述や、 オープンソースという言葉の効力を損ねるような発言は指摘し続ける必要があると思うのだ。
*1 フリーソフトウェアでないオープンソースソフトウェアはある。では、オープンソースソフトウェアでないフリーソフトウェアはあるのか
アメリカではOpen Sourceが商標を取れなかったこともあって、1999年ごろOSD準拠のソフトウェアを OSI Certified Open Source Softwareと表示して明確にしようという戦略に変更したということは 知っている人も多いだろう。 私は最近まで知らなかったけど(ダメすぎ)。
でも、自分からOSI Certifiedと名乗るのはなんか違う気もする。 ここはいっそOSD準拠のライセンスを持つソフトウェアをOSIが一方的に
と認定してしまうのはどうだろう。んで、リストに追加しちゃうの。 こんなに膨大な数のソフトウェアがOSI Certified Open Sorce Softwareですって。
いいアイディアだと思うんだけどなあ。 Freshmeatあたりを利用すればすぐにできそうだし。
ところで、ソース公開しているけどOSD準拠でないソフトウェアってのはどんなものがあるだろう。
HORBのように作者の主張が強すぎて結果的にOSD準拠でなくなったもの、 Delegateのように勤務先の制約でOSD準拠でなくなったものは理解できる。 これを「気持ちだけオープンソース」ソフトウェアと呼んでみよう。
また、「マイクロソフトシェアードライセンス」のような 「見せるけど再配布はダメ」というのは、 セキュリティ検証の観点とオープンソースに対する対抗という観点の両方から理解できる。 呼ぶとしたら「オープンソース対抗」ソフトウェアかな。
それ以外にはどんなものがあるだろう？
深い理由はなかったとして、 それらをオープンソース化するように勧める良い手段は？
たしかに、 オープンソースについて全然知らない人に説明する時に「だまってここを見よ」 というようなサイトがあれば便利ですよね。
私の知ってる中で一番良さそうなのは<URL:http://www.catch.jp/openoffice/open.htm>です。 ただ、私の感覚は人とはずれてるみたいなんですが。 たぶんこれなら大丈夫だと思うんだけど。
ほかにも良いサイトがあれば紹介してください。
「オープンソース」などにかまけていたら、SeanがREXMLをコミットしてしまった。 REXMLがコミットされたらすぐにpreview3を出すと予告していたので、 作業が必要だ。
だいたい片づいているんだけど、Block/Procについては少々悩みが残っている。 あと、原稿の〆切が...。
コードブロックをオブジェクト化したBlockと、 無名関数オブジェクトとしてのProcを分離しようというのが元々のアイディアなのだが、 使い勝手という点でやや難点がある。
要するに使い分けが難しいのだ。似過ぎていると言ってもよい。 Dave Thomasからもこの変更の導入直後に指摘を受けた。気持ちは分かる。
で、いくつか考えているのだが、結論は出ていない。が、私の考えの経過に興味を持つ人もいるだろうから、 ここの書き連ねておく。"Think out loud"だと思って読んでほしい。
当初の目的は上に述べた通り「コードブロックをオブジェクト化し たBlockと、無名関数オブジェクトとしてのProc」の分離である。 が、実際に使っていると混乱してきそうだ。
そこで生成の仕方を明確に分離することにした。 Block.newはブロックなしで指定すると現在のメソッドに与えられているブロック (yieldの対象)をオブジェクト化するが、 Procの方はブロックを与えなければ警告する(最終的にはエラー)。
これでProcはあくまでも関数オブジェクトでlambda, proc, Proc.newはブロックをくるんだ 関数オブジェクトを返すという意味づけができる。 最終的にはDave Thomasの提案に沿って「関数オブジェクトを作る構文」を導入してもよい。
あ、そうそう。この意味づけを強調するために近くBlockとProcの継承関係を外すつもりだ。 ところどころで見かける
p.kind_of?(Proc)
のようなコードは、今のうちに
p.respond_to?(:call)
に変更することをお勧めする。
Blockっていうのはかなり一般的な語彙なので、すでに使っている人がいるかもしれない。 というか、実際に問題が起こったケースもあるようだ。
無名の関数オブジェクトってメソッドオブジェクトたるMethodと似過ぎていると考えることもできる。 BlockとProcとMethodと、callで呼べる似たようなものが一杯あるのは望ましくないかも。 まあ、それぞれ生成方法が明確に異なっているから、Polymorphicに同じなら気にしないというのが Dynamic Typedな考え方なのかもしれないけど。
1.8.0では以下のいずれかになるのでは。
リリースのタイミングを考えると最初のものが一番ありそうだなあ。
もうそろそろ８月号の〆切が迫っています。 今月のテーマは「エクストリーム・プログラミング」にしようかと思ってます。 もはや「初等」でも「入門」でもありませんな。
今後の内容については〆切を乗り切った後、更なる考察が必要そうです。