  |
はてなキーワード: Open Source Softwareとは
弊社で受託しているソフトウェア開発プロジェクトが終了間近となり、納品物をまとめる作業をしている。
納品物の一つにはFOSS (Free and Open Source Software)、俗に言うOSS、の説明書がある。
増田はこれまでで受託開発企業を3社ほど転々としてきたが、これをきちんと納品している会社は過去には見たことは無かった。道義的責任として、「このソフトウェアはこんなOSSを使ってます」という説明は顧客に対して為されるべきだとずっと思ってた。もちろん、納品時ではなくてプロジェクトの初期で実施するのが良いと思うけども。
経済産業省が公開している「情報システム・モデル取引・契約書（第二版）」という、受託開発の契約書の雛形が存在する。この雛形の中では次のような条項が提案されている。
https://www.ipa.go.jp/digital/model/model20201222.html
（FOSSの利用）
第49条 乙は、本件業務遂行の過程において、本件ソフトウェアを構成する一部としてFOSSを利用しようとするときは、当該FOSSの利用許諾条項、機能、開発管理コミュニティの名称・特徴などFOSSの性格に関する情報、当該FOSSの機能上の制限事項、品質レベル等に関して適切な情報を、書面により提供し、甲にFOSSの利用を提案するものとする。
2. 甲は、前項所定の乙の提案を自らの責任で検討・評価し、FOSSの採否を決定する。
3. 乙は、FOSSに関して、著作権その他の権利の侵害がないこと及び契約不適合のないことを保証するものではなく、乙は、第1項所定のFOSS利用の提案時に権利侵害又は契約不適合の存在を知りながら、若しくは重大な過失により知らずに告げなかった場合を除き、何らの責任を負わないものとする。
開発者は「こんなFOSSを使ってます、それはこんな機能があって、こんだけ人気があって信頼がおけるものです」みたいな説明をする義務を負う代わりに、万が一そのFOSSがバグったりしても責任が限定される、という話だ。
もしも受託開発の契約書にこのような条項があったとしたら、きちんと利用しているFOSSの説明をしよう。しなかったとしたら、後で不利益があるかもしれないし、それ以前にその仕事は技術的に真摯なものではないと言える。
ここ最近の COVID19Radar https://github.com/Covid-19Radar/Covid19Radar 上でのゴタゴタにより、開発者の @kazumihirose さんが https://twitter.com/kazumihirose/status/1274616019420471296 疲弊してしまいっているのを見て、(今回の揉め事の根本的な原因はソフトウェアがOSSとして公開されているのが原因ではないと思うが)いたたたまれない気持ちになったので書く。書いてみた結果ただのとりとめもないOSSへの愚痴になってしまった。
いくつかのOSSプロジェクトのメインコントリビュータとして関わっています。
私の周囲のソフトウェアエンジニアがOSSに対して以下のような意見を述べているのをよく聞く。
確かに、OSSは特定の企業に所属していないので特定企業の方針で運営が捻じ曲げられる心配がなく民主的で、細かい実装が気になったらソースコードを読むことが出来、顔も合わせたこともない優秀なエンジニアと議論を交わし共通のゴールに向かってともに開発を進められる。OSSは楽しい。
しかし一方、OSSメンテナのバーンアウトが近年問題になってきている(なんとなくここ数年で目につく数がなんとなく増えてきている)気がする。
というのも、OSSを運用していく上では楽しく優秀なエンジニアと開発をすすめるだけではなく、ドキュメントを読めば分かるようなことを質問してくる人、PR に対して changes required を下すと怒ってくる人、Twitter でこのライブラリは使いにくくて最悪だと罵ってくる人、こういった普通の会社ならカスタマーサポートさんがワンクッション挟んでくれる人たちに対しても開発者が直接対応しなければならない。
元々楽しくて始めた/関わり始めたはずのサイドプロジェクトだったのに、いつの間にか日々やってくる頓珍漢で再現環境のないバグレポートや、Issueも立てずに突然提出される意味不明なPRに対して、義務感で、就業後や土日の時間を削って、根気よくコメントを続けていると、何で貴重な自由時間をこんな訳のわからない連中のために使っているんだ?という気持ちになってくる。
実際、私の関わっていた一つのプロジェクトでは、もともと6人ほどいたアクティブなコントリビュータが徐々にプロジェクトを離れていき、(私を含めて)2人はメンテナンスに疲れてしまったのでしばらく距離を置くと宣言し休みを取っている(あまりに精神が回復したので戻れるのかは不明...)。
こういう現場を見ていると、手放しにオープンソース万歳！透明性最高！と言いながら自分自身は大してOSSに貢献してない人たちに対して苦い気持ちを覚える。
一方、私の関わっているもう片方のプロジェクトは非常に円滑に運用が回っていた。もうひとつのプロジェクトと何が違ったかというと、そちらのプロジェクトはいくつかの企業がソフトウェアエンジニアの業務時間の半分/全部をそのプロジェクトのメンテナンスに費やしていたのである。(何人かのメインコントリビュータが企業から出向する(?)する形で運用している)。
issueへの一次対応などの日々のつまらないタスクは業務でメンテナンスしてくれているエンジニアがやってくれるおかげで、他のメンテナが対応する必要のあるissueやPRは減り、みんなが開発やバグ対応に集中できている。業務でOSSに取り組んでいるエンジニアにストレスはないのかと聞いたところ、多少大変ではあるけれどお金をもらいながら自分の仕事をオープンにできるし、仕事だと思えば多少のストレスは我慢できる。とのことだった。
このプロジェクトに限らず、なんとなく長期間運用がうまくいっている大規模なOSSプロジェクトはだいたいどこかの企業が支援しているような印象を受ける(Facebook とか MS とか Google とか(大企業ばっかだな...))。もちろん全てのソフトウェア企業に大してOSSに大して大金をつぎ込めというのは現実的ではないが、open collective や github sponcers なんかに企業として少しずつでも寄付してくれたら、OSSコミュニティはもう少し良くなるんじゃなかろうか。
結局何が言いたかったかというと、エンドユーザー(OSS利用者)がめちゃくちゃ増えてきた昨今、個人レベルでそれなりの規模のプロジェクトをメンテナンスしていくのは最早厳しくなってきており、結局企業によるバックアップなんかがないと持続的な開発は難しいんじゃないかと思っている。
今日になって思ったより多くの方に読んでいただいて驚いています。あまりオープンインターネットで話しにくい話題だけど皆がどう思っているのか気になっていたので嬉しい。増田がブクマされても通知は来ないんですね(そりゃそうか)。
@bouzuya
まず焦点を当てている持続可能性が見出しから思い浮かべるものより狭いんだと思う。「最悪フォークすれば持続可能」みたいなのがぼくだと最初に思い浮かぶ
確かに、OSSの持続可能性という少し主語の大きいタイトルにしてしまったが、この文章はソフトウェアの持続性というよりかはOSSに携わる人のバーンアウトに対する憂いをつらつらと綴っているもので、ソフトウェアの持続性という意味では他にも色々やりようがある気はする。
また、私が目にしたうまく回っているのが企業による支援を受けたプロジェクトだったので、バーンアウト対策として企業による支援について述べたが、企業による支援がなくともうまく回っているプロジェクトは世の中にはいろいろあるだろうし、今後OSSは企業による支援がないとやってけないと決めつけるのは早合点ではあった。反省。(とはいえ問題意識は変わらないし、その一つの解決策が企業による支援だと思っているのも変わりない)。
---
自分の記事を読み直してみて、一番問題に感じているのはユーザーサポートの工数なんだなと分かったが、@mathane さんがその問題への一つの解答をつぶやいていた。
@methane
雑な質問やバグレポート（99％レポート者のミス）をする場所は、とにかくメンテナ以外の人が回答しやすい場所でしてもらう事が重要だと思う。
これは確かに。私はまだOSSコミュニティど初心者なので、こういうOSSをメンテナンスする上で重要なことをどんどん知りたい。
