私がカスタマイズした OpenDolphin-2.7m （という電子カルテ。本家 LSC Dolphin の直接 Fork）は、以前に前期LSC一家と言ったら良いんだろうか、ともかく 2018 以前の LSC と繋がりの深かった人々からおかしな非難をされていた。
（『保健医療科学院 小林慎治が国家公務員法違反疑いで厳重注意を受けた件について』や『小山哲央（アーク情報システム）の件』参照）
彼らがいうには、Fork 順は
LSC Dolphin（いわゆる本家） → 2.3m（いわゆる増田ファクト）→ 2.7m （ワイのバージョン）
なんだそうだ。
正しくは LSC Dolphin(Ver 2.7) → 2.7m なんだが、それはソースコードを見ればわかる。
例えば、ModuleModel.java というファイルの冒頭をみてみよう。
2.7 と 2.7m では一字一句いっしょ。
この箇所は 2.3m ではこうなっている。
赤枠の部分が追加されたコードで、検索（hibernate search）のためのアノテーション（＠から始まるコード）が付加されていることがわかる。
私がわざわざカスタマイズしたのは、
・2.7 にあったバグ（通院精神療法のコメントが正しく表示されない）を修正したい
・簡易なファイルバックアップシステムを実装したい
というのが主な動機で、データの互換性は完全に保ちたかったから、データ構造周りには一切手をつけていないし、上記の機能に関係しない部分も同様に手を加えていない。
だから、2.3m → 2.7m という Fork 順はありえない。
いちいち、付加されたコードを削ぎ落として作業すんの？
ありえんでしょ。
なお、ModuleModel.class というのは、Dolphin サーバーがカルテ記載内容をデータベースに永続化する際に最も基本となる単位で、SOA 欄文字列・図などのグラフィック要素・P欄文字列をそれぞれ一つのモジュールとしている。
シンプルだが、当時のデータベースが CLOB をうまく扱えなかった関係上、図も文字情報も全てバイナリ化してBLOB として格納されている。
カルテに復号する時は、モジュールを拾い集めた後、内容毎に処理を変える必要があるというなかなか地獄のような仕様になっている。
さらにおかしいのは皆川和史氏が設計したことにはなっている点だ。
しかし、
・LSC の経営陣が変わった際に彼は担当役員を外されている
・この程度の基本的なデータ構造を把握していない
（自分が設計したデータ構造を他のものと取り違えるということがあるだろうか？）
・メドレーに至っては開発者認定していない
といった事実があり、個人的には別の人が設計したのではないかと思っている。
増田茂医師に関しては言わずがなだろう。
hibernate serach を用いた検索機能はアイディアとして素晴らしいし、付加されたコードも申し分のないものだ。だが、こんな完璧な修正を行える人が、データ構造を把握しておらず、Fork 順に関して間違えるとは思えない。
やはり、別の人が設計・コーディングしたと考えざるをえない。
ところで、オープンソースの世界は一般には不親切で（商用を前提にしていないので当然だ）、よくわかってない人間に対してメンテナが言う言葉は大抵の場合
ソースコード嫁
である。