オープンソースに関わられている方には一読をおすすめします

関係者の怒り方が半端なかったため、やむなく投下。

小山哲夫(当時アーク情報システム所属)の誹謗中傷 tweet について

まあ、ちゃんとソースコードにあたって検証していれば、間違えないところですからね。

にもかかわらず、あたかも自分がオープンソースの代表者のように振る舞うのはどうなんだろう?

オープンソースに関わられている方には一読をおすすめします。

 

Protected Mode への入り方【HorliX/Horos/OsiriX?】

HorliX のユーザーさんで Protected Mode に入れないという方がいたので、動画で解説してみました。

Horos も同じ手順で入れると思います。

現行 OsiriX は、持ってないのでわかりませんが、以前のバージョンなら、これで入れると思います。

ビューアがダイコムファイルを読み込む時、タグ情報などをデータベースに保存、画像は適当なフォルダに入れておくと思います。
が、おかしなダイコム(異常ダイコム)の場合、タグ情報や画像をうまく展開できず、ファイル(スタディ)としては登録されているのに、画像表示できない時があります(ひどい時は、以降、起動不能)。
そこで、画像を表示させない状態でアプリ自体を立ち上げるモードが Protected Mode というものです。
このモードで立ち上げて、異常ダイコムを取り除く、という操作をすると、次回以降は、データベースは元の状態に戻り、起動可能となる場合もあります。

ただし、’INCOMING.noindex’ フォルダの方におかしなファイルが引っかかっている場合は、そもそも Protected Mode 自体に入れないので、これが絶対ということはありません。

 

猪股弘明
HorliX メイン開発者

 

接触確認アプリ cocoa とオープンソース

某所でコメントしたことの転載。


cocoa はバグが枯れてきた印象はあるんですが、今後も継続的に適切な保守開発が行われるかというと若干疑問もあります。
契約の詳細まではわかりませんが、実際に保守開発を行っているであろうデザイアードには405万の費用しか渡っていないからです。
https://www.tokyo-np.co.jp/article/87051/

エンジニアを一人 40 万/月でアサインして 10 ヶ月保守したら、予算尽きてしまいます。
今後どういう運営をするつもりなのかの説明がまったくないのでこのままでは信用できません。

そして、このプロジェクトが興味深い点は、元はオープンソースで、献身的なエンジニアがバグなどをボランティア的に見つけ、その改善策を提案しているところです。
今回の修正もおそらくそれらを参考になされたものだと思いますが、その点をいっさい伏せて、さも「自分たちで修正しました」というのは、ちょっとどうかと個人的には思います。

そして、これが一番ダメなんじゃないかと思うのは、プルリクエスト(コードの修正依頼)に対して、厚労省側のレビューが全くない点です。
これされると(=オープンソース性の喪失)今後バグが出てもその責任箇所を指摘できないし、どう修正していいかといった提案も当然できません。
これやって失敗したプロジェクトはけっこうあります。

最後に、ボランティアで参加したエンジニアの方の意見を一つあげておきます。

Issueとは直接関係ないのでコメントとして記載します。

現在のCOCOAの状況を大変、憂慮しています。

このIssueを見ている関係者の方は居られないのかもしれません。しかし、もし居られるならば、今一度、オープンソースのやり方でCOCOAを継続的に改善する方向へ舵を切ることを何卒ご検討ください。

もしそうなったならば、ぼくはAndroidアプリ開発に携わるソフトウェア開発者の一人として、お力になれるものと確信しています。

https://github.com/cocoa-mhlw/cocoa/issues/21?#issuecomment-780502093

 

猪股弘明
医師:精神科

 

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

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

開発者目線では…

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

筆者の 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 お墨付きのライセンスが適用されていましたが、現在ではそうなってはいません。
この話は説明しだすと長いのでここでは詳しくは触れませんが(『OpenDolphin -wikipedia 風解説-』あたりをご参照ください)、このプロジェクトの経過を追うと日本においてオープンソースのソフトが成立しにくいと言われる理由がよくわかると思います。

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

例を一つ。

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 に関しては私たちのグループはそれなりに評価されているようだ。
これまでにもファイルバックアップシステムやデータ移行ツールは、それなりに評価されていたと思うが、正直、それほど派手な機能ではなく、熱心なユーザーさんや独自カスタマイズを入れている医療機関(のSEさん)に支持されていた程度だと思う。

最近の OpenDolphin HTML/PDF ViewerWebDolphORCA は、まだプロトタイプ程度の完成度なのだが、それよりも評判がいい。

これに関して某氏が「この関係者のみでソースコードを共有する仕組みは、一般のオープンソース開発方式よりうまくいっているようで」(『OpenDolphin と商業GPL』)と面白いことを言っていた。

確かに、医療用ソフトでは上で述べたようにオープンソースプロジェクトが成立する条件(汎用的なプロダクツで透明性への要求が高い云々)は満たしにくい。
ただ、解決しなければいけない課題は、(OSのカーネルを構築するのに比べれば)遥かに限定的・具体的なため、その分野に明るいエンジニアが数名集まれば解決までの道程はかなり短縮できる。

この開発方式はなんていうんでしょうね?

たぶん、専門的な正式名称はありそうだが、個人的には「コンソーシアム開発方式」とでも呼びたい。(私が以前に在籍していた ERATO のプロジェクトはこれに近い方法論を取っていたし、拠点にしていたのは「つくば研究コンソーシアム(現つくばイノベーションベース)」というところであったから)

 

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