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

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

開発者目線では…

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

筆者の 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 して独自プロジェクトをおこせばいいだけだ。

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

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

 

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

 

猪股弘明

ORCA のメーリス

そういえば、昔、ORCAのML(メーリングリスト)にいくつか投稿したことがあったわ。

Re: ORCA と OsiriX の接続について

Re: ORCA と OsiriX の接続について その2

Re: ORCA と OsiriX の接続について その3

Re: ORCA と OsiriX の接続について その4

この時点では、その後、DICOM を本格的に触るようになるとは思ってもいなかった。

内容的に情報が古くなっている点もあるが、


一般のDICOMファイルの情報をすべて読み出し・管理するのは難しいが、特定のDICOMだけを操作するのは、それほど面倒ではないはずだ

というのは、今読み返しても「なるほどな」とは思う。

 

 

猪股弘明(精神科, HorliX 開発者)

 

グッズw

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

https://suzuri.jp/PHAZOR

からどうぞ。

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

 

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

 

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

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

 

猪股弘明(HorliX 開発者)

 

HorliX のリアルな使われ方ってこんな感じでしょう

「知り合いの知り合い」みたいな先生なのですが、現役精神科医の高木希奈先生にブログで画像ビューア HorliX を取り上げてもらいました。

COVID-19 による肺炎CT画像!<HorliX にて表示>
(高木希奈オフィシャルブログ)

精神科的には

「精神科って、画像検査必要なの??」

という疑問を抱かれる方も多いかもしれません。

精神科と言えども、もちろん画像は取り扱います。

まず、精神疾患の診断をつけるためには、器質性疾患(身体的な疾患)の除外が必要なので、受診されたらまずは、血液検査、心電図、頭部CTやMRI,心電図、脳波などの身体的な検査を行います。

さらに

認知症疑いの患者さんの脳CTやMRI画像のチェックは必須ですし、大学では 統合失調症の患者さんの画像解析などは、一つの研究テーマにもなっています。

というのは常識なんですが、世間一般にはあまり伝わってないかなと思います。

それはともかくご紹介ありがとうございまーす。

 

猪股弘明(精神科医:精神保健指定医)

 

医療画像の fusion とは?

今回は医療画像の fusion (一種の画像合成)のお話。
諸々の事情で MR(Magnetic Resonance 磁気共鳴)系の fusion を取り扱っていた。

なお、MRI って何?って方は、『MRI とは? -その1-』・『MRI とは? -その2-』・『MRI とは? -その3-』あたりをご覧ください。特に『その2』のスピンの説明はけっこう好評のようです。

 

しかし、MRI のプロトン密度強調画像程度でことが済んでいればいいんですが、この分野の技術進歩は速い。「拡散」強調(という撮像法。水分子の「拡散」というより「移動」といった方が正確なような気もしますが、ここでは慣例に従います)などは、以前より脳梗塞急性期の診断などに使われている。

大脳右半球に広範な梗塞像(白いところ)が見られる

上の画像は、脳梗塞の拡散強調像(DWI… Diffusion Weighted Image)です。拡散「強調」とは言うものの、実際に撮像するときは、移動しているプロトンからの信号を抑えるような工夫をするので、水分子が動きにくくなっている部位は、高信号になります。梗塞部位に含まれる水分子は、正常組織に比べ「動きにくく」なっているため、結果として梗塞部位は高輝度(白い)領域となって描出されます。

拡散強調画像は、基本 T2 強調画像をベースにしているので、本当に知りたい水分子の挙動(大抵の病変部で水分子は「見かけ」上、拡散しにくくなる。梗塞しかり、癌しかり)を取り出したい。このとき元の拡散強調画像より T2 などの影響を排除するため ADC(Appearant Diffusion Coefficient 「見かけ」の拡散定数) Map というのをつくる。
症例によっては DWI では異常を認めず、ADC Map で低信号(ときには高信号)となって描出されることがあるからだ。
水分子の拡散の度合いを知る上ではこの ADC Map は大変便利なのだが、その反面、組織のコントラストが普段見慣れているそれと違って形態などが読み取りにくい。ストレートに言えば「どこを見ているかわかりにくい」のだ。

この欠点を補うため、解剖学的な形態が読み取りやすい T1 強調画像に ADC Map を適宜「着色」した画像を重ね合わせると、医療者にとって「どこで何がおこっているか」直感的に理解しやすい画像が得られる。

一般に特定の情報を持った画像とそれとは別の情報を反映した画像を「位置を合わせて」合成して表示させることを fusion と言います。PET と CT の fusion はよく知られた例です。(参考:『PET/CT フージョン画像』)

右側頭葉(画像では左)に何かありますね

今回は、T1 強調に ADC Color Map ともいうべき画像を fusion させたわけです。もちろん、HorliX 使いまくり。規格(DICOM)があることゆえ私一人では決められない問題もあったりするのですが、目処がたったらプラグインの形でまとめたいと思っています。

 

猪股弘明(精神科医、理学士)