OSS選定時に個人的に考えていること

この記事はみすてむず いず みすきーしすてむず Advent Calendar 2023 17日目の記事です

adventar.org

はじめに

こんにちはこんばんわ、たろです。
その辺でJavaとTypeScript書いてます。
IT系の多種多様な話が飛び交うみすてむずでOSS選定の話とかあまり見ないなということでアドカレのネタにしてみました。
ググればわかるだろとかそういうのはなしで

個人的OSS選定基準

あくまでも僕が業務でOSSを選ぶときに何を基準に決めているかになります。チーム・プロジェクト全体の方針などによっては相容れないものもあるかと思いますがご容赦ください。

適度に更新されているか

メンテナンスされていることは本当に大事ですよね、脆弱性に関わるバグが見つかったのに一向に修正されないから小手先で何とかするのは避けたいものです。年単位で更新がなかったりすると、ちょっと使うのやめようかなって思ったりします。

枯れているか

適度に更新されているかどうかを基準にすると言いつつ、追加機能を期待しなかったりする場合は枯れている(更新が止まっている)ものを選んだりします(csvパーサとかはこのケースに該当しますかね)。脆弱性が見つかった場合は対応しないと大変なことになるので、枯れているからキャッチアップをしなくていいというわけではないことに注意しましょう。

先人の知恵にあやかれるか

OSSに関連するエラーが出たときに毎回OSSの解析をして解決するよりはググって先人の知恵を利用できた方が圧倒的に速いし楽です。ここで注意したいのは先人の知恵にあやかれる≠人気ということです。単に人気なだけだと「Hello Worldしてみた！」みたいな記事ばっかりで困ったときに調べても当てにならないなんてこともあります。

公式ドキュメントの充実度合

いくら先人たちの知恵があるとはいえ、公式ドキュメントが空っぽなのはさすがに辛いです。最後に信じられるのは先人の知恵＋公式ドキュメントの合わせ技です。

OSSを導入して実現したいことを実現できるか

「当たり前だろ！」って思う人いるかもしれません。そうです、当たり前です。でもめちゃくちゃ大事です。最初は目的通りのものを探していても比較対象を羅列するにつれて少しずつずれていくなんてことはよくあります。

LTSの期間

基幹フレームワークの場合はLTSの期間なんかも見たりします。「LTS短くても切れる前にあげればいいじゃん！」と思う人はいるかもしれませんが、プロジェクトによってはたいそう立派な文書を育てて顧客に提出して顧客承認をもらわないとバージョンアップできないなんてこともあります(2014年3月リリースのJava8が現役で動いているところもあるのでそういうことです)。バージョンアップに追われ続けない程度の期間があればいいかなというのが個人的所感です。

選定時に考慮しないもの

今いるメンバーが使いこなせるか

今から1週間でアラビア語とロシア語をマスターしろって言ってるわけじゃないんです、使いこなせるようになりましょう。
大げさに書きましたが、自分たちが普段使っている言語のOSSを選定することがほとんどだと思います。普段使っている言語であればある程度は中身を読めると思うので、読んで理解すればいいんです。最悪読んでわからなくても超絶マイナーなOSSを使ったりしなければどこかに情報は落ちています。

今話題のニューフェイスか

新しければ自分たちが直面している課題が解決するわけじゃないです。「広い家に住みたい！」って言って新築1R4畳を選ぶ人はいないですよね？

終わりに

つらつらと書いてきましたが、まとめると「自分たちが使っていて問題に直面した時に解決できるような地盤が整っているか」です。
チームによっては堅牢なものよりイケイケなものを好んだりするので、実際に選定するときはチームの考えも考慮しつつ選定できるとよいかなと思います。

ということでアドカレの機運に乗じて初めてまともな記事を書きました。
気が向いたら他のことも書く…かも…？

明日はいぬうださんことusaponさんの記事です。
「何か書きます！」と書いてありますが、何が出てくるか全くわかりません！
…何を書いてくれるんでしょうか、期待して待ちましょう。