本記事では、「OSS応援企画」として記事末に「応援ボタン」を設置しています。1回の応援につき、Findyが100円をOSS団体などへ寄付し、エンジニアの成長とOSSの発展を応援する取り組みです。開発者の想いや取り組みに共感した気持ちが、OSSの支援にもつながっていく、そんな前向きな循環をFindyは目指しています。「応援ボタン」は、1日1回まで押すことができます。記事を読んで「いいな」と感じたら、ぜひボタンを押してあなたの応援の気持ちを届けてください。
こんにちは。k1LoWと申します。普段はテイラー株式会社という会社で、ソフトウェアエンジニアとしてプロダクト開発に取り組んでいます。趣味は少し実用的で小さなOSSを書くことです。
今まで awspec、tbls、octocov、runn などをつくってはメンテナンスをしています。また、最近は deck というMarkdownとGoogle Slidesでプレゼンテーションを作成するツールを開発しはじめました。おそらく趣味と自称しても良いくらいの数はあると思うのですが、GitHubの個人リポジトリの総数は300を超えています。なんでそんなにゼロからOSSをつくるのかというと、楽しいからなんです。
今回はこの「ゼロイチのOSS開発」の良さについて紹介させていただければと思います。
コントリビューションだけではないOSS活動とは？
みなさんはOSS活動についてどのようなイメージを持っていますか？
- OSSのバグを見つけて修正パッチやPull Requestを送る。もしくはIssueに登録する
- OSSの機能追加や改善のためのPull Requestを送る。もしくはIssueに登録する
- OSSのドキュメントの作成やチュートリアルの執筆、コミュニティでのサポート
どれもOSS活動であることに間違いありません。これらのOSS活動は「コントリビューション（貢献）」というくくりになると思います。
ところで、コントリビューションとはまた違った側面からのOSS活動があります。そうです。「ゼロから自分でつくってOSSとして公開する＝ゼロイチのOSS開発」です。（「コントリビューション」と同じようにいうとしたら「クリエーション」でしょうか。）
「Pull Requestを送るだけでも敷居が高いのにゼロからつくるなんてとんでもない」と思ったそこのお方、いやいやそんなことはないんです。コントリビューションも慣れたらとても有意義にできるOSS活動ですが、（とても個人的な意見ですが）ゼロイチのOSS開発は「はじめやすいOSS活動」だと思っています。
ゼロイチのOSS開発がはじめやすい2つの理由
「ゼロイチのOSS開発がはじめやすい」といってもピンとこない方もいるかもしれません。でもそこには確かに理由があるのです。
自分の欲しいものを、自分の好きなようにつくれる
ゼロイチのOSSは何といっても何でも自由に決めることができます。対象も方針も設計も技術スタックも名前もすべてあなたが決めることができます。慣習も忖度もトレンドもありません。あなたが欲しいものを自由に開発することができるのです。
開発をはじめたらメンテナンスも自分ですることができます。これは一種の箱庭と言っていいでしょう。どんな手の入れ方も自由です。新機能の開発優先度もスケジュールもあなたが決めることができます。技術トレンドを追いかけてみたり、完全なるCI/CD（継続的インテグレーション／継続的デリバリー：開発・テスト・デプロイを自動化する仕組み）自動化を目指してもいいでしょう。少しづつ良くしていく。少しづつ自分好みにしていく。すべてが自由です。
一番のユーザーはあなた自身、続けるも停めるも自由
あなたがゼロから開発したOSSには、最初からユーザーがいます。それはあなた自身です。
あなた自身が使って改善点をIssueに登録し、あなた自身がそのIssueを取捨選択し改善していく。最初からフィードバックループを回すことができます。「もし、その熱心なユーザー（＝あなた）が離れてしまったら...？」そのときは素直に開発を停止すればいいのです。停止も自由に決めることができます。
ゼロイチのOSS開発者だからこその得難い体験
ゼロから開発してOSSとして公開したのならば、そのOSSの作者はあなたです。
（まだ）LinuxやEmacsのような大規模なOSSではありません。小さなOSSです。ただ、実は、小さなOSSの作者であるからこそ体験できることがあります。私が体験した印象深いエピソードをいくつか紹介したいと思います。
Ruby力が足りない！？ 相談から生まれたブレイクスルー体験
awspecというRuby製のAWSリソースのテストツールの開発をしている中でのエビソードです。Rubyでの開発経験が浅い中つくっていたのですが、その中で実装に困った機能がありました。
例えば awspec ではS3バケットの存在やACL Ownerを以下のようなコードでテストできます。
describe s3_bucket('my-bucket') do
it { should exist }
its(:acl_owner) { should eq 'my-bucket-owner' }
end
ただ、:acl_ownerのような特定の値を取得するためのキーをすべてつくっていては、いくら開発リソースがあっても足りません。そこで、aws-sdk.gemから受け取ったAWSリソースのインスタンスにそのままアクセスできるような :resource キーを用意して、任意のプロパティにアクセスできるようにしようと考えました。
describe s3_bucket('my-bucket') do
it { should exist }
its('acl.owner.display_name') { should eq 'my-bucket-owner' } # :acl_owner と同じ値を指している
end
とはいえ利用者が its('resource.delete')と間違って書いてしまってインスタンスが持つdeleteメソッドを実行してバケットを消してしまっては大変です。なんとかしてこのresourceに渡すインスタンスの操作系のメソッドを潰す必要がありました。
ただ、私のRuby力ではどう実装したらいいのかわかりませんでした。
そこで、福岡のRubyコミュニティ Fukuoka.rbに参加して、そのオーガナイザーでもあるudzuraさんに助力を仰ぎ、設計から実装まで付き合ってもらう機会を得ることができました。Rubyのメタプログラミング（プログラムが自身の構造を動的に変更するプログラミング技術）の強力さを実感できるとてもエキサイティングな体験でした。 （この顛末は私のブログにエントリがありますので、興味があればご覧ください。）
この最高の体験ができたのは、作者としてOSSにオーナーシップを持っていたからこそ、技術的に深い相談ができたからだと思っています。
想定外のユースケースに驚いた！議論が深まった体験
runnというオペレーション自動化ツール・パッケージの開発をしている中でのエピソードです。runnは今でこそ様々な企業でもAPIテストツールとして使っていただいていますが、当初はあくまで自分たちのアプリケーションの品質を維持しながら開発スピードを上げるためのパッケージとして、プライベートで開発をはじめたOSSです。
ある時、頻繁にIssueやPull Requestを送ってくださる方が現れました。内容もバグの報告や修正だけではなく機能の提案まで様々です。どれも「なるほど」と思うものが多く、多くの気づきを得ることができました。どんな方なんだろうと思いつつも面識があるわけでもなかったので、GitHubのレポジトリ上でコミュニケーションを取るだけでした。
ある時、PHPコミュニティの繋がりを通じて実際にお会いすることができました。その方が今はrunnのメンテナでもあるk2tzumiさんです。それからは全国各地のカンファレンスで会うたびに「runn開発者会議」と称してrunnの方向性について様々な角度から議論をする機会を得ることができています。
runnも私が作者ですので、実装やアーキテクチャについては把握しています。その上で全く想定していなかったユースケースとその機能提案（さらにはPull Request）を貰うことがあります。みなさんも業務でプロダクトやツールや機能をつくることがあると思いますが、ユーザーや他の仲間から自身が関わるプロダクトの幅を広げる提案を受けたら、「嬉しい」と同時に「どうすればそれが実現できるか」を考えてしまうと思います。感情と思考の高まりが同時にくる体験です。
OSSでも同じです。作者であることでオーナーシップをもって深い議論ができるのはとてもエキサイティングです。
想像以上に進化！コントリビューターによるオーバーホールから学び、成長できたと思う体験
プレゼンテーション作成ツールであるdeckでも貴重な体験をしました。deckは私が2つのコンセプトを持って開発をはじめたツールです。
- 継続的にスライドを作成できるようなツールであること
- コンテンツとデザインをMarkdownとGoogle Slidesに明確に責務を分けること
2つのコンセプト自体は当初から実現していました。ところが、deckはSongmuさんが開発に参加したことによって大幅に変わりました。まず、私が掲げた2つのコンセプトは一切変わっていません。MarkdownからGoogle Slidesを作成するというシンプルな機能も変わっていません。スライド内容変更処理のアルゴリズムも変わっていません。確かに機能の追加はありました。しかし、それでは「大幅」とは言えません。
では、何が大幅に変わったのでしょう。「コンセプト（アーキテクチャ）以外のすべて」です。
処理速度が大幅に向上し、Markdownの各要素の解釈がより正確になり、Google Slides APIの利用方法がより洗練されました。まさに「オーバーホール」と言っていいと思います。コンセプトに関わる部分以外のあらゆる要素が改善されました。
おそらくこの変化を一番理解しているのは私だと思います。コンセプトを尊重し、その上でより洗練させていく様子は、Pull Requestを通じて（時にはオンラインで会話して）すべて見ることができています。技術的な面だけでなく進め方も本当に勉強になりました。
この体験はdeckの作者だからこそ、オーバーホールを目の当たりにでき、結果として私自身の成長につながったのではないかと思っています。
ゼロイチのOSS開発はエキサイティング！自由な箱庭づくりを
ゼロイチのOSS開発は何をするのも自由です。そして時にOSSをつくっていたからこそのエキサイティングな体験をすることができます。それはそのOSSのあらゆるコードや課題についてオーナーシップを持てる、まさにオーナー＝作者の特権です。OSS開発は本当に楽しいです。
あなたもゼロイチのOSS開発で、自分だけの小さな庭を育ててみませんか？