Table of Contents
人は生まれながらにして貴賤の別なく、ただオープンソースプロジェクトを勤めて物事をよく知る者が貴人となるなり。
昔、偉い人がそんな感じのことを言っていたような。
私がGitHubで開発しているライブラリ、Pcap4J のスターの数がつい先日 200 に達したのを記念して、これまでどんな活動をしてきたか、この活動によって何を得たかなどについて書きたい。
願わくは、この記事に触発されてオープンソースプロジェクトを始める人のあらんことを。
Pcap4Jとは？
Pcap4Jは、パケットキャプチャとパケット解析をするJavaのライブラリ。 ニッチ。
ただ最近になってビッグデータ解析技術が発達し、大量のパケットをリアルタイムで解析してシステムや運用にフィードバックするというのが現実的になってきたので、パケットキャプチャへの注目が高まってきている雰囲気がある。 こういう分野ではJavaがまだかなり人気なのもあってワンチャンある。
パケットキャプチャの部分は pcap のラッパ。 パケット解析の部分は割とプラガブルで、外からプロトコル追加などのカスタマイズができるはできるんだけど、作りのせいなのかJavaなせいなのか解析器を書くのが結構つらい。
競合は jpcap や jNetPcap など。
Google.comでjava packet captureと検索するとだいたいjpcap、Pcap4J、jNetPcapの順で表示される。
打倒jpcap。
数字で見るPcap4Jプロジェクト
Pcap4Jリポジトリの一番古いコミットは 2011/12/18。 東日本大震災後の節電施策として実施された休日シフト中にコーディングしていた覚えがあるので、多分2011年夏くらいから開発していたんだけど、とりあえずこの最古のコミットをプロジェクトの開始とすると、スターが200になった 2016/8/11 まで 1698日 かかったことになる。 約 0.118個/日。遅い…
コミット数は 559個。ほとんどが自前のコミット。 プロジェクト成長過程の動画を Gource というツールで生成してみたが、一人でかけずりまわっているのがよく分かる。
コミット頻度は約 0.33個/日 で、だいたい3日に1コミット。 思っていたより多いけど、胸張れるほどの頻度ではない。
リリースは 17個 で、約 0.30個/月。少ない…
Issuesが 52個、プルリクエストが 16個。 自分ではIssuesもプルリクエストもあまり作らないので、ほとんどが他人からのもの。 ちゃんとチケット駆動にしてトレーサビリティを確保しておくべきだったと後悔している。 けど面倒だし今更なので今後も適当にコミットしちゃう。
あとはWatchが 28人、Forkが 66個、コントリビュータが 7人。
スター200ってどうなの?
jQueryやReactなんてスター40000超えてるし、JavaならSpring Frameworkも10000に達しようとしている。200なんて全然大したことなくない? と言う声が聞こえるようだが、そんな知らない人を探すのが難しいようなプロジェクトと比べてはいけない。
スター200以上のプロジェクトは割合でみるととても少ない。
現在GitHubがホストしてる全プロジェクトは 14,308,407 個。 Javaプロジェクトはその内二番目に大きい割合を占めていて 1,501,840 個 (約 10.5% )。
スター200以上のプロジェクトは 37,031 個で、全プロジェクト中、上位約 0.26% に当たる。
スター200以上のJavaプロジェクトは 3,922 個で、全Javaプロジェクト中、上位約 0.26% に当たる。
無名の個人にとっては、スター200、というかとりあえず100くらいは手ごろで手ごたえのある目標だ。
オープンソースプロジェクトの育て方
GitHubのスターの数というのはそのプロジェクトを気に入ってくれた人の数である。 この数はそのプロジェクトの成果物を実際に使ってくれている人や組織の数、つまり普及率と正の相関があるはずだ。 成果物の普及率はプロジェクトの成長度のひとつの指標であり、スターの増加を見るのはわが子のようなプロジェクトの成長を見るようでとても楽しい。
ここでは、私がPcap4Jプロジェクトを育てるためにやったことと、やってないけどやるべきだと思っていることなどについて書く。 Pcap4Jはライブラリなので、アプリとかよりもライブラリよりの話が多めかも。
未解決の問題を探す
Pcap4Jプロジェクトを始める前は、競合を調べ、それらとの差別化を考えた。 他のプロジェクトが既に解決している問題を同じように解決したのでは魅力が出ない。 機能なり、性能なり、ユーザビリティなり、デザインなり、サポートプラットフォームなり、何かしらの点で競合より優れていたり、競合にないものを持っていることが重要。 そうでなければ作っていても面白くないし、モチベーションも続かない。
まだ解決されていない問題を見つけたり、使っているアプリに不満を感じたら、新しいアプリやライブラリやプラグインを自分で作るチャンスととらえるべし。
APIを練る
Pcap4Jの開発を始めて、一番頭を使ったのがAPI設計。 分かりやすく、汎用的で、シンプルで、つまり使いやすいAPIを実装すべきことは言うまでもない。 APIがころころ変わるのはユーザにとても嫌がられるので、長い目で見ても問題なさそうな、拡張もしやすそうなAPIを設計すべし。 自分でそのライブラリを使ったアプリを作ってみると、ユーザ視点でAPIを評価できるのでよい。
逆に、内部の設計はAPIに比べたらそんなに重要じゃない。 10年前の技術を使ったイモい実装でもいい。 とりあえずリリースして、技術的負債として後で済し崩せばよし。
GitHubに上げる
ある程度コードが書けたらどこかに公開するわけだけど、パブリックなリポジトリなら GitHub 一択。
今の時代、猫も杓子もGoogleもMicrosoftもAppleも、ソースを公開すると言ったらGitHubだ。 迷うことはない。
(弊社も最近組織アカウントを作ったようだ。知らなかった。)
ドキュメントを充実させる (英語で)
Pcap4JのREADME.mdやドキュメントは、大変だったけど最初から英語と日本語で書いた。 英語がメイン。
英語は世界でもっとも多く使われている言語で、8.5億人が日常的に話す。実用レベルの英語を話せる人はもっと多く、17.5億人。英語を読んで理解できるというレベルならもっといるかもしれない。 一方、日本語を理解できる人は1.5億人もいない。しかもそのほとんどは極東のごく限られた地域に住む保守的な民族だ。 さらに、ソフトウェア技術の中心は英語の国アメリカにある。日本はどちらかといえばソフトウェア後進国と言わざるを得ない。 せっかくオープンソースプロジェクトに挑戦するなら、それが日本に特化したものでなければ、英語で公開してより多くの先進的な人たちに繋がり、使ってもらい、揉まれるのがやりがいがあり楽しい。
ドキュメントの内容にも割と力をいれた。
ドキュメントは理想的には、機能やサポートプラットフォームやインストール方法などを説明するドキュメントと、体系的で網羅的なAPIリファレンスに加え、簡易アプリケーションを書くようなチュートリアルやユースケースベースの解説があるといいと思う。
因みにここでドキュメントと言っているのはユーザ向けのもの。 コントリビュータ等に向けて内部設計書みたいなものを書くと親切かと思うかもしれないが、全く必要ない。 世界的にはウォータフォールはほぼ完全にその役目を終え、アジャイルな開発が当たり前になっている。 こうした開発プロセスでは体系立った設計書など書かない。知りたいことがあればソースを見ればよいというスタンス。 設計書が無くても誰も文句を言わないので安心してさぼるべし。
因みに因みにプラグインの開発者はユーザの括りなので、それ向けのドキュメントはちゃんと書くべし。
APIリファレンスはJavaならJavadocでもいい。 Pcap4JのJavadocは javadoc.io で公開している。 このサービス最高に手軽でありがたいので、なくならないようにもっと広まってほしい。
メアドを晒す
README.mdには開発者へのコンタクトとしてメアドを晒すべし。
質問やエンハンス依頼などをしたいがGitHub Issuesに登録するのはちょっと気が引ける、というシャイな人は海外にも意外と結構いて、Pcap4Jの場合、Issuesの5,6倍くらいのメールが来る。 また、仕事がからんでいる人はメールでコンタクトしてくる場合が多いようだ。
こういう人たちの心をがっちり掴むために、メアドを晒し、素早く丁寧に、できればクールにフレンドリーに対応すべし。 アメリカ人なんかは特にこうした対応の質を重視する。 (逆に言えばバグを出してもしっかりサポートすれば万事OKみたいな雰囲気があってしまうんだけど。)
パッケージマネジメントシステムを利用する
ライブラリの配布は、言語ごとに普及しているパッケージマネジメントシステムに 必ず 乗っかるべし。
使いたいライブラリがオレオレ配布されていたときの絶望感ったらない。 他のライブラリと統一的に扱えないし、バージョンや依存性の解決も手動でやらなければいけない。 そんな絶望を撒き散らす魔女に自分がなってはいけない。
Javascriptなら npm や Bower、Rubyなら RubyGems、Pythonなら PyPI(?)。
Pcap4JはJavaなので Mavenリポジトリ。当初から Maven Central Repository に上げているけど、今なら JCenter の方が手軽でよさそう。 (けどjavadoc.io使うならやっぱりMaven Central Repositoryか。)
敷居が高そうに見えるが、やってみると意外と簡単なので恐れることはない。
ロゴを作る
ロゴを作るのを勧めたい。
パワポでシステム構成を説明するダイアグラムを書いているときに、ロゴがないコンポーネントを見つけた時の絶望感ったらない。 ニートなロゴを作って、希望を振りまく魔法少女たろう。
プロジェクト名をおしゃれなフリーフォントで書いて、ちょっとカーニングしただけのロゴタイプでもいい。 自分で作ったものがださくてかっこ悪いんじゃないかと不安になったら、runCのロゴマークを見ると心が休まるかもしれない。
Pcap4Jのロゴは、PのついたキャップをJavaカラーでというアイデアをもとに嫁に描いてもらった。端っこがちょっとジャギジャギしてるのと、ファビコンにするとつぶれてしまうところをいつか何とかしたい。
ホームページを作る
プロジェクトのホームページを作るのはいいアイデアだ。 箔がつくし、少なくとも作っている自分が楽しい。
GitHubのプロジェクトページをホームページと言ってもいいが、せっかく GitHub Pages が使えるのでトライすべし。(2016/12/16 追記: GitHub PagesにJekyll Theme Chooserという機能が追加され、非常に簡単にホームページを作れるようにもなった。)
最近はシングルページのシンプルなホームページが流行りなので、内容は薄くても構わない。 Gulpのホームページを見て勇気づけられよう。 webpackもなかなかの手抜きだ。
ドキュメントには載せにくいカジュアルなPR文句とか、簡単な導入方法とかチュートリアルとかをホームページに書くのがいいかもしれない。 あとはロゴを貼ってGitHubへのリンクを張っておけば充分。 もちろん英語で。
Pcap4Jのホームページは Hugo を使って十数時間くらいでできた。
慣れている人ならもっと速くできるだろう。
この際ドメインを取ってしまうのもいい。箔のため。
pcap4j.orgはバリュードメインで買ったけど、別にどこでもいい。
費用は業者やドメインによって異なるけど、pcap4j.orgの場合は年1598円。リーズナブル。
Stack Overflowで盛り上げる
プロジェクトの成熟度を Stack Overflow の関連投稿数で図る人が一定数いる。
Stack Overflowはプログラミング技術に関する世界で最も人気なフォーラムサイトだ。 Stack Overflowの投稿数が多ければそれだけコアなユーザや情報が多いということだし、困ったときにそこで質問すれば適切な回答が得られる見込みが高いということ。 ユーザコミュニティが育っているとも言え、そのライブラリを採用する根拠の一つになる。
Stack Overflowに投稿される質問をチェックし、自分のライブラリなりツールで解決できる問題があったら回答してアピールすることで認知度が高まるだろう。 自分のプロジェクトに対する質問があれば、もちろん積極的に回答すべきだ。特に黎明期は。
私もStack Overflowで一度だけPcap4JのPRをやったが、めんど^h^h^h時間がとれなくて続かなかった。 反応はよかったのでちょっと後悔。 自分のプロジェクトに関する質問をモニタリングする効率的な方法はないものか…
コミットをし続ける
コミットはなるべく頻繁に。
修正量は多くなくてもいいので、間をあけないことが重要。 今もメンテされているか、活発に開発されているかは、そのライブラリを使うかどうかの大きな判断基準の一つだ。
同様にIssuesやプルリクエストに迅速に対応することも重要で、できたらいいんだけど、ちょっと大変。
Issue Stats という、Issuesやプルリクエストへの対応速度などを解析してくれるサービスがある。 対応速度に自信があるならここのバッジを貼るのもいいかもしれない。
Pcap4Jのこの数字は怖くて見れない。
継続的インテグレーションを実装する
継続的インテグレーション(CI)を実装すると、品質にまじめに取り組んでる風が出て、ライブラリへの信頼が高まる。
利用するサービスは Travis CI でも CircleCI でも Appveyor でも Codeship でも Drone でもなんでもいい。 どれも無料で利用でき、GitHubと連携してコミットのプッシュでビルド/テストをキックできる。 なんならAWSやGCPやHerokuなんかへのデプロイまで自動化して継続的デリバリ-(CD)を実現することもできる。
CIを実装したらREADME.mdにバッジを貼るのを忘れずに。 とてもオフィシャル感が出る。
Pcap4JはLinux(Ubuntu)でのテストをTravis CIで、WindowsでのテストをAppveyorでやっていて、Travis CIでのテスト中に Cobertura でコードカバレージを測って Coveralls にアップし、Appveyorでのビルド結果をMaven Central Repositoryにアップしている。
今からJavaのコードカバレージを測るなら、Coberturaよりも活発に開発されている Jacoco を使うべき。 コードカバレージの管理も、Coverallsより Codecov の方が多機能でサポートもいいらしい。
静的コード解析もCIの一部で、絶対やるべきなんだけど、Pcap4Jではまだやってない。 いつの日か。 Javaだと何を使うといいんだろう。
コーディング規約を作る
Pcap4Jではできてないんだけど、インデントをどんな感じにするのかとか、変数の命名規則だとか、コメントの書き方とか、プロジェクトのコードを書く上での作法を定め、コーディング規約として公開しておくべし。 できればフォーマッタとかLinterとかの実行をビルドプロセスに組み込んで、コーディング規約への準拠を自動化しておくのが理想。 コードの書き様が統一されると、可読性が増し、品質の向上につながる。
また、プルリクエストの対応を心穏やかに効率よくできるようになるのが大きい。 今までPcap4Jに来たプルリクエストの中で、処理方式や実装方式は置いといて、許容できるコーディングスタイルで書かれていたものは2割もなかった。 周りのコードに合わせたスタイルで書いてくれるなんてことは期待すべきではない。 インデントがスペースかタブかというレベルでさえ合わせてくれない。 修正箇所以外の部分にまで自前のフォーマットを適用してくるやつもいた。
コーディング規約がないと、こういったプルリクエストに対してコーディングスタイルの説明から始めないといけない。 自動化して手順を公開していれば、事前にやってくれることが期待できるし、やってくれなかったらここ見ろと言うだけでいい。
もっと言えば、コーディング規約を含んだコントリビューション手順書を作って、どこのブランチにプルリクエストを送るのかとか、テストはどうするとかまで定めて公開しておいたほうがいいかも。 やり過ぎるとプルリクエスト来なくなりそうだけど。
オープンソースプロジェクトをやっていてよかったこと
Pcap4Jを5年近く続けたことで、単純に楽しい以上によかったことがあったのでそれについて書く。
グローバルな気分になった
Pcap4Jにスターを付けてくれた人は5大陸31ヶ国にわたり、世界中に向けて公開されている実感がある。 プログラミングに国境はなく、日本も西洋諸国も同じ天地の間にあって、同じ日輪に照らされ、同じ月を眺め、海をともにし、空気をともにしているんだと、なんとなくグローバルな気分になれた。
(所在不明者のスターはグリーンランドに置いた。)
少子高齢化で日本のマーケットは縮小していく一方だし、景気回復もまだまだ遠そうだし、グローバルに事業を展開しないとジリ貧だ、というのは10年以上前から言われている。 グローバルにやるっていうのはつまり、日本市場を特別視するんじゃなくて、プロダクトやサービスを世界で最適な市場に投入するってことなんだと思う。 日本市場→世界進出じゃなくて、世界展開→日本向けローカライズという順。 ソフトウェアやWebサービスにとって、ここでの世界とは具体的に言えば英語圏で、もっとはっきり言えばアメリカ。 PS4はそういうやりかただったし、Pokemon GOは、…ちょっと違うか。
かつて日本のSNS市場を開拓し席巻したMixiは、世界のSNS市場で天下を取ったFacebookよりちょっとだけ早くサービスを開始していた。もしMixiが最初からアメリカ向けに公開されていたらどうなっていただろうと、ちょっと残念に思うときがある。
と、こんなにもグローバルな気分、オープンソースプロジェクト無しにはなれなかったであろう。
真面目な話、スペインのスタートアップに誘われたり、アメリカの国立研究所から質問が来たり、ドイツのJDの卒論をサポートしたり、ウクライナの教育機関から謝辞をもらったりと、貴重なエキサイティングな体験ができ、自分の世界が広がったのは確か。
いろいろなことに取り組むモチベーションが出た
Pcap4Jプロジェクトに絡めて、CIとか、JVM言語とか、Dockerとか、いろいろなことに取り組むことができた。
技術とは、ただむずかしき字を知り、解し難きドキュメントを読み、世上に実のなき文学を言うにあらず。 手を動かし、Hello Worldレベルを超えたところにこそ学びがある。 とはいえ、こうした学びの作業は多くのひとにとって楽しくも大変なことなので、続けるにはちょっと工夫して動機付けしてやるのがいい。
私も基本的に腰が重いタイプだが、Pcap4Jプロジェクトがいい動機付けになった。 特に、プロジェクトの改善として結果が表れ残るものは、学びのやりがいがあり高いモチベーションを保てた。
ユーザから色々教えてもらえた
凡人一人ででなんて大したことは学べない。 Pcap4Jのユーザから、要望や指摘やIssuesやプルリクエストを通して、色々なことを教えてもらった。 見つけにくい環境依存のバグ、プロジェクト構造のアドバイス、知らなかったプロトコル、思いもしなかったPcap4Jのユースケース、それを実現するためのAPI。
ユーザの声を聴き、フィードバックを取り入れていくことで、ソフトウェアは真に有用なものになる。 ついでに知識も知見も知恵も深まる。 これがOSSの醍醐味であろう。
理想的には、Team Geekにも書かれている通り、未完成の内からソースを公開し、可能な限り早い段階でユーザのフィードバックを受けるべきだ。
いつも1人でやっていると、失敗のリスクが高くなる。そして、成長の可能性が低くなる。
(中略)
つまり、1人で仕事をするほうがリスクが高いということだ。誰かと一緒に仕事をすると、アイデアを盗まれたりバカにされたりしないかと不安になるかもしれないが、間違ったことをして時間をムダにすることを不安に思うべきだ。
まあ、無名の個人が未完成のソフトを公開してフィードバックをもらえるかという疑問もあるが。
小金を得た
プロジェクトに興味を持ってくれる人が増えれば、中にはお金を払ってくれる人も出てくる。 それは寄付であったり、作業の見返りだったりする。
私はPcap4J開発を通して、ちょっとした幾許かの小金を多少得ることができた。 普通オープンソースプロジェクトは直接的にお金を稼ぐ目的でやるものではないし、私もただ自分の楽しみのためにやっていただけだが、もらえるならもらえるに越したことはない。 ありがたや。
これを目当てにすべきではないが、たなぼたな展開もあるよということで。
終わりに
オープンソースプロジェクトに依っては、前節で書いたような開発者自身が得るもののほかに、その活動の成果を享受し、活用してさらなる価値を生み出す多くの他人がいる(かもしれない)ことも忘れてはいけない。
およそ何人にてもいささか身に技術あればこれによりて世の益をなさんと欲するは人情の常なり。 ソフトウェア技術の発展にわずかでも貢献ができたかもしれないと思えば、開発の励みになるものだ。
ひとつのオープンソースプロジェクトを生み出すのは、無限の未来を生み出すこと。
願わくは、この記事に触発されてオープンソースプロジェクトを始める人のあらんことを。
