オロでは業務時間で OSS の開発をしても良く、僕は業務で作ったものをライブラリにして様々なところで使ったり、逆に趣味で作ったツールを業務で使い、フィードバックを得て改善するというようなことをしています。
最近、オロの OSS 用 GitHub Organization ができたので、個人で持っていたいくつかの OSS を移管しました。移管してもしなくても僕ができることは変わらないのですが、業務で使っていてかなり役立っているものや、ユースケースが限られているものは、移管して開発を続けやすいようにしたほうが良いと判断しました。
Houl
移管したものは、ほとんどはソースコードが1ファイルしかない小さなものですが、Houl というツールはそこそこ長く開発を続けていて思い入れがあります。
https://github.com/oro-oss/houl
Web サイト制作では、エントリポイントがたくさんある複数種類のファイルをビルドするためにまだまだ Gulp が現役で使われていて、これといった代替もありません。オロでも Gulp を使用して Web サイトのビルドを行っていたのですが、規模の大きい Web サイトを制作していると、ビルド時間が長くなったり、gulpfile.js が複雑になったりしてつらくなっていました。
この問題を解決するために実装したのが Houl です。Houl の開発がある程度進んだときに、試しに業務で開発している Web サイトのビルドに取り入れました。今まで困っていたビルド時間が長い問題が解決し、全員の開発体験が大きく上がりました。Houl はビルドの設定をプリセットとして別パッケージにできるようにしているため、ビルドの設定を1ヶ所でメンテナンスし、npm install するだけで必要な設定が終わるようになったのも良かったです。
現在、Houl はオロのほとんどの Web サイト制作で使われていて、大いに業務に役立っています。
Houl については何度か勉強会で話しています。Gulp をやめて Houl を作ることにしたモチベーションや特徴などは以下のスライドで説明しています。
Houl に取り入れている依存関係を考慮したキャッシュ、動的コンパイルの仕組みは以下のスライドで説明しています。
OSS にする意義
正直なところ多くの OSS は外部の人から Issue や Pull Request がくることはほとんどなく (Houl もそうです)、そこはあまり期待できないと思っています。
個人的な考えですが、公開されていることで先の Houl のスライドのように気軽に発表できるのは嬉しいですし、それによってフィードバックをもらうこともあります。
今回 OSS を置く場所ができたことで、移管した OSS の開発もそうですが、オロの OSS 活動がより活発になっていったら良いなと思っています。