grunt-parallelize v1.1.0リリースおよび零細OSSの継続性について
2015/03/29 10:30 フォークについて末尾に追記
gruntタスクのファイルリストを分割して並列実行するgruntプラグイン、grunt-parallelizeを前に作った。
そこそこ使われてるっぽいのだけど、
- ファイルリストが長大な場合にエラーになることがある
- ファイルリストにdestがあるタスクに対応していない
という2点についてissueや問い合わせがよくあってどうしたもんかなと思いつつ放置していたところ、ちょうど良いプルリクをもらったので重い腰を上げて取り込みつつもろもろ修正してv1.1.0をリリースした。
さて、最近こんな記事を読んで、「プラグイン開発者として」あたりのところをまさに感じていた。
若気の至りで、おっさんも昔はよくGruntプラグインを作ったのです。実際に自分のプロジェクトでGruntを使い、必要だったので、プラグイン開発に対する情熱もあったわけですけど、まぁGulpとか使い出したり、普通にコマンド打ってたら、開発するモチベーションがダダ下がりなわけです。
grunt-parallelizeについて言えば、既存のgruntタスクを変更せずに超手軽に並列化できるっていう点では今だに良いコンセプトだと思うのだけど、「既存のgruntタスク」という前提がないとき、つまりゼロベースでビルド環境を構築するなら、Unix的な汎用CLIコマンドとxargsがあれば事足りるような気もする。そんなこんなで、自分でも既存のプロジェクト以外ではgrunt-parallelizeを新規採用することはなくなっていた。
npmで月間4,200ダウンロードは人気ライブラリというには微妙な数字だけど無視するにはしのびなく、またプルリクを無視される気持ちも知ってるので、マージして、修正して、リリースして、issueを全部見て閉じた。それなりに大変で、ぶっちゃけもうこのライブラリはあまり自分でいじりたくないという気もした。
同時に最近こんな記事も読んだ。
筆者は更新頻度が少ない、あるいは更新が滞ったオープンソース・プロジェクトの作者に協力を提案して管理を引き継ぐ、ということを何度か行っています。
放置したいオーナーがいる一方で、引き継ぎたい人もいる。とはいえ何の素性も知れない人にいきなり任せるのもリスクがある。このあたりをうまくマッチングできたら、零細OSSの開発継続性問題もうまく解決できるんだろうか。
追記 Re:「フォークすれば良いのでは？」
GitHubリポジトリだけならフォークできるけど、npmなどパッケージマネージャにはフォークのような概念が無いってところが問題の本質。前掲の記事から引用すると、
それでも筆者がフォークではなくメンテナンスの引き継ぎに拘るのは、似通ったモジュールの乱立を防ぐことができるからです。開発リソースが分散せずに一つのリポジトリに集約されることはもちろん、開発者の混乱を防ぐことにも繋がります。
徳の高さに頭が下がる思いであります。。
パッケージユーザーにとって負担のない形でパッケージのフォークのようなことができると、解決策のひとつにはなりそう。例えば本家が一定期間更新が無いかつフォークに一定数以上の推薦者がいる場合はオーナー権もらえるとか、そういう仕組みを持ってるパッケージマネージャってあるのかな。なんだか敵対的買収みたいで殺伐としそうな気もするけど。
