読者です 読者をやめる 読者になる 読者になる

Konifar's WIP

親方!空からどらえもんが!

DroidKaigi 2016 公式アプリのOSS成功要因

オープンソース化した直後くらいに一度経過を書きましたが、今回はその後日談です。

konifar.hatenablog.com

個人的には、今回のOSSは大成功だったんじゃないかなと思います。成功の定義は難しいですが、自分だけで開発するよりもずっと速く開発できたこと、自分も知らないイケてる実装が次々にぶっこまれたこと、前夜祭のような盛り上がりを見せたことなどを鑑みると、成功したと言っていい気がします。

盛り上がりの様子は、ContributorsやPR、Issuesの数から見て取れます。 184個のPR、114個のIssuesが投げ込まれ、35人ものAndroiderがContributeしてくれました。2週間弱のプロジェクトとしてはスピード感あって、まさに集合知という感じで最高でした。

f:id:konifar:20160227094616p:plain DroidKaigi 2016 Welcome Talk Day.2 // Speaker Deck

忘れないうちに、今回のOSSがなぜ成功したのかを少し振り返っておこうと思います。成功要因というと大げさですが、自分が少し気をつけていたことや、後から考えるとよかったことをまとめておきます。

welcomecontributorラベルがわかりやすかった

hotchemiさんが作った緑色の welcomecontributor ラベルが最高でした。簡単なIssueには片っ端からこのラベルをつけていたんですが、Contributeしたい人が見たときに 「とりあえず緑のラベルをやればよい」というのがわかりやすくて、実際にすごい勢いでIssueが消化されていきました。20時に8つくらいIssueをあげて welcomecontributor ラベルをつけておいたら、翌日10時には全てPRになって消化されていたこともありました。圧倒的感謝…!

他のラベルもつける時に迷うこともなく特に苦労しなかったので、なかなかいいラベルの切り方だったのかもしれません。 Labels · konifar/droidkaigi2016 · GitHub

Issueの粒度をできる限り細かくした

できる限り小さいIssueをあげておくようにしていました。これはあまり意識したことではなく、実務でもそうしているからです。Issueの粒度を細かくした方が抜け漏れも少なくなりますし、残りのタスク量を見誤ることも防げます。また、簡単なザコをどんどん倒していくと開発のリズムもよくなります。

あとでContributorの方に話を聞いてみると 「わりと簡単そうじゃん。自分でもできそう」と感じてPRを送ってくれた方もいました。

基本的に英語でやりとりした

IssueやPRはすべて英語でやりとりしていました。海外のエンジニアから何か反応があるんじゃないかと期待していたからです。実際には海外からは特に何もなかったわけですが、結果的に英語でコミュニケーションしていたのはよかったんじゃないかと思います。

何がいいかというと、英語の表現に慣れていない分、日本語よりもコミュニケーションに気を遣うところです。PRでは日常的に "Awesome!"、"Super nice!"、"Cool!"のような言葉が飛び交い、優しい雰囲気で進められた気がします。実装の混み入った話は英語だと辛かったので、そこはスピード優先で時々日本語でやりとりしたりもしました。例えば八木さんが書いてくれたGistがそうですね。

あとでContributorの方に聞いた話ですが、英語で "Awesome!"とか言われると「ありがとう!」とか言われるよりテンション上がったという人もいました。たしかに自分も前に個人でプラグインを改善した時 "Well done, sir!"と言われてすごいテンションが上がったのを覚えてします。

英語でのコミュニケーションはハードルが高そうに見えて、やってみると逆にうまくいくこともあるというのは面白い結果でした。

ブログで広く周知できた

OSS化した時にすぐに書いたブログホッテントリ入りしたので広く周知できたのがよかったです。

また、ブログの中で「どんな修正でも最高だから頼む」みたいなことを書いたんですが、これを見て自分もやろうと思ってくれた人が何人かいたことを後で知りました。

全部英語でわりと活発なので気がひけるかもしれないですが、どんなIssuesやPRでも構わないので気づいたことがあったら気軽に投げてもらいたいなぁと思います。例えばREADMEのタイポの修正だけでもすごく助かります。

即レスで常に見てる感を出した

これは自分が一番心がけていたことで、とにかくリアクションをすぐに返すようにしていました。PRやIssueをあげてくれる人って、大なり小なり不安があると思うんですよね。「こんな小さい修正あげていいんだろうか」とか「トンチンカンなこと言ってたらどうしよう」とか考えてしまって。そんな中で出してきてくれたわけですから、どんな修正でもまずはレスポンスを返すことで感謝を示そうと思っていました。

自分の場合、まず確認したら「見たぞ!」という意味で目のマークをつけていました。

f:id:konifar:20160227102515p:plain

小さいものだとそのまま見て、すぐにコメントやLGTMを返しました。簡単なものだと1分もかからないです。夜でも何か投げ込まれたら速攻で確認して、マージできるものは速攻でマージしていきました。コンフリクトすることも少なかったように思います。

gfxさんのPull Requestを放置して迷惑をかけてしまったことがあって、この一件以降はちょっと議論が必要なものでも 「すこし悩んでるので明日まで待って」のように何かしら返すようにしていました。

自分の知識だと判断に迷うところは、他の人にヘルプを求めたりもしました。例えばEspressoのテストを導入してくれたPull Requestがあったのですが、自分は全然詳しくなくて判断できなかったのでヘルプを求めたらhkurokawaさんが助けてくれて最高でした。

f:id:konifar:20160227104945p:plain

コードの細かい部分は気にしないようにした

本質的でないところは見ないようにしました。例えば細かい変数名やコードのフォーマットがちょっと崩れてるとかです。 実務であれば認識合わせて揃えるように工夫するところですが、OSSの場合は細かいところを気にしてたらキリがないので気にしないようにしました。

いちいち気にしてスピードが落ちるよりは、細かいところは後で一括で直せばいいよねと考えたわけです。なんとなくもっといい修正方法がありそうみたいな予感があった時も同じで、もしいい方法思いついたら後で直せばいいしとりあえずマージしようぜみたいなスタンスでやっていました。もともと小さいアプリですしね。

スピードを優先した

とにかくスピード感あってガンガン開発進んでる空気にしたかったのもあって、スピードを最優先に考えていました。細かい部分を無視するのもその一環ですね。UIのテストを入れたらCIの時間が10分から20分にになったので、テストをいったん外したこともありました。 PR #145

業務だとそうもいかないこともありますが、今回の規模くらいのアプリなら後で直した方が速いことの方が多いですし、これだけたくさんのエンジニアが見てくれていればたぶん速攻で直せるだろうという自信もあったのでスピードを優先していました。

迷わないパッケージ構成にした

Androidのパッケージ構成については色々議論が分かれる部分だと思います。今回はアプリの規模も小さかったですし、どこに何を入れればいいか迷わない構成にするために activityfragment のようにパッケージを切りました。

例えば複数の画面にまたがるような修正をする場合、「このクラスはどこに入れればいいのかな」と迷う人が出てきます。レビューの時もわりと気になってしまって「このクラスはここに置いた方がいいのでは?」みたいなやりとりで時間を取られることもあります。それが嫌だったので、 「とりあえずActivityは activity にぶっこめばいいのね」みたいな感じで誰でもわかるような構成にしました。これもスピードを優先するための方針ですね。

このへんは、android-jpのSlackで詳しくコメントしています。 https://android-jp.slack.com/archives/apps/p1455264742000087

Contributorページを作った

Contributorへの圧倒的感謝を形にしたくて「Contributorページがほしい」というIssueをあげたところ、gotokatsuyaさんが実装してくれました。最高にクールですね。

github.com

DroidKaigiの懇親会で何人かのContributorの方と話してみると、Contributorページに載るというのがモチベーションになって背中を押されてPull Requestしたという人もいたので、リリースに入れられてよかったなぁと思いました。

エンジニア自身がユーザーだった

これは今回のラッキーポイントだったのですが、エンジニア自身がユーザーとなりうるアプリだったのでとっつきやすかったのだと思います。自分が実際に使うアプリなら、ここの動きおかしいとかどういう機能がほしいとか想像しやすいですよね。

また、DroidKaigiで必要なアプリだったので締切の意識が一致していたのも、短期間で爆発的にPRが飛んできた要因だったのかもしれません。


ざっと書き出しただけなのでところどころ被ってる部分も多いですが、一言でいうなら 「初見のContributeのハードルをなるべく下げられた」というのがよかったんじゃないかなと思います。

これからの話

実は今でもガンガン修正が来ていて、先日しれっとリリースもしてセッション詳細からスライドが見れるようになりました。

締切から解放された今、DroidKaigi 2016 公式アプリは自分含め皆さんの遊び場にしたいなぁと考えてます。 Kotlin化しようぜというIssueが来たので、とりあえずkotlinブランチ切って生煮えプルリ出しておきました。興味ある方はどんな修正でもどうぞ!

github.com

来年DroidKaigiがどうなるかはわかりませんが、 OSSとして変化を続けていったらいつの間にか次のカンファレンスのアプリとして使えるようになってた みたいな感じに進められると最高ですね。引き続き、どんなIssueやPRもお待ちしております。