私のOSSを使うユースケースはこんな感じでした。
こういうことしたいなー→ググる→お!なんかあんじゃん→git clone →あれ動かねえぇ→Qiitaの記事に対処法かいてあるわ→動いた動いた（なんで動かなかったんだろなぁ）
普段色々とOSSを使っていますが、フリーウェアと勘違いした使い方は嫌だなあと常日頃思っていました。会社ですと、利用申請をペライチで出して使えるものって認識の人もいますね。じゃあ具体的な貢献方法となると・・・これを押すくらいしか思いつかなかった。(ただの画像です)
かといってクリティカルなところを修正したプルリク投げて直したぜ！やだかっこいい濡れる///みたいな技量もないしなぁ・・・と思っていた次第。そんな中 「OSS」とか「OSS もくもく」とかでTechPlayなどのセミナー募集サイトをさがしていたらOSS Gateワークショップを発見しました。
実は６月に開催されたワークショップにも応募しましたが、キャンセルが出なくていけませんでした。
今回も２カ月前くらいに申し込んでキャンセル待ちになっていましたが、一週間前にキャンセルが出て、参加することが出来ました。
この記事ではワークショップの流れと、思ったことを書こうと思います。
実施内容
詳細を見たい人はdoorkeeperを見てください。タイムテーブルなどが乗っています。
入場
WSは1.5カ月に一度のペースで日本各地で行われていて、各地の有志がメンターをやっていて、さらに有志の企業がスペースを提供しているようです。
今回のワークショップでは渋谷のGMOグループさんの会議室でした。オシャンティーなフレンズの敵の名前みたいなビルだった。
地下で受付を済ませて説明をちゃんと読んでいなかった為、一回ホテルに凸したけどフロアは白かった。掃除大変そう。横の会議室ではマイクラのハッカソンのようなものがやっていて、一瞬そっちに歩いていきそうになりましたがちゃんとOSSGateの方に行きました。
絶対迷うと思ったので３５分ごろつきました。ラップトップのステッカー数から猛者感を感じつつ着席。
電源もWi-Fiも提供していただけたので長いワークショップも安心でした。
このワークショップではビギナー、サポーター、サポートメンターと３つのロールがありました。
- ビギナー:OSSやってみたいけどわからないから来た人
- サポーター: OSSやってる人、以前にこのワークショップをやった人
- サポートメンター: サポーターが回ってないところにヘルプで入る人
そして、会場を貸してもらっているGMOさんからもヘルプがありました。
すごくないですか？有志でこれだけ集まるんですよ？
アイスブレイク
自己紹介のやつ。勉強会やセミナーは同人活動っぽく動いているので、技術書だしたりしてますーていったら司会がシス管女子の中の人@piro_or さんだった。世間は狭い
全体でというよりは今日一緒にやるサポーターさんに挨拶しましょうって感じ。他のビギナーさんとは交流があまりなかったかな。
OSS開発手順の説明
OSSってなに？というところから噛み砕いて説明してもらいました。
OSSはコワクナイヨー、いかついコード修正だけが貢献じゃないよー、力抜いてリラ～ックスということが伝わった。
- OSSを使ってつまづいたところはissueのネタ元になるから常にメモする癖をつけよう
- 使うときに公式以外の情報が必要だったら、それは指摘したほうがよい
- issueがたっても採用するかどうかは製作者だから、悩むくらいなら立ててみよう
- けど出来ませんでした直して（テヘペロ）は製作者は嬉しくない
- 直すと使う側も嬉しいし、製作者も嬉しいと感じれるようなことをしよう
- OSSかどうかはライセンスファイルを見よう
という感じでした。私は何年かソフトの品証をやっていたので、くだらない指摘したら悪いなぁと思うことが多かったのですが、issueは指摘じゃなくて、こうしたら良くないですか？と提案するものだと考えを変えることが出来ました。
対象OSSを動かす
ではやってみましょう！とスタートしました。OSSといっても色々あります。まず最初になにを扱うか考えるわけですが、悩みました。とっつきやすいところとして、chromeのExtensionやfirefoxのAdd-on、Linuxコマンド、ライブラリ、atomのプラグインとかがよいよーと教わりました。
最初はTwitcherというchromeの拡張機能の一つで、複数のツイッターのアカウントを切り替えできるものを取り扱おうとしましたが、
githubを見てみると８年前で更新が止まっていたので、issueを立ててもリアクションが見込めないだろうと思い別のものを探すことにしました。
他になにがあるかなぁと思ってたとき、たまたまツイッターで見た東京アメッシュをCLIで表示するツールameshがgitで公開されていたと思い、対象のOSSに決めました。
対象のOSSが決まったら公式のドキュメントだけで（ブログとかstackoverflowは見ないで）使えるかをやってみます。その際は手順を詳細にかいて、戸惑ったポイントを書きましょう。それがissueのネタになります。
私がやった手順はOSSワークショップのレポジトリにissueとしてあげている（issueをあげる練習にもなっていました）ので、詳細は見てください。
他の参加者や以前のWSのログもissueから見ることが出来ます。
結果としては２つ戸惑ったところがありました。
- go get したときレスポンスがなくてちゃんとインストールできたかわからないので完了メッセージがほしい
- macのbashで使うと画像が荒くてよくわからん。sixel対応のターミナルだと綺麗に見れるからアピールしたほうがいい
１つめのはgoを触っている人からするとそれがgoのいいところなんだが？と思われるかもしれないです。ですが、素人目線でみるとちょっと困惑しました。
２つ目は勿体ないよ！と思ったことです。
実際にフィードバックする
次にこれを元にissueもしくは改善案まで出せるならプルリクまでを作っていきます。
この作業が難しかった。何が難しかったかというと、余計なことを考えていたからかな。使う側としてはこうなったらよいのだけど、それはこっちのわがままかもしれないし、ただコストをかけさせても嫌だし、issueが公開されてしまうし・・・という心境でした。
なので、色々なOSSのコミッターをしているサポーターの人たちにissueが立てられたときどう思っていますか？と聞きまわりました。
多くの人が、こう答えていました。
- issueは嫌だとは思わない、むしろウェルカム（怒る人もいるけどごく一部だから大丈夫らしい）
- プログラムではなく使う側の問題でも、issueとして残るので、次から説明しなくてすむから楽
- 自分が考えていなかった観点から見てもらえて、さらに良いものを作ることができればハッピー
- 対応するかどうかは、issueの内容とそれを解消するためのコストを考えるので選別はする
- pullリク付きの場合、妥当であれば即承認しやすい
- issue内で一言このソフトいいねとほめてくれてもいいんじゃよ？
そしてissueの書き方は決まりはないですが、ある程度のテンプレがあります。
- 再現手順
- 期待される結果
- 実際の結果
- 自分の環境
- 改善案
ソフトウェアのバグの指摘(JIRAとかRedmineのチケット)と大きく違うのが最後の改善案を書くことでした。実装者の気持ちになる必要はなく、ユーザの視点でみることが品証のありかたなので正しいと思います。ですがOSSの場合、大げさに言えばissueを書くことでユーザから共同開発者の一人になってプロジェクトに携わることになります。作ったissueはこちらです。
https://github.com/otiai10/amesh/issues/15
https://github.com/otiai10/amesh/issues/16
プルリクまで行きたったです・・・といったんですが、issueを立てただけでも貢献になると言ってもらったのを家宝にしようと思いました。
思ったこと
今回のWSのアウトプットとして２つissueを上げることが出来ました。
OSSGateを通過できたのかな・・・ｗ
issueをどう扱うかは製作者の自由なので、とりあえず投げてみればよいのかなと一つOSS参加の障壁が取れた気持ちになりました。
なによりガッツリOSSを作っている人たちの話を聞けたのが良かったです。github上だけでは作者の気持ちを考えることが難しかったので、issueやプルリクが来たときどう思うかを知ることが出来ました。
OSS開発はボランティアとは違う気がしました。OSSをやりたい！というより、常日頃からOSSを使うときに改善点が出せないかを考えながら使うと自然にissueを書いているといったライフワークのような。
人のレポジトリだけ見るのではなく、自分で作ったものを公開して、issueを立てられる側にもなりたいですね。
OSS gate ワークショップ行ってみてください。
https://oss-gate.github.io/
といってもサポーターが増えないとビギナー枠増えないんだけどね（もうちょっとレベル上げしたらサポーターで行ってみたい）