この記事は 東葛.dev Advent Calendar 2025 11日目の記事です。
昨日はponyoxaさんで「東葛.devのここが好き 3選」でした。
はじめに
こんにちは kozy4324 です。さっそくですが質問です。
みなさんOSS開発してますか？！
こう書くと「ソフトウェアエンジニア、余暇の時間もOSS活動に従事すべき！(MUST, SHOULD)」みたいに聞こえてしまいそうですが、本記事はそういう主張をするつもりはありません。どちらかというと「これからOSS開発チャレンジしたいけど何をすればいいか分からない」という人向けに、OSS開発を始める一つの「型」としての「プラグイン開発」を提案したいと思います。
筆者のOSS開発スタンス
自分に関して言うと、フルコミットOSS開発をしていたり、有名ライブラリのメンテナをしているというレベルでは全くありません。
あくまで趣味の範囲で余暇に以下のようなことに取り組んでいるという感じです。
- 他の人も使いそうでライブラリとして切り出せそうな処理や関数があればOSSライブラリとして公開してみる
- 仕事で使っていたり気になるライブラリを見つければソースコードを読んだり、Issueを眺めたり、PRを送ったりする
OSS開発を始めたいけど敷居が高そうで何やればいいか分からん問題
そう感じている人は少なからずいるのではないのでしょうか？私も昔はそうでしたし、今もそうかもしれません（有名＆長年続いている＆規模の大きなOSSにIssueを登録するのはいつだって緊張します）。
さて、OSSコントリビューション最初の1歩としてよくオススメされる「型」として「READMEやドキュメンテーション、コメントなどの記述ミスやtypoを見つけたら修正PRを送ってみましょう」というものがあると思います。OSSプロジェクトにおいてドキュメンテーションは大事ですし、そこまで手が回っていないプロジェクトも多くあるのが現状です。こういった貢献から入っていくのはすごく価値がありますし、何より修正の難易度も高くない、かつ自然言語で書かれた文章からスタートできることもポイントでしょう。
だがしかし、やはりコードが書きたい！コードを書いて貢献したい！！と思うのがエンジニアの心情ではないでしょうか。少なからず私はそうです。その場合にドキュメンテーションの次のステップとして何か「型」があるといいなと考えました。そこで「プラグイン開発」です。
プラグインとプラグイン志向なOSSプロダクト
AIによる概要
プラグインとは、既存のソフトウェア（アプリやWebブラウザなど）に後から機能を追加・拡張するための小さなプログラムのことで、「拡張機能」や「アドオン」とも呼ばれ、本体にはない便利な機能（PDF表示、フォーム設置、デザイン変更など）を、個別にインストールして使えるようにするものです。
AIくんの回答をそのまま引用させてもらいました。
さて、世の中にはプラグイン機構、もしくは明確にプラグインとは言っていないがほぼそういった思想をもって設計されているOSSプロダクトが数多く存在しています。また、ここが割と重要なポイントでもあるのですが、筋の良いプラグイン機構を持つOSSプロダクトでは プラグイン開発者が集まる → ユースケースが広がる → エンドユーザーの裾野が広がる → 大きなエコシステムを形成する という機序が発生するようにも感じます。
プラグイン開発から始めることのメリット
なぜプラグイン開発がオススメなのかというポイントをいくつか挙げてみます。
1つの課題に集中することができる
大きな課題領域やユースケースは本体のOSSプロダクトが担ってくれており、それを利用する中で「追加でこういったこともできればいいのにな」と思うシーンがプラグイン開発のスタート地点になるでしょう。「本体に足りない+α」の課題部分だけに集中すれば良いのは開発を始めやすいポイントになるのではないでしょうか。
また1つの課題にのみ集中すれば良いということは実装を小さくシンプルにできるということです。その結果として素早くリリースすることも可能になるでしょう。これも開発を始めやすいポイントになると思います。
エンドユーザーに届けやすい＆使ってもらいやすい
すでにエコシステムとして発達しているOSSプロダクトであるということはそのエンドユーザーがすでに多く存在します。エンドユーザーにとっては全く別の新しくツールを導入するよりもプラグインを導入する方が導入コストは低くなります。つまり自分が開発したプラグインを利用してもらえるチャンスも高いと言えます。
またあるOSSプロダクトのプラグインであれば特定の命名規則に沿って公開されることが慣例的になっているケースをよく見かけます。例えば自分は Ruby をよく使うのですが、rubygems.orgにおいて rubocop- という接頭辞や rspec- という接頭辞を検索することでそのプラグインgemを検索することが容易になっています。
本体OSSプロダクトにも貢献するチャンスができる
プラグイン機構を設計するということは、そのOSSプロダクトのユースケースにおいてプラグインにはどこまで何ができるのかを考えることだと思います。またプラグイン開発の開発体験はプラグインに対してどういったAPIが公開されているのかということにも直結します。つまりプラグイン開発者もそのOSSプロダクトのユーザー形態の1種と考えることができます。
より良いプラグイン機構とプラグインユースケースを実現するためにはプラグイン開発者からのフィードバックも必須だと考えられます。プラグイン機構を持つOSSプロダクトにおいてはプラグイン開発者も重要なロールの一部なのではないでしょうか。
kozy4324のOSSプラグイン開発をふりかえる
プラグイン機構を持つOSSプロダクト事例の紹介を兼ねて、実際に自身が取り組んできたOSSプラグイン開発をふりかえってみます。
Gruntとgrunt-concat-sourcemap
GruntはJavaScript製のTask Runnerですね（なつかしい）
WebpackもTypeScriptもまだまだ無かった頃の話です。複数のJavaScriptを連結(concat)して1ファイルとして配信していた時に、今や当たり前にあるSourceMapも後発として生まれました。単純にファイルを連結する機能はGruntに最初からありましたがSourceMapは解決してくれません。無いなら作るかとなったのがこのgrunt-concat-sourcemapです。
initial commitを確認すると今からもう12年以上も前です。コード量は100行ぐらいのJavaScriptファイルが1つのみです。コンパクトですね。
https://github.com/kozy4324/grunt-concat-sourcemap/blob/master/tasks/concat_sourcemap.js
その時のニーズにマッチしたのか50スターほど付けてもらいました。なお余談ですがSourceMap解決ロジックがバグっており少し複雑なケースでSourceMapがぶっ壊れます。
1つの課題に集中できたので素早くリリースできたプラグインだったなぁと思いつつ、concat時のSourceMapは本体機能でちゃんと解決されるようになったのでお役御免ということでarchiveとなりました。
JasmineとJasmine-TAPReporter
JavaScriptテスティングラインブラリであるJasmineのReporterプラグインを作っていました。これのinitial commitはさらに古く14年も前だった。実装を見たら「おお！CoffeeScript CoffeeScriptじゃないか！久しぶりじゃないか 元気にしてたか」という気持ちになりました。これも100行程度のスクリプトファイルが1つでコードサイズもコンパクトなものになっています。
https://github.com/kozy4324/Jasmine-TAPReporter/blob/master/src/tapreporter.coffee
RuboCopとrubocop-oneoff_codemod
RuboCopのプラグインを作りたくて作ってみました。TSKaigi 2025の基調講演でAnthony FuさんがESLint Plugin Commandというやつを紹介していたのですが、
「カッコよ！それRubyでもできんかな？」と思ってRuboCopのプラグインとして作ってみたというやつです。PoCレベルの実装だけして「似たようなことできるやん！」で満足して放置してしまっていますね（良くない）。アイデア思いついてからgemとして公開するまで1日ぐらいしか経っていません。そういったスピード感でリリースまでいけるのはプラグイン開発のオススメしたい点だと思います。
これも一つ一つのcop（RuboCopのpluginの単位となるもの）はコンパクトになっているのでソースコードリンクを掲載しておきます。
RubyLSPとruby-lsp-rake
Shopifyが開発しているRubyLSPにもプラグイン機構があります（ドキュメント上は Add-on とありますが、この記事中は全て「プラグイン」という概念でまとめさせてください）
ドキュメントページがしっかりと整備されておりRubyLSPの仕組みを理解したいなと思ったのでプラグインを作ってみたという流れのものです。
本体のRubyLSPに比べると小さい実装にまとまっており、これぐらいなら自分でも作れそうと思ってもらえれば良いなという事例として紹介してみました。
ruby-lsp-brakemanへのPR
RailsのセキュリティスキャンツールにBrakemanというものがあります。
Brakeman: Brakeman Security Scanner
このBrakemanのRubyLSP Add-onが作られていました。その名もruby-lsp-brakeman
GitHub - presidentbeef/ruby-lsp-brakeman: Ruby LSP Addon for Brakeman
このBrakemanのAdd-onですがソースコードのエラー箇所をLSPとして表示してくれます。ですがソース位置を表す情報として行情報しかなくカラム位置情報がありません。なんとかうまいことカラム位置を含められないものかと思い修正を検討しようと思いましたが、修正するにしてもまずはテストないと修正はキツいだろうなということでテストを追加するPRを送ってみたというのがこちらです。
ruby-lsp-rakeを自作して得た知見を展開してみるムーブをかましてみました。なお肝心のカラム位置情報の追加ですが、Brakemanが扱うASTにそもそも具象情報としてのカラム位置が欠落しており、Add-onじゃなくてBrakeman本体をなんとかしないと無理では...となって頓挫しています。現実はなかなか厳しい。
自分でプラグインを開発するだけでなく、他のOSSプラグインに対してコラボレーションするというOSS開発スタイルもあるよねということで事例紹介してみました。
まとめ
プラグイン開発のオススメポイントを説明させてもらいました。またその具体例として自分が過去に行ってきたOSSプラグイン開発の事例を紹介してみました。紹介した事例の本体OSSプロダクトは有名どころだったり長年続いていて規模の大きなコードベースのものばかりですが、そのプラグイン開発であれば本体に比べて敷居が低く見えたのではないでしょうか？またプラグイン機構（もしくは似たような設計）を持つOSSプロダクトの一部を紹介させてもらいましたが、そういったOSSプロダクトが世の中に多くあることも多少は伝わったのではないでしょうか。
少しでも「このやり方だったら自分でもOSS開発にチャレンジできそう」と思ってもらえたなら幸いです。この記事を最後までお読みいただきありがとうございました。
さいごに: 東葛.devと私
東葛.devのAdvent Calendarなのでさいごに東葛.devの紹介をしておきます。東葛.devは東葛地区中心のIT/Web技術コミュニティで定期的なオフラインイベントやDiscordなどでワイワイやっています。
私個人としての参加モチベーションはこの記事で紹介させてもらったようなOSS開発にまつわる活動や事柄を会話したり相談したりしたいなぁというものがあります。この記事を読んで同様な興味・関心を持ってもらえたならば東葛.devの方もぜひのぞいてみてください。よろしくお願いします！
