Subscribed unsubscribe Subscribe Subscribe

Hatena Developer Blog

はてな開発者ブログ

オープンソース活動への取り組み方

はじめまして。iOSとAndroidアプリの開発を行っている、アプリケーションエンジニアの id:ikesyo です。今年1月の入社後、初めての開発者ブログでの記事になります。最近の大きな出来事は、家族会議の結果、『ユーリ!!! on ICE』のBlu-ray全巻購入をしたことです。

この記事は、はてなエンジニアアドベントカレンダー2016の17日目の記事です。昨日は id:aereal によるはてなブログのデプロイを約6倍高速化したはなし - Sexually Knowingでした。

私は現在、自分のライブラリであるHimotokiやiOS開発用のパッケージマネージャのCarthageなど、全部で十数個のオープンソースソフトウェアの開発、メンテナンスを行っています。最初の頃はGitHubでPull Requestを出すのも怖かった私ですが、自身の活動を振り返ることで、どのようにオープンソース活動に取り組んでいくかという一つの事例をお見せしたいと思います。

目次

はじめに

私がオープンソース活動にのめり込んだのは、ReactiveCocoaというリアクティブプログラミングライブラリとの出会いがきっかけでした。GitHubが、自社で開発していたものをオープンソース化したそのライブラリは、当時の自分にとって未知の領域であり、その元となったRx.NETに関する記事やドキュメントをたくさん読んだり、関数型プログラミングの考え方に触れたりと、非常に興奮したのを覚えています。内部実装に興味を持ってコードリーディングもしていたと思います。

当時はフリーランスのiOSアプリエンジニアをしていたのですが、機会があればそれを仕事で使ってみたいと思っていました。2013年にある仕事で実際に使う機会に恵まれ、使い込んでいく中では色んなバグに遭遇しました。日本語の情報もほとんどない中で、使い続けるには自分でバグを直すしかないという気持ちになり、ここから本格的にGitHubにPull Requestを出していくことになります。

コードを直すこと自体はそれほど問題がなくても、タイトルや説明の英語をどう書いていいものかと悩み、ちょっとした修正を出すのに何十分、何時間と掛かっていたこともあったように思います。レビューのやり取りをするにも、こんな英語でいいだろうかと悩んだりもしていましたが、回数を重ねるうちに、コードの中身が明瞭であれば十分だと思ったり、他者の会話から言い回しを参考にすれば必要なコミュニケーションは取れるのだと、開き直ることができました。そうしてレビューをパスしてマージされた時にはとても興奮したものです。

フリーランスをしながらオープンソース活動をしていく中で、Cocoa勉強会関西関西モバイルアプリ研究会といった勉強会に出会いました。活動の経験や成果を発表していたところに声を掛けてもらい、はてなに入社する運びとなったのでした。オープンソース活動が高じて転職したことになりますね。

といったところで、ここからは実際の活動を時系列で振り返ってみようと思います。

活動遍歴

https://github.com/pulls を開くと、自分の過去のPull Requestを確認することができます。遡ってみると初めてのPull Requestは2012年でした。

2012年

  • Kiwi
    • https://github.com/kiwi-bdd/Kiwi/pull/124
    • 初めてのPull RequestはKiwiというBDDのテストライブラリでした。テスト名称に日本語を使うと挙動がおかしくなるというのを直していたようです
  • ReactiveCocoa
    • ReactiveCocoaを知ったのもこの年でした。まだまだモバイル開発での認知度は低かったですね……
    • この頃はまだcontributeはしていませんでした

この年はKiwiの1件のみでした。

2013年

  • ReactiveCocoa
    • 2013年に入ると、ReactiveCocoaへ時々Pull Requestを出すようになっていました
    • きっかけは仕事でこのライブラリを使い出したことでした。挙動を追うためにソースコードを読む中で気になった箇所を改善したり、遭遇したバグを修正するなどしていました

2014年

  • ReactiveCocoa
    • 前年末に集中的にPull Requestを出していたら、年明けすぐにCollaborator(いわゆるコミッター)の誘いを受け、コミット権を得ました
    • この辺りからGitHubでのオープンソース活動にハマっていった感がありますね
  • Quick (Nimble)
    • https://github.com/Quick/Quick/pull/57
    • WWDCでのSwift発表直後に登場したBDDテストライブラリで、Swiftのコードを書いてみたくていじっていた気がします
    • 後にCollaboratorになります
  • その他

2015年

2014年まではPull Requestの数は20〜30程度でしたが、この年にはなんと370程と爆増しました。Swift製のライブラリが増えてきて、Swiftのコードを書くのが楽しかったこと、Carthageに深くコミットし始めたこと、自分のライブラリの開発もPull Requestベースで進めていたことが増加の要因だと思います。

  • ObjectMapper
    • Swift製のJSONマッパーです。これも仕事で使っていたもので、機能追加やリファクタリングを多数行いました
    • が、Collaboratorにはなっていません
  • Himotoki
    • 自作のJSONマッパーです。自分のライブラリでちゃんと認知を得たのはこれが初めてでした
    • ObjectMapperのAPIや内部実装に不満が出てきた頃に、ならば自分で作ってしまえばいいと気付かせてもらって、作り始めたのがきっかけです。
  • APIKit
    • 設計が参考になるなーと思ってコードを読んでいる中で、ちょっとしたコード改善をたくさん積み上げていき、Collaboratorにもなっています
  • ReactiveCocoa
    • Swift対応が本格的に始まり、継続的にコミットしていました
  • Carthage
    • Swift製のパッケージマネージャです。ReactiveCocoaのSwift版を実プロジェクトで使ってみるという実地検証の役割もあったものでした
    • ReactiveCocoaのSwift版を洗練させていく過程でここのコードにも関わっていき、Collaboratorになりました
  • その他
    • ReactiveCocoaやCarthageの依存ライブラリである以下のライブラリも、芋づる式にメンテナンスするようになりました
    • Result
    • Commandant
    • ReactiveTask

2016年

昨年よりも手を広げた結果、以下のライブラリのCollaboratorにもなりました。現時点でのPull Request数は440程まで増えていました。こんなにやっていたのか……。

  • はてなに入社しました
    • 活動ペースは落ちていません
    • SwiftGenなど、業務に関係して業務時間中に作業したPull Requestもあります
  • ReactiveSwift
    • Objective-CのAPIも並存していたReactiveCocoaからSwiftのAPIを分離したもの
  • Tentacle
    • Carthageから分離したGitHubのAPIクライアント
  • OHHTTPStubs
    • APIKitやTentacleで使用していたネットワークのスタブライブラリ
  • SwiftGen
    • 画像やStoryboardなど各種リソース用のコード生成ツール
  • Quick, Nimble
    • 先述のテストライブラリで、ReactiveCocoa、Carthageでも使っています

何に取り組むか

いざオープンソース活動をしようと思っても、何に取り組むかを考える必要があります。これまでの経験で、私は以下のような探し方をしています。

  • 仕事で使っているもの
    • 使い込む中で機能不足やバグにぶつかることが多いので、一番モチベーションが湧きやすいのではないでしょうか
  • ライブラリの依存ライブラリ
    • OSや言語のバージョンアップへの追従の関係で、依存ライブラリのアップデートにも先手を打っていきたくなるものです
  • オーナー、メンテナーの別プロダクト
    • 人単位で見ていくのもよさそうです
    • 別のプロジェクトで既知の間柄だと、Pull Requestを出すのも気が楽になります
  • https://github.com/trending
    • 言語別に最近盛り上がっているリポジトリを探せます(たまに見る程度)

私の場合、ReactiveCocoaからCarthage、そしてその他諸々、と依存の依存を芋づる式に辿っていくことで関わる範囲が広がっていきました。逆に、自分の関わるライブラリに依存している依存元を辿っていく方向もありそうです。

どう貢献するか

  • 機能追加、バグ修正
    • 最も直接的な貢献方法ですね
  • リファクタリング
    • 既存コードのちょっとした整理だけでも、結構やる余地があるものです
  • バージョンアップ追従
    • 依存ライブラリ、言語バージョンなど
    • iOSやSwiftのようなバージョンアップ頻度が高いものは、貢献のチャンスも多いです
    • 今時のSwift界隈では、Swift Package ManagerやLinux対応も貢献チャンスです
  • Issueへのコメント、回答
    • GitHubやStack Overflowでのユーザーの質問に答えることも、メンテナーの負担を軽減することで大きな意味があります
  • ドキュメンテーション
    • 直接コードをいじらずとも、ドキュメンテーションコメントやREADMEなどを充実させていくのも立派な貢献です

気を付けること

  • CONTRIBUTING.md
    • Issue報告やPull Requestを出す上での注意点、新バージョンのリリース方法などが記載されていたりします
    • あったら一読してからアクションを起こしてみましょう
  • コーディング規約
    • 明確な規約がない場合もありますが、既存コードや過去のPull Requestでのレビュー内容をチェックして、雰囲気を掴むのも大事
    • 「郷に入っては郷に従え」
  • Issue, Pull Requestのテンプレート
    • テンプレートがある場合は無視して削除したりせず、きちんと埋めてあげましょう

気にし過ぎないこと

  • 英語
    • ネイティブじゃない人も多く、多少文法がおかしくても伝わるし、そんなに気にされないはずです
    • チャットではないので、コメントを書くのに多少時間が掛かっても問題ありません
    • Google翻訳の精度が上がったのも助けになりそうです
    • リポジトリをWatchしてIssueやPull Requestのコメント、議論をなんとなく眺めていると、言い回しや語彙のパターンが掴めるかもしれません
  • 焦らない
    • 時差の関係で、コメントの一往復に1日掛かることも珍しくありません
    • 空き時間の対応だったりするので、回答やレビューに時間が掛かることも多いです
    • 気長に待ちましょう

おわりに

オープンソースソフトウェアへの貢献の種は色んなところに落ちています。身近なものや簡単に出来ることから始めて、気楽にオープンソース活動に親しんでいってみてください。

とはいえ、それが行き過ぎて負担になって消耗しては元も子もないですし、GitHubに草が生えていないとダメというわけでもありません。とにかく気楽にやっていきましょう(私も最近はFINAL FANTASY XVに時間を奪われがちです)。

hatenacorp.jp

明日のアドベントカレンダーは id:taketo957 です!

P.S.

来週12月23日(金)発売のWEB+DB PRESS Vol.96(なんと16周年!)で「Swift 3開発最前線」という特集記事を執筆しました。こちらもぜひお楽しみください!

gihyo.jp