«前の日(02-24) 最新 次の日(02-26)» 追記

Matzにっき


2004年02月25日 次女誕生日

_ [OSS]オープンソースの歴史

もしかして、オープンソースの定義が後づけだと思っている人がいるのだろうか。 ほえさんのツッコミを読んで不安になった。

私の知識が正しければ、経緯は

  • 1997年: Eric Raymondが論文『伽藍とバザール』を書き、バザール的な開発を紹介した
  • 1997年: ソフトウェアのバザール的な開発に利する条件として「オープンソース」と「OSD」が議論された
  • 1998年(?): オープンソースという単語とその定義OSDが紹介された

である。 1997年以前にはオープンソースという用語は存在したことはなかった。 オープンソースは登場した最初の時点からOSDという定義が与えられていた。そのはずだ。

もっとも一次資料が見つかってないので、今後も探す必要はある。

追記:

オープンソースという単語が登場したのは1997年だと思いこんでましたが、 <URL:http://www.opensource.org/docs/history.php>によれば、 実は1998年2月初頭のようです。この文章を信じる限り、 オープンソースとOSDはやはり(ほぼ)同時に登場したようです。 それぐらいあらかじめ調べておけよって。その通り。恐縮です。

_ [OSS]世間一般のオープンソース

繰り返しになるけど、世間一般はオープンソースなんて知りませんって。

思考実験してみよう。

世論調査をするのと同じ方法でオープンソースについて意識調査をするとしよう。 公正のためrandom digit numberingのような手法を使う。人数は3000人くらいだろうか。 きちんとした調査のプロにやってもらうのがいい。

質問内容は

  1. 「オープンソース」って言葉を聞いたことがありますか
  2. その意味を知っていますか
  3. 知っていたらその意味を教えてください

結果はどうなるだろうか。私の予想は

  • 9割程度は「オープンソース」って単語を知らない
  • 意味をきちんと言えるのは2%以下
  • OSDを知っている人は「意味を知っている人」の過半数は下まわる

というものだ。これでもだいぶ甘めに見積もっている。

もし、私の予想が正しいとしたら、「世間一般で言われている「オープンソース」の意味と「OSD 定義によるオープンソース」とは同じものではなくなってしまっている」なんてのは幻想だ。そもそも世間一般でオープンソースなんて言われていない。たとえ「オープンソースを知っている人」の中で「誤解している人」の割合がいくら多くても、そんなの誤差の範囲だ。コップの中の嵐だ。

オープンソース運動は利用者の立場なので、これからメリットを受けられる人はソフトウェア開発者に限らずずいぶん多いはずだ。 そういう(現在98%に属する)人たちにちょいと啓蒙すればいくらでもひっくり返ると思う。

そんな状況で「正しい定義」をあきらめるのは、私には賢い選択とは思えない。

「「すでに知っている人」はITについてのオピニオンリーダーなので、重み付けが違う」という考え方もあるだろう。 だけど、本当にオピニオンリーダーになるべき人はOSDくらい理解できるんじゃないだろうか。 今回、私と議論した人たちも、自分自身ではOSDを理解しているのだと思う。 「そんなのどうでもいい」と思ってるかもしれないけど。 ただ「なにがオープンソースか」などと他人を説得したくないのではないだろうか。 憶測だけど、そうだとしたら、その気持ちは分かる。

でも、それは私があきらめる理由にはならないよね。 「Mワールド」の定義が私の属人的な後づけの定義ではなく、歴史的に正当であることは示した。 「Mワールド」の定義が多数派になるのは不可能ではない。

私にはあきらめる理由がない。

_ [OSS]コップの中の嵐

これだけオープンソースについて議論をしていても、 うちの家族は、父親が1日コンピュータに向かってなにをいっぱいタイプしているのか想像もできない。 そんなもんだ。

_ [OSS]世間一般のオープンソース(2)

世間一般の「オープンソースソフトウェア」は「OSD準拠ソフトウェア」とは違うものらしい。 複数の人がそのように指摘している。だが、その世間一般の定義は人によって違う。

  • ソースがオープンなソフトウェア
  • オープンソース運動に賛同している人が開発しているソフトウェア

ほんとはどれやねん、と小一時間問い詰めたい気分だが、 あるいは重要なのは「どのように変質したか」ではなく「変質している」という事実だけなのかもしれない。 そうだと仮定して話を進めよう。

そのような主張している人を「オープンソース変質派」と呼ぶ。 「こんなのはレッテルだ」と嫌がる人もいるだろうが、 議論のためここだけで限定的に呼ぶだけなので容赦していただきたい。 オープンソース変質派の主張は以下のようなものだと理解している。

世間一般のオープンソースソフトウェアの意味はOSDから変質してしまっている。 だから、オープンソースという言葉の意味としてOSDを使うのはやめよう。

しかし、すでに述べたように、 実際には世間一般で広く認知されたオープンソースという言葉の定義なぞ存在しないのだ。私はそう思う。 「ソースがオープンなソフトウェア」という認知も、 「オープンソース運動に賛同している人が開発しているソフトウェア」という認知も ごく限られた状況でしか存在しない限定的なものだ。 「OSD準拠」と比べて圧倒的有利というのは幻想でしかない。

むしろ、OSDの歴史的正当性から世の中の趨勢はOSDに圧倒的に有利だと考えることができる。

あなたが雑誌か新聞の記者だとして、「オープンソースソフトウェア」について記事を書くとしたら、 なにを調べるだろうか。まずはGoogleだろうか。

「オープンソース 定義」での、検索結果を上から3つあげると(2004-02-25現在):

  1. オープンソースの定義
  2. オープンソースの定義 日本語版
  3. 「オープンソースの定義」の意義

である。全部、OSDを扱っている。すべて八田さんの手によるものというのが彼の貢献の大きさを意味しているような。

「オープンソースとは」で検索しても出てくるのは種々雑多な「俺定義」よりもOSDを尊重したものが多い。 検索上位にあるもののうち、<URL:http://www.mochioumeda.com/archive/consensus/981001.html>だけは OSDよりは「ソースコードが公開に重点」という表現を使っているが、 <URL:http://www.opensource.org/>へのリンクがあるので尊重していないわけではない。

しかし、玉石混淆のインターネットからの情報を鵜呑みにするわけにはいかない。 実際に誰かにインタビューしなければ。聞くとしたら誰だろう。 私だったら、ちょっと考えると

  • OSDNの佐渡さん
  • OSDLの高沢さん
  • Techstyleの風穴さん
  • FSIJのすずきひろのぶさん
  • 産総研のg新部さん
  • Rubyのまつもと

最後のはちょっとアレだけど。

他にもいろいろいらっしゃるだろうが、これらの人を含めて思いつきそうな人はたいてい 「オープンソースとは」と聞かれたら、とりあえず「OSD」と答えるんじゃないだろうか。 人によっては「そうじゃない使い方をする人もいるけどね」と言うかもしれないけど。

そう考えると、「オープンソースソフトウェアについて考える」コンテキストでは、 すでにオープンソースの定義はOSDが主流であり、 「オープンソースソフトウェア=OSD準拠ソフトウェア」である。 この流れは動かせないと認識するのが正しいんじゃないだろうか。 「オープンソース変質派」はもう遅いと感じてるのかもしれないが、 実はそれは逆で「(ソフトウェアの文脈で)オープンソースという言葉をOSD以外の意味で使う」行為を、 広く定着させ、正当化させるにはOSDは広まり過ぎていると思う。

「オープンソース」という言葉そのものは誰のものでもない。 商標登録したって、世間一般での使い方を規定できるはずはないし。 今後も「オープンソース政治」のような訳のわからない使い方をする人は出てくるだろう。

だが、ソフトウェアの話に限れば、個々人の現状認識がどうであるかに関らず、 実は「Mワールド(OSD=OSS)」と「現実世界」の距離は遠くないのではないか。 少なくとも現実世界と「オープンソース変質派」の世界との距離に比べたら。

_ [OSS]シェアギフト・ソフトウェア

藝夢日報より。 面白いので引用。

無償でソフトウェアを公開し使用させてくれた人に感謝の気持ちを表すための運動をしましょう。たとえ有償ソフトを売るためであっても、ソフトウェアの試用ができることは素晴らしいことです。感謝の気持ちを表す方法は人それぞれです。寄付をしても構いませんし、感謝のメールを送ったり、心の中で祈っても構いません。また、それによってさらに同種のソフトウェアが増えることを期待します。この活動を「シェアギフト運動」とします。シェアギフト活動は、シェアギフトソフトウェアを認定し、シェアギフトソフトウェアに対して感謝の気持ちを表すことを目的とします。シェアギフトソフトウェアは次のように定義されます。

  1. オンラインあるいは雑誌の附録などで取得可能なもの。
  2. 取得に際して、個人情報の入力や会員登録などの条件を設けていないもの。ただし、使用許諾への同意を求めることは認める。また、入手に実費(通信費・雑誌の購入費等)が必要なことは「条件」とはみなさない。
  3. 使用に際して期間の制限や有償のキーなど、そのソフトウェが現に有する機能に関して使用の制限がないもの。同種の有償ソフトに対して機能に制限があっても構わないが、有償のキーによって機能制限が解除されるものは除く。

この定義を満たすソフトウェアを「シェアギフトソフトウェア」と呼びます。あるソフトウェアがシェアギフトソフトウェアかどうかは、定義に沿って客観的に判断できますので、開発者・作者の意図は無関係です。この定義はシェアギフトイニシアチブによって民主的に決定されました(メンバーは私一人ですが)。シェアギフトという言葉の意味と、定義が一致していなくても、これが定義ですから客観的に判断できれば問題ありません。

どのソフトウェアをシェアギフトソフトウェアと認定するかは、シェアギフトイニシアチブによって決定されます。現在認定しているソフトウェアには、Rubyと数多くのエロゲの体験版があります。他にも多くのソフトウェアがあると思いますが、申請があればシェアギフトイニシアチブで民主的に議論の上、決定いたします。シェアギフトイニシアチブで認定されたソフトウェアは、「シェアギフト承認済み」のマークを掲げることができます。このマークを掲げたソフトウェアは、きっと多くの感謝を受けることができるでしょう。また認定していなくともこの定義を満たすソフトウェアを「シェアギフト準拠」と呼ぶことができます。

感謝の気持ちを表明することは、もっぱら使用者の善意と、代償を支払っていないことに対する贖罪を意味します。したがって、この運動はソフトウェアの使用者によるものであり、シェアギフトソフトウェアであることは、この運動の支持を意味しません。しかしながら、シェアギフトの定義を満たすソフトウェアを作成し提供したということは、この運動を許容しているとみなされても仕方ありません。それに大量の感謝のメールを受け取ることができるというメリットがありますから、きっと嬉しい悲鳴を上げてくれることでしょう。この運動は完全に善意のものですから、否定する理由などあるわけありません。

また、シェアギフトソフトウェアに感謝の気持ちを表明するために寄付をしたいが、寄付の先が分からない場合に、シェアギフトイニシアチブが寄付を受け付けます。シェアギフトイニシアチブは、シェアギフトソフトウェア普及のためにその寄付を使います。個々のシェアギフトソフトウェアが利益を得られなくても、それが全体の利益というものです。

大変面白い。前からそういう活動が必要だと思っていたのだ。 スライドにも書いたように、 現状ではオープンソースソフトウェアに対する感謝を表現する十分なチャネルが存在しない。 私自身は対象をオープンソースに限ったものを考えていたが、 そうでなくても別に構わない。 ただし、実効的であるためには「シェアギフトソフトウェアの定義」は十分検討した方が良いだろう。 ぜひ実現してもらいたい。

しかし、この後、「ちょっと皮肉がすぎますかね」とあるし、本文中に「Ruby」が登場するので、 もしかすると私はこれを読んで気分を害することが期待されているのだろうか。

とすると、私はこの「皮肉」のどの点で気分を害すべきであったか。

  • Rubyとエロゲの体験版を並列している点

    私自身はその主のゲームになんの興味も持てないが、 Rubyがなにと同一視されようが私には関係ない。 同一の客観的な基準を満たし、私に不利益がないので、私は意に介さない。

  • 「シェアギフトの定義を満たすソフトウェアを作成し提供したということは、この運動を許容しているとみなされても仕方ない」点

    「許容する」のが「仕方がない」とか「関係ない」という意味であれば、 確かに許容しているだろう。

  • 「この運動は完全に善意のものですから、否定する理由などない」点

    善意だろうがなんだろうが、否定する理由がある場合があるので、 これは事実に反する。しかし、これは元々日記のエントリなので深い考察の結果ではないだろう。 実際にシェアギフトイニシアチブの活動が開始される時までには 趣意書からこの表現は取り除かれていることだろう、きっと。

  • 「個々のシェアギフトソフトウェアが利益を得られなくても、それが全体の利益」という点

    その通り。それがオープンソースのやり方である。あ、これは「シェアギフト」だったっけ。 ただ、もし「シェアギフトイニシアチブは、シェアギフトソフトウェア普及のためにその寄付を使います」という 宣言が事実でなかったら、それは詐欺であり、犯罪だ。犯罪には荷担されないようにお勧めする。

他には思い付かないなあ。

それに続く疑問にも答えておこう

また、「オープンソース」という言葉が 世間でもっと広い意味で使われているのは、 OSI自身が「 the term has become widely used and its meaning has lost some precision.」と書いてある通りです。だからOSI Certificatedマークを決めました、とあるわけですが、定義はOSIのものを使うのに、「オープンソース」であるものを区別するためにOSIの方針に従わないのはなぜでしょうか

私は「the term has become widely used and its meaning has lost some precision.」の続きにある、 「we still encourage use of the term "Open Source" to mean conformance to the OSD.」に従って、 「薦めている」のです。だから、OSIの方針に従っていないわけではないです。 もっとも、私はOSIの一員でもなんでもありませんから、OSDを尊重してもOSIに従属する義務はないんですけどね。

_ [OSS]反省点

で、一連の「議論」を振り返って考えると、反省すべきだった点は、 たかはしさんの指摘にある

それはそれとして、まつもとさんのプレゼンにも、「OSD準拠なソフトウェアの開発」と「オープンソース運動への参加」とを混同させかねない傾向があるのではないか、という気もします。

だろう。

実際のプレゼンでは、あのスライドを使いながら1時間以上(質疑応答込みで90分)しゃべっているわけで、 その情報を抜きにしてスライドだけから評価されてもなあ、という気持ちも心のどこかにあるのだが、 それはそれとして、今後プレゼンを用意する場合には 「OSD準拠なソフトウェアの開発」と「オープンソース運動への参加」との混同を 招かないような書き方を心がけよう。

あと、「いち利用者」さんのコメントにある「間違った前提にたっています。(自身の無謬性を疑ってみるのが先決)」というのは気になる。自分に間違いがないなんて一度も思ったことないんだけど。 実際に今回も塩崎さんの意図を読み間違えるという失態を演じているし。 具体的にどこが間違っているのか教えてほしいなあ。

それとも、もしかして「自分だけが正しいような口ぶり」とか「態度がデカい」とかが気に入らない ということなんだろうか。 自覚はしてるんだが、こればっかりは簡単には直らないなあ。

_ 避難訓練

今日、娘たちの学校は避難訓練だった。 私たちが子供のころ、避難訓練といえば火事や地震を想定しての訓練だったものだが、 最近の避難訓練は不審者が学校に侵入したというケースを想定するのだそうだ。

世の中も変わったものだ。


2005年02月25日 次女誕生日

_ [家族] 次女誕生日

今日は次女の誕生日。しかし、夕べから熱を出して今日は学校休み。 彼女が8歳のときにも同じようなことがあったような気がする。

_ [OSS] 株式会社ユヒーロ

Googleの広告によれば「若き日本人によるオープンソース企業」なのだそうだ。

が、しかし、

オープンソースアーキテクチャ

システムの開発や運用において必要となるアプリケーションには、オープンソースアーキテクチャを選択しています。 当社ではオープンソースアーキテクチャを用いたソフトウェア、システム開発実績を有します。

という以外は、 オープンソースについてなにも述べられていない。

トップページにもあるHiTo!なる データベース管理者(DBA)務支援システム(主力商品?)もどうやらオープンソースではないようだ。

だとすると、どの辺が「オープンソース企業」なのだろう。 堂々と「オープンソース企業」を名乗るためには、 単に「オープンソースを利用したソフトウェア開発をしたことがある」だけでは十分ではないようにも思う。 最近ではそんな企業は全然珍しくないしね。

それはどうでもよいのだが、このページのどこを見ても、 「人」が出てこないのが不満だ。企業情報のページを見ても、社長の名前さえ登場していない。 オープンソース界隈ではやはり人が資産になるのではないだろうか。 今時「慶應義塾大学湘南藤沢キャンパスとの連携」だけでは十分とは言えないような。

正直、このページの情報だけからではここに仕事を依頼したい気持ちにはならないなあ。 Google AdWordsの効果は上がらないかも。

もっとも、うちの会社のページも悲惨だが、 正直ここから仕事を得ているわけではない。 実は「ホームページ改善プロジェクト」は何年もペンディングになっているが、 来年度こそは動きだせそうな材料がある。

ま、それはそれとして、Matzにっきは株式会社ユヒーロを応援します。 堂々たるオープンソース企業に成長してほしいものだ。

私の名前に似てるし、さ。

_ FCCのデジタルTVコピー規制は「度を超している」と裁判所

日本のデジタルTVコピー規制(コピーワンスのみ)も「度を越している」と誰か判定してくれないものか。

デビッド・B・センテル判事もこれに同意した。センテル判事は、高画質の映画やTV番組を著作権侵害から保護できない状態で放送することをエンターテインメント企業が嫌がっていることは認めたが、これはFCCが関与する問題ではないと述べた。

「コピープロテクトが施されなければ、提供されるコンテンツは少なくなるだろう。しかし、議会はFCCがコンテンツを最大限に増やさなくてはならないという指示は出していない。FCCは洗濯機を規制できないし、世界を規制することはできない」(同判事)

日本の放送関係者に聞かせてやってくれよ。 テレビでデジタルTVについてCMが入る度に暗い気持ちになる。


2006年02月25日 次女誕生日

_ 次女誕生日・買い物

次女の誕生日。本人のたっての希望で米子(日吉津)のジャスコに買い物に行く。買い物好きの次女は、「今日はこの店がいい」のだそうだ。好みがうるさい。

いろいろ悩んだ揚げ句、気に入ったものが買えたらしい。

息子はムシキングのゲームを楽しんでいた。なんだかいいカードが入手できたのだそうだ。誰にでも分かるジャンケンとカードを組み合わせるとはデザイナーはなかなか考えたなあ。

食事をしたり、アイスクリームを食べたり、さんざん楽しんだ後、帰宅。

病み上がりなので少々くたびれた。

夜は教会へ。バプテスマ会。2週続けてなんて珍しい。


2007年02月25日

_ [教会] 父親来襲

教会の用事があったので、父親が松江訪問。 聖餐会では孫娘(次女)の話をうれしそうに聞いていた。

聖餐会後、託児クラスのお手伝いに行ったのだが、 これは失敗だった。 末娘が離れなくなってしまって、 他の用事にさしつかえてしまった。 どこに行くにもくっついてきてしまって、弱った、弱った。

集会後は、今日も引き続き合宿で頑張ったメンバをお見送り。 東京組のみなさんはバスで無事に米子空港に向かった。

お疲れさま。

_ ものがたり

息子が「ものがたりを書く」という学校の宿題を頑張っていた。

「宝探し」という基本テーマが決まっていて、 後はそれにどう筋をつけるか、という宿題。

宝の地図を見つけた男の子と女の子が、 動物たちの見張りを知恵を絞ってかいくぐり、 無事宝箱を手に入れるというストーリー。 粗削りだが楽しいものであった。

が、終盤、突然主人公たちは手に入れた宝をお金に換え、 半分で新居を購入し、残りの半分は将来のリフォームのために貯金するのだそうだ。 家は古くなるものだから、だそうだ。

なんか急に現実的になるギャップがおかしくて大笑いしてしまった。

_ 誕生日

今日は次女の誕生日。13歳になった。 自分で自分のケーキを(姉と協力して)楽しそうに作っていた。 女の子らしい。


2008年02月25日

_ 帰還(4)

時差ぼけか、体がだるくてやる気が出ない。 過去の経験だとこれが5日から1週間続く。

_ 誕生日

次女の誕生日。おめでとう。 お菓子作りが好きな彼女は自分でケーキを作っていた。

ごちそうさま。

_ [Ruby] programming: Google TechTalk: Matz on Ruby 1.9

先日のGoogle TechTalkのビデオが公開されている。

で、redditのコメントか見てると「英語へたくそ」というコメントが多くて泣けてくる。 が、英語の勉強するくらいだったらそのぶんコーディングしてたいので、 無視することにする。

文句を言うような奴は聞かなくていい(涙

泣いてやるッ。

それはそうと、鵜飼さんのブログによるとSteve Yeggeが

Who's going to take point on handcuffing him to a massage chair until he signs his offer? -- Steve Yegge

と言ったんだそうだけど、Steve Yeggeが私のようなものとGoogleで一緒に働きたいと 思ってくれるというだけで幸せだ。

働かないけど。

_ [Ruby] Virtuous Code > Monkeypatching is Destroying Ruby

Monkey Patchingとは既存のメソッドを置き換えちゃうテクニックのことだが、 Ruby(特にRails方面)で多用されている。

言語そのものをどんどん拡張できるという意味で非常に強力かつ便利なテクニックだが、 良いことばかりではない。

Monkey Patchingは本質的にグローバルな状態変化であるため、 思わぬ影響がでないという保証はない。 また、複数の場所から同じメソッドに対してMonkey Patchingを行おうとすると 衝突により不整合が発生する可能性もある。

Ruby 2.0ではnamespaceやpackageやmethod combinationでこのような問題に対して なんらかの対処を行おうと考えている。


«前の日(02-24) 最新 次の日(02-26)» 追記