Home > Latest topics

Latest topics 近況報告

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

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

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

Page 6/248: « 2 3 4 5 6 7 8 9 10 »

結婚指輪を常に付けるかどうかとかの話 - Feb 09, 2014

中国嫁日記の、結婚指輪を紛失した話を見て思い出したり思ったりしたこと。

僕自身は、母がずっと結婚指輪を付けている人だった(小さい頃に聞いたら「肉が付いて外れなくなったから」と言ってたんだけど……)から、結婚指輪とはそういうものかと思い込んでいた。

が、自分が実際に店に行ってカタログを眺めてみる段になって、それらは「当たり前」の認識ではないのだという事を知った。

  • 派手なデザインの結婚指輪も色々あるらしい。
  • あんまり派手だと生活する上で不便じゃないだろうか、と疑問を口にしたら、「常時付けるとも限りませんし」みたいな事を言われた。

率直に言ってカルチャーショックだった。結婚指輪を付け外しするかどうか、なんてそんなに話題に上る話でもなかったから、最初の時点でインストールされた認識以外の考え方があるなんて思いもよらなかった。

とはいえ、なぜそれでカルチャーショックになるのかというのが重要な点だ。目玉焼きには塩でしょ醤油でしょソースでしょみたいな話は、突き詰めれば好みの問題と片付けられるけど、結婚指輪を付けるかどうかというのは僕にとってはもっと重要な意味合いがあった。それは、「結婚指輪を付けていることが、良好な夫婦関係の証明である」という認識だ。

というのも、ドラマやなんかで既婚者が浮気・不倫をする時に、既婚者だとバレないように指輪を外してから行くとか、「自分と一緒にいる今は、結婚の事を忘れて欲しい……」とかなんとか言って相手が既婚者側の指から指輪を抜き取るだとか、そういう描かれ方をしているところを何度か見てきていたから、「結婚指輪って特別なものなんだな」と、知らず知らずのうちに刷り込まれていたのだと思う。どこでそういうのを見たのかを思い出せないくらいには、僕にはすっかりその規範が内面化されてしまっていた。

でも、この事がきっかけとなって、僕は「そうでない価値観があるのだ」と思えるようになった。そう考えるに足るいくつかの気付きがあった。

  • 「そもそも結婚指輪を作ってない」とかの極端な例すらあるという事をその後知った。というか父がそうだった(いや、ずっと付けてるものと思い込んでたんで……思い込みって怖いですね)。
  • 自分が見てない所で結婚指輪を外していたとしても、どうせ気付けない。
  • 結婚指輪をしていたって、浮気する人はする。
  • 自分が相手に強制して、相手に嫌々指輪を常時付けさせていたとして、それが良好な夫婦関係の証明であるとは到底言えない。それはむしろDVの証明であろう。

相手が本気になれば僕のことなんかいくらでも欺けるのであって、結婚指輪1つにこだわっても本質的な解決にはならない。それに、欺かれないように監視・束縛を強めることで相手が幸せになるわけでもない(束縛されたがりの人は除くとして)。結局、自分がどれだけ相手のことを信じられるのかにかかっている。相手は絶対に自分の事を欺かないはずだと確信するとか、自分は相手に欺かれたとしても絶対に後悔しないでいようと心に決めるとか、そういう事なんだと思う。

という事に気づいたことで、僕は結婚指輪に対する妄執から解放された。今では、自分がずっと結婚指輪を付けているという事自体についてすらも、客観的にフラットに認識できているのではないかと思う。習慣と「自分がこうしていたいから」と、あと「自慢したいから」、そんな程度の理由で付けている、というのが今の自分の認識です。

もらって嬉しいプルリクエストと、もらって残念な思いをするプルリクエスト - Nov 10, 2013

人格攻撃をしたくて書いてるわけじゃないですよ、という事はまず最初に表明しておきます。

GitHubで公開してるプロジェクトについて、幸いなことに時々プルリクエストをもらえる事があるんだけれども、その時に、何のストレスもなく「Merge」ボタンを押せる時と、そうでない時とがあるなあと思ってた。

その差は何なんだろう?と思ってたんだけど、今回treestyletabのargumentsを使っている箇所を書き換えるプルリクエストをもらって、それに関してやり取りをした事を通じて、「あ、こういう事かな」と思った点が1つあった。

それは、「相手の考えを尊重する態度が見られるかどうか」。

ロケールの翻訳であったり単純なtypoの訂正であったりというパッチではそういうのはまず見えてこないんだけど、今回のように設計のポリシーにまで踏み込んだパッチだと、互いの思惑がずれていることが見えてくる事がある。今回の場合、僕と彼とでは「こうあるべき」と思っているコードの姿がずれているんだなと思った。また、「ああ、僕がこれほど大事に思っていることが、彼にとっては些事に過ぎないと見えているのだなあ」という残念な思いも感じた。

考え方が違うことがすべて悪だとは思わない。JavaScriptの古い仕様であるargumentsから、ES6のRest argumentsへの置き換えを進めるというのは、古い物ばかり見てしまっていて且つ保守的な自分からはそういう発想がまず出てこない(大抵、どうしようもなくなってからようやく重い腰を上げる感じです)ので、自分の目が届いていないところについて「こういうのもあるよ」と教えてもらえるのは、正直、とてもありがたい。

ただ、僕が大事だと思っている事についてバッサリ切り捨てるような態度を取られるのには、いい気がしない。arguments・Rest argumentsで全部の引数を引き渡すように書くべきか、それともすべての引数をきちんと定義しておくべきか、という議論では特にそれを強く感じた。

僕は僕なりの考えを持って、過去に悩まされた色々な事例からの反省であったり、現実的にどこまでメンテナンスに時間をかけられるかという葛藤であったり、どういうコードであれば僕の思う「How」を正しく書き記せるのかであったり、といった事を考えた結果としてああいうコードを書いていたのだけれども、それらの一切合切を無視して「こうあるべき」と別のスタイルを押しつけられることに、僕はどうしても不快感を感じてしまった。コードを自分と同一視していて、自分自身を否定されたかのような感覚すらあったのかもしれない。最初の1回だったら、まあそういう前提が共有されているはずもないので、齟齬があるのはしょうがないと思うんだけど、2度にわたって否定されると、「あ、この人は僕のいろんな思いを尊重しようというつもりが全然ないんだな」と感じて、急速に心が冷たくなっていく、そんな感じがした。

何年もコードを書いてきたんだとか、自分がここまで育ててきたんだとか、そんなクソくっだらない個人的感情に基づいた見栄でもって、真理を歪めてはならない、というのは、その通りだと思う。でも、とても残念なことなんだけど、僕は大義のために自分の命や思い入れをためらいなく差し出せるタイプの人間ではなく、むしろ個人的な感情の方をこそ大事にしてしまうタイプの人間のようなのだ。僕はそういう頭の悪い人間ではないのだ・もっと賢くて理性的な人間なのだと思い込もうとしてたんだけど、実際にはそうではない・そうなれないのだなということを、31歳の今では痛感している。

思い返してみると、僕がかつて「技術系コミュニティ」という物に激しい拒否感を持っていたのは、それが理由だったのかもしれない。唯一絶対の真理として論理的な正さを偏重し、そうでない価値観は無意味と切り捨てる、そういう傲慢さや冷酷さのような物を僕は嫌っていたのだと思う。まあ、そういう自分の想いでもって彼らを・世界を変えたいと思っていたというのも、また同種の傲慢だったのだなという事も今では分かる。我か彼かではなく、どちらの価値観も並行して存在していてよいのだ、そういうカオスを受け入れることが大事なのだ、という事を認識できるようになったのは、それよりずいぶん後になってからのことだ。

ともかく、そういう残念な人間である僕にとって、一緒に作業をしたいと思える相手はやはり、僕の思いをなるべく尊重してくれる人という事になるのだなあ、と思うし、また自分が他の人と一緒に作業する時も、ある一面から見た時だけの正義をいたずらに振り回すことなく、最大限相手の思いを尊重して事にあたっていきたいなあ、と思う、そんなことを改めて考えた出来事だったのでした。

世の中には、ぬるま湯に浸かっていては駄目だ、自分の間違いをビシビシ指摘してくれる厳しい人と一緒にこそいるべきだ、という言説もある。僕はそれは、基本的にはいい事言ってると思うんだけど、でも、そこに相手を尊重する態度があるかどうかってのが、結構重要なんじゃないかと思ってる。

相手を尊重した上で、その思いを遂げるためにはもっとこうした方が良いよ、というアドバイスをしたり、その思いはこれこれこういう前提がおかしいよと新しい視点を示すというのは、僕にはまだ受け入れられるんじゃないかなって思う。でも、そうでなく、お前は間違っているからこうするべきだ、と、僕の思いを歯牙にもかけないでその人の思う正義であったりあるいは誰か第三者が掲げる正解であったりに沿って特定の行動を押しつけられるというのは、ストレスになる。その「厳しい指摘」がどっちであるかというのは、論理的な正しさだけを見ていると分からないと思う。

俗な言い方をすると、それが「愛があるかないか」って事なんじゃないだろうか。「厳しい指摘」をする時に、「指摘する側である自分の自己愛に溢れた指摘(独り善がりな指摘)」ではなく「指摘される相手への愛がある指摘」をする、というのは、なかなか難しいことだと思うけれども、せめてそう心がけたいとは思ってる。

また、逆に言うと、自分に向けられた「厳しい指摘」をすべて受け入れるでもすべて拒否するでもなく、その中で「愛のある指摘」を上手くより分けることができれば、他人の言説にいたずらに振り回されて疲弊することも、世界全部を敵に回しているかのような疎外感を感じることも、ないのかな……とも思う。

結論:愛は地球を救う!

Why I don't provide "disabe animation of tab dragging operations" feature for Tree Style Tab? - Nov 06, 2013

This is the English translation of my another entry.

I decided to reject a pull request for TST, adding new secret preference to disable animation effects around drag and drop of tabs, because it contradicts the principle of the TST project. This entry describes why I rejected the pull request.

Why I introduced such an animation effect?

Because it is introduced by Firefox itself. After the animation effect is activated on Firefox, I updated TST to follow it. However, it was unwelcome update for some people and I got many requests like "it is hard to operate tabs with drag-and-drop", "I want an option to disable animation effects during tabs are dragged." Actually, I can see two issues on the issue tracker:

The patch of the pull request adds a secret preference to do it. It is enough small and clear. If I added the option, I wrote just same patch.

But I disagree to merge the pull request, because I think that the approach of the patch is similar to a story: "Firefox's Gecko engine is too buggy and less compatibility to WebKit, so why don't you delete all codes of Gecko and introduce WebKit with Firefox-like UI?" In other words, it is very easy to add new option which is requested by people, however, I'm extremely reluctant to do it beacuse it is opposed to my polify on Tree Style Tab project.

Basic premises and my policies.

Basically, this project depends on Mozilla Firefox project --which is very large and uncontrollable by me-- and it is unavoidable to be tossed up and down by the storm of changes in Firefox. Actually, on my another project, I had to rewrite the addon for new versions of Firefox again and again. I learned through the bitter experience that I should have some strict policies on my addon projects:

  • Don't re-implement a feature included in Firefox itself. For example, Tab Mix Plus has its own session management mechanism, because TMP project is started before the session management feature is introduced by Firefox itself. If the TMP project was started after that, they project team didn't implement such a custom session manager. There is no merit to implement a custom feature which conflicts to Firefox's.

    To reduce maintenance cost, and to keep better compatibility with other addons which are developed based on Firefox's APIs, I think I should update and re-construct my addons for new APIs introduced by Firefox. It is better than I struggle to keep old custom implementations against Firefox's changes.

    • However, sometimes I decide to keep my custom implementations, when it is hard to rewrite codes for Firefox's new API for me.

      For example, TST uses a library "JSDeferred" to process asynchronous operations easily. On the other side, lately Firefox uses Promise and Task for the same purpose. I know I should rewrite TST based on them instead of JSDeferred, but I still don't do it because: 1) TST is strongly designed based on JSDeferred. 2) Promise/Task are not available on the current ESR (Firefox 17). (In other words, I'll merge pull requests to do such a reconstruction, if there is no disadvantage about compatibility with other addons.)

    • When the API of Firefox's library is too untrustworthy for me, I decide to use my custom library based on very low stable APIs.

      For example, Firefox has a system named "preference" which can save/restore users' configurations. Because it is not developer-friendly (ex. there are three deferent types --boolean, integer, and string--, and hard to observe changed configurations dynamically), Firefox provides some libraries like FUEL. But, such libraries are untrustworthy and risky for me because Firefox team sometimes changes those APIs despite they promised those APIs are developer-friendly --obviously they should be stable and safe--. I don't want to spend time to update my codes for such unstable APIs, so I actually use my custom library modules/lib/prefs.js which is based only on very stable low APIs. It is one of reasons why I don't update my codes for Promise/Task yet.

      Anyway, I think that FUEL APIs are untrustworthy because Firefox team created FUEL just for third party add-on developers, not themselves. Because Promise/Task are used everywhere in Firefox, Firefox team will keep them stable for themselves.

     
  • Don't depend on deprecated features. For example, "E4X" became obsolete on lately Firefox. TST used E4X in some cases, so I had to decide that I keep E4X for TST or I give up. Some projects (not mine) decided to re-implement E4X by themselves, but I decided to give up and rewrite codes without E4X.
  • Don't include features not related to the main concept. The basic concept is: what I want to use, one feature per one addon, and, as minimum as possible.

    In my old blog entry (note: written in Japanese), I told that: features which I never use or unrelated to the main concept may satisfy users in the short term, but it will shorten life of the project in the long term. Basically I develop and publish my addons on GitHub because I need it and I want to keep it available for me. So I don't want to introduce changes which can disrupt the concept.

  • Provide higihly compatible, natural look-and-feel for Firefox's built-in features and other addons. For example, Firefox has a feature "auto hide toolbox" for the fullscreen mode started by F11 key. And, TST also provides "auto hide tab bar" feature. Yes, it is not related to "tree" feature. But if TST doesn't have the feature, you'll see unexpected vertical tab bar in the fullscreen mode. You press F11, you expect that the web page becomes fullscreened, then the vertical tab bar should not appear on the scene.

    This is the main reason why I took much time to update TST to support drag-and-drop animation effects. Before the animation effect is introduced to Firefox, I respected behaviors of drag-and-drop around layers and objects on Adobe Illustrator. This behavior is still available when you drag a link to the tab bar.

Reasons why the pull request is unacceptable for me.

Based on the above policies, I disagree to merge this pull request to TST's master, because:

  • Firefox has no option to disable animation effect of dragging tabs.
    • There are different and large codes for both cases: with and without animation.
    • However, animation-less operations in rare cases seem to be inhospitable (for me), contrastively basic operations with animation are developed actively.
    • So I forecast that codes for animation-less operations can be removed from future versions of Firefox. It is risky that I develop TST strongly based on such a disappearing implementation.
  • Because there is no option to enable/disable animation effects, I think that Firefox team basically designs Firefox to do drag-and-drop operations with animations. Then, I should keep TST along the design of Firefox itself.

    • I believe that animation effects in GUI often provide better user experiences. I'm affirmative about such a policy of Firefox project.
    • Actually disabling animation effects by userChrome.css or other ways sometimes break Firefox itself. For example, the internal operation to finalize closed tabs uses "TransitionEnd" DOM event to trigger itself, but it didn't workcorrectly because the event was never fired if the animation efect was disabled by userChrome.css. (I don't kwnow the bug is already fixed or not.)

      I don't think my addon should be specially hospitable for people who live without animation effects, because Firefox itself disfavors them.

     
  • I disagree to add new option to disable animation effects, for a request like "it is hard to operate tabs with animation effects." Instead, I think I should improve usability of tab operations with animation effects, to reduce frustrations around such operations.
    • If you don't have to operate tabs manually, you won't suffer from animations. If you have to operate tree of tabs manually to put them as you want, then TST should build tree of tabs automatically more intelligently to set you free from stressful manual operations.
    • If it is hard for you to drop the tab to the favorite position with animation effects, then TST should make it easy, instead of disabling animation effects.
  • Currently I have no plan to use Firefox without animation effects. I don't want to maintain codes for a feature I never use.
  • Of course, disabling animation effects is useful for some people who suffer from visual transitions, about accessibility. However, remember, Firefox itself is not providing ability to disable animations, for such people. And, this addon is "Tree Style Tab." I think TST should not include custom accessibility features which is missing on Firefox itself --it should be done by Firefox project--.
    • If you seriously suffer from the problem, you should file a bug for the issue, induce developers to implement ability to disable animation effects. Or, you should create a new addon which is based on a simple concept: disabling animation effects. (Note, I never develop such an addon because I never use it!) The user script zzzz-removeTabMoveAnimation.uc.js for userChrome.js seems to be written for the purpose.

The conclusion: fork this project freely.

This is just my personal, current opinion. Of course I don't think this is the final truth of the topic. If you have information which can solve my worrying, or if you explain compelling reasons that I should do it, then I possibly merge such a change.

Otherwise, I'm sorry but I never merge such pull requests to my master repository. Then please fork this project, extend, maintain, and release it for people who have same distress - it is my stance on this project. To keep my codes forkable -- this is one of reasons why I distribute all codes of TST under OSS licenses.

プロジェクト名や製品名等、固有名詞の英語表記の1文字目を大文字にするべきか否か - Oct 17, 2013

英語ネイティブの人に、それが固有名詞であると分かってもらいたいなら、1文字目は大文字にしたほうがよい。ということは言えるようだ。

プロジェクト名や社名や製品名の英語表記について、「テキストデータの中では大文字始まり」「ロゴタイプでは小文字始まり」という使い分けがなされている事例をよく見る。例えばこんなの。

振り返ってみると、「固有名詞だがテキストデータ上も小文字始まりである」というケースは、日本人が書いている以外の例を僕は見た事がない気がする(Gemのパッケージ名だとかコマンド名だとかは例外ね)。

例えばミクシィは、ロゴタイプが小文字始まりの「mixi」だが、Webサイト上のテキストデータも小文字始まりの「mixi」で統一されているようだ。mixi自身が提供する英語版コンテンツでも小文字始まり。でも外部の人が編集したと思われる英語版Wikipediaのページでは、大文字始まりで表記されている。

英語ネイティブの人達にとってはどういう感覚なのだろうか?という事を知りたくて英語版Wikipediaで固有名詞の英語におけるキャピタライゼーションについての記述を参照したら、「summer」や「winter」などのごく少数の例外を除いて、固有名詞は大文字始まりで表記するのが原則であるという風なことが書かれていた。

そういえば以前に読んだ記事で、TwitterだかGoogleだかが、サービス名や社名を小文字始まりで書いたり、「ググる」みたいな俗語として「googling」を使ったりということについて、文句を言っているとか、辞書にそういう見出しで掲載するんじゃないと非難しているとか、そういう話を見たことがあったと思う。

英語ネイティブな人が身近にいないから、外してるかもなって思うんだけど、彼らにとっては、「固有名詞は大文字始まりで書くのが原則である、小文字始まりの固有名詞は不自然である」という感覚は、「印象を柔らかくしたいので小文字で表記したい」という欲求よりも優先度・重要度が高い……というか、 後者を優先するという発想が出てこないほどに、前者の感覚が常識として浸透している という事なのかなあ、と、僕は思っている。

もっと言うと、(mixiがそうしているように)日本人が固有名詞を頑なに小文字表記で書きたがるというのは、彼らから見たら、日本語の事を分かっていないDQN親が中二病な発想でキラキラネームを子供に付けてキャッキャ言ってるようなものなんじゃないのかなあ、と、僕には思えてしまう。いや、英語ネイティブの人達がほんとにそう思ってるかどうかは知らないけど、僕はmixiのような事例を見る度に、「うあああニワカが厨二病発症して俺ルール貫いてるよおおお!! 英語の本家であらせられるところのネイティブの人達に失笑されてるに違いないよおおお!!」と、無意味に恥ずかしく感じてしまう。

と、ここまで書いたところでこのサイトの名前も小文字始まり表記である事に今頃気が付いて、どう見ても完全にブーメランなのでした。

ツリー型タブにおける、タブのドラッグ時のアニメーション効果についてのポリシー - Sep 13, 2013

English version of this entry is available.

ツリー型タブに頂いたプルリクエストについて、ポリシー上の理由から取り込めないなあと思ったのだけれども、これまで、参照しやすい形でまとまった文章としてポリシーを表明していなかった気がするで、何故この変更を取り込まないか(タブをドラッグ&ドロップするときのアニメーション効果をOFFにできるようにしないのか)の判断理由を頑張って文章にしてみました。アーカイブとして、少し手直し&追記してこちらにも転記しておきます。

Firefox本体の挙動としてタブのドラッグ&ドロップ操作にアニメーション効果が適用されるようになって以後、ツリー型タブにも、その挙動に合わせるための変更を随時行ってきました。

しかしながら、この変更は万人にとって望ましい結果をもたらしたとは言えず、「タブをドラッグ&ドロップで操作しにくい」「タブのドラッグ&ドロップ操作時のアニメーション効果を無効にできるようにして欲しい」といった意見・要望が何度か寄せられています。今すぐにパッと挙げられるだけでも、Issue Tracker上には以下の2つのIssueがありました。

メールを通じて寄せられた意見も合わせると、無視できない数の人がこの件に関心を持っているようだ、という印象を僕は持っています。

冒頭に挙げたプルリクエストは、ドラッグ&ドロップ時のアニメーションを無効化する設定をツリー型タブに加える、という物でした。変更箇所は最小限で、内容もおかしなことをしている部分はなく、コードとしてはそのまま取り込んで全く違和感のないパッチです。

ですが、自分の認識としては、このパッチで示されている方向での対応というのは言わば、「FirefoxのGeckoエンジンはバグだらけだしWebkitと互換性が低いから、Geckoを全部消して、WebkitにFirefox風のUIを付けた物を次のバージョンのFirefoxにしますよ」というような物なのではないか、と考えています。……という例えは極端なのでもう少し普通の言葉で言い直すと、「確かに皆が望む通りに対処することは簡単なのだけれども、プロジェクトの運営ポリシー的に、この点で皆が望む通りの対処の仕方をする事には非常に慎重である」ということになります。

大前提として、このプロジェクト(ツリー型タブというアドオンの開発プロジェクト)は、Mozilla Firefoxという自分には制御のできない別のプロジェクトに依存している・振り回される事を避けられないプロジェクトである、という事をまず押さえておく必要があります。

ツリー型タブ以外も含めた自作のFirefoxアドオン全体で、Firefoxの仕様変更に追従するために大きな変更が必要だったことが過去に何度かあり、その時の苦い経験から、現在のところ、自分はこれらのアドオン開発のプロジェクトにおいて以下のような方針を立てるようにしています。

  • Firefox本体で実装している物と同じ目的の物は、できる限り、アドオン側で独自に実装し直さない。
    例えばTab Mix Plusはタブのセッション管理機能について、Firefox本体にそのような機能が入る前から開発されてきたという経緯から、Firefox本体のセッション管理機能とは全く別のセッション管理機能を持っています。が、今新たにTab Mix Plusを開発するとしたら、独自の仕組みを持つメリットは全くありません。 メンテナンスコストの削減と、「Firefox本体の機能と親和性が高くなるように開発されている」他のアドオンと併用したときの相互運用性を高く保つという、2つの観点から、独自の仕組みをメンテナンスし続けるよりは、Firefox本体で実装された仕組みにうまく載っかるように改修する道を選ぶべきであると、自分は考えています。
    • ただ、アドオン内の各部分が独自の仕組みに強く依存した設計になっており、Firefox本体で採用された新しい仕組みに基づく形に改修するのが非常に難しい(工数が大きい)場合には、独自の仕組みを保ち続ける選択を取る場合があります。
      例えば、TSTでは非同期な処理と非同期な処理の連携をうまく取るために、JSDeferredというライブラリを使用しています。一方で、最近のFirefoxではPromiseTaskといった仕組みが導入されており、本来であれば、JSDeferredではなくこれらに基づく形で全体を作りなおすべきところです。が、ESR版Firefoxではまだこれらが使えないという事情もあって、移行はできていません。
      (逆に言うと、そのような手のかかる変更に現在のところ自分は着手できていないが、問題視はしているということで、この点を解消するプルリクエストであれば、他のアドオンとの互換性などいくつかの懸念が払拭できていれば、是非とも取り込んでいきたいと思っていると言えます。)
    • Firefox本体で提供されているライブラリのAPIの安定性がいまいち信頼できないという場合、そのより低位の、より変更が少ないと予想されるAPIに基づいて、自分でライブラリを作成して使用しているという場合もあります。
      例えば、Firefoxではユーザ設定を保存する機能としてpreferenceという仕組みがありますが、真偽値・整数値・文字列値という型の違いがあったり、設定の変更を監視するのが面倒だったりということで、より簡単に使えるようにするためのライブラリをFirefox自身がいくつか提供しています。FUELもそのひとつです。しかしながら、それらの「シンタックスシュガー」的な用途で作られたライブラリは、ライブラリ自体のAPIが彼らの都合でコロコロ変えられてしまうリスクが結構あり、それで泣かされるのは非常にアホらしいという認識が自分にはあります。なので、僕は自作のアドオン群では、preferenceを扱う最も低いレイヤのAPIであるnsIPrefBranchを直に操作するライブラリ(modules/lib/prefs.js)を自分で作って使っています。
      PromiseやTaskへの移行に踏み切れていない理由の1つとしては、このような懸念もあります。が、FUELのようなライブラリがFirefox内部でほとんど使われていないために捨てられてしまうリスクがある(彼らは、自分が使う物は大事にメンテナンスしますが、「アドオン作者が使うように」といった感じでお仕着せの便利ライブラリとして用意した物については、彼ら自身が使っていないので冷遇しがちという印象が僕にはあります。)のに比べると、PromiseやTaskはFirefoxの中の深い部分で既に多用され始めているので、今更捨てられてしまうリスクはそれほどには高くないかな……という目算もあります。
  • Firefox本体で廃止が決まっている機能、廃止される見込みがある機能には、なるべく依存しない。
    例えば、記憶に新しいところではE4Xの廃止というトピックがありました。文字列のヒアドキュメント代わりにE4Xを使用している箇所が、E4Xの廃止で動かなくなるという事に対して、E4Xを諦めるか、E4Xを使い続けるのか、という2つの道があり得ました。プロジェクトによっては、E4Xを自前で実装し直すことでそれ以外の箇所の変更を最小限に留めるという道を選んだところもあったようですが、自分は、E4Xを捨てる道を選びました。このあたりの判断については過去に会社のブログで詳しく書いていますので、そちらも見てもらえると幸いです。
  • プロジェクトのコンセプトから外れる事は、なるべくしない。
    コンセプトは「自分が使いたいものを、1機能につき1アドオンとして、最小の形で開発する」ということ。
    過去のエントリで詳しく書いていますが、自分が使わない機能や、コンセプトから外れる機能を盛り込むことは、短期的にはユーザの満足度を高める結果に繋がる可能性がありますが、長期的には、プロジェクトの寿命を縮めるリスクを増やす事だと自分は考えています。GitHub上に置いてある僕のアドオンは、基本的にはどれも「自分が使いたいから・使い続けたいから」開発をしているので、自分が使い続けにくくなる可能性が高まる変更は、なるべく取り込みたくないと考えています。
  • 細かい挙動はFirefox本体の本来の挙動に可能な限り合わせる。違和感が無いように作り込む。
    例えばFirefox本体の機能として、F11キーでフルスクリーン表示に切り替えた時に、ツールバーが画面の外に隠れるというものがあります。ツリー型タブには「タブバーを自動的に隠す」機能がありますが、単機能だシンプル化だと言っておきながら一見するとツリーとは関係ないこのような機能を未だに含め続けているのには、このF11でのフルスクリーン表示時の挙動をFirefox本体の挙動に自然にマッチするようにしたいからというのが大きな動機としてあります。
    タブのドラッグ&ドロップ操作のアニメーションに、ツリー型タブでそれなりの労力を割いて対応している最大の理由も、これです。(Firefoxにタブのドラッグ&ドロップのアニメーションが実装されるまでは、UIが似ているAdobe Illustratorのオブジェクトとレイヤーの操作性を参考に作り込んでいました。これは今でも、タブ以外のオブジェクトをタブバー上にドラッグした時に見ることができます。)

以上を踏まえてこのプルリクエストで触れている問題を考えると、自分は以下の理由から、この変更を行わない方が良いという考えを持っています。

  • Firefox本体に、タブのドラッグ&ドロップ時のアニメーションをOFFにする機能が無い。
    • アニメーションするかしないかでFirefox内でのコードパスが大きく異なり、どちらもそれなりに大きな規模である。
    • が、アニメーションのための開発が活発に行われていたのに対して、アニメーション無しのドラッグ&ドロップについては冷遇されている(気が、自分はする)。
    • ということは、今後、アニメーション無しのドラッグ&ドロップは実装が削除される可能性もある(と、自分は見ている)。 削除される可能性がそれなりにある実装に強く依存してしまうのは、リスクが高い。
  • ON/OFFの設定がないという事は、Firefox的には、タブのドラッグ&ドロップは基本的にアニメーションするものであるというスタンスだと考えられる。であれば、Firefoxに依存するプロジェクトは、Firefoxの方針に従っておくのが得策であろう。
    • アニメーション効果を適用することは、見た目のキレイさだけでなく、使い勝手の向上にも関係するので、自分はそのようなスタンスを取ることには肯定的である。
    • アニメーション効果をユーザが無理矢理無効化すると、正しく動かなくなる、という部分がFirefoxの中にすらある。
      具体的には、タブを閉じる処理は内部でのデストラクタを走らせるトリガーとして「アニメーションが完了した」というイベントを使っており、アニメーションが無効化されているとデストラクタが走らないのでタブがきちんと閉じられないという問題があった(今その問題がどうなっているかは把握していない)。
      Firefox本体の側がアニメーションOFFでの利用をここまで冷遇している以上、そのような使い方をこのアドオンで手厚くサポートする必然性を、自分は感じない。
  • 「アニメーションがあるとタブをドラッグ&ドロップで操作しにくい」、という要望に真正面から「アニメーション効果をOFFにできるようにしました」と応えるよりも、そういう要望が出にくくなるような形での解決を図るべきだと考えている。
    • そもそもドラッグ&ドロップで操作する必然性が薄ければ、問題なくなるのではないか。手動でツリーを編集しなければ意図した通りにならない、という状況があるのなら、ユーザに手動でのツリー編集という手間を強いる方向よりは、ツリー編集しなくてもストレスを感じないように、ユーザの意図を汲んで自動的にいい感じにツリーを構築するようにした方が、より望ましいのではないか。
    • アニメーション有りの状態でドラッグ&ドロップすると狙った位置にドロップしにくい、という問題があるのであれば、それは、アニメーションをOFFにすることで対処するのではなく、アニメーション有りでも狙った位置にドロップできるようにするのが、正しい解決ではないのか。
  • 僕自身は、アニメーションをOFFにして使うつもりがない。自分が使わない機能に対するメンテナンスコストを抱え込みたくない。
  • 視覚的に連続した変化を認識しにくい、アニメーションされた方が却って認識しづらくなる、といった性質あるいは障害を持っている人がいる、という事を考慮すると、アニメーションをOFFにできるようにすることは、アクセシビリティ上意義のある事だと思う。
    が、Firefox本体がアニメーションをOFFにできるようになっていない以上、「タブをツリー表示できるようにする」というコンセプトのこのアドオンが、独自にアクセシビリティ上の配慮を盛り込むのはおかしいのではないか。
    • この点を真面目に考えるのであれば、「FirefoxのBugzillaで問題提起して、Firefox本体の側でアニメーション効果のON/OFFをできるようにする」あるいは、「Firefoxのアニメーション効果を無効にするという1つのコンセプトに則ったアドオンを開発する」という道を選ぶべきだと、自分は思う。(アドオンではないが、userChrome.js用のzzzz-removeTabMoveAnimation.uc.jsというスクリプトは、そのための物と言えそう。)

以上の事は、あくまで現時点での自分の考えがそうであるというだけで、絶対普遍の真理であるとは考えていません。ここに挙げた数々の懸念点を払拭できる材料があったり、あるいは、そのような懸念があってもなおこのようにするべきであるという強い動機があって、僕が同意できるのであれば、変更を取り込むことにはやぶさかでないです。

でも、そうでない限りは、この種の変更については「フォーク版を作ってそっちで自由に開発していって下さい。そして、その機能を必要とする人自身の手でメンテナンスしていって下さい。」というのがこのプロジェクトの方針ということになります。僕がこれらのアドオン群にオープンソースライセンスを適用しているのには、そのような自由を保障しておきたかったからという理由もあります。

冷たいようですが、どこで線を引くのか・何を基準に線を引くのかを熟慮した結果、このような線引きに落ち着いたということで、同様の不満を抱いている方々にはどうかご理解を頂ければ幸いです。

オフィスの広さとか - 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年続いたんだ!と思うと、非常に感慨深い。

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

Page 6/248: « 2 3 4 5 6 7 8 9 10 »

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のコメント

最近のつぶやき