CLA)のサインをもらわなければいけなくて、大変でした。サインをもらえなかった場合、その方のコミットはすべてRevertしなければいけなくなります。再実装する手間も生じますし、何よりお互い気持ちよくない。CLAは、簡単に導入できるので、前もって入れておくべきです。CLAへのサインを拒む方の人数が多いと、譲渡の話自体が立ち消えになる可能性も十分にあります。横溝:Trivyのようなケースが増えてくると、開発者にとって励みになりますよね。お二人は、個人としてのオープンソースの持続可能性についてはどうお考えでしょうか?knqyf263:なかなか難しいですよね。最初は「楽しいからやるぜ」となりますが、コミュニティが大きくなり、ユーザが増えたらIssueが次々と来て寝る暇もなくなる。その結果しんどくなってしまい、クローズしていくプロジェクトは多いじゃないですか。やめるだけならともかく、悪意のあるメンテナーの手に移り、トラブルにつながることもある。天地:Trivyで個人でのオープンソース開発の難しさを身をもって知ったので、今手がけている別のプロジェクトでは、できるだけメンテナンスコストがかからないように工夫しています。Issueをつくる段階で、利用者にIssueの種類を選ばせ、トリアージしやすい仕組みにしました。これは、のちにVulsとTrivyにも導入しました。設計面でいうと、勘違いによるIssueを減らすため、バグに見えるような挙動に繋がる機能は、効率がよくなるとしても入れないようにしました。同様の理由で、機能を意図的に少なく設計しています。knqyf263:自分もそれは他のオープンソースを見て感じていたので、Trivyも最小機能にこだわっています。Slack通知機能をつけてしまうと、HipChat通知やChatwork通知のリクエストも来てしまうので、Trivyでははじめから通知機能をつけていません。代わりに、JSONで結果を出し、通知のスクリプトをユーザーに書いてもらうようにしています。できるだけ自分たちで抱え込む範囲を狭めるようにしているんです。横溝:たしかに、いつの間にかプロジェクトがサグラダファミリアのようになってしまうのはあるあるですよね。ちなみに、プルリクやコントリビューションをうまく断るために、工夫してることはありますか?knqyf263:まだ実現できていないのですが、人間が閉じると角が立つので、Botにやらせようと思っています。Kubernetesにはものすごい量のイシューが立っていますが、一定日数が経ってもコメントやリアクションがなければ、自動でBotが閉じる仕組みになっています。自分で意思決定していると、申し訳なさからメンタルもやられるので、機械に任せるのは良いなと思っていて。横溝:めっちゃ面白いですね!イシューへの対応方針などは定めていますか?たとえば僕が手がけていたBoostnoteだと、英語以外は問答無用でクローズしたり、プルリクには該当のイシューをつけたりしていました。knqyf263:しょうもないミスは自分で直さないようにしています。自分がコントリビュートしたオープンソースプロジェクトの方が、愛着が湧くじゃないですか。メンテナーの方が「本当にありがとう。お前のおかげで良くなった」とコメントをくれてマージしてくれるだけで、またコントリビュートしたくなりますよね。ファンを増やすために、5分くらいで直せるものでも、あえて残すようにしていますね。BoostIOでは、これから1年で10個くらいオープンソースを作ろうと思っているのですが、コミュニティを広げるための再現可能な手法として、さっそく使わせていただきたいです。READMEの作り込みから。「広める」努力を怠らない横溝:少し話を変え、日本国内でオープンソース開発に携わる人を増やすための方法についても伺いたいです。聞くのは、「自分の書いたコードを見られるのが恥ずかしくて、コントリビューションに踏み切れない」という話。僕も綺麗なコードを書くのが苦手なので、気持ちはよく分かります。すればこの壁を乗り越えられると思いますか?knqyf263:気にしないことが大事です。有名で世界的に使われているオープンソースプロジェクトでも、コードが汚いものはたくさんあります。それでも、みんな恥ずかしげもなく出しているので、自分だけ恥ずかしがっていてもしょうがない。いう話はよく聞きますが急に羞恥心を捨てるのは無理なので、まずは巷にあるオープンソースプロジェクトのコードをいくつか読んでみてください。「これくらいなら俺にも書けそう」という気持ちになりますから。別にdisっているわけではなくて、コードなんて汚くても、誰かの問題を解決できるなら、十分に価値があると思うんです。コードが汚くても誰かの役に立っている自分と、コードの綺麗さを気にして誰の役にも立っていない自分を想像し、比較してみると良いかもしれません。日本人は完璧主義者も多いと思うのですが、100点満点にならないと出せないと思っていては、永遠に前に進めません。横溝:プロダクト作りと同じですね。開発したオープンソースを広めるためのコツについても、教えていただきたいです。天地:Vulsもそうでしたが、まずは海外から攻めるのが良いと思います。日本人はそもそもユーザー母数が少ないうえに、スターをつける人の割合も多くはない。News』などのニュースサイトに載るように努力しましょう。インフルエンサーの方に「取り上げてください」とメッセージを送るのも手です。無視されることも多いですが、使われなければ価値は出てこないので、そのくらい死に物狂いで広める努力をすべきです。あと僕らはREADMEにもこだわっています。TrivyもDockleもREADMEをお互いにレビューしあって、納得いくものができるまで1週間くらい使っています。knqyf263さんは、できることを、ひと目で表現することにこだわっていました。knqyf263:一画面だけ見れば使い方が理解できるREADMEがいいですよね。スクロールして読んでいかないと伝わらないものだと、途中で閉じちゃうじゃないですか。見てできることが分かってはじめて、「ちょっと使ってみようかな」という気にもなる。機能がたくさんあっても、コア機能は一つに絞れると思うので、それが一目で伝わるようにすべきです。最初に爆発的に広めてくれる人って、第一印象で判断しているケースが多いと思うんですよ。面白そうと思ってもらうことが大事。良いものを作ることは必須ですが、最初の「使ってもらう」ハードルを乗り越えないと、せっかくの価値が伝わりません。あと動画を使う際は、GIF形式にするのがおすすめです。別ページに飛んで再生ボタンを押してもらうプロセスを経ずに、GitHub上で開いたらすぐに見てもらえるので。knqyf263:僕は昔、かなりの自信作のオープンソースをつくったにも関わらず、他人に使ってもらう努力を怠ってしまったがために、誰にも使われずに終わったことがあります。その反省があるからこそ、今はこうして広めることもサボらないようにしています。自分のようにゴリゴリ押しに行くのが苦手でも、とりあえずREADMEだけでもちゃんと書きましょう。インフルエンサーの方に拾ってもらえる確率がぐっと高まるので。スターを押すだけでもいい。できる所から「貢献」をはじめよう横溝:そもそも、日本でオープンソースにコントリビュートする人の絶対数が少ない点も問題だと思います。コントリビューターを増やすために、お二人はどうすればいいとお考えでしょうか?天地:まずはコントリビューションのハードルを下げるところからはじめる必要があると思います。スターを付ける回数ですら、海外の人に比べると、圧倒的に日本人は少ないと感じます。スターでも、READMEの誤字脱字を直すだけでもいいから、何かしらのコントリビューションを行うことが「かっこいい」とみなされるような文化ができるといいですよね。knqyf263:あとは、「とりあえず直せばいいじゃん」と思えるマインドセットを広めることですね。冒頭でお話した通り、僕自身が大学の先輩にそうした考えをインストールされて、オープンソースにコミットするようになりました。特別な技術やテクニックを教わったわけではありません。オープンソースにコントリビューションしている人は、まずは周囲の人にそうした考え方を広めていってほしいですね。天地:ツイートするだけでも、開発者はたいていエゴサーチをしているので、見つけてもらえる確率は高いです。できる範囲からでいいので、何かしらの「貢献」にトライしていけるといいですね。横溝:今回のTrivyの買収は、日本のオープンソース開発者や開発者コミュニティをたいへん勇気づけた出来事だったと思います。最後に、今オープンソース開発を手がけている人や、これからトライしようとしている人に向けて、応援のメッセージをいただけますか?天地:技術力が高くなくても、オープンソースに参加していいんだと伝えたいです。僕も2年前までは、「オープンソースは技術力が高い人が手がけるもの」というイメージがありました。実際にオープンソース開発にコミットしている人たちに会うと、人間味あふれる面白い人が多く、分からないことや改善点があればやさしく教えてくれます。その結果、僕ができることが増えていきました。オープンソースへの参加をためらっている人の中には、いまの僕よりもコードが綺麗に書けて、技術力が高い人はたくさんいます。僕がオープンソースでそこそこ上手くやっていけているので、ハードルを高く捉えないでほしいです。あとは先ほどもお伝えしたように、何かをつくった際は「広める」ための仕組みもしっかりと考えましょう。チャンスも増えますし、なによりも利用者の声はめちゃくちゃモチベーション上がりますよ。knqyf263:僕は「一旦、最後まで走りきる」ことを大切にしてほしいです。作った後に誰かに使ってもらえる保証はないし、無駄になってしまうかもしれない中で、開発を続けるのは大きな不安やプレッシャーを伴います。途中で気持ちが切れてやめてしまう人も多いのですが、「この人、最後まで走り切ったらいけたのに」と思えるような人も少なくない。Trivyも、ゴールデンウィークの半ばまでは上手く行くイメージが見えず、途中で投げ出しそうになったのですが、なんとかやり切りました。あそこでやめていたら、ただゴールデンウィークの半分を無駄にしただけになっていましたね(笑)。横溝:諦めない、やりきる、不安やプレッシャーと戦う・・まさにスタートアップと同じですね。knqyf263:そうですね。途中でやめるのは、本当にもったいない。最後まで走り切り、駄目ならまた次を考えればいいんです。あと、「オープンソース開発に興味はあるが、特に作りたいものがない」という悩みを抱えている人も多い印象があります。した人は、まず目の前の業務に真剣に取り組んでみましょう。「オープンソース開発をしたい」という気持ちだと、取り組みたい問題は見つかりにくいと思います。必要とされることを普通に一生懸命やっていくうちに、テーマは自然と見つかります。僕も、Kubernetesの運用にがむしゃらに取り組むなかで、コンテナのセキュリティへの関心が湧いてきました。焦らずに、目の前のボールを1個ずつ打ち返していきましょう。誤解を恐れずに言えば、「性格の悪さ」も身につけた方がいいでしょう。性格の良い人は、不満があっても飲み込んで受け入れてしまうと思うのですが、「これはおかしい」という不満に正直でいたほうが、オープンソースソフトウェア業界では強いと思います。横溝:めちゃくちゃ「起業家」ですね。日頃の生きづらさを、サービスに昇華していくことこそがアントレプレナーシップですし、オープンソース開発も同じだなと感じました。オープンソース開発における大変さやそれを乗り越える大事さ、作った後の広げ方など、精神面から実務面まで役に立つ情報をシェアいただき、本当に勉強になりました。BoostIOからのお知らせIssueHuntにて、オープンソースプロジェクトの支援や、求職中の開発者の方々と企業をマッチングするサービスを提供しております。Relations・海老島までご連絡下さい!https://forms.gle/RXwrj7SpwDEeX8RTAまでご連絡ください!ダウンロード#ソフトウェア開発#Github#オープンソース#OSSこの記事が気に入ったら、サポートをしてみませんか?気軽にクリエイターを支援できます。サポートをする「スキ」を押してクリエイターを応援しよう!34OPENSOURCE.TOKYOフォローこのクリエイターの人気記事オープンソースはいかにして普及していったのか?黎明期を知る二人と語る、OSSの軌跡と展望1OPENSOURCE.TOKYOオープンソースの発展には、“あなたの貢献”が必要だ。アカツキの「貢献して当たり前」なカルチャーに迫る16OPENSOURCE.TOKYO退勤後、深夜のプルリク対応。それでも楽しいOSSコミュニティ運営の魅力【kazupon×Hiroppy】13OPENSOURCE.TOKYOオープンソースへの最大の貢献は「やってみること」。Ueyamaオープンソース開発者が報われる世界を作る為に。