見出し画像

「GitHubのスター数が多いから良い」と盲目的にライブラリ選定をしていないか胸に手をあてて考える

serima

これはGameWith Advent Calendar 2019の22日目の記事です。
昨日は、同僚のsys-cat氏のキーボードに対する熱い思いが書かれた記事でした。こちらも、ぜひご覧ください。

GameWithでのライブラリ選定事情

GameWithでは、プロジェクトで使用するライブラリ・フレームワークなどの技術選定は基本的に各チームに一任することにしています。
常日頃、対象のコードベースと向き合っているソフトウェアエンジニアのほうが適切な判断を下せるだろうという考えからです。

たとえば、Androidアプリに新たにライブラリを導入するか検討する際は、Androidエンジニアのチーム内で十分に議論して決定してもらう、といった具合です。

参考までにですが、選定する際の観点として、社内ドキュメントには下記のようなものを記述しています。

・学習コスト
・ライセンス
・メンテナンス性
・技術コミュニティの活発さ
・ライブラリ側に不具合があった場合の対処
・プロダクト側のコードベースにフィットするか

当然、導入に際しては事前に妥当性を検証するとは思いますが、ライブラリやフレームワークの導入の妥当性が肌感覚として判明するのは、得てして本番環境に導入からしばらく経ってから（下手したら数年後とか）というケースが多いように思います。

たとえば、以下のようなシーンなどはよく見かけるのではないでしょうか。

・ライブラリのメンテナンスが想定よりも早く終わってしまい、セキュリティ的にリスクがある
・ライブラリの破壊的変更が多すぎてプロダクトとして追従が困難になる

そのような状態になってしまったときに、なぜそのライブラリを導入したのか背景や理由がドキュメントとして残っていないと「どこまでリスクを検証した結果、そのライブラリを選定したのか」が分からず、開発チームとして同じ失敗を繰り返してしまう可能性が高くなってしまいます。

そのため、GameWithでは技術選定の理由をドキュメントとして残してもらうようにしています。

ライブラリの選定基準について

上記にも書きましたが、ライブラリ選定を行う際は様々な観点があり、プロダクトのフェーズや開発チームのスキルセットにも依存すると思っています。

どういった観点を抑えておけば良いかはデビッド・ホイーラー氏の「How to Evaluate Open Source Software / Free Software (OSS/FS) Programs」というホワイトペーパーが非常に参考になるので、ぜひそちらをご覧いただければと思います。

私達が指標としているGitHubのスター数の罠

昨今、多くのOSSはGitHubにホストされていますが、そのOSSのプロジェクトがどういう状態にあるかを手っ取り早く理解するための指標として「スター数」があると思います。

画像1

このスター数、当然ですが、あくまで"今"そのスター数であるということを示しているだけで、時系列でどのように評価されてきたかを知ることはできません。

画像2

スター数をクリックしても、上記のように誰がスターをつけたかというページが現れるだけです。

"罠"と少し強めに表記したのは、

・今も継続的にウォッチされているのか
・数年前はトレンドだったが、今はウォッチされていないのか

がスナップショット的な数字からは判断ができないためです。

メンテナンス性を評価する際に他の指標も利用すればもちろん気付くことはできると思いますが、スター数という指標があまりにも分かりやすいがために盲目的に「スター数が多いから良い！」となっている方はいませんでしょうか。

"今"のスター数だけに惑わされない

ひとつのケースとして「CSVに対してクエリを実行することができるOSS」を紹介したいと思います。
私が把握している限り、比較的ポピュラーなプロジェクトは以下の3つです。

・dinedal/textql ★ 8.3K
・harelba/q ★ 7.3K
・noborus/trdsql ★ 417

単純にスター数だけを比較すると、textqlが優勝です。じゃあ、textqlでいいね！となりますでしょうか。
ちょっと待ってください。まずは、Latest commitに着目してみましょう。

画像4

3月25日が最後のcommitになってます。参考までにほかのプロジェクトも確認してみましょう。

画像5

画像6

たまたまかもしれませんが、どちらも数時間以内にcommitされた形跡が見て取れます。

次に、実装言語を確認してみると、textqlとtrdsqlはGo言語、qはPythonでの実装となっていました。
今回導入したいのはコマンドラインツールなので、手元の環境を汚染しないGo言語でのワンバイナリで配布されている形が適切かもしれません。

さて、次にそれぞれのプロジェクトがどのような時系列でスターを獲得してきたかを確認してみましょう。
Star historyというサイトで以下のようなトレンドのグラフを生成することができます。(こちらのプロジェクトもまたOSSです)

画像3

基本的にGitHubのユーザは一度スターをつけたプロジェクトから、スターを外すという行為はしないため純増していく傾向にあります。
そのため、スター数は非常に多かったとしても、横ばいの状態が長く続いている場合はメンテナンス性の観点からは少し注意したほうがいいかもしれません。

結果的にスター数が一番少ない「trdsqlを利用する」という判断になっても全くおかしくないということがお分かり頂けましたでしょうか。

まとめ

今、そのプロジェクトがどういう状態にあるのかを把握するためにスター数だけを見ていると思わぬ罠にハマってしまうかもしれません。

あくまでひとつの指標として利用するのは有用だと思うので、今まで全く意識してなかった方がいたら、ちょっと気をつけてみることをおすすめします！というお話でした。

最後に、facebook/reactとvuejs/vueのスター数の推移のグラフを置いておきます。拮抗してますね。

画像7



いいなと思ったら応援しよう！