Mr.orzによるツッコミが理解できていない。
>「メンテナが望まないフォークが発生して、互換性を維持できなくなったケース」
正確には、メンテナ→オリジネータですね。
で「かつてあったか」→少なくとも著名なケースはない（と思います）
「今後あるか？」→可能性としてある以上、企業としては何らかの対策が必要かと（でないと経営責任になる）
いや、オリジネータから引き継がれている可能性もあるので、メンテナで良いでしょう。
さて、互換性が維持できない可能性があるということであるが、 いったいどういう事態を想定しているのか想像ができない。おそらくは私の想像力が貧困なのであろうが。
「可能性を否定する」のはなかなか難しいので、 日本が沈没する可能性も、私が明日バスに轢かれる可能性も否定できない。 明らかに予測可能な事態に対策を行わなかった場合には経営責任になるだろうとは思う。 きちんとした企業では飛行機が落ちても大丈夫なように経営陣を複数の便に分散させるということだし。
しかし、ここでMr.orzやその他の方々が「予想している可能性」とは、具体的にはどういう事態なのか。
時々発生する「互換性の低い互換品」問題はオープンソースとは直接関係がない。
既に述べたが、注目を集めるプロダクトには互換品が登場することが多い。 IBM汎用機、インテルx86プロセッサ、NEC PC98、Microsoft Office。 場合によっては特許、商標、ライセンス、不当競争防止法などで疎外できることもあるが、 いつも互換品を留めることができるとは限らない。
互換品が登場した場合、差別化のためなんらかの差異が加えられることが多い。 性能や価格など互換性に問題のない差別化であれば問題はないが、 しばしば新機能(たとえばAMDの3DNow!)だったりして、 プロセッサによって動いたり動かなかったりすると悲しいことが起きる(こともある)。
あるいは互換性が不十分で問題が発生することもある。 これは単なる努力不足であろうけど。
さて、オープンソースであった場合、この互換性問題はどうなるか。 変化するのか、しないのか。
まず、オープンソースであるので、その定義からソースコードが自由に利用可能で、 かつ、修正したものの再配布が可能である。 これだけを見ると、ちょっと修正した非互換なソフトウェアが蔓延し、 互換性の保証を行うことが困難になる可能性を感じるのかもしれない。
しかし、そんなことは起きない。
あるソフトウェアAが存在し、なんらかの事情により、そのソースコードを改変した 「似ているが非互換」なソフトウェアBとCが登場したとする。 オープンソースライセンスでは(たとえLaTeXライセンス1.3を利用したとしても)、 これを禁止することはできない。
しかし、BやCをオープンソースにすること、BやCがAを起源にすることと、 またBやCがAに対してどのような修正を行ったか明示することを求めることは可能だ。 実際、GPLをはじめ多くのライセンスはそれを要求している。
であれば、もしBやCがAに対する差別化を目標としていても、 Aと、BやCの区別を明確にすることが可能であれば、 ユーザにとっては通常の互換品との差はまったくない。
開発者にとってみれば、 BやCがどのような変更を加えたかの開示要求が可能なので、 差別化を目指したBやCの良いものはAに取り込んでもよし、 そうでなければ放置してもよい。 取り込むかどうかの選択権がAにあるぶん、 通常の互換品よりも望ましい事態とさえいえるかもしれない。
というのが私の感じるところなのだが、Mr.orzが
GPLがフォークについての懸念を法的処置してないのに対して、たとえば、LaTexライセンスあたりはうまく処理していると思います。また昨年１２月リリースのモノはデキもいいし。
とおっしゃる真意はいかに。
私はGPLがフォークについて扱っていないのは、 そもそも懸念でないからだと思っている。 LaTeXライセンス(1.3)については、私にはOSD準拠にみえるが確証はないし、 GPLコンパチかどうかも(まだ)明確でないわけだから、 かえって(別の)リスクが高いのではないかと思っている。
ソースは公開するが改変についてはライセンスで一定の歯止めをかける（原則改変自由だが、不合理な非互換フォーク※を避ける）というのは可能です。
※わたくしは、非互換でも合理的なversion-up なら「やむなし」という考えです。
これも具体的なイメージが湧かない。 禁止したい「不合理な非互換フォーク」や、「やむなし」である「合理的な非互換version up」とは、 誰による、どのようなものなのだろうか。
Estraierで関連検索をしようと思えば、あらかじめestindex relateを実行しておく必要がある。
しかし、ソースを見る限りではこれは別にバッチで行う必要はなさそうだ。 ある文書に対して関連検索を要求された時にはじめてoddocscores()を呼び出し、 重要キーワードを得てから、 それらキーワードを(OR検索で)含む文書に対してふたたびoddocscores()でキーワードを取得して、 それらのベクトルの比較を行えば、eagerにスコアを求めておく必要はない。
ということで、estindex.cを切った張ったして、30分ほどでオンデマンドにスコア計算をする(_scoreに結果を保存する)コードが完成した。estindex relateを実行しなくてもキーワード抽出や、関連検索が動いているみたいだ。
ということで、平林さん、いかがでしょう。次期Estraierにはオンデマンドスコアリングを導入してみては。 ただ、_dateデータベースを更新してないんでなんかまずいことが起きるかも。