オープンソースの世界 〜残酷な自由さ〜

オープンソース開発方式は理想の開発形態の一つとして語られることも多いが、現場寄りの人はかなりリアルな見解を持っている。

開発者目線では…

例えば、以前評判になったこの記事。

筆者の megamouth さんによれば、contributor(ソースコードを提供した者)にも序列があるという。


OSSへのコントリビューターにもカーストがあって、ついでに書いておくと

カーネルメンテナ>言語メンテナ>カーネルコミッター>言語コミッター>有名ライブラリメンテナ>色々>ユーザーグループ主催者>ブログでアプリへの文句だけ書奴~

みたいな序列である。

ある程度名の通ったプロジェクトの contributor になるだけでもけっこう苦労するよ、という挿話が語られている。

曰く、


アホみたいな量のコードを読み下し、コーディングスタイルを真似し、単体テストケースを書き、開発者とコミュニケーションをとってまで、自分のコードをマージしてもらう。

プルリクエスト(Pull Request PR, 自分の改変したコードを取り込んでもらう修正依頼のこと)送るだけでも大変なのだ。

さらに、新機能の提案などになると・・・

新機能にしても、同じようなことは過去の誰かが考えているものだ。それらの機能が今存在しないのは、何らかの経緯で却下されたか無視されたことによることがほとんどである。
もし彼が「ぼくのかんがえたすごいしんきのう」を拙いCコードで表現することに成功したとしても、Google翻訳を駆使して、なんとか英語圏の人間に読めるプルリクを送れたとしても、忙しいメンテナが一瞥して言うことは「過去ログ嫁」である。

単に PR 送るより大変なのがわかる。

きっかけは個人的な欲求から始まる

ところで、私がオープンソースの世界に足を踏み入れ始めたのは、2018 年の春頃からだ。
きっかけは horos という医療用画像ビューアのプロジェクトの存在を知ったとき。
医療画像ビューアは一般に高額で、レントゲンや CT の画像を「ちょっと」確認する程度であれば、オープンソースのプロジェクトの公開されているソースコードを自力でビルドして使った方が金銭的な節約になる。
おまけに自分で改変もできる。ちょっと使いにくいというところがあれば、そこを自分で改変したっていいのだ。
私の場合、改変したいくつかの機能は、horos の本プロジェクトにも PR を送り、マージしてもらった。


そういう意味では、私は「医療用の OSS」 というニッチな分野では contributor なのだが、上で述べられたようにすごく苦労したかといえば、そんなことはない。
OSS のカースト的にみれば「アプリケーション」レベルだし、何よりも「医療」と名が付くと開発寄りの参加者は極端に減る傾向がある
慢性的な人手不足なのだ。この分野では一定水準のプログラミングスキルを持った人なら、新機能の提案・実装は、(カーネルなどへ contribution するのに比べたら)かなり楽だ。

ある程度慣れたきた段階で、自分でもプロジェクトを持つようになった。

だから、けっこう短期間の割には PR を送る側の経験も受け取る側の経験も両方したことになる。

ところで、ネットを見ていると「どうやったら PR をマージしてもらえるか?」みたいな記事は見つかるのだが、逆に「これやっちゃあかん!」というような記事はあまりない。
参考になるかどうかわからないが、一つ例示したいと思う。

マージされなかった Pull Request の例

以下は、私たちが OpenOcean という OpenDolphin 由来の電子カルテのプロジェクトで、クライアントバイナリを配布してきた時にもらった PR 。
公開するのもはばかれるような内容な気もするが、当人たちは open にしろしろと主張しているのでここで取り上げても問題ないでしょう。


一目でわかる通り、単純に特定行を delete したのみ(文頭の – は削除した印)。
この場合で言えば、public static int expired( ) という関数が関与する部分を削除しましたってだけの内容。

一般にコード書きが何かを実装する場合、たいてい、狙った機能というものがある。
上記のコードでは特定時刻と現在の時刻を比較し、現在時刻が特定時刻より先に進んでいた場合、そのプログラム自体を終了せよというのが狙った機能だ。
要するにこのアプリの使用期限を設定している。(この時点で元のプロジェクトにはれっきとした商用版が存在しており、こちらはちょっとした機能の提案をしたかっただけ。気合い入れて継続的に開発していく意思がなかったというのがその理由)

だから、これは bug (バグ)ではない。

確かに、プログラムが複雑になってくると、深刻なバグがあるにもかかわらずそれがどこにあるかわからないといった場合はよくある。このような場合、それを特定するだけでも貴重な情報になる。
だが、これはそういった類のものではない。

だから、この PR はマージできない。

逆に、「残り XX 日で使用不能になります」といったアラートダイアログなどを表示させるようなコードの場合、おそらくコードの書き方が少々稚拙であってもこちらで手直ししてマージしたのではないかと思う(例え、この噂が本当であったとしても、だ)。

つまり、相手(レビュアーやメンテナー:PR を評価しリポジトリを管理する人たち)の意図を汲み取ってプロジェクトにとってプラスの価値を与えるようなプルリクには大概のメンテナーは寛容でありマージもされやすいが、単に自分の願望を押し付けるだけでは考慮もされないのだ。実際このときもそれが主な理由でマージはしなかった。

(付記)その他の理由 -著作権に対する配慮-

上で「主な理由」と書いたが、他にも気になった点はあった。
というのは、このとき PR 送ってきた相手の GitHub アカウントのアバターが、全世界でかなりの人気を誇るアニメのキャラだったから。漫画・アニメなどで人気のあるキャラの2次利用は、たいていの場合制限されている。
実際、このキャラクターは基本的には2次利用を許していない。
もしかすると、この人と著作権管理団体などで使用許諾の契約がなされているのかもしれないが、基本的には第三者にはそんなことはわからない。
そして、PR を送ってきた相手はまったく知らない人だ。信用できる人なのかどうかもわからない。
一応、名前や所属などは確認したが(京都大の小林慎治という人。現在は、保健医療科学院に所属)、ここらへんの権利関係に関してはまったく気にしていないようだった。
私が気になったのはこの点だ。
OpenOcean プロジェクトに関しては特に行動規範(CODE of CONDUCT)のようなものは定めてはいなかったが、やはり「知的財産権に関して一定の配慮ができる」というのが最低限の暗黙の前提になる。
どんなオープンソースのプロジェクトでもそうだが、ネット接続環境を持っていて、アカウントさえあれば、議論に参加するくらいのことはできる。有意義な議論になることもあれば、まったく不毛な質の低いものになることもある。ネットで不特定多数を相手にするというのはそういうことなのだ。そして、意味のある議論ができるかどうかは実社会のステータスとは相関しない場合が多い。主張している内容や実際に書いたコードでその人の能力を推し量るしかないのだ。(蛇足かもしれないが、それはオープンソースの可能性でもあるだろう。全く無名の人でも活躍できることに繋がるのだから。)
だから、何かをしたい・信用を勝ち得たいというならば、その資質を実践で示す必要がある。それ以外の基本的な部分でレビュアーやメンテナに不信感を持たせては、まず PR は拒否されるし、以降はまともには相手にしてもらえないだろう。

Fork の効用・意味

また、付け加えておくと、アプリケーションレベルのOSSでは、「エンドユーザーに近い」という特性ゆえ、異なるバージョンの開発が並行して進められるということはよくある(当たり前だがユーザーには「好み」があるから)。
特に、電子カルテのように施設毎でのカスタマイズが前提になる場合はその傾向が顕著になる。実際、元になったプロジェクト自体、施設毎での独自カスタマイズを奨励していた。自分で既存のプロジェクトにはない機能を付加したいというなら、元プロジェクトを fork して独自プロジェクトをおこせばいいだけだ。

まとめ? 残酷でもあるが自由でもある

既存のプロジェクトに自分の提案を受け入れて欲しいというなら、相手の意図にはある程度意識的になる必要がある。もし、それが叶わないというのなら、自分で独立してプロジェクトおこせ、ということになる。
タイトルに「残酷」と入れたが、ある意味、それはオープンソースの世界の自由さとも言える。

 

他にも面白い話もあるので、また続き書きます。

 

猪股弘明

オープンソースの世界

オープンソース(Open Source)ソフトウェアに関する軽めの話など。

まず、オープンソースって何ぞやって人は、『伽藍とバザール』あたりを読むと雰囲気掴めると思います。このエッセイ自体、お話として抜群に面白い。
筆者のエリックレイモンドさんが自身が開始したプロジェクトでオープンソース開発方式を意識的に選んだときの経験談やコードを書く際の箴言めいた教訓が語られています。

Linux コミュニティはむしろ、いろんな作業やアプローチが渦を巻く、でかい騒がしいバザールに似ているみたいだった(中略)。そしてそこから一貫した安定なシステムが出てくる なんて、奇跡がいくつも続かなければ不可能に思えた。
このバザール方式がどういうわけかまともに機能するらしく、しかもみごとな結果を生むなんて、衝撃以外の何物でもなかった。

よいソフトはすべて、開発者の個人的な悩み解決から始まる。

何を書けばいいかわかってるのがよいプログラマ。なにを書き直せば(そして使い回せば)いいかわかってるのが、すごいプログラマ。

目玉の数さえ十分あれば、どんなバグも深刻ではない

賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。

ところで、OSI (Open Source Initiative) という団体が認めたライセンスに合致したソフトしか「オープンソース」としては言わないとかという面倒くさい主張もあるんですが、ここでは「ソースコードが公開されていて、改変・再配布などの自由も認められているソフト」程度の意味で使います。
特に後で出てくる OpenDolphin に関しては、当初は GPL という OSI お墨付きのライセンスが適用されていましたが、現在ではそうなってはいません。
この話は説明しだすと長いのでここでは詳しくは触れませんが、経過を追うと日本においてオープンソースのソフトが成立しにくいと言われる理由がよくわかると思います。

話が横道に逸れました。オープンソースそのものの定義とかという半ば宗教論争みたいな議論をここでしたいわけではありません。
ソースコードが公開されていること、それを自由に改変してもかまわないことという特徴からどんなメリットが生まれてくるのでしょうか。
ここでは、この点に注目します。
実際、ユーザー視点や運営視点に立つと、ライセンスがどーのこーのと難しく考えるより、ソースコードを自由にいじれるかどうかという視点でみた方がわかりやすかったりします。

例を一つ。

Dynamics(ダイナミクス)

医療用のソフトの領域で Dynamics(ダイナミクス)という電子カルテ&レセコンのソフトがあります。


画像はHPトップのものですが、”開業医が開発した診療所発のソフト” とあるように、メーカー製のソフトの使いにくさに嫌気がさした診療所の先生が独自に作成し発展してきたソフトです。

だから、コミュニティ運営的は診療所開業医の先生方の相互扶助的な面が重視されています。「データの囲い込み」などもちろん持ってのほか。
HPにはこんな記載もあります。

Dynamics はプログラム内容などをすべてオープンにしていますので、ちょっとしたプログラムの知識があれば、好きなように画面や文字をレイアウトしたり、データを抽出したり、ときにはオリジナルの機能なども追加することが可能です。
このウィッキッキサイトでは全国のダイナユーザーが作成した独自プログラムやノウハウが多数、掲載されております。Dynamics の機能にはなくても、このウィッキッキサイトで解決するようなプログラムもあるかもしれません。是非、ご活用ください。

ね。開業医さんの立場にたてば、活用してみたくなるでしょう?

このような経緯があるので、ダイナミクス自体は OSI 認定のライセンスではライセンスされていません。
あくまで商用ユーザーにソースコードを公開しているのみです。
ですが、ソースコードを自由に改変してもいいという特徴は十分に「オープンソース」的です。
そして、この特徴は対象となるユーザーを何か強く惹きつけるところがあるようです。

実際、このダイナミクスというソフト、数あるメーカー製のソフトに負けない人気があります。導入数ランキングや購入後満足度ランキングなどでは、例年、上位にきています。

1998 年頃より配布を開始して、現在は導入実績が 4000 超。
データベースが MicroSoft Access に依存しているため windows OS でしか動かなくて不便とか電子カルテ部が使いにくいといった声もありますが、立派なものです。

これは、OpenDolphin(オープンドルフィン)という電子カルテと比較した場合、顕著になるでしょうか。

OpenDolphin(オープンドルフィン)

OpenDolphin という電子カルテがどういうものなのかは見てもらった方が早いでしょうか。

使ったことのない人にうまく伝わるかわかりませんが、ダイナミクスより UI などは凝ってますし、医師目線でもかなり使いやすい電子カルテです。

ライセンス的な観点でいううと、一時期の OpenDolphin は、GPL でライセンスされていたオープンソースの ORCA 連動型電子カルテでした(ただし、現在ではこのプロジェクトが GPL として妥当であったかは疑問が呈されているし、運営している会社も何度か変わっていますが、変わるたびに、この点に関してはむしろ同様に否定的な見解を示しいています)。

(一時時的だったとはいえ)OSI お墨付きのライセンスはあるし、ユーザーフレンドリーな設計だしで、普及しそうな要素はあったと思うんですが、残念ながらそうはなりませんでした。

2000 年代に開発が活発化し、一時期は商用開発元から 200 程度出ていましたが、現在は販売を終了しています。
いわゆるクラウド型では命脈は保っているのですが、2018 年頃よりライセンスは曖昧になったまま、それ以降のバージョンのソースコードは開示はされていません。

実際には、商用開発元を経由せずに使われている例が多かったと思いますが、プロジェクト自体の発展やコミュニティの熟成という意味では、上手くいったとは言い難いものがあるかなあと思います。
この理由に関しては、ここでは触れませんが、いづれどこかの機会にでも書きたいと思います。

(参考)
OpenDolphin -wikipedia 風開設-ANN2B Blog
OpenDolphin-2.7m のこれからPHAZOR.JP Blog

オープンソースプロジェクトが成功する条件

ところで、冒頭で「目玉の数さえ十分あれば、どんなバグも深刻ではない」という箴言を引用しましたが、この言葉は「目玉の数が不十分な場合、バグは深刻なものになりうる」とも取れるでしょう。

やはり、ユーザーの数や活発なコミュニティが重要なんですね。

オープンソースの成功例としてよくあげられる Linux カーネルの開発は、この条件をよく満たしていると思います。
これはソフト自体の特徴、つまり

・誰もが使う機会が多く、汎用的である

・システムの基本部分を受け持ち、透明性への要求が高い

ことから、この要求を満たしやすかったんでしょうね。

一方、医療系のソフトはなかなかこの条件を満たしにくいですね。
ORCA, OpenDolphin, OsiriX は三種の神器だったのか?』あたりも参考にしてください。
かつてはオープンソースであったがクローズドなプロジェクトになったもの、もはやその運営形態を維持できなくなったもの、などの具体例を解説しています。

 

猪股弘明
医師(精神科医:精神保健指定医)
OpenDolphin-2.7m : developer
HorliX : developer
Horos : contributor
OsiriX(open-source version) : contributor

グッズw

HorliX や OpenOcean のアイコンなどを利用して、Tシャツなどのグッズをつくってみました。

https://suzuri.jp/PHAZOR

からどうぞ。

なお、HorliX のアイコンは「二つあるのか?」と聞かれることがあるんですが、その通り二つあります。

 

で使われているのが、初期の頃使っていたもので、タイの若いデザイナーさんの手によるものです。

 

の方は、MacAppStore からリリースするにあたり、「シリアスな雰囲気の方がいいのでは?」という声が上がり、大急ぎで元アイコンの背景を流用して作り直したものです。

HorliX.app を走らせると環境によってはドックに元の可愛い感じのアイコンが出現することがあります。これはサプライズでもなんでもなくて、Xcode のバグです。

 

猪股弘明(HorliX 開発者)

 

電子カルテ記載内容をテキスト処理したい

電子カルテのテキストマイニングに関連して。

MENTAT というのがあるらしい。
https://www.mentat.jp/jp/service/

精神科カルテからテキストデータ抜いてきて IBM ワトソンで解析、治療の難しさなどを評価・予測しカンファレンスなどで使われるらしい。

だからどうしたと言われそうだが、未来感みたいなのはある。

問題は予測精度だと思うので、関係者に問合せ中。

 

なお、私自身も OpenDolphin-2.7m というオープンソースの電子カルテの開発者なのだが(経緯は『OpenDolphin について』で)、医療関係者からそこそこ評価されているのはカルテ記載内容をプレーンテキスト(UTF-8)に書き出すファイルバックアップシステムを実装した点だ。
もともとはクライアント-サーバ間で通信障害が発生したときの臨時記録手段としてこの機能を付け加えたのだが、カルテ記載データの2次利用にも使えるのでは?という声も上がっている。
これに関しては検討中。

 

猪股弘明(精神科医)

 

その後、自然言語処理などにも実際に手を出す。
→『OpenOcean』や『 juman++ で分かち書き』など。

雰囲気つかめますかね?

 

にほんブログ村 病気ブログ 医者・医師へ

 

OpenDolphin について

OpenDolphin を Window 7 上にインストールしてみた。

dolphin_win7.JPG

まだ設定など検討の余地はありますが、なんとか ORCA との通信はできているようです。

ちなみに ORCA は Ubuntu 上の 4.7 です。ちょっと Dolphin 側のコードに手を入れてます。

(追記)この記事書いた当時(2013 年頃ですか、けっこう昔ですね)と OpenDolphin を取り巻く状況が変わってきたため、修正。

「上記スクリーンショットは、増田内科 増田茂氏の OpenDolphin-2.3.8m を手順書に従ってインストールしたものです。」

と以前に書いてました。
これは事実なんですが(ただし、和歌山の増田内科は既に閉院しているようです。今は高槻病院所属?でしょうか)、同氏(確か循環器内科の医師)から”私の著作物をあたかも自分で作り上げたかのように振る舞う不届き者”という(今から思うと)意味不明なクレームをつけられて、そうしただけです。一応、相談にのっていただいた某組織からも「先生、よく我慢して大人の対応しましたね」と変な褒め方されました。
ただし、この件に関してはさすがに厚労省・保健所ともに許さなかったようで、当局主体で迅速に処理していただきました。

もちろん、独自カスタマイズしているわけだから、「私の著作物」という言い方は完全には間違いではないんでしょうが、細かいことをいうと、私もさらにカスタマイズ入れ始めた頃であり、上記スクリーンショットが完全に OpenDolphin-2.3.8m と同一かというと違います。いわゆる増田ファクトは、電子カルテの要件である『保存性』を担保する機能や『真正性』を担保するカルテ記載内容の抽出ツールが提供されておらず、これは危ないと思い、独自にファイルバックアップシステムの実装・データ移行ツールの作成をしていたところでした。

データ移行ツール

「手を入れて」とあるのは、このことを指しています。

その後、データ移行がうまくいき始めたため、ソフトのベースもいわゆる本家に戻してます。「カスタマイズのカスタマイズ」より「オリジナルのカスタマイズ」の方がなにかと安心ですから。

おそらくこういった「導入は増田ファクトで(当時としては、確かによくできた導入環境でした。ただし、導入手順書にしてももっぱら windows 前提で、Mac OSX へのインストールなどはまったく触れられていませんでした)。ある程度、様子がわかってきたら、さらにカスタマイズ。その後は、独自路線を突き進むなり本家に戻るなりして開発を継続」といったパターンは多かったと思います。オープンソースの本来の意義からすれば、割合、自然なことだと思うのですが。

それはともかく opendolphin 自体を「私の著作物」といってしまったり、本来、商標に成りえない「m」という表記に対して排他的独占権を主張したり、誰が書いても同じような言い回しになる定型文に著作権を主張したりするのは、ちょっとどうかと思います。


最近になると、かなり高名な先生もドルフィンプロジェクトの運営自体に関して疑念を表明しており、彼らの主張を額面通り受け取れない状況になってきている。

(参考)『いるかの住む闇』や『「いるか」の都市伝説は本当だったか?』『開いたイルカ再び』などをご参照ください。

特に後者の「そもそも GPL を適用すること自体が、けっこう無理筋なプロジェクト」だったのではないかという指摘は、日を追うごとに説得力が増していっているように思える。
GitHub リポジトリでのプルリク・コードレビューがほぼない、なんて話を聞くとこれは一体なんだったんだろうという気持ちになる。

例えば、公的な立場でドルフィンプロジェクトを支援した当局もこの観点からプロジェクト自体の検証を開始している(ただし、かなり前のプロジェクトであるから、いわゆる不正告発制度の本調査に入るかどうかは微妙。だが、まったく放置しておくにはいかないという状況になってしまったということだと思う)。

また FSF(Free Software Foundatioon)も下記の事情があることから、「判断が難しい」としながらも「純然たるGPLとは言えない」と一定の評価をくだした。
今では広く認識されていることだが、「本家」と称される LSC 版には、かなり以前のバージョンからオラクルのサンプルコードがそのまま流用されているし、2.3m 時代の増田ファクトには dcm4che (という PACS サーバ)のコードが含まれていた。

他者の作成したコードを再利用すること自体は、オープンソースの特性ゆえ問題ないのだが、問題となるのは、以前のLSCがこれらの事実を伏せて特定のソースコード提供者のみを優遇していたことや、増田さんに至ってはよくわからない理由(私がライセンス違反なんだそうだ)でソースコードの一般公開をやめてしまっていることだ。
彼らの解釈(ソースコードを提供したものはすべてクレジットされなければならない云々みたいなやつ)からしたら、GPL 違反をしているのは増田さんなんだけどね。

なお、当方は、こういう面倒な問題を「いちいち気にする」のが嫌なので、ソースコード自体を一般公開するという方針を取っている。

 

そういう経緯もあってか、以前の商用版の開発元であった LSC (ただし、現在は運営権などもメドレーに移管)も「商用版とオープンソース版は基本的には別物と考えてほしい。他組織での独自カスタマイズはむしろ奨励している」というふうに方針を変えた(これは確認を取った、というか LSC の方がわざわざ会いにきてくれた。そして以前の運営方針で(私のみならず)関与した方にかなりの迷惑をかけたことを謝罪してくれた。メドレーの担当者の方も全くこの件に関しては関与していないにも関わらずご丁寧にも迷惑をかけたことを遺憾に思う旨のご連絡をいただいた)。

 

このプロジェクトのオープンソースの妥当性は、今となってはもうかなり疑わしいのだが、このプロジェクトをオープンソースの理想の実現とみたい人たち、例えば、和歌山の増田茂氏や京都大の小林慎治氏(現在は国立保健医療科学院)や皆川和史氏などはそうは考えていないようだ。理想論はもちろんあってもいいが、どういうわけかこの手の人たちは、いまだに事実を捻じ曲げて解釈している。

その一つに、私の OpenDolphin-2.7m が  LSC 版の直接のフォークではなく、増田内科版のフォークだと主張していた。経緯から思い込みで言ったのだと思うが、いくらなんでもこれはひどい。

ちゃんとソースを追っていけばわかるように、上述のように 2.7m は、LSC 版の直接フォーク、どちらかといえばファイルバックアップ機能とバグフィックスに重きを置いたフォークになっている。
OpenDolphin には直接タッチしていない小林さんが勘違いするのはわからないでもないが(→ただ、現所属機関の医療保健学院は私ほど甘くはなく、事実誤認に基づくネット上での表現などは国家公務員法違反疑いにあたるとして厳重注意処分)、基本設計をしたとされる皆川さんが間違うのはまったく理解できない。また、皆川さんはどこかで「MIT ライセンスにしておけばよかった」とのたまわったそうだが、これは無理な話だ。いくつかのサンプルコードは GPL でライセンスされているので、それを勝手に MIT ライセンスに変えることはできないからだ。
また、この時期には増田茂医師は既に自身の OpenDolphin はソースコードを「一般」公開しておらず(なお、この行為は上記の理由もあって GPL 違反の可能性が指摘されている)、フォークなぞできるはずもないのだ。なんで、論理的に間違ったことを主張するのかわからない(ついでで言っておくと dolphin とは直接関係はないのだが、増田茂は医療広告規制ガイドラインで厚労省から行政指導を、和歌山保健所から患者保護の観点から厳重注意を受けている)。

 

なお、国費を投じられ、一時期とはいえそれなりに普及したプロジェクトであることから、現在の状況は理想的とはとても思えず、関係者で今後の方針などを模索しているところです。特に、商用プロダクツとして提供しているベンダーは、関心は高いようで、軽い打ち合わせ程度の内容だが、いくつかのベンダーさんから連絡をいただいてます。

 

(追記2)メドレーに開発元が移って状況はさらに変わりました。
メドレー自体が「OpenDolphin は GPL に従う必要はない」とかなりはっきり言うようになった。
増田さんの取り扱いに至っては(はっきりと言ったわけではないですが)「契約上、著作権者として取り扱っていただけ」のようです。

それまでにも

医学部しか出ておらず(=プログラミングの系統だったトレーニングを受けていない)、かつ、それまで学術的な業績がほぼゼロ(=研究・開発の経験なし)の医師が突然 Java でプロ級のコードを書くのは不可能に近い

というようなことを言う人は多かったですね。

どういう契約だったのか知る由もないですが、実態としては当人が言うほどには関与はしていなかったんでしょうね。
確かに GitHub 上でもコードを提供した痕跡はほとんど残されていませんね。

 

猪股弘明(医師:精神科医:精神保健指定医)
OpenDolphin-2.7m, HorliX 開発者


なお、本家 OpenDolphin 2.7.0.b とその私の改良版 OpenDolphin-2.7m の windows10 へのインストール方法は、こちらで。

Mac OSX など Unix 系 OS への導入は、

OpenDolphin-2.7(m)を Mac OSX へインストールする

などを参考にしてください。

上で触れた機能(ファイルバックアップ機能)は OpenDolphin-2.7m を経て OpenOcean に引き継がれています。OpenOcean のインストール(ビルド・デプロイ)方法は

OpenOcean を Windows 10 にインストールする

をご参照ください。


→ OpenOcean は、

・上述のような背景があること

・以前から「全面書き直し」してほしいという要望があったこと

などから、現在は公開を停止。基本的な設計コンセプトを検討しているところです(余談ですが、これには近年のスクリプト系言語のウェブフレームワークの成長も背後にあります。「Java と JavaScript の立場が逆転した」みたいな表現がなされています。とある会社は PHP で書き直したいそうです)。

例えば、ファイルバックアップシステムの延長線上にあると思うのですが、カルテデータの2次利用を強く意識した構成にしてはどうか?というような要望が出ています。
いきなり高度な診断支援は無理だと思いますが、カルテ記載内容の統計処理・テキストマイニングなどは興味深い試みだと思います。

 

🌟 参考
OpenDolphin と電子カルテの3要件とメドレー
オープンソースと知財権に関するちょっと小難しい話
OpenDolphin -wiki 風解説-
横から見た OpenDolphin-2.7m