wyukawa’s blog

OSSプロダクトとのつきあい方

etc

僕は様々なOSSプロダクトを使ってシステムを構築しているけれど、自分なりにぼんやりと考えているOSSプロダクトとのつきあい方について書いてみる。

どのようなシステムを作るにせよ、それが一定以上の規模になるのであればOSSプロダクトを使わずに全部自前で実装するのはもはや現実的ではないです。例えばDBが必要だからってDB実装しますか？

ただこれがHTTPクライアントライブラリぐらいになるとちょっと微妙になってきて既存のライブラリが使いにくいから自作するってケースはもしかしたらあるかもしれないです。僕はそんなスキルないので自作しないですけどね。ただ既存ライブラリをラップして使いやすいAPIを提供するとかならあるかも。

商用製品だったり内製プロダクトだとぐぐれないし、ドキュメントとかソースが無くて情報共有しづらいことが多いし、またそれを使って学んで他に役立つか微妙なのでエンジニアのモチベーションも上がらないと思うんですよね。もちろんそれがベストだと判断したなら使いますけど、僕ならまずOSSプロダクトを使うことを前提にします。

ユースケースにフィットしそうなOSSプロダクトを選定して使うんですが、どうしてもフィットしきれない部分だったりツール作ったほうがいいと判断したなら自作します。自作したものもビジネスロジックが含まない汎用的なものであればOSSとして公開します。

僕の場合は下記プロジェクトを公開してます。

https://github.com/wyukawa/eboshi

https://github.com/wyukawa/yanagishima

システムを運用しているうちに使っているOSSプロダクトのバグを踏んだり機能追加して欲しい場合はどうするか？

OSSだからソースも公開されているし、いざとなったらソースいじって修正すればいいじゃんという考えがあります。これは半分正しいと思いますが、例えばCentOSのバグを踏んだらCentOSのソースいじるんでしょうか？僕はそこまでのスキルはないので別のworkaroundを考えますね。

規模が大きくて簡単に修正できそうも無い場合はMLに報告するとかissueを起票するのが良いと思います。活発に開発が行われているプロジェクトなら無視されないでしょう。僕はPrestoに関してはこの方針でやってます。エラーが発生したらとりあえずMLに報告してます。無視されるようであれば別のOSSプロダクトを使うことを検討した方がいいかもしれません。AzkabanのMLとか無視されがちですし、正直言って未来が無い感じなのですが、他に良い選択肢がないので使い続けてます。。。

一方でそこまで規模が大きくないライブラリならソース修正してpull request出すことはあります。

僕の場合は下記プロジェクトにpull request出してmergeされたことがあります。

https://github.com/tagomoris/shib

https://github.com/BradRuderman/pyhs2

https://github.com/treasure-data/prestogres

https://github.com/azkaban/azkaban

pull request出す理由は独自パッチを自分で管理したくないからです。upstreamにmergeしてもらって次のバージョンアップに含めて欲しいんです。そうすればライブラリのバージョンアップを行えば自分が踏んだバグも無くなって機能追加もされてハッピーです。

まあ、そんな感じです。

あわせて読みたい

業務とオープンソース活動の話 (日本OSS奨励賞 受賞報告にかえて) - たごもりすメモ

Permalink | コメント(0) | トラックバック(0) | 20:32