昨日、Estraierでauthor属性の検索ができないとか書いたら、 さっそく平林さんからメールをいただいた。近いうちに対応していただけそう。ありたがいことだ。
追記
改めて調べたらEstlaier 1.2.16が出てるじゃありませんか、今まで1.2.7なんてのを使ってました。 メールオーガナイザーを作ろうと思った時に入手したのに、もうこんなに進歩してるとは。 いつのまにか正規表現やワイルドカードでも検索できるようになってるし。
昨日の時点で、関連検索以外のバックエンドはほぼ動いたので、 今日からフロントエンドを作ろう、と思っているのだが、 今までバックエンドのことばかり考えていて、 フロントエンドはイメージが固まってないので、 またしばらくはぐたぐたと脳内で考える日々になるのかもしれない。
なんか、いつだって何日も(あるいは何ヶ月も、何年も)ぐだぐたと考えないと、 コーディングに入れないのは年取ったせいだろうか。
追記
結局、フロントエンドには手をつけず関連検索を実装しました。
Debianのパッケージが更新されたので、0.1.7にアップグレードする。 すばらしい。
今までFirefoxと交代で使っていたが、これ一本に集約できそうな気がする。
すばらしい点
気に入らない点
しかし、気に入らない点も些細なことばかりなので、我慢できる。
Sun Microsystemsという企業がどのような経営判断するかどうかは、 私の手に余るので、「オープンソースプロジェクトのフォークと互換性」という点に絞って考えたい。
ここ数日いただいたコメントからは、 なんとなく「オープンソースではメンテナが望まないフォークが発生して、互換性を維持できなくなるケースがある」という暗黙の過程があるような気がする。
たとえば、
オープンソース化されれば、差別化、重視になるでしょう。
一部のコミュニティが互換性を無視することに対してコミットして、互換性は失われる方向になる。
オープンソース化すると、誰にも互換性の維持はできない。
あるいは
私は、仮にJAVAをオープンソースとした場合、SUNがリーダーシップを取れなくなってしまう「可能性がゼロでない」のを恐れているように感じます。 些細な分岐がSUNに変わる本流となりえないとは言い切れないところに躊躇しているんじゃなかろうかと推測してます。
あるいは
言語系とか（TEXなんかも含めて）は、これまで蓄積してきたソース・スクリプト（コンパイラ・インタープリタ側からみると「データ」）の互換性がでかいですよね？ だから「forkをおそれる」という企業のスタンスはよく理解できます。 「旧バージョンで動いていたプログラムが新バージョンで動かない」というサポートはとても面倒。ましてや「新バージョンはウチじゃなくて別のコミュニティで勝手にコミットしてるんですがーーorz」なんて間抜けな対応したくないでしょうし。
とか。
Mr.orzさんのコメントを取り上げてみれば、 前半の「互換性がでかい(重要ということか？)」というのは十分に理解できるのだが、 「forkをおそれる」というのはどういうことを想定しているのだろうか。 どのような事態が発生することをおそれているのだろうか。
オープンソース化しなくても新バージョンを出せば互換性問題の危険はあるし、 オープンソース化しても、勝手に「新バージョン」がリリースされるわけじゃない。 フォークはあるかもしれないが(めったにないけど)、 そんな場合でも「そのフォークはうちは知りません」の一言で済むはずだ。
オープンソースではフォークを禁止することはできない、これは事実だ。
しかし、メンテナが互換性を維持したいと望んでいるのに、 フォークなどの理由によって互換性の問題が発生するようなケースがあるのだろうか。 より厳密には、オープンソースだからという理由で互換性の問題が発生しやすくなることがあるだろうか。 私には想像できない。
私は「オープンソースが原因で互換性の問題は発生しない」と思っていて、 7月6日のエントリでも7月7日のエントリでも、 その理由を説明してきたはずだ。もちろん、あれでは「ゼロであること」を証明できてはいないが、 それはムリな相談だろう。やや危険なたとえを使うと、交通事故の可能性はゼロではないが人は車に乗るわけだし。
これは「オープンソースで互換性の問題が新たに発生しない」という意味で、 逆に言うと「オープンソースでなくても互換性の問題は発生する」と読み替えてもかまわない。
かつて「メンテナが望まないフォークが発生して、互換性を維持できなくなったケース」あったのだろうか。 これからありえるのだろうか。それともFUDにすぎないのか。
それをはっきりさせたいと思っているのだ。 もし、具体的なイメージはなく、ただ単におそれているだけならばかばかしい。
企業が自分のプロダクトをオープンソースにするもしないも、その企業の自由だ。 オープンソースというやり方を信じられない。結構。 オープンソースにしない方がビジネス上有利だと思うから。結構。 苦労して開発したソースは秘密にしたい。それも結構だ。
しかし、「オープンソース化すると互換性が損なわれるから」などという、 事実でないことを理由にしてほしくない。
言語の互換性問題と言えば、各種「方言」問題がある。たとえばPascalはいろいろ方言があり、 結局ある方言(コンパイラ)用のプログラムは、別のコンパイラでは動かない(ので結局別の言語と同じ)というような。
でも、このような方言問題の原因は、オープンソースではなく、 不完全な(あるいは曖昧な)言語仕様とそれに基づいた独自実装によるのではないか。 オープンソースの処理系があれば独自実装の必要性は薄れ、むしろ方言問題は回避できるのではないか。
Javaについては、おそらくはマイクロソフトの「J++ショック」が尾を引いているのかもしれない。
気持ちは想像できるが、その問題はSunのJDKのライセンスをオープンソースにしないことでは回避できない。
SunがJDKをオープンソースにしようとしまいと、 やろうと思えば、今日存在しているオープンソースJavaコンパイラ(たとえばgcj)を改造して、 Java方言を作るのは簡単だ。
私の知る範囲でプロジェクトのフォークが発生するのは次のような理由だ。
進歩の方向に意見の対立が発生し、意見の調整ができなかった。
この場合には「本家」はそのまま存続するので、本家についての互換性は問題ではない。 分家と本家との間には互換性の問題はあるが、これはオープンソースに限らない(独自実装とか方言とかの問題)。
メンテナがメンテナンスを放棄したが、後継者が複数登場し、一本化ができなかった。
「本家」が放棄されているので、少なくとも互換性は問題にならない。
あと、可能性としては「ただフォークしたかった」というものもあるのかもしれない。
オープンソースでフォークが発生すると、重複した作業が発生するので、 リソースの無駄づかいが起きるし、進歩が阻害される傾向があるので、 望ましくない。しかし、たとえ発生したとしても、すくなくとも「互換性」の問題は発生しない。
ありがたいことに、フォークというのはめったに起きない事態だ。 これはオープンソースプロジェクトではオーナーシップが尊重されていることを反映しているだろう。
日曜日は用事があるので、役場で期日前投票を行う。 国民の権利であり、義務だから。
もっとも青木自民党参議院幹事長を擁する島根県では結果が見えているわけで、 投票行動に対する動機づけが希薄なのは確かなのだが。