Home > Latest topics

Latest topics 近況報告

たまに18歳未満の人や心臓の弱い人にはお勧めできない情報が含まれることもあるかもしれない、甘くなくて酸っぱくてしょっぱいチラシの裏。RSSによる簡単な更新情報を利用したりすると、ハッピーになるかも知れませんしそうでないかも知れません。

萌えるふぉくす子さんだば子本制作プロジェクトの動向はもえじら組ブログで。

宣伝。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

Page 5/245: « 1 2 3 4 5 6 7 8 9 »

オフィスの広さとか - Sep 05, 2013

妻の勤務先の会社が、なんやかやでオフィスが広くなったという話を聞きました。

場所を変えずに人を雇っていったら机が増えて椅子も増えてだんだん混雑してきて、最終的には、椅子を引いたら後ろの人に当たるくらいに物理的に窮屈なレベルになってたとかなってなかったとか。横でうるさくされていると気が散って作業に集中できないタイプだと言っていたので、それだけ混んでたらまあ嫌でしょうね……と、話を聞いて思ってたんですけど。それが一気に広くなって、だいぶストレスが軽減されたそうです。

他方、自分が仕事上でお付き合いのあるとある会社のオフィスは、マンションの一室で数人のスタッフがいて作業をしているという環境でした。後ろを通過するためには椅子を引いてもらわないといけない程度……ということは、話に聞いていた妻の職場環境と同じかそれ以上の人口密度なんじゃないかと思います。が、(実際どうなのか正直な所は聞いてみないと分かりませんが)そんなに皆さんストレスフルでイライラしているという印象は受けませんでした。

人には、踏み込まれると不快になる距離、パーソナルスペースというものがあるという話を聞いたことがあります。よく知らない相手だったり、嫌いな相手だったりすると、踏み込まれたら嫌な距離は大きくなり、家族だったらその距離は小さく、恋人同士や新婚カップルや親子だとゼロ距離でも不快に感じない、と。

妻の勤務している会社は数百人規模で、顔も名前も知らない社員がいて当たり前という環境だと聞きました。その一方で、僕がお邪魔したその会社は社員数1桁台で、気心知れた仲間同士でやっているという雰囲気があった気がします。もちろん個々人の性格や考え方による部分もあるとは思いますが、パーソナルスペースが重なり合うような窮屈さでも大丈夫というのは、気の合う仲間とだから成り立つ働き方なのかなあと思ったのでした。

僕はグッデイとクリアコードとMozilla Japanのオフィスしか仕事環境としては体験したことがなかった(打ち合わせやなんかで他の会社にお邪魔しても、見られるのはだいたい会議室まで)ので、世の中にはいろんなオフィスがあるのだなあと思うのですが、僕自身はというと、作業に集中してると周りのことが見えなくなってしまうタイプなので、もしかしたら(クーラーとかがきいてれば)トイレくらいの広さのスペースででも仕事できちゃうのかもしれません……

ニオイ - Aug 24, 2013

最近、奥さんのおばあさんの米寿のお祝いで、奥さんの実家にお邪魔しまして。泊まりがけだったのとその時はめちゃめちゃ暑かったのとで、着て行った服を洗濯していただきました(翌日がお祝いの本番で、その時用には別の服を持って行っていたのです)。

その事を特に思い出すこともないまま帰ってきてしばらく経ったある日のこと、出勤するのに着た服からなんか妙に甘い香りがするんですよね。なんだこれって思って。

それで理由をずっと考えてたんですが、トイレでウンコしてるときに気がつきまして。ああこれこないだ奥さんの実家に着ていったやつだ……と。普段自分ちで使ってる洗剤と違う洗剤で洗ったから、違う香りがついてたんですね。

テレビ見てると「一日中香りが続く!」と宣伝してる洗剤があったりしますが、実際丸1日同じ甘い香りが続くと(別に常時プンプン漂ってるわけではないんですが、風向きとかでふわっと漂ってくる)、なんか……べつにここまで香らなくてもいいかな……って気がしました。彼女とか奥さんとかに近寄ったときにふわっと漂ってくるのは多分ドキがムネムネしてキュンと来るアレなのですが、31歳おっさんの自分から漂ってきてもうれしくないです……

それはそれとして。

米寿のお祝いによせてメッセージカードを孫一同から送ろうという話になったそうで、ついでだからと自分もそこに混ぜて頂きました。しかし、以前に1回しか会ったことがなくて一体何を書けばいいものやら……と本番前日夜にうんうん唸っていて、「おめでとうございます」みたいな無難なメッセージから先にペンが進まずにおり、さりとて例文集を調べたら負けかなみたいな思いもあってまた一層うんうん唸っていたのですが、ふと思いついた事があって、それを書き始めてみたら自分で結構いい事言ってんじゃねって気分になってきたので、その路線で最後まで書き切ってみたんです。で、何を書いたのかという話なんですけども。

ほとんど話した事も無い直系姻族のおばあさんだけれども、当たり前だけどその人がいなかったら僕が結婚したこの奥さんは生まれていなかったし、もちろん僕が奥さんに出会うことも無かったんですよね。結婚自体してなかったかもしれない、漫画連載なんて事もできてなかったかもしれない(今できているのは奥さんのサポートがあってこそだと結構思ってる)。家の近くを散歩して何気ない風景を見て「面白いねえ」なんてなごやかに話すこともなかっただろうし、ダイビングだってやってみもしなかっただろうし、イルカと泳ぐことも、珊瑚礁の中を泳ぐこともなかっただろう。おばあさんがいなかったら、自分の今の幸せのかなりの部分が丸ごと全部無かったんだ。

そう思うと、奥さんのルーツにあたる人が88歳で今も生きていて「ありがとう」「おめでとう」を言えるというのはすごい事なんだなあと思えてきて、そういう事をメッセージカードに書いたのでした。

それで実際お会いした時に直接「ありがとう」と言えば良かったんだけど、お祝いの席では結構緊張してしまってそこまで気が回らなくて言えなかったので、次にお会いしたときに覚えていたら言っとこうと思います。

あとそういう感じでなんだか最近自分の親とか祖父とかにも今更なんだけど感謝だったり尊敬だったりという思いを感じるようになってきていて、最近になってやっと人間らしくなってきたのかなあ今までは文字通り薄情者だったのだなあということを思ったりもしています。自分が幸せだなあと心の底から思えるようになってないと周囲、特に親への感謝なんてできないものなのかなあ、とか。かつては「なんで幸せになれないんだ」という感じの妬み嫉みだったりムカツキだったりが強くあって、それから現実を受容して無心の境地を経て、やっと感謝の気持ちに辿り着いたのかなあとか。というふうな書き方をしているとなんだか宗教体験っぽくてアレですね。

それと、親の介護がとか自分や奥さんが大怪我して介護が必要になってとか、そういう重大な問題に見舞われた時にも自分がそんな殊勝な気持ちを保っていられるのかどうかというのは未知の領域なので、どうにか殊勝な気持ちを保っていられるといいなあと思っていますという所で話を結んでおこうと思います。

「コピーレフトとBSDスタイルではBSDスタイルの方が発展するのでは」という議論についての誤解あるいは言葉の裏にある欺瞞 - Feb 03, 2013

元のプロダクトがGPLでも、自分で開発した部分のソースは別のライセンスを指定できるよ、というエントリを書いた後で、言及した事例が自分の想像を超えた残念事例だったという事を認識して、非常に落胆しています。

ここまでのまとめ

先のエントリで言及したProximodo Liteの事例は、まとめると、こういうものでした。

  1. 元々クローズドソースのProxomitronというソフトウェアがあって、これが大人気だった。
  2. しかし、作者が死亡してしまい、作者によるメンテナンスが行われなくなってしまった。
  3. ソースがないから誰も開発を引き継げなくて、完全に死んだプロダクトプロジェクトになってしまった。
  4. しょうがないからProximodoというクローンが新たに開発された。
  5. 今後同じ事が繰り返されないように(という理由だったのかどうかは分かりませんが、結果として同じ事が繰り返されなくなる効果がある選択として)、Proximodoにはコピーレフトなライセンスが設定された。
  6. Proximodoの開発は頓挫し、機能的にも性能的にも中途半端な状態で放置されてしまった。
  7. そこにhide氏が目を付けて、改造版となるProximodo Liteの開発を始めた。このhide氏は、元開発者が様々な理由からプロジェクトの継続を断念したソフトウェアについて、ソース提供を受けてその改良版・後継版を積極的に開発している人物であった。
  8. Proximodo Liteのバイナリを公開しようとした段階になって、hide氏はProximodoがGPLでライセンスされていることに気がついた。
  9. hide氏はGPLでProximodo Liteのソースを公開するつもりがなかった(ひょっとすると、いかなるライセンスであろうともソースを公開するつもり自体が無かった)ため、バイナリ公開を断念した。
  10. それでもProximodo Liteを公開したくて、hide氏はProximodoの作者に対して、ProximodoのライセンスをGPLからBSDスタイルに変更する事を求めている。(イマココ)

実際の経緯については、一旦バイナリを公開した後、指摘を受けて公開を取り下げた上で、上記のような経緯であったと読み取れるようにページ上の記述を改変したという話もあるようですが、自分はその時の動きも改変前のページも見ていないので、どちらが事実だったのかは僕には分かりません。いずれにしても現時点ではライセンスに反している状態にはなっていないということで、とりあえず、以下の記述の前提としては、僕が見た時に書いてあった通りに解釈した上記の「経緯」が事実であったと仮定することにします。

意義ある活動である事は事実

僕自身釈然としない物がありますが、hide氏のしている事が善か悪か、という事は一概には断ぜられません。

ソフトウェアはユーザに使われて用を果たしてナンボの存在、用を果たせなければゴミクズ同然です。いくらかつて好評を博したソフトウェアであっても、今の環境で動かなかったり、重篤な脆弱性が放置されたままであったりするならば、ユーザにとっては無価値です。そういった「死んだ」プロジェクトを引き取って、新しい環境でも動くようにしたり、あるいは欠けていた機能を補ったりして、後継バージョンとして提供を続ける、という点においてhide氏の活動には大きな意義があります。

元作者が趣味の範囲で継続できなくなったプロジェクトは、他の人が趣味の範囲で引き取るのが、本来は最も望ましい自然な形でしょう。しかし誰にも引き取られておらず、それでもユーザがそのソフトウェアの利用を望むのであれば、趣味の範囲でなく仕事の範囲で引き取って貰うほかありません。つまり、プロジェクト運営専任のスタッフを雇ったり、ソフトウェア開発を生業としている人にお金を払って続きを開発して貰ったり、ということです。僕が所属しているクリアコードでも、顧客の要望を100%満たしてはくれない既存のソフトウェアについて、受託開発という形で改良して顧客に成果を提供するということは少なくないです。

その一方で、(hide氏にソースを公開する意図が無いのであれば、)Proxomitronの悲劇をまた繰り返そうとしているのか、あの過ちから何も学んでいないのか、あの悲劇を避けることよりも自分が独占的に対価や称賛を受け取る事を優先するのか、Proximodoの成果にただ乗りするだけただ乗りして何も還元しないのか、という憤りを僕は感じています。

成果を還元するということ

先程「僕も仕事で似たような事をやっている」と書きましたが、それでもクリアコードでは全社的な基本方針として、変更点のうち本来そのプロダクトに含まれているべき部分、他にも多くの人が困っているであろう部分については、アップストリームにpull requestやパッチとして還元するか、あるいはfork版として同一ライセンスの元でソースコードを公開する、という事をしています。ライセンス的にコピーレフトであろうと無かろうと、この方針は変わりません。(これが事実である事は、GitHubのオーガナイゼーションのページから各メンバーの活動状況を見てもらってもお分かり頂けるのではないかと思います。)

そして、成果を還元したい(成果をソースも含めてすべて公開したい)という思いと、お客さんに不利益をもたらしたくない(クリティカルな情報は公開できない)という思いの2つを、天秤にかけてどちらかを即決で選ぶのではなく、どちらも大切だから両立できるような道を探りたい、と考えています。自分自身が、フリーソフトウェアであったりオープンソースであったりの文化の中で育ち・育てられてきて、有形無形を問わず様々な形でおこぼれに預かってきたのだから、何かお返しをしないと格好が付かないし、誰もが収奪するばかりでは後が続かない。そのための努力を惜しむんでは自分に言い訳が立たない。そういう、誇りとか矜持とかの問題だと自分は思っています。

そこまで手間をかけられない、誇りじゃおまんま食えないよ、だからよくわからないGPLは避けてBSDスタイルを選ぶよ、という立場もあるとは思います。でもできれば、自分が1つ果実を持って行ったのであれば、畑に1鍬入れていって欲しい。そういう思いが僕にはあるので、オープンソースとかフリーソフトウェアとかコピーレフトとかについて誤解があるせいで還元できる場面なのに還元できていないという事例を見かけたら、先のエントリのような形で言及して誤解を解きたい、皆が安心して1鍬入れていける状況を整えたい、と思っています。そこで先のエントリでは、「自分で書いた部分はBSDスタイルのライセンスを設定してソースを公開し、元のソフトウェアと組み合わせた結果をGPLで公開する」というやり方を解説してみました。

上記のような事、「1つ実を取ったら1鍬入れる」を、綺麗事であるとか非現実的であるとか思う人はいると思います。宗教じみてて気持ち悪い、と思う人もいるかもしれません。そういった風潮に対して、寄付頼みの宗教団体でなくとも現実的な経済の営みの中でちゃんとできる事なんですよ、汚染物質を垂れ流さなくてもいい製品は作れるし利益も上げられるんですよ、非正規雇用のスタッフを使い潰さなくても利益は上げられるんですよ、コンプライアンスを軽視しなければ利益は出せないということはないんですよ、CSRは果たせるんですよ、という事を証明したくて、僕はクリアコードに在籍し続けているのかもしれません。(今思うと、Web標準は非現実的な絵空事ではないんだ、Web標準準拠でも格好いいWebページは作れるんだ、ということを証明したくて活動していた頃と、動機は変わっていないんですね。)

「BSDスタイルの方が発展する」という言葉と、その後に起こる事が一致していないという欺瞞

僕がこの事例で特に強い違和感を覚えたのは、hide氏の以下のコメントです。

発展しているオープンソースのプロジェクトは大抵BSDかそれに準ずるライセンスを採用している状況を鑑みて、もし後継を望むのであれば修正BSDにすべきでしたね。

Proximodo Liteのページより引用)

BSDスタイルの方が何故発展しやすいのか、そもそも何を発展と呼ぶのか。何を以て後継とするのか。そこをこのコメントではごまかしている気がしました。

オープンソースのプロジェクト自体の発展とは、そのプロジェクトがオープンソースであるままで継続的に開発が行われる事、派生プロジェクトも含めて後がどんどん続いていくことである、と僕は考えています。例えば仮にProximodoがBSDスタイルのライセンスであったとして、hide氏がProximodo Liteをクローズドソースでバイナリのみ提供するようになったとして、それを「オープンソースのプロジェクトが発展した」と言えるでしょうか。hide氏による開発が途絶えた後で誰か他の人がさらにその後継バージョンを作りたくても、もうできません。短期的には派生物が出てきても、その後が続かない、長期的に継続しないのです。僕は、このような未来を「発展した」とはとても言えません。

GPLやLGPLは、自分が開発した成果のソースコードを利用者にも開示するよう強制することで、必ずソースコードを社会に還元させるという方式のライセンスです。それに対してBSDスタイルのライセンスでは、自分が開発した成果のソースコードを社会に還元するかどうかを、その人自身の判断に委ねています。必ずしもすべての部分を社会に還元できるわけではなく、どうしても秘匿しなければいけない部分があるという場合がままある、そういう場合にGPLだと「全部公開するか、全く公開しないか」の二者択一になってしまうから、GPLのソフトウェアを元にした成果は社会に還元しづらい。BSDスタイルだと、秘匿したい部分を秘匿したままにできるので、成果を気軽に還元できる。そういう話は確かにあると思います。

AppleやGoogleは、ソースコードを再度オープンなライセンスで公開する道を選びました。Appleはゼロから製品を開発する事を避けて、LGPLのKHTMLを改良してWebKit(WebCoreとJavaScriptCore)を作り、LGPLでソースコードも含めて公開しました。そしたらその成果に載っかる形で、GoogleがV8を開発し、Chromeを開発し、それらのソースを修正BSDライセンスで公開しました。V8がオープンになっていたことから、node.jsが生まれました。皆、自分達の製品を作るための要素技術としてオープンソースのソフトウェアを採用し、成果をまたオープンソースのソフトウェアとして社会に還元しています。ソースコードをオープンに保ったままで、付加価値によって利益を上げ、継続するシステムを作り上げています。僕はこのような流れをこそ「発展」と呼びたいと思っています。

コピーレフトとBSDスタイルのどちらが「発展する」のかという議論は、どちらの方がよりソースコードを社会に還元して貰いやすくなるのかという観点での議論であって、どちらの方がクローズドな派生物を作りやすいかという観点での議論ではないはずです(そもそもGPLではクローズドな物を「作れない」わけで、そのためにわざわざLGPLという物が別に用意されているのであって、この点での議論の余地は元から無いでしょう)。そこをごっちゃにして、「BSDの方が発展する」と言って元作者にBSDスタイルのライセンスへの変更を持ちかけ、自分は成果のソースコードを還元するつもりは無いというのは、筋の通らない話だと僕は思っています。

ところで、ライセンスというのは双方(権利者と利用者)の合意で成り立ちます(合意に至らないならば、当然交渉になります)。

開発とライセンスのホットな関係より引用)

hide氏はこのように書いていますが、hide氏の合意形成あるいは交渉のやり方は、僕にはいまいちアンフェアであるように思えます。

I think that GPL is cause of the various problems.
I do not like trouble.

So please change "New BSD License" or "2-clause BSD license".
I will publish new version if it does so.
Please understand and accept my proposal!

Proximodo Liteのページより引用)

hide氏はProximodoの作者に向けてこのようにライセンス変更を求めていますが、「その上でソースを秘匿しシェアウェア化したいと思っている」「バイナリのみ公開したい」といった意図があるのか無いのかを、少なくとも僕は、この文言から読み取ることはできませんでした。

ライセンスの変更は、おいそれとできるものではありません。自分のポリシーと照らし合わせて検討し直すだけでなく、場合によっては関係するすべての人に連絡を取り、貢献して貰ったコードのライセンスを変更して良いかどうか承諾を求める必要もあります。あるいは、GPLフリーにするために、GPLな他のソフトウェア由来の部分をすべてスクラッチで書き直さないといけないことすらもあります(実際、AppleはGCCを使わないで済むようにするためにCコンパイラの再実装に多大な貢献をしていますし、僕もXUL/Migemoを問題のない形で再公開するにあたって、ライセンスが不明瞭だった部分を手間をかけて入れ換えました)。信念の問題としても手間の問題としても、それなりに重い作業である可能性があります。それだけのことを求めるにあたって、「GPLには色々問題があるからBSDにしてくれ」だけでは、説明責任を十分に果たしているとは言えないと僕は思います。自分が何故BSDスタイルへのライセンス変更を求めているのか、この「publish」がどのような意味での言葉なのか、BSDライセンスになった後で自分がどのような形で成果を還元しようと思っているのか、あるいは思っていないのかを、hide氏は十分に説明できていないのではないでしょうか。

BSDスタイルとコピーレフトとを僕が使い分ける際の基準について

「こういう事をああだこうだ言っても人は動かない」「説得になってない」といった指摘はあると思います。僕自身、他人に何を言われようともこのhide氏が方針を変えるということは無いだろうと思っています(過去の活動の事を知るまではその可能性も考えていましたが、他のBSDスタイルのソフトウェアについて「改良版をバイナリだけ公開、シェアウェア化」という事をされていると知って、これは相容れないタイプだな……と思い知りました)。ただまぁ、「そもそも元作者とこの人の2者間の話なのだから他人が口出しする筋合いではない」ということについては、確かにそうですが傍目にフェアなやり取りとはちょっと思えなかったので、前項ではその点については口出しをしてみたんですけれども。

このエントリで言いたかったのは、「なんとなくBSDのほうがよさそう」「よくわからないけどなんだかGPLって面倒そう」ということで手放しにBSDスタイルが良いとされる風潮には、僕は違和感がある、ということです。

僕自身、ライブラリとして広く使い回したい物にはMITライセンスを設定して公開していますし、そうでない物についてもGPL/LGPL/MPLのトリプルライセンス(これはかつてのFirefoxに倣ってのもの)やMPL2.0を設定するなどして、ガチガチのコピーレフトよりはもう少し緩いものを選択しています。それに、ストールマンの「何でも公開しろ」という態度は、あれはあれで傲慢に感じていて好きではありません。コピーレフト寄りであっても、どこまでコピーレフトにするかという事には個人差があるものです。

  • 自分の作った物が誰にどう使われようとも構わない、極端な話、誰かが看板だけ掛け替えた「改良版」を作って商売していようとも全く構わない、という事であれば、パブリックドメインにしたり、あるいはBSDスタイルのライセンスを選択して問題ないでしょう。
  • 自分の作った物が看板を掛け替えただけの「改良版」として勝手に商売に使われるのは我慢ならない、やるならこっちにも分け前をよこせ、それが嫌なら無償で同じ条件でソースも含めて公開しろ、という事であれば、コピーレフトなライセンスを選択した方がいいでしょう。
  • 自分の作った物がアイデアだけ引き継がれるのはいいけど、自分の血と汗と涙の結晶であるソースコードが他人にそのまま利用されるのは腹立たしい。アイデアを同じように具現化したかったら、自分で同じだけの血と汗と涙を投じて実装し直して欲しい。という事であれば、ソースコードを公開しないクローズドライセンスにした方がいいでしょう。
  • 自分の作った物がソースコードも含めて引き継がれていって欲しい、他の人が自分と同じような苦労をしなくてもいいようにしたい、人類共有の財産にしたい、という時に、コピーレフトにするべきなのか、それともBSDスタイルにするべきなのか。そこが問題です。

僕がBSDスタイルのライセンスを選択する場面は大抵は、それ以上の改良が他の誰の手によって行われなくても別に構わない、あるいは、直すときには自分で直すつもりだ、という時です。BSDスタイルのライセンスにするということは、他の人が行った改良がフィードバックされない可能性が出てくるということです。それでも別にいいやと思える時に、僕はBSDスタイルのライセンスを採用する事が多いです。既存のプロダクトの多くで共通して存在していた部分を共有ライブラリとして切り出した、という場面で僕はよくこの選択をします。

その一方で、完成したプロダクトとはちょっと言えない、まだまだ改良が必要そうだと思える物や、アプリケーションレイヤの物については、僕はコピーレフトのライセンスを設定することが多いです。僕が関心を失った後でも、必要としている人がいつでも開発を引き継げますし、その人がまた興味を失ったとしても、さらに次の人が開発を引き継げます。

その時に僕がBSDスタイルを選択していないのは、やはり、オープンな形で開発が継続していて欲しい、仮に一旦途絶えたとしてもいつでも継続できる状態が保たれていて欲しい、「継続されて欲しいという意図」まで含めて引き継がれて欲しいからです。いつか自分が帰ってきたときに継続できなくなっていて欲しくないからです。囲い込みたい、継続する流れを途絶えさせたいと思っている人には使われなくても構わない、とすら思っています(でも完全に排除するつもりもないので、選択するのは若干緩いコピーレフトにしています)。

自分が作った物をBSDスタイルのライセンスにするということは、自分が感心を失って開発を放棄した後、誰かがそれを引き継いでくれたとして、その人が機能的に不足していた部分を補って完成させてくれたとして、自分がユーザーとして戻ってきて「ここはちょっと不満があるな……」と思ったとしても、もう二度とそこに手出し口出しできなくなる可能性がある、ということです。そうなってしまうともう、涙を呑んで、車輪の再発明や再実装に精を出し、泥をすすってデバッグに途方もない時間を費やすしかありません。元はといえば自分が作った物なのに、善意でそれを社会に還元したはずなのに、なんでそんな思いをしなきゃいけないのか。目の前に既に「あとちょっとここが直っていれば、期待通りなのに」という物があるにもかかわらず、不毛な開発に精を出さないといけないのか。これほど馬鹿馬鹿しい話もないでしょう。

僕はそういう事を我慢できそうにないので、自分が趣味の範囲で作った物のうち、アプリケーションレイヤの物やまだまだ改良が必要そうな物をBSDスタイルのライセンスで公開する勇気を持てないでいます。(でも仕事でやる物については、開発する工数自体に対してお金を払ってもらえるので、ライセンスはわりとどうでもいいと思っているかもしれません。同じ事をやり直すことにやる気は湧きませんが、その分お金が出るのであれば我慢できると思いますので。)

また、僕はアプリケーションレイヤの物について、ソースを秘匿することで利益を出せるという気がしていない、というのもあります。自分がそんな革新的な物を作れるとは思っていませんし秘密の技術をマネタイズする術も持っていません。誰にでもできる事の「やり方」を隠すことでお金を稼ぐというのは好きじゃない、というのも大きいかもしれません。それよりは、やり方は誰でも知ってるけどやるのが面倒くさいとか、やり続けるのに熟練が必要とか、うまくやるのにはセンスがいるとか、そういう所からお金を頂ければいいんじゃないのかな、と思っています。日経Linux誌での「シス管系女子」の連載も、やってる内容はそんなに高度な技術は扱っていませんし、絵もそう上手というわけではないですが、漫画で技術を説明するという事にユニークな価値を見出して頂けているからこそ、連載が続いているのだと思っています(自画自賛)。

ソフトウェアのユーザにとっての寿命は人の寿命よりも短いものですが、人1人の関心の寿命や、人1人が趣味でコミットできる期間の寿命よりは長いことが多いのではないでしょうか。また、開発の主体が企業である場合も、ユーザにとってのその製品の寿命は、企業の製品開発サイクルよりも長い場合が多々あります(Windows XPが一体何年使われ続けてきたか思い出してみて下さい)し、ともすれば企業の寿命よりも長いかもしれません。開発者としてなるべくソフトウェアが長いこと生き続けていて欲しいし、ユーザとしての自分にとってもなるべく長く便利に使える物であって欲しいので、僕は上記のような方針でライセンスを選択しているし、「独占的な権利を1000ドルで売ってくれ」なんていうメールが来てもガン無視しているのだと思います。

もちろん、これは非常に悲観的な見方で、楽観的な見方からBSDスタイルの方が発展しやすい・生き残りやすいと言う人は少なくないです。コピーレフトとBSDスタイルは、この点において北風と太陽のようなもので、多少のフリーライドを容認してでも寛容であった方が最終的にはいい結果につながるだろう、という話です。また、GPLが毛嫌いされている現状ではGPLを選択することの方が却って後継の登場を妨げるから、政治的にGPLは選択できない、という話もあります(先のエントリに書いた通り、誤解によって恐れられている部分があると思っているので、それが理由でBSDスタイルを選択するというのは本末転倒だと僕は思っていますが)。僕は、これについては「そうかもしれない」と思っていて、それ故に、「誰も彼もが無条件にコピーレフトにすればいい」とまでの過激な意見は持てずにいます。

なので、このエントリでもあくまで「自分はこうしている」という判断の事例を述べるに留めます。あくまで個人の心情として、上記のような不安をぬぐいきれず、また、ソースを公開していた所で大多数の人はパッチなど送ってくれないものであるという実感もあり(これについては、既にGPL/LGPL/MPLで公開しているコードなのでそのせいでパッチが提供されないのだという推測も成り立ちますから、鶏と卵だと思っています)、どうせいつか自分でメンテナンスを再開することになるのだろうという諦観から、気分の問題としてコピーレフトの選択をする場合がある、という話です。

すべての人がすべての状況で同じ判断をしてくれ、とは思いません。僕ほどには泥をすすることを厭わない人もいるでしょうし、そんな先のことなんか考えたってしょうがないよという人もいると思います。「やり方」からお金を稼ぐのが全然嫌じゃないという人もいるでしょうし、ものすごくユニークな技術を持っていて、そこから莫大なお金を引き出せるから秘匿したいという人もいるでしょう(コカコーラとかペプシコーラとかが、レシピを特許化しないでいるのはそのためだと聞いた記憶があります)。僕だって、そういう状況になったら別の判断をするかもしれません。人それぞれ前提が異なりますから、みんなが自分の前提に合った選択をして欲しいし、惑わしてその意志を曲げさせるような事もあって欲しくない、と僕は思います。

サナギ - Nov 12, 2012

蝶とか蛾とかは幼虫→蛹→成虫と変態するんだけど、蛹の状態というのは一部の器官を除いてあの袋の中で体がドロドロに溶けてて、成虫の形にちょっとずつ作り替えられてるんだそうだ。その間身動きなんか取れるわけがなく、変態が完了するまではほんとに何もできないんだと。自分は高校の理科で生物を選択しなかったからよく知らんかったけど、生物選択だとその辺詳しくやるんだろうか。僕は大人になってからグロ写真見て「うぇえ……」となりました。

プログラム書いてて思うんだけど、僕に好き勝手に作業をやらせると、リポジトリが蛹のようになってしまいがちだ。全体的な見通しが立たないままに作業を始めて、やがていろんなモジュールをぶっ壊してしまう。この時はまるで何にも動かない。そういう状態のままコードをさらに書いていって、次に動くようになった時にはあら不思議! 元のモジュール構成は影も形もありませんでした! でも動いてて当初の目的は達成されてる……みたいな。

こーいうのはよくないよなー。ほんとよくない。複数人でやってるプロジェクトでこういうことはしてはいけないと思ってるんだけど。でもやってしまってる。テストドリブンとか何処吹く風や。コミット履歴の中にこういうことになってる部分があると、その周辺はもはや履歴が履歴として役に立たない。

masterでやらずにトピックブランチ切ってやりましょうよって話かもしれないんだけど、それとてmasterが動く状態を保てるということを除けば、特に、履歴がグチャグチャになるとかの点ではあんまり変わらない気がするし。

「ワンライナーで頑張っちゃうとかの変態的なプログラミングは、コードがアンリーダブルになってしまうからやめときましょう」というのは多分一般的な認識だと思うんだけど、「蛹な状態を作ってしまうと上記のような感じで宜しくないので、昆虫的な意味での完全変態的なプログラミングもやめときましょう」なんて事も言えるのかなー、ということを考えていて、誰がうまいこと言えって言ったよと自分で自分に突っ込みつつもドヤ顔でこういうエントリを書いてしまうところが、まだまだ大人になりきれてないと思った次第です。

大学で立ち上げ期に参加したサークルが大発展を遂げていた - Nov 05, 2012

先日、母校の大学祭に合わせてサークルのプチ同窓会が催された。僕も参加したかったんだけど、スケジュールが埋まってて参加できなかったので、大学祭の様子の詳細なレポートを後で見せてもらった。

大学では最初「SF研究会」という部に仮入部したんだけど、ちょっと方向性が違うなあ……と思っていて、そんな時に「新しくサークルを作ろうとしてる人らがいるらしいよ」という噂を聞きつけて、「ぼ、ぼくも仲間に入れてもらえませんかねデュフッ」と参加させてもらった、それが「コミックアート」だった。メディア学科の1年生が中心となって活動を始めたばかりの小規模な非公認サークルだった。

僕の母校のサークル活動にはいくつかのレベルがあって、大学の運営や学生会とは全く関係なく勝手に集まってわいわいやる「非公認サークル」、学生会に認められた「公認サークル」「同好会」、予算や部室なんかもついた「部」という感じで昇格していくシステムだった。人を集めたり活動したりするにはやっぱり予算や部室があった方がいいので、「部」を目指して活動してたんだけど、昇格するためには「これこれこういう理由で意義のある活動なんですよ」「ちゃんと活動実態もありますよ」みたいなことをアピールする必要があった。だからというわけでもないんだけど、会則を決めたり、絵の描き方・漫画の描き方の自主勉強会(教室を借りるのは無料でできた)をやったり、漫画の参考書を梅田のジュンク堂まで探しに行ったり、僕の高校時代の漫研での活動を参考に大学祭で展示発表をしてみたり会誌を製本してみたり(そういうわけで「会誌編集長」という役職をやらせてもらっていたというのが、僕の携帯電話のメールアドレスに「へんしゅうちょう」って入ってる理由なのです。その頃からずっとアドレスを変えてない。)、そうさく畑に参加してみたり、勧誘のために色々チラシを作ってみたり、空いてる時間に集まってダラダラしゃべったり、安い焼肉屋で忘年会をしたり、とにかく前例がないところで自分たちが最初にルールや運用を決めていかないといけないって事で、色々やってた。僕の大学時代はそんな感じで、講義を受けてるかコミックアートの活動をしてるかMozillaの拡張機能を書いてるかで埋まってた(いわゆる合コンというものにも1度も参加しないままだった……)から、ものすごく思い入れがある。

僕が在籍していた当時は結局非公認サークルのままだったんだけど、その後の世代がちゃんと継続して活動してくれてて、今では数十人のメンバーを抱える大所帯となり、同好会になってさらには部にも昇格したのだそうだ。検索したら、大学の公的なサイトにも「41人」って書いてあって、うわーまじかーって思った。(ちなみに、サークル名で検索するとトップに当時の僕らが作って放置かましてしまった化石サイトが出てきたりして、それは別の意味で「うわーまじかー」って感じだ。)また、参加者の中にはプロの漫画家としてデビューした人も2人いるそうで(そのうち1人は、本屋の店頭でコミックスが今まさに平積みされてるのを見たばっかりの人だったので、余計に驚いた)、まあそういう人は元から漫画描きまくってる人だったりするからそこにコミックアートがどれだけ寄与したのかは何とも言えない(それどころか、ひょっとしたら、SF研究会を抜けた時の僕みたいに「ここにいても駄目だ……」って見切りを付けられる側だったりしたのだろうか……本当のところを知るのが怖い)んだけど、とにかく素人集団で始めたものがこうしてちゃんと10年続いたんだ!と思うと、非常に感慨深い。

これからもずっと続いていってほしいものです。

同居と食生活 - Aug 19, 2012

家事とか料理とか普通にしてますよって言ったら「意外だ」って言われた、という事が過去にあった。

「料理してる」という言葉の響きがなんか大仰だけど、実際僕の方がやってる事って、スパゲッティを茹でるか、ご飯の上に鰹節載せてレタスと水菜を刻んで載せてアボカドとネギトロ載せてマヨネーズと醤油かけて「アボカドネギトロ丼や-!!」って言い張って出すか、Cook Doするか、そんな感じですよ。特に料理が趣味というわけでも無い人間が、朝出勤して夜帰ってきた後に残った気力でできる事なんて、たかが知れてますよ。

なんとなくだけど、自分以外の人がいると、カップラーメン出して「晩ご飯これで」とか、スーパーで見切り品の弁当買ってきて「はい」とか、そういうのは、何か、こう……ちょっと、ないよね、って思っちゃって。結果的に取れる栄養の内容は大差なくても、スパゲッティ茹でて出来合いのソースかけて出す方を選んでしまう。

そこにどれだけの意味があるんだろう。見栄なんだろうか。薄いプラスチックのペコペコの容器で出す、っていう事に一番抵抗があるのかも。家でまでそういう器で食事を取るって、なんか、みじめな思いをさせてしまう気がして。そういうのが動機のかなりの部分を占めている気はする。栄養バランスをちゃんと考えていたら、こんなもんじゃ全然駄目なんだろうし。体裁だけ整えようとしてるんじゃんって言われたら、返す言葉も無いですね。

という風な事を、中村うさぎ×伏見憲明 トークライブの記事私にしてもパートナーがいるとか、一緒に暮らしてる人がいるってことは、ちょっと重荷なのよ。だけど、その重荷がずっしりと重くて、背負って歩けないというほどではなく、ちょうどいい重しみたいな感じ。あたりの件を読んで自分を省みて思ったのでした。

漫画、連載 - Jul 02, 2012

「描かないマンガ家」の3巻で、マンガ家デビューを目指す若手が3話連載のチャンスをもらって、好評なら長期連載ということだったんだけど不評で予定通り3話でおしまいになって、長期連載になるチャンスを逃して涙する、という話があって、見てていたたまれなくなった……

日経Linuxで連載中のシス管系女子も、実は当初はとりあえず3回くらいでっていうことで話をもらってて、3話目の最後に「つづく」って入れていいのか良くないのか(っていうか話的にちゃんときりのいい所で終わらせなきゃなんじゃないのかとか)悩んでたりしたんだけど、なんか特にそこを突っ込まれることもなく4話5話と続いて、今に至ってる。それでもうすぐ1周年ですよ。感慨深い。

でもそれはあくまで技術系の雑誌(専門誌?)の連載「記事」としての評価なのであって、「雑誌の連載漫画作品」というのとはまたちょっと違うのかな-、と思う所もある。画力も話作り(技術解説の部分ではない、エンタテインメントとしての部分)も取り立てて優れているわけではない……というか、むしろ下手な方だと思うし。そこら辺、純粋に画力や話作りで勝負する「漫画業界」に比べるとずいぶんユルく甘やかされてるんだと思う。「描かないマンガ家」「バクマン」等のマンガ家漫画を見てると、こんなんで連載やらせてもらってるのが忍びないです。

という事に引け目を感じるくらいなら、上達することに一生懸命になれよって話ですよね……

tabFx2Compatible.xul、tabFx2Compatible.css、tabFx2Compatible.xmlを使わないようにした - Feb 09, 2012

ツリー型タブ情報化タブの今日付でのリリース分から、tabFx2Compatibleという自作のライブラリ(?)を使わないようにした。当初はマルチプルタブハンドラでも使ってたけど、ツリー型タブ・情報化タブに先駆けて一足先に使わないようにしていた。今回残りの2つでも利用をやめたことで、TBEやり直し組のアドオンからはこのライブラリが全く姿を消したことになる。作ったのが2008年の2月からだから、丸4年くらいは使ってたのか。

このライブラリは元々、Firefox 3での仕様変更に追従するために仕方なく作った物だった。

Firefox 2ではタブの中に任意の要素(サムネイル描画用のcanvasだったりカウンタ表示用のlabelだったり)をXBLのコンテナ要素を使って動的に追加できていた。しかしFirefox 3になる時、具体的には2007年の12月頃に、高速化のためにそういう冗長性を排除する変更が行われてしまって、JavaScriptで動的にタブの内容を追加するということが原理上不可能になってしまった。

正確には、方法はあった。Firefox本体がタブに適用していたXBLによるバインディングを独自のバインディングで置き換えて、それを使ってタブの内容を変更するというやり方だ。しかし、XBLのバインディングは同時に1個だけしか適用できないという制限がある。複数のアドオンが同じ事をやろうとしたら、結局どれか1つのアドオンしかまともに動かないという事になってしまう。他の人の作る物との互換性という話に限らず、リッチでファットなAll-in-One型のアドオンであったTBEを捨てて各機能ごとに個別のアドオンに開発し直す道を選んでいた僕にとっては、自分の手がける物同士の互換性を維持するためにも、これは致命的な問題だった。

前述のライブラリは、特定のアドオンのために特化したバインディングを適用するのではなく、Firefox 2時代の「ある程度好きなようにタブの内容を増やせる余地がある」、冗長性を持った汎用的なバインディング定義を、Firefox 3向けに復活させるという物だった。

風向きが変わったのは2010年9月の事だった。Firefox 3.7のモックアップで示された視覚的なデザインを実現するために、タブのバインディングに再び冗長性が付与された。メジャーバージョンとしては、この変更はFirefox 4から反映されている。僕はこの仕様変更をうけてtabFx2Compatibleを改修し、Firefox 4以降のタブのバインディングの構造と、Firefox 2以前のタブのバインディングの構造の、両方を併せ持つ状態に変更した。

という経緯を見ると分かるかもだけど、このtabFx2Compatibleというライブラリは本質的に、Firefox 3.0から3.6までの間のバージョンに対応するためには欠かすことができなかった。ツリー型タブ等のアドオンの対応バージョン範囲の下限がこの範囲に重なっている間は、このライブラリは絶対に使う必要があったので、いくらTMPやVimperator等とバインディングの衝突の危険性があったとしても、構成ファイル群から外すことができなかった。

今回、Firefox 10のESR(延長サポート版)がリリースされたことにより正式にFirefox 3.6の死期が確定したので、サポート終了を待たずにFirefox 3.6のサポートを打ち切って、それと同時にtabFx2Compatibleも廃止することにした。レガシーなFirefox 2由来のDOMツリー構造を前提にして書かれたスクリプトやスタイルシート等を、全面的にFirefox 4以降の既定のDOMツリー構造に合わせて変更する作業は、それなりの手間を要したけれども、これでカビの生えた過去から決別できるのなら安い物だと思った。

選択肢の1つとして、tabFx2Compatibleを今後も使い続ける(Firefoxのタブのバインディングの構造が変わったら、その度にtabFx2Compatibleを更新していく)というやり方もあった。今この瞬間にかける労力を最小化する事を選ぶのなら、そういう選択もあり得たと思う。でも、tabFx2Compatibleは元々Firefox 3から3.6までの暗黒期を乗り越えるためだけに用意された物だったのだから、用済みになったのなら、思い切って捨てた方が今後のためになると思った。

こういう切り替えをできる時にやっておかないと、またTBEみたいな事になってしまう恐れがある。TBEでは、タブの移動等といった基本的な機能すらFirefox本体に備わっていなかった頃から開発していたため、TBE自身で独自の「タブを移動する」などのAPIを実装していた。そういう古いオレオレAPIから、Firefox 1.5くらいから新しくFirefox本体に備わったTabMoveとかのDOMイベントベースでのやり方にスイッチする事の手間を惜しんで、「とりあえず今動いてるから」と独自のオレオレAPIを維持することに固執してしまったがために、TBEはFirefox 1.5とともに時代に取り残され死んでしまった。そんな愚はもう繰り返してはいけない。

それにつけても、あの辺(Firefoxのタブまわり)の開発をやってる人達の意向に振り回されっぱなしだった4年間だったなー……と思うと、なんか感慨深い。

より良いコード - Feb 01, 2012

自分で自分の書くプログラムが(道具として使って目的を達成できるかどうかという評価ではなくて、プログラムコードそのもの綺麗さとかそういう意味で)良いかどうかっていうのは正直よくわかんない。もちろん「良いコードを書こう」と思って意識はしてはいるけど、他の人から見たら「全然駄目じゃん」って言われるんじゃないかって思ってる。ただ、それでも、過去(数年単位に限らず、下手したら数ヶ月単位で)の自分が書いたコードは確かに悪かったのだなということは、今なら分かる。

良くなってる点があるとしたら、一言で言うと、「独り善がりさが減った」って事なんじゃないかなーと思う。属人性が減って、普遍性が増したというか。

過去の僕は、今よりずっと多くの時間を趣味のコーディングに費やせていたし、作っていた物の規模も今より小さかった。だから、傍目にはスパゲッティコードにしか見えないようなコードであっても、その時の僕の頭の中にはプログラムの全体像が入っていて、問題があったらどこを直せば良いのか、新しい機能を付け加えるにはどこに手を入れればいいのか、把握できていたのだと思う。そういう状況では、モジュールの分割であるとか関数の分割であるとか変数・関数の命名であるとかに気を遣う必要性が薄いから、自分の頭の中にモヤモヤとあった物がそのまま形になったような、そういう物ができあがるんじゃないかと思う。

でも、作る物の規模がだんだん大きくなっていったり、抱え込む物の数が増えて関心があちこちに分散したりして、全てのプログラムの全体像を常時完全には把握しきれなくなってくると、だんだんボロが出始める。また、費やせる時間もだんだん減ってきて、力業でも補えなくなってくる。そうなってきて初めて、「良い設計」とか「良いコード」とかいうものが身に染みて分かってきた気がする。

それまでも一応知識として「どういう設計になってるのがいいのか」とかいう事は知っていたし、元々完璧主義者な所もあって、頭でっかちなりに「良い設計」とか「良いコード」とかいう事は考えてはいたと思うんだけれども、実感は伴ってなかったんじゃないだろうか。

最初は誰かの受け売りだった「1ヶ月後や1年後の自分が見ても分かるコードを書く」という方針は、そういう事があって、今自分の中に実感を持って染み着いている。初めてその言葉を聞いた時の僕にとっては、「1ヶ月後の自分」「1年後の自分」とは、「昨日も今日もその事に没頭し続けていて、そのように連続した開発が1ヶ月間、1年間と続いた先にいる自分」という意味にしか受け取れなかったと思う。だから「1ヶ月後の自分なんてもう完全に他人」なんて言われてもピンと来なかった。でも今はよくわかる。なんだかんだで時間を取れなかったりやる気を維持できなかったりして1ヶ月くらいプロジェクトから離れてしまうというのは、実によくある事なのだ。毎日毎日同じ好きな事ばかりやっていられるとは限らないのだ。そうして久しぶりに触れた時に愕然とするのだ。1ヶ月前の自分が何を考えていたのか、まるで思い出せないという事に。

ましてや本当に他人だったら、「思い出す」ための手がかりすら無い。他の人がやっているプロジェクトに共同開発者として参加したり、誰かからプロジェクトを引き継いだりした時に、独善的で属人的なコードがあるとどういう事になるか。複数人で1つの物を手がける時、将来的には誰かに引き継がなければならない物を作る時に、自分自身が何に気をつけなければいけないのか。

クラスやらモジュールやらが分けられているとか、名前空間がどうであるとか、関数が小さいとかコメントが豊富とか、そういう個別の「テクニック」が駆使されている「から」、「良いコード」である、という事ではない。毎日毎日「今の自分」のためにしかコードを書いていないような人間には欠けている、1ヶ月後の自分やあるいは全くの他人でもスムーズに開発を継続・継承できるような状態を保とう、自分という人間がいなくても勝手に生き残って生き続けてくれるようにしておこうという、美学とか哲学とか信念とか言われるようなもの、未来を見ている姿勢。少なくともそれがあるのが「良いコード」なのではないかと、僕は思ってる。

1ヶ月前に自分が書いたっきりのコードを読み返してみて、ちゃんと分かるかどうか。良いコードなのかどうかは、時間が証明してくれると思う。

Firefoxと自分の関係を見直す - May 07, 2011

Twitterとかでポロポロこぼしてるのをまとめておきたいと思ったのでまとめることにした。要点だけ先に書いておくと、以下の3点。

  • Firefoxが世の中に受け入れられてたのは、オープンソースだからでもWeb標準だからでもなく、単純に「無料で手に入り、必要十分な機能を持ってて、ヘビーユーザの使用にも耐えるポテンシャルを持った、良いアプリケーションソフトウェア」だったから。
  • その点において世の中の関心は既にGoogle Chromeに移っている。
  • 今でもFirefoxにこだわってる人は、おそらく時代を読めてない(でも敢えてそうしてる所が多分ある)。

何度も書いてる話をまた繰り返すんだけど。

僕がMozillaに肩入れしだしたのは、僕がW3C信者で、Geckoエンジンが当時一番マシなCSS2の実装を持ってた(ように僕には思えた)からだった。ポジショニングがちゃんと仕様通りにできて、疑似要素とかも使えて、スタイルシートWebデザインで語られていた「あるべきWeb」を実現してくれる物だ、という風に僕は思ってた。

そのうち僕はMozillaの拡張機能開発にのめり込んでいったんだけれども、のめり込む中で「Web標準は世間知らずの学生やら学者やらが語るだけのオモチャで非現実的な絵空事、なんかでは決してないという事を証明したい」「プラットフォームを選ばずWeb標準技術でアプリケーションソフトウェアを作れるという事そのものが、その証明になる」という思いをだんだんと強めていった気がする。その後でUIがどうとか色々加わったものも有るんだけど、発端にあって且つ今もある核の1つであることは間違いないと思う。

そうこうするうちにオープンソースというキーワードから就職が決まり、「オープンソース素晴らしい!」的な言説にそれまでよりも沢山触れるようになった。Mozillaも、「Firefoxはオープンソースだから多数の目によって監視されていて品質が高い」とかのアピールをよくしてた。Firefoxのシェアがちょっとずつ増えていって、「オープンソース素晴らしい!」「コミュニティ素晴らしい!」「バザール!」「カスタマイズ性が高いのって素晴らしい!」的な言説にもさらに多く触れるようになった気がするし、自分でもそういう事を言うようになった気がする。

  • Web標準技術に基づいているという事。
    • 仕様が特定のプラットフォームの習わしに囚われていない。無色透明である。
    • Webの礎を作った人達のお墨付きである。
  • オープンソースで、全てのコードを見られるという事。
    • トラブルの原因をとことん調べられる(根気さえあれば)。
    • 既存のコードを参考に派生物を作れる。誰にも気兼ねせず、恐怖に怯える事もなく、安心して成果物を公開できるし他人の成果物も取り込める。
    • 誰でも関われる。コードを書くだけでなく、検証したりバグを立てたりドキュメントを整備したりといった、自分にできる形でプロジェクトに参与できる。
  • カスタマイズ性が高い事。
    • 使っていて不満に思う所があれば、かなりの程度自由に挙動を変えられる。
    • 愛用の道具に少しずつ手を加えていく、秘密基地を少しずつ整備していく感覚で、居心地の良い空間を作っていける。

こういうものがMozillaの、Firefoxの価値だと僕は思うようになっていた。

Mozillaの拡張機能を開発する中で僕は、それなりの評価を世間から得る事ができた。Firefoxが世の中で受け入れられていく中で、僕の成果も評価されていった。W3C信者でCSSコミューンで啓蒙啓蒙と息巻いていた頃に抱いた「どうしてこんな素晴らしい物を皆分かってくれないんだ」という鬱屈、運動ができず特段勉強ができるわけでも人気者でもない自分がメインストリームの人達を横目に休み時間机に俯せていた時に感じていたやるせなさ、朝礼での表彰だとかトロフィーだとか優勝旗だとかに憧れながら無縁のままだった口惜しさ、そういった物から僕は解放されたような気がしていた。

僕は、僕を救ってくれたモノの事を、僕自身の存在意義をも仮託して支持するようになっていたのだと思う。


ただ、世間がFirefoxを評価していた最大の理由は、そういう事とは全く別の所にあったんだな。

世間が評価したのはあくまで、Ben GoodgerやDavid Hyattといった人達が「こういうブラウザがあったら使いやすくて便利なのに」と思ってスカンクワークス的にユーザ視点で作ったアプリケーションソフトウェアとしてのPhoenix、そしてその血を引くFirefoxだった。これは多分間違いない。

オープンソースだとかWeb標準だとかは、ある意味ではオマケの要素に過ぎなくて、ある意味では「今時そうであって当たり前だろ?」っていうレベルの話でしかない。カスタマイズ性だって、別にFirefoxのやり方でなきゃいけなかったなんて事は全然無くて、というかFirefoxのやり方(不安定且つドキュメント不在のAPIの山で、全てが個々人のアドオン開発者に丸投げ)なんて下策もいいとこで、結果的に「フツーの人」や「ヘビーユーザ」が欲しい機能が手に入るのであれば、それは安定したAPIと開発を支援する仕組みによって実現されるものであっても何ら問題ないどころか、そうであった方がユーザのためにも良い。

「必要なのはこの機能だ」「こんな機能は不要だ」といった判断を下して方針を定めて1つのビジョンの元に形作られたからこそ、Firefoxには「使いやすくて便利だ」という分かりやすいメッセージが備わって、小難しい事になんか興味の無い普通の人にも受け入れてもらえてたんだと思う。


つまり、こういう事だ。「オープンソースでWeb標準」なMozillaが元々そこにあった。その中から「便利なアプリ」のPhoenixそしてFirefoxが産まれてきて、その「便利なアプリ」に惹かれていろんな人が寄ってきた。でもそのうちに「便利なアプリ」を作った中心人物達はMozillaを去って、AppleやらGoogleやらに行ってしまった。そして彼らはそこでまた別の「便利なアプリ」を作り始めた。今またその「便利なアプリ」が新たにいろんな人の関心を集めている一方で、「便利なアプリ」を産んだ中心人物達がいなくなったMozillaにはFirefoxには、多くの人の関心を集める材料たり得ない「オープンソースでWeb標準」という部分だけが残された。

「今まで使ってたFirefoxの新しいバージョンが入ったから使ってみたけど、重くてヤダ。これだったらGoogle Chromeっていうの? こっちの方がいいや。」カジュアルにFirefoxを使い始めた人は、こうしてカジュアルにFirefoxから去って行っている。今Firefoxについて行っているのは、その残された部分に元から惹かれていた僕のような酔狂な人間と、Firefoxやそのアドオン(特にTab Mix Plusあたり)にロックインされて他に移れなくなってしまったドン詰まりの人間だけだったりするんじゃないのか。

さらに言うなら、前述した通りオープンソースもWeb標準もカスタマイズ性も今となっては「どのプレイヤーも備えていて当たり前の、最低限の要素」となっているのだとすれば、Firefoxに残された部分にすら何ら特別な独自性は無いという事にはならないか?


他のプレイヤーが持ち得ない全く独自のカラー、進むべき道を指し示す分かりやすい「方針」「指針」を持てないと、Firefoxの衰退のスピードは加速する一方なのではないか。

Ben GoodgerらがPhoenixをスリムに作れたのは、彼らに「こういうものを作りたい」という思いがあったからというだけでなく、スカンクワークスとして余計な横やりに晒される事無く初期の開発を進める事ができたからではないだろうか。まだ世の中のどこにも無いまだ見ぬ「より良い物」を求めて最先端をひた走っていたからこそ、そういう事ができていたのではないか? 10年来の「Mozillaユーザ」といったしがらみに囚われて、船頭多くして船山に登りまくりになっているようにも見えるFirefoxが、他の模倣・後追いではない独自の「最先端」を切り開いていく事は可能なのだろうか?

FirefoxボタンやApp Tabやステータスパネルといった新機能の導入は、OperaやChromeといった競合製品の猿真似に過ぎなかったりはしないか? Microsummariesやプロファイルマネージャの廃止は、「アンケート調査の結果」という一見するともっともらしい数字を楯にした思考停止だったりはしないか? 受け身に徹していたりはしないか? そこにビジョンはあるのか? 一本筋の通ったストーリーはちゃんとあるのか?

……というかそもそもの話として、「進むべき方向が分からない。プロジェクトが生き残るために、進むべき道を定めなければ。」なんて考え方をしてるなら、その時点でもう終わっちゃってるとも思う。進みたい道があるから進む、その道を進むためにプロジェクトを立てる、それが当たり前のあり方だ。組織の自己保全が目的となった組織の末路なんて、今更語るまでも無い。プロジェクトの自己保全が目的となったプロジェクトだなんて、一体何の冗談か。プロジェクトとしての役割を果たし終えたのであれば、プロジェクトは解散しないといけない。

Netscapeのための「無償労働力集めの場」ではなくなったMozillaプロジェクトの目的は、一体何なのか。その目的はまだ達成されきってなどいなくて、今も果たし続けなければならない物なのか。The Mozilla Manifestoが「何かを言っているようで実は何も言っていない」言い訳などではないなら、ここから演繹される物がFirefoxの進む道なのだろう。

その道に、僕はどのように関われるのか。あるいは、どのように関われないのか。もうすぐ三十路に突入する僕は、個人的な承認欲求が満たされるかどうかといった話に留まらず、仕事上での関わりも含めて、いいかげん真面目に考えないといけないという気がしている。

Page 5/245: « 1 2 3 4 5 6 7 8 9 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき