カテゴリー: プログラミング

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

開発者目線では…

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

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

Fork の効用・意味

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

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

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

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

猪股弘明