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

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

開発者目線では…

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

筆者の 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 開発者)

 

医療画像の 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)があることゆえ私一人では決められない問題もあったりするのですが、目処がたったらプラグインの形でまとめたいと思っています。

 

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

 

STAY HUNGRY, STAY FOOLISH

私は横浜に住んでいるが、東京近郊の中では横浜は個性的な会社・ショップ・飲食店が多いように思う。

本日、冬に備え、

下 に 何 を 着 て い て も コ ン ビ ニ に い け る

ようにパーカーを購入した。

 

エジプト神話のセト神の下に Jobs のスピーチで一躍有名になった

STAY HUNGRY, STAY FOOLISH

の言葉が。

この意味がわかる人だけ買ってくれればいいという凄まじく割り切りのいいデザインだ。

なお、セト神は兄オシリスを殺害したため、『兄殺し』と呼ばれ、オシリスの子ホルスとはライバルの関係にある。

Osiris を殺害し、Horus のライバル…

本当に私にぴったりなのかもしれない(謎)。

よくわからない人はここここへ。

 

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

世界デビュー

医師ならば、DICOM 画像ビューアの OsiriX には一回くらいは触れたことがあると思うが、近年、高額化が進んでおり、私の周囲では OsiriX 5.8 からフォークした Horos ユーザが増えている(こちらは無料)。

Horos は通常の使用、つまり 2Dビューアで画像を閲覧するとか、簡単な 3D 画像を構築するとかといった用途であれば、ほぼ問題なく使える。ただし、動作が不安定であったり、日本語が使えなかったりして、特に日本での普及の妨げになっていた。

私が放浪している間、手持ち無沙汰であった(と思われる)私の仲間がこれらの問題を解決しにいってくれた。具体的には、日本語リソースを追加したり、読めない画像を読めるようにしたり、といったことだ。

私もこの5月くらいからこの動きに合流。手始めに ROI 周りのUI の改変をまとめた

この改良を Horos 本体の方々が気に入ってくれたらしく、この度、私たちのコードが Horos 本体に取り込まれる運びとなった。

インストール後すぐに使えるインストーラー版では、この取り込みはまだ反映されていないのだが、先日更新されたソースコード上では既に結果は反映されている。こんな感じ。

ありがたいことに私の名前も PHAZOR, LLC (=フェイザー合同会社の英文表記)とともにクレジットされている。

OsiriX のユーザー数40万人には負けるとはいえ、世界170ヶ国、12万人が使っているソフトに貢献者として名前が載るというのは、光栄というか嬉しいというか、とにかく良い気分だ。

英文査読誌のファーストオーサーになった場合にも似たような感覚が沸き起こると思うが、こちらはやはり専門家向けだし、医療者の日常業務に直接役に立つということはそう多くないので、その分だけ喜びも抑制される感じはある。内なる充実感という意味ではこちらの方が上かもしれないが。

今回の改変では、ROI 操作時の UI に手を加えたので、ユーザーが直接使う機会もそれなりにあるはずだ。だから「気に入ってもらえるだろうか」とか「さらなる改良を求められるかな」などと想像が膨らみ、その分、わくわく感がある。もちろん、気に入ってもらえない可能性もある。だが、そういったネガティブな反応でも直接的であるが故にある意味嬉しい。

Horos にしても、そこからさらに派生させた HorliX にしても、「メーカーの押し着せではなく、自分たちが必要なものは自分たちでつくるんだ」という強い意思が込められているし、それが旺盛な開発ペースの源になっている。

こういうアプローチに興味を持たれた方には、ぜひとも使って欲しいと思う。

 

猪股弘明


なお、「OsiriX と Horos と HorliX の関係がわかりにくい」という声をたまに聞く。ANN2b さんが、

HOROS -WIKIPEDIA 風解説-

HORLIX -WIKIPEDIA 風解説-

に簡潔にまとめてくれているので、そちらをご参照のほどを。

 

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