«前の日(03-01) 最新 次の日(03-03)» 追記

Matzにっき


2004年03月02日

_ [OSS]Young Programmer, Stop Advocating Free Software!

村田さんからのタレコミによる。

「なんでもかんでもFree Softwareであるべきだ」という若いプログラマよ、 考え直せ。実社会に出てプログラミングで生活しようと思えば、 Free Softwareじゃ食べていけないぞ。フリーソフトウェアを推し進めるべきでない。

とかいうような内容のオープンレターがslashdotにポストされた。 年よりのたわごとと断言したいところだが、どうも このレターを書いた本人より私は年寄りらしい。どうしたものか。

まあ、「フリー(この場合は無償)」では食べていけないというのは、よくある指摘である。 実際、ありとあらゆるソフトウェア関連のプロダクトおよびサービスが代価なく配布されると、 産業として成立しないのは事実でもある。

しかし、ソフトウェアの性質である

  • コピーが安価
  • コピーによって劣化しない
  • コピーの配布が安価

によって、ソフトウェアのコモディティ化は避けることはできないだろう。 フリーソフトウェアでなくても、ソフトウェアそのものを販売するビジネスは そう遠くない将来に、ごく一部の例外を除いて成立しなくなると思う。 そうなったら、このレターを書いた人はソフトウェア産業の保護を訴えるのだろう。

もちろん、訴える権利はある。が、実際に保護されるだろうか。 むしろ、ラッダイト*1運動のようになってしまうのではないだろうか。産業革命に取り残される運命の人々が不安を感じて人たちが騒いだのはある意味当然だ。 しかし、その運動は産業革命そのものを止めることはできなかった。 100年以上たった今、産業革命は定着し、ラッダイト運動は存在しない。

ソフトウェアのコモディティ化はソフトウェア産業の構造変化だと思う。 「ソフトウェアの自由」提唱者はそれに便乗して、さらに先に行こうとしている。 プログラミングラッダイトはそれを止めることができるか。

本棚から古い『GNU Emacsマニュアル』取り出し、その中の『GNUマニフェスト』を読んでみると、 このオープンレターを書いた人物がまだまだ子供であった頃に、 彼のレターに対する答えがすでに与えられていることがわかる。

「プログラマは飢え死にしてしまわないだろうか」

誰も強制的にプログラマにさせられるということはないとお答えしておきましょう。 我々の大部分は道の上に立ってしかめ面をしてそのまま飢え死にせよといいわたされることもありません。 我々は何か他のことをするでしょう

しかしこれは質問者の暗黙の仮定を受け入れてしまっている点、誤った答えです。 つまりソフトウェアの所有権がなければ、プログラマは一銭たりとも稼げないという仮定です。 おそらくそれはオール・オア・ナッシングという仮定でしょう。

プログラマが飢え死にしない本当の理由は、プログラム作業に対してお金が支払われることが可能だからです。 ただし、今ほどは儲からないだけです。

コピーを制限することだけがソフトウェアにおけるビジネスの基礎ではありません。 それが最も多くのお金をもたらすので、最も共通した基礎になっているだけです。 もしも顧客の方からそれが禁止されたり、拒絶されたりした場合には、ソフトウェア・ビジネスは、 今のところほとんどなされていないような他の組織的な方法を基盤として変遷していくでしょう。 どんなビジネスでもそれを組織化するのにはいく通りもの方法があるものです。

おそらく新しい基盤のもとではプログラミングは現在と同じほどは儲からないでしょう。 しかしそれだからといって新しい変化に反対する理由にはなりません。 セールスマンがいまと同じだけの収入を今後常に保証してもらえないことが不公平だとはいえません。 プログラマも同様で、収入が減じてもそれはやはり不公平だとはいえないでしょう。 (実際には、プログラマはそれ以上の稼ぎがあるに違いありません。)

このマニフェストが出されたのはおそらく1987年ごろだと思うのだが、 そのころStallmanはこれからの社会のあり方について十分考察していたことがうかがえる。 さらにマニフェストの後半に登場するビジョンには感動さえ覚える。

長い目で見れば、プログラムを無料にすることは、欠乏の終わった世界への第一歩です。 そこでは生計を立てるためにあくせく働かなくてはならない人はいなくなります。 人々は(週10時間の化せられた仕事、たとえば法律の制定、家族のカウンセリング、ロボットの修理、 小惑星の探査といった作業をこなしたあとは)プログラミングのような面白い活動に自由に熱中することができます。プログラミングによって生計を立てることはもはや必要ではありません。

StallmanはSFじゃなく、本気でこういう世界が来ると考えているのだ。 もちろんこれはまだ実現していないが、この先人類が滅亡しなければ、 100年後にはこれに近い世界が来るかもしれない。

Stallmanは100年先を見ていた。 「無償じゃ生活できない、これが現実だ」と文句を言う人はどこまで先を見通しているのだろう。 Stallmanと比べてしまうとすごく近視眼的な気がする。

そういう観点では、CNETの「オープンソースの採用で共食い状態?--ソフトウェア企業のジレンマを探る」という記事で紹介された、 IBMソフトウェアの技術戦略ディレクターDoug Heintzman氏の言葉の方が現実を見ている(ような気がする)。

たしかにリスクはある。しかし率直にいって、上り調子のものをしゃかりきにつぶそうとするのはエネルギーの無駄だ。誰も市場には勝てない

最初に戻ろう。若きプログラマはフリーソフトウェアを推し進めるべきか。

推し進めるべきだ、と私は思う。なぜか。

もし、私の予想通り、フリーソフトウェアが未来であれば、それ以外の道は衰退の道だ。 抵抗するものはラッダイトだ。 今フリーソフトウェアを選ぶことは新しい世界で人よりも先んじることができる。

もし、私の予想が間違っていて、フリーソフトウェアが未来でなければ、 いつでもフリーでない世界に帰ることができる。 その時、フリーソフトウェアのソースコードとコミュニティから学んだ知識と経験は絶対に役に立つ。

たとえ私が間違っていても、未来がどうであっても、けっして損はない。

*1  ラッダイト運動とは、19世紀英国の産業革命の際の職工団員による機械破壊の暴動


2005年03月02日

_ [知財] iPodショックから日本企業は何を学ぶのか

「笠原一輝のユビキタス情報局」より。

前回筆者は、今の日本のコピーワンス方式は容認できないと書いた。なぜなら利便性や自由度を損なうという、ユーザー側の論理だけでなく、日本の産業界にとっても、そして結果的にはそれを強いている放送業界の側にとっても有害なモノであると思うからだ。

(中略)

日本の機器ベンダが日本独自の事情に振り回されているうちに、海外のベンダがどんどん魅力的な製品を作り、それを海外でどんどん投入されたら、どうなるか。今後、デルなどのIT系企業がデジタルAVに参入してきた時に、高コストの日本企業は太刀打ちできなくなる可能性がある。日本向け製品と海外向け製品で別の製品を作らされることになれば、それだけ日本の機器ベンダの競争力が低下していくからだ。

(中略)

その結果、日本企業は広告に回せる費用が無くなり、広告を出すことが難しくなる。そうなれば、広告収入に頼っている放送業界にとってもかなり痛い状況になるのではないだろうか。これは言ってみれば“最悪のケース”だが、このまま突き進めば、こうなるのは目に見えているのではないだろうか。

それなのになぜ、良い点だけしか視聴者に示さず(放送業界からコピーワンスの件について聞いたことはない、隠しているとは言わないまでも、触れたくないとは思っていそうだ)、「破滅への道」を突き進むのか。

音楽業界でも同じようなことが起きた(起きつつある)。

なぜ、ネットワークウォークマンが受け入れられなかったのか、それはソニーの幹部が認めているとおり、サポートするコーデックの著作権保護(DRM)を厳しくしすぎたため、ユーザーにそっぽを向かれたからだ。

しかし、そんなことになる前に、もっと緩やかな著作権保護を採用するなどの選択肢はなかったのだろうか? おそらく、ソニーの関係者も心の中では「こんなモノだめだ」と思っていたのだと、筆者は思う。実際、筆者もある機器ベンダの社員に「こんなのじゃ受け入れられないと思いますよ」と何度も言ってきた。そうした時に、機器ベンダの関係者から帰ってきた答えは「それはよくわかっている、でも駄目なんです」というものだった。

駄目だとわかっているのに、できなかったのだ。なぜかと言えば、レーベル側が強行に駄目だと言い続けてきたからだ。

目先の利益しか見えない経営者たちによってコンテンツホルダー、ベンダー、ユーザーすべてが不幸になる。 それがコピーワンスや強DRMのたどる道だ。手遅れにならないうちに手が打てないものか。

_ [言語] カールとターボリナックスがリッチ・クライアントソリューションで提携

本国で不調な言語ビジネスを引き取った(株)カールが生き残るために模索を続けている。

最近のAjaxやJSON*1のようなテクノロジートレンドの前にはますますCurlは不利のような気がするけど、それでもなお、Matzにっきは言語ビジネスに果敢にチャレンジする(株)カールを応援します。

*1  正確にはJSONはAjaxではなく、XMLやYAMLと同類のテクノロジーである。Ajax的アプローチでXMLの代わりにJSONを使うことが注目されているというだけのこと。

_ [Ruby] The Internet Company − Special Offer for Ruby Users

年$50でホスティングを、というのはあまり珍しくないし、単にRubyが使えるというのだと普通の話だが、

  • Ruby CGI
  • FastCGI
  • proxy-integrated WEBrick
  • mod_ruby
  • PostgreSQL

までサポートするのはちょっと珍しい。それだけではない。ここは更に

  • Ruby on Rails (either with PostgreSQL or MySQL)
  • IOWA

までサポートしているそうだ。なんと勇気があることだ。

_ ピアノの移動

出社前に妻と二人で電子ピアノを二階の子供部屋からリビングへ移動。 子供たちが最近一階にばかりいてちっとも練習しないから、というのが理由だが、 練習嫌いの子供たちには別の動機づけが必要なのかもしれない。

それはそれとして、電子ピアノとはいえ結構重い。 腰を壊すかと思った。

_ Computer History Museumに見る小型化の歴史(その1)

「本田雅一の週刊Mobile通信」より。

カリフォルニア州マウンテンビューにあるComputer History Museumに見るコンピュータの歴史。 ハードウェアが着実に、安く、速く、小さくなっていく歴史を目で見ることができる。 この博物館には一回行ってみたいな。

しかし、ソフトウェア、特にプログラミング言語の方はさほど進化していないなあ。 少なくともFortran、COBOL、Lispが生まれた50年代のコンピュータと現代のコンピュータほどの違いはない。 それどころか時代がやっとLispに近づいてきた程度ではないかと。

まあ、言語ってば基本的には「思考のための記法」なので、 人間がすぐには進歩しない以上、そんなに急激には変われないんだけど。

_ [OSS] 効果的なリリースの仕方

アップルは年に2〜3回新製品を発表するが、その度にマック・ファンが熱狂して、マスコミの目を引く。アップルは、その狂騒に乗じて広報活動を行っている。オープンソース・プロジェクトは、こうしたアップルのやり方に学ぶべきである。広報こそ新しいユーザーを獲得する鍵であり、新しいユーザーはオープンソース開発モデルの活力なのだから。

なるほど。考えてもみなかった(だからダメなんだ)。

となると、1.8.4のリリースはOSCONの会場からというのはどうだろう。

問題は宣伝文句だな。完全安定期に入った1.8系では目新しい機能は入りそうにない。 人目を引くためには、もっとたくさんの機能が追加されたリリース、つまり1.9系を打ち上げるしかない、か。

それは開発者サイドにはあんまりうれしくないかも。

_ [言語] JSON: The Fat-Free Alternative to XML

上のエントリでも触れたJSONはJavaScript Object Notationで、 JavaScript(やPython)で読み込める記法でオブジェクトを表現しようという試み。

過去に私が「私はなぜXMLを愛していないか 〜 言語屋の視点から」で書いた XMLへの不満に対する答えにもなっている。

JSONは以下のような「XMLは優れている」という主張ひとつひとつについて、 「少なくとも同程度には優れている」ことを丁寧に示している。

詳細は上記JSONページを見ていただきたいが、 要約すると「JSONはXMLと違って拡張(新規タグの定義)とかはできないし、 ドキュメントマークアップ言語ではないが、 データ表現フォーマットとしては単純性、相互運用性、可読性において同等か、より優れている」ということだ。

Rubyに変換するのも簡単だ。 YAMLとどっちが優れているか、決めるのはちょっと難しいかも。

単純さではJSONの勝ちだが。


2006年03月02日

_ マレーシア調査

とにかく日本以外のアジアに行くのは初めてなので、ちょっとドキドキする。

で、とにかく調査してみよう。

  • 通貨 マレーシアリンギット 1MYR≒30円
  • 平均気温 3月は最高で28度、最低で26度。日本だと真夏だ
  • 電源 240V/50Hz。プラグはB, B3, CF, Cがリストされている。 一国で4タイプもあるとはどういうことか
  • 時差 +800。日本とは1時間差
  • 言語 マレー語。英語、広東語なども使われている
  • 宗教 イスラム教。イスラム教国は初めて。

ふーむ。暑いのね。夏の格好で行かないといけないわけか。

スライドは既に書いたが原稿を書かねばならない。 freshmeat.netからデータを入手せねばならないな(less activeなプロジェクトの割合)。 「1年以上updateがないプロジェクト数」でどうだろうか。


2007年03月02日

_ [言語] The Jim Interpreter

組み込みにも使えるスモールフットプリントのTcl再実装。

もともとTclってのは組み込みを目指した小さな言語ではあるが、 コンパイル後のサイズで85kというのは大したものだ。 後でソースも見てみたいものだ。

_ Sun & Users - Solaris 10ファイルシステムZFS誕生エピソード『心を解き放て!』

時代や状況の変化で以前には不可能だと思われていたことが できるようになることってときどきあるよね。 ZFSもそのようなものだということらしい。

この開発エピソードはいろいろと興味深い。

  • 「みんなが無理」と思うことでも改めてやってみようとする技術者
  • それをやらせてみる組織
  • しかも、適当に技術者を引っ張ってこれる(Sunの)技術風土

_ SQLAlchemy - The Database Toolkit for Python

通常の式からSQLを合成するライブラリ。

こういう技術は結構便利だと思う。

_ does it suck?

Love/Hate Ratioみたいなものか。

Rubyは結構高い。Matzも高いが、Larry Wallには負ける。

_ [言語] perl.com: The Beauty of Perl 6 Parameter Passing

Perl6の引数渡し。

  • 文字列の中のブレースがすべて式展開ってつらくないか? 式展開でないブレースを含む文字列はかならずシングルクオートを使えってことか。
  • コロンを前置するとキーワード引数。 ポジショナル引数としても呼べるのかな
  • 可変長引数とキーワード引数の組み合わせとかどうなるんだろう?

追記

Danさんに「そんなことはありません」と突っ込まれた。 これは「シングルクオートを使えってことか」の部分に、「いや、Perlにはシングルクオート以外にもいろいろとクオートがある」というツッコミだと思うので、 ここは「ダブルクオート以外を使えってことか」と言い換えておく。

あっちのコメントにも書いたけど、本質は

ダブルクオートというよく使う文字列の中で、ブレースというよく使いそうな記号で展開してしまうと引っかかる人が多くないか

ってことなのよ。

_ [言語] Weblogs Forum - What Are Your xxx Pain Points, Really?

各種言語で本当に「痛い」点ってなによ、というシリーズ。

Rubyについては、主に「遅い」、「IDEがない」、「native threadサポートが無い」などで、言語そのものに関するものはさほどないようだ。

_ [OSS] 第6回オープンソースサロン

開催された。参加した。

プログラム
テーマ
開発者サイドから見たOSSの利用
話題提供
吉永浩和氏(ログリー株式会社)
内容
「カレンダー2.0」カレンダーサービスの開発者サイドの話
話題提供
奥田佳子(日本証券テクノロジー(株) 新システム開発推進プロジェクト)
内容
証券会社でOSSを利用した開発事例

感想。

  • かずひこくん、ひさしぶり
  • ベンチャー系システムでオープンソースソフトウェアを活用する話。 実践しているというケーススタディとして有用だが、珍しい話ではない。
  • ある種の企業はエンジニアを(私の基準では)人間扱いしていない、ように感じた。 内部統制だとかいろいろ理由はあるだろうけど。 そういう環境でも人は生きていけるんだねえ。 私だったら抑圧されるよりは外に飛び出しちゃうけど。

2008年03月02日

_ [教会] 第一安息日

先週は(雪のせいで)教会に来れなかったが、 今週は無事参加できた。 毎週教会に出席するのは当たり前と感じていたが、 改めてありがたいかとだなあと思う。

集会終了後、息子が飛ばしていた紙飛行機が 駐車場の車の屋根に乗ってしまう。 「お父さん、とって」と頼まれるが ひとの車によじ登るのはなあ、とためらっていると 車の持ち主(180cm超)がやってきて、 やすやすと取ってくれる。

あんなに身長が高けりゃな。

「こんなことにしか役立ちませんけど」とか 言われたけど、それでもやっぱり身長が高いのはあこがれる。

アメリカに行った時とか、(立ったまま)打ち合わせしてても みんな背が高いから見上げないといけなくてつらいんだよな。


«前の日(03-01) 最新 次の日(03-03)» 追記