個人開発のiOSアプリをOSS化するためにやったこと
先日、個人開発のiOSアプリをOSS化したので、その際にやったことを書きます。
なぜOSSにしたのか
元々Like Paperはprivateリポジトリで開発してました。
なんならver1.0のときはGithubにもあげてませんでした。
ローカルでGit管理でした。
さすがにそれだとPCが吹っ飛んだときに大変なことになるので、Githubには最低限あげてました。
（正直バージョン1.0のときは吹っ飛んでもいいぐらいでしたので）
ストア公開からそろそろ半年たつのですが、ダウンロード数はじわじわ増えて、8,000件を超えました。
ユーザーが増えてるのも嬉しいですが、何より僕自身がヘビーに使ってるアプリなので、もっと機能拡充したい気持ちになっています。
OSSにしたのは、一言で言えば、もっとアプリを良くしたかったからです。
広告はユーザー体験を下げる
個人アプリ開発で、無料でやるか収益化を目指すかは一つの大きな分かれ目だと思います。
収益化にも、有料アプリにするか、無料アプリで広告を入れるか、あるいは無料ユーザーには広告出して有料ユーザーには出さないの三通りが考えられると思います。
アプリの構想段階では、そのうち広告入れて〜という考えもあったのですが、今では完全に入れないことにしました。
これは個人的な価値観ですが、可能ならば広告は自分のアプリに入れたくないです。
理由はいくつかありますが、大きくはデザイン面とユーザー体験面です。
広告による収益化が、Webを大きく発展させてきたことは認めています。
けれど、素朴に考えて、自分が毎日使うソフトウェアに広告入っていて嬉しいですか？
嬉しくないですよね。
それにLike Paperくらいの規模のアプリでは、広告収入といっても、大した額にはなりません。
ユーザー体験を犠牲にする価値がある額ではない、と判断しました。
それよりもコードを公開することで、自分の開発者としてのアピール材料にしたり、自分の技術的成長の足がかりにしたり、あと似たようなコードを書こうとしている人の参考材料にしてもらったり（本来のOSSの意義）した方がよっぽどいいんじゃないかなと思い、パブリック化しました。
セキュリティの不安
OSSにするときに一番不安だったのが、公開してはいけない情報を含んでいないだろうか、という点です。
よくAWSのアクセスキーを埋めこんでGithubにあげてしまって、不正利用されるという話を聞きます。
僕のアプリの場合、パブリッククラウド不使用の、回線に優しいアプリになっており、その辺の心配は不要でした。
もしキー情報をcommitしてしまっていたら、リポジトリつくりなおした方が良さそうですね。
git commitする時に、秘密にしなければならない情報があればどうしたらいいのでしょうか？
そもそもiOSアプリってオープンソースにするものなの？ というのも疑問でした。
Bundle IDが知られると、なんかマズいことあるんじゃないか？ などと思ってたんですが、オープンソースでやってるリポジトリは探してみたらいっぱいありました。
ガイドラインに従って作業する
どこまで本気でOSSの体裁を整えるかはソフトウェアの規模次第だとは思いますが、下記にすばらしいガイドラインがあります。
基本的にはこれに従えばいいと思います。
READMEを書く
privateリポジトリだったら、READMEなんて空欄でいいと思いますが、OSSにするならある程度ちゃんと書く必要があります。
- このアプリは何か
- 誰がつくっているのか
- 実行環境
- コントリビュート方法
あたりの記述は最低限要るかと。
ライセンスを選ぶ
OSSのライセンス、フワッとしかわかってなかったので、少し調べました。
オープンソースライセンス比較用早見表 - Google ドライブ
MITライセンスかApache v2.0かなーと思ってたんですが、違いは商標の利用に関する条項しかないみたいです。
商標の利用がよくわかってないのですが、「Apacheって名前を勝手に使って商売されたら困る」という解釈であってるんですかね。
僕の場合、別に勝手に商売されてもOKだったので、MITライセンスにしました。
ライセンスを明記する
リポジトリにライセンスを明記するには、ルートディレクトリにLICENSEというファイルをつくってください。
MITライセンスならここにありますので、コピペして年と名前だけ変えます。
masterに反映すると、Githubがライセンス情報を読んで、「このプロジェクトはMITライセンスなんだな」と認識してくれます。
ちなみにリポジトリ作成時にライセンスを選べるみたいで、最初からライセンス選んでおけば、この作業は不要でした。
途中からライセンス追加するには、このステップが必要みたいです。
（Githubの設定画面からできそうですけど、できないみたいです）
ブランチをちゃんとする
プライベート一人開発時代はmasterに直プッシュでやってたのですが、さすがにアレなので、ブランチをちゃんと切りました。
[日本語訳]A successful Git branching model
↑こちらを読んで、リモートリポジトリには、master/developだけにしました。
masterにはリリースごとにGithubのWebからリリースタグをつけてました。
ローカルからのpushはdevelopに対してのみ行い、テストが完了したタイミングでdevelop→masterにプルリクを出す、としました。
あとGithubの設定からmaster/developのブランチ保護を有効にしました。
ここまでやっても、僕がローカルブランチでdevelopという名前で開発ブランチつくっていて、それをリモートのdevelopにpushするとそのままオートマージされてしまう、というのは防げませんでした。
防御方法としては、Git hooksを使うというのはあったんですが、
これはローカルの仕込みであって、Github側での設定ではありません。
最初にリポジトリをcloneする時点でなんらかのスクリプトしこんで、コラボレーターに環境構築させる仕組みをつくっている例も見ましたが、正直それはめんどくさいです。
結局OSSといっても、Like Paperにコントリビュートするのって基本的には僕だけで、他にコントリビュートしてくれる方もその辺の事情わかってるだろう、ということで、Git hooksで完全防御するのはやめました。
issue/pull requestのテンプレートをつくる（未対応）
ガイドラインに従って作業していくと、 「issue/pull requestのテンプレートをつくる」というのが出てきます。
ちゃんとしたOSSなら、対応した方が運営的に楽だと思います。
が、僕の場合OSSといっても小さな個人開発なので、そんな月に何十件もissueやpull requestが集まることはないので、フリーフォーマットにしてます。
プロジェクトの行動規範を追加する（未対応）
ちゃんとしたOSSなら、CODE_OF_CONDUCTを設定するといいそうです。
全体的に英語にする
あとissueとかソース内のコメントとかを日本語で書いてたんですが、全体的に英語にしました。
OSSにしてよかったこと
以上でやったことは終わりです。
よかったことを書きます。
OSS化したものの、結局実質一人プロジェクトになるのを想定していましたが、twitterでOSS化した報告をしたら、ウホーイさんがCI基盤をつくるプルリクを出して、コントリビューターになってくれました。
OSSや〜〜〜って思いました。
あとパブリックリポジトリにすると、無料ユーザーのプライベートリポジトリだと使えなかった機能が全力で解放されました。
たとえばブランチ保護機能や、Github Actionsの月あたりの実行時間制限もなくなりました。
今のところOSSにしたメリットはあっても、デメリットはないです。
収益化を考えないソフトウェアなら、ガンガン公開すべきだな〜って思いました。
Discussion