Node、ひいてはJavaScriptを取り巻く環境は目紛しく変化し、ライブラリやフレームワークもそれに合わせて日々更新され続けています。特にNodeモジュールの場合は、それ自体のコードはもちろん、頻繁に行われる依存パッケージのアップデートも精査の対象としなければなりません。そんな環境の中で、大量のコードまたは複雑なパッケージ依存関係を持つにも関わらず、何ヶ月、あるいは何年も更新されていないNodeモジュールを使うのは、少なからぬリスクがあると考えるべきでしょう。

放置されたモジュールをそのまま使わずに、フォークして自身の用途に合わせて修正を行うというのも(オープンソースらしい)一つの手段です。同様の目的を果たすモジュールをコードベースから書き直して作成する手もあります。あるいは、既に別の開発者が代替手段となるモジュールを作ってくれている場合もあるでしょう。

そういった、代替物を探す/作る解決方法に加えてもう一つ、自分がその放置されたプロジェクトを引き継ぐ、というのも有効な選択肢です。

実際に、筆者は更新頻度が少ない、あるいは更新が滞ったオープンソース・プロジェクトの作者に協力を提案して管理を引き継ぐ、ということを何度か行っています。

フォークとの違い

フォークに比べたデメリットとしては何よりも「連絡の手間がかかる」ことが挙げられるでしょう。gulp-renameの場合は連絡をもらえるまでに3ヶ月掛かっています。当該プロジェクトだけでなくGithubへのアクセス自体が少ない作者であれば、そもそも連絡をとる事が困難です。連絡がついたとしても提案が受理されるとは限りません(実際、断られたことも何度かあります)。早々にフォークしてしまい、独自にメンテナンスを続ける方がずっと簡単に済みます。

それでも筆者がフォークではなくメンテナンスの引き継ぎに拘るのは、似通ったモジュールの乱立を防ぐことができるからです。開発リソースが分散せずに一つのリポジトリに集約されることはもちろん、開発者の混乱を防ぐことにも繋がります。

プロジェクトへの参加を提案する方法

メンテナンスを任せても大丈夫な開発者だと認識してもらう必要があります。最も分かりやすいのは、プロジェクトに対してPull Requestなど何らかの貢献することです。継続的に何件か行っていると、作者に覚えてもらえる可能性も高まりますし、安心感も増すと思います。これまで行ってきたOSSプロジェクトのメンテナンス経験を提示するという方法もあります。

ことNodeのプロジェクトに関して言えば、リポジトリへのコミット権の付与だけでなく、作者と相談してnpmパッケージのオーナーとして登録してもらうと尚良いでしょう。リポジトリの更新をすぐにnpmパッケージに反映することができます。

リスク回避の手段として

もちろん、完全に廃れきったソフトウェアにしがみ付く必要はありませんし、見極めて早々に別の開発手段に移行するフットワークの軽さも肝心です。それでも、トレンドを追って様々なライブラリ/開発環境を渡り歩くよりは、自分が使っているソフトウェアのレガシー化を防ぐべくコミュニティに働きかけた方が、総合的に考えれば少ない労力で済む場合もあるかと思います。

AppVeyorでセキュア変数を設定する
外部コマンドを実行するNodeプログラムの作り方