OSSへのフィードバックをしてみたいけど、何をフィードバックしたらいいのか分からない

結城です。

これまで、「OSSを使用していてトラブルに遭遇しているか、改善の提案があり、その情報を開発元のイシュートラッカーに伝えようとしている」という人向けの情報として、「どういう場所に報告するのが適切か」「どんな内容を書くのが適切か」という話をしてきました。

しかしOSS Gateワークショップにビギナーとして参加された方の中には、そういった「どうやるか」の前の段階の話として、「フィードバックしたい情報」をまだ持っていないという人もいます。というか、「別に今の段階で何か具体的にOSSの使用上で困っているわけではないが、とにかくOSS開発に関わりたい、OSS開発に関われる人になりたい」という人の方がまだ数としては多く、OSS Gateワークショップはまさにそのような人を想定した内容になっています。

なので、OSS Gateワークショップでは「フィードバックするネタ¹の見つけ方」からやるようにしています。この記事ではワークショップで実際に伝えているやり方も含めて、「フィードバックするネタ」の見つけ方を紹介します。

どのOSSにフィードバックするか

ネタを探すには、当然ですが、ネタを探す先のOSSが必要です。

ワークショップに来られた方に「このOSSにフィードバックしたいなあ、というプロジェクトは何かありますか？」と聞くと、「Linuxカーネル」や「Docker」といった有名なプロジェクトの名前を挙げられる事が結構あります。

ワークショップでは「なるべく普段から使っているOSSを題材にしましょう」と案内しているので、その意味ではこれらの名前を挙げても間違いではないのですが、単に「OSS」と言われてそれらの有名なプロジェクトくらいしか思い浮かばなかったと見受けられるケースでは、筆者はなるべく、もっと身近な・小規模のプロジェクトをお薦めするようにしています。というのも、有名だったり大規模だったり歴史が長かったりするOSSは、「別に今の段階で何か具体的に使用上で困っているわけではない」という人がフィードバック先にするには色々とハードルが高い事が多いから²です。

「普段使っているOSS」を意識してみよう

「身近なOSS」なんて思いつかない、という人でも、普段の仕事で使うアプリケーションやコマンドを作業の順番に従って思い浮かべてみると恐らくOSSがいくつも見つかるはずです。例えば以下の要領です。

インターネット上の情報を調べるためにChromeを起動した。
- ChromeのベースとなっているChromiumはOSSです。
- Chrome/Chromiumが依存しているcrc32c、dom-distiller-js、enum34などの多数のライブラリ（ chrome://credits/ で確認できます）もOSSです。
- Chrome/Chromiumで使える拡張機能にもOSSが多くあります。
作業を始めるために、ターミナルを起動して、Bashの上でgit cloneを実行した。
- GitはOSSです。
- BashもOSSです。
Ruby on Railsで構築されたサービスのユニットテストを走らせるために、bundle instalLしてrake testした。
- Ruby on RailsはOSSです。
- RubyもOSSです。
- RailsやRailsアプリケーションのGemfileに従ってbundle installでインストールされた多くのGemもOSSです。
- bundleコマンドを提供するBundlerもOSSです。
- rakeコマンドを提供するRakeもOSSです。
ソースコードを編集するためにVisual Studio Codeを起動した。
- VSCodeはOSSです。
- VSCodeのベースになっているElectronもOSSです。
- ElectronのベースになっているChromiumもOSSです。
- VSCodeで使えるプラグインにもOSSが多くあります。
Vue.jsで構築されたフロントエンドにファイルを追加し、ESLintでエラーがない事を確かめて、Babelでトランスパイルした。
- Vue.jsはOSSです。
- ESLintもOSSです。
- BabelもOSSです。
- ESLintやBabelのpackage.jsonに従ってインストールされた多くのNPMモジュールもOSSです。
編集したソースコードをコミットする時、コミットメッセージの編集にVimを使った。
- VimもOSSです。
- VimのプラグインにもOSSが多くあります。

こうして見てみると、開発に使用しているフレームワーク自体やツールがOSSであったり、また、有名なOSSも名前を聞いた事のないような無数のOSSを利用して作られていたり、という状況である事が分かります。現代のソフトウェア開発の現場では、OSSを全く使わずにいるということはあまりないでしょう。

「OSS」の見つけ方

ところで、いきなりたくさんOSSの例を挙げましたが、そもそも「どうだったらOSSなのか？」を説明していませんでした。

OSS（Open Source Software）とは、OSIがOSSライセンスと認めているライセンス一覧に載っているいずれかのライセンスの元で頒布されているソフトウェアのことです³。例えばVSCodeでは、「Help」→「View License」で開かれるページの冒頭に「Source Code for Visual Studio Code is available at https://github.com/Microsoft/vscode under the MIT license agreement at https://github.com/Microsoft/vscode/blob/master/LICENSE.txt.（VSCodeのソースコードはMITライセンスの元で入手可能です）」と書かれています。MITライセンスは上記の一覧にあるOSSライセンスなので、VSCodeはOSSであると言える訳です。

他にも、ソフトウェアのライセンスを調べる方法はいくつかあります⁴。

GUIアプリであれば「（ソフトウェア名）について」「ライセンス」のようなメニューからこのような情報を確認できる事があります。
配布ページやプロジェクトのトップページにライセンスが書かれている事もあります。
公開されているソースコードのリポジトリ上にCOPYING（著作権情報）やLICENSE（ライセンス情報）といった名前のファイルがあり、そこに詳細が書かれている場合もあります。
READMEに端的に「このソフトウェアは何々ライセンスです」と書かれている事もあります。

「OSSに何かフィードバックしてみたいが、具体的にはビッグネーム以外すぐに思いつけない」という場合には、まずはこのようにして、自分が直接的・間接的に使用しているOSSを掘り下げてみて下さい。LinuxカーネルやDockerよりは、ずっと身近な所にOSSを見つけられるはずです。

些細な「つまずき」に敏感になろう

題材にするOSSを決めたら、次はそのOSSを普通に使います。そうして 普通に使っている途中で遭遇した些細な「つまずき」 が、フィードバックする内容となります。

しかし、そう言われても、何が「つまずき」なのかピンと来ないという人も多いでしょう。「普段から自分もOSSを使っていた事は分かったけど、べつにつまずいた事なんて無いんだけどな……」そう思うなら、それはあなたの運がよかったか、あなたより前につまずいた他の人が道を整備してくれていたか、あるいは、あなたが「自分がつまずいたという事」自体に気付いていないかのいずれかです。

最後の「気付いていない」というのは実はよくあります。ITに詳しくない人から「エラーって言われるんだけど！」と泣き付かれて、「何かした？」と聞いても「何もしてないって！」と本人は言うばかり、というのはよく聞かれる話ですが、それと同じ事を自分でも知らず知らずのうちにしている可能性があるのです。

「そんなバカな！」と思いますか？　では、以下の事に身に覚えはないでしょうか？

公式に情報が無いので、「（機能の名前）使い方」でWeb検索してQiitaやStack Overflowや個人のブログの解説を探した。
動かしてみたらいきなりエラーメッセージが出た。
よく分からないけどWebを検索したら対処法が出てきたので、書いてある通りにやったらエラーが出なくなった。

どうでしょう。「いつもの事だから、特別つまずいたとは思っていなかった」「そんな事でいちいち立ち止まってたら仕事にならないし」と思う人もいるのではないでしょうか。ですが、これらはすべて立派な「つまずき」なのです。

つまずくのは自分のレベルが低いからではなく、説明が足りないから

インストール説明の手順の中に、必要な前提条件が書かれていなかったので、インストールに失敗した。ググったら、◯◯というパッケージを先に入れておかないといけないと書いてあるブログが見つかった。
コマンドを実行しようとしたら、初期設定をして下さいというメッセージが出てエラーになった。
機能を実行しても、ちゃんと動いたかどうかよく分からなかった。

実は、これらは実際にOSS Gateワークショップでもよく登場するつまずきです。こういうつまずきに遭遇した時、「つまずいたのは自分の勉強が足りなかったからだ」「こんな所でつまずくのは初心者だけに違いない、こんな所でつまずいたと人に知られるのは恥ずかしい」と思う人は少なくないでしょう。

しかし、謙虚に学ぶ姿勢は確かに大事なのですが、ここは一旦謙虚さを忘れて、自分の気持ちに素直になってみませんか？

インストール説明の手順の中に前提条件が書かれていなかったのでつまずいた。→必要なパッケージがあるなら、最初からそれも手順に書いておいたり、自動的にインストールするようになってくれていたりすればいいのに……
コマンドを実行しようとしたら、初期設定をして下さいと言われてエラーになった。→初期設定が必須なら、インストール手順の中に書いてあればいいのに……
機能を実行しても、ちゃんと動いたかどうかよく分からなかった。→確認方法も書いてあればいいのに……

ほら、改善できそうな点が見えてきましたね。

多くの小規模なOSSプロジェクトでは、インストール手順や使い方の説明などのドキュメントの整備には手が回らなくなりがちです。この手の情報は、1回使い方を習得した後は2回3回と同じ人が見返す訳ではないため、今現在関わっている人にとっては「かかる手間のわりには自分自身が恩恵を受けられない」という性質があるからです。

しかしそのような状況が長く続きすぎると、「既にわかっている人」以外にとってそのOSSはどんどん使いにくく・関わりにくくなってしまいます。そうすると、新規のユーザーや開発に関わる人が増えない一方で、関わっていた人達はライフステージの変化などにより離れていき、最終的には新機能の追加も無ければ脆弱性の修正も無い、誰にもメンテナンスされない見捨てられたプロジェクトになってしまいます。そうなって一番困るのは、一般のユーザーです。「不親切な案内を丁寧な内容に直す・補完する」のは、プロジェクト自体の長期的な継続のために重要なフィードバックと言えます。

ですので、「つまずいたのは自分の勉強不足のせい」「こんな所でつまずいたと人に知られたら恥ずかしい」という考え方は一旦封印しましょう。むしろ、 「つまずいた自分じゃなく、こんな最初の方につまずくような部分が残ってる事の方が悪い」 くらいに考えておいてちょうどいいくらいです。

「注意しなくても使える」のが一番いい

また、「使う上で注意が必要」という箇所も、フィードバックのきっかけにしやすい部分です。

例えば、筆者はFirefoxの法人利用においてポリシー設定でのカスタマイズをよく行っていますが、この機能自体は導入されてまだ歴史が浅いために、色々とこなれていない部分があります。つい最近も、「検索候補を表示するかどうか」を制御するポリシー設定がロケーションバーに対してしか作用せず、単独のWeb検索バーでは設定に関わらず常に検索候補が表示される、という制限事項に遭遇しました。

そういう制限事項を見つけた時に、「この機能にはこういう制限事項があるので、使う時は注意が必要だ」というノウハウを社内で共有したりブログやQiitaに書いたりするのは、もちろん有用な事です。ただ、そういった情報ばかりが増えていくと、新しく使い始めようとした人には「なんだか、使うのに色々勉強が必要なんだな……」「気軽には使えないんだな……」という印象を持たれ、いずれは「敷居が高そうだから、触るのやめておいた方がいいかな……」と思われるまでにもなってしまいかねません。

OSSに関わりたいと考えている人は、ぜひそこから一歩先に考えを進めてみて下さい。「使う時に特別な注意が必要ないのが一番いい」、これはどんな場合にも言える事です。その視点で考えれば、「検索候補を無効化する設定はロケーションバーだけでなく当然Web検索バーにも反映されるべきで、そうなっていないのは不具合だ」という見方ができるようになり、「注意点」に見えていた物は「フィードバックした方がよい点」として浮かび上がってきます。

実際に、先のポリシー設定の制限事項は筆者が不具合として報告した結果、改善されるべき点と認識してもらう事ができました。そして、提出したパッチが取り込まれた結果、「ポリシー設定で検索候補を表示しないように設定したら、ロケーションバーでも単独のWeb検索バーでも検索候補が表示されなくなる」という、使う上で特別な注意が必要ない状態になりました。

ドキュメントの例にしても機能の例にしても、つまずきに対して「無いならしょうがない」「駄目ならしょうがない」「変えられないんだからしょうがない」と考えていると、どうにかして自分のフィールドの中だけで物事を解決しようという、いわゆる「運用で回避」の方向に行ってしまいがちです。しかし考え方を少し変えれば、そういった「面倒事」は「解決した方がよい問題」と言い換えられます。「OSSにフィードバックするって、何か特別な事だ」「そんな事ができるのは別の世界の人だ」と思っていた人でも、そう考えてみれば、OSSへのフィードバックとは決して特別な事ではなく、日常の延長線上にある物だ、という事を実感できるのではないでしょうか。

まとめ

現代は「問題は自分で解決できる」という実感を得にくい時代かも知れません。ITの分野だけ見ても、今はスマートフォンのように分解修理が不可能な機械は多いですし、Webサービスにしても、クラウドで提供されている物に何かトラブルがあってもユーザーはただベンダーによる復旧を待つ事しかできません。「駄目なら、しょうがない」と早々に諦めなくてはならない場面は非常に多いです。

また、「未解決の問題の解決に取り組む」という事は、まさしく挑戦です。成功が確約された挑戦というものは無く、挑戦するからには失敗のリスクも伴います。「これ以上の失敗はしたくない、失敗は許されない」という空気が強いと、そういう点でも挑戦するのは憚られるものでしょう。前述したFirefoxのポリシー設定の改善提案も、Firefox開発チームの理解や協力を得ることに失敗していたら、制限がそのまま残り続けることになっていたかもしれません。

しかし、「できることは何も無い」「絶対に解決できると分かっている問題以外、取り組みたくない」と最初から諦めていると、それ以上知識も深まらなければ経験も増えません。問題に遭遇した時、「もしかしたら何か解決策があるかもしれない」「解決できるかどうか分からないけど、もし解決できるなら解決したい」と考えて試しに掘り進めてみる、それこそが多くのOSS開発者が日常的にやっている事です。「OSS開発者という人になりたい」という思いは一旦脇に置いて、まずは「OSS開発者がしているような考え方をして、OSS開発者がしているような行動を取る」という事を実践してみて下さい。そうして行動している人、それが「OSS開発者」の正体です。

「OSS開発者」は、プロのスポーツ選手や士業のように試験に合格すればなれる物でも、名誉として手に入れる肩書きでもありません。行動しているという状態こそが「OSS開発者」なのだと言えます。行動すればすぐになれる「OSS開発者」に、皆さんも是非なってみて下さい。

そのような行動をいきなり一人で始められる自信が無いという方は、OSS Gateワークショップがいいきっかけになるかもしれません。東京以外の地域でもワークショップが開催されていますので、一度足を運んでみてはいかがでしょうか。

OSS Gateワークショップでは「フィードバックポイント」と呼んでいます。 ↩
例えば、Issue Trackerではなくメーリングリストが主な情報のやり取りの場だったり、独自の高機能なイシュートラッカーを使用していたり、プルリクエスト形式ではなく伝統的なパッチの形で修正を送る必要があったりという事があります。 ↩
他の意味・定義でOSSという言葉を使う人もいますが、OSSという言葉を生み出し広めたOSIはそのように定義しています。 ↩
多くのOSSライセンスは「何らかの形でライセンス名を明記する事」を利用条件に含めているため、根気よく調べると何かしらの情報を見つけられるようになっているはずです。OSSではない物をOSSと誤認して二次利用すると、もしかしたら訴訟を起こされたり賠償を求められたりするかもしれませんので、ライセンスに関する情報を見つけられない場合は安全側に倒して、OSSではない物と判断する事をお勧めします。 ↩

ククログ