RubyKaigi 2026 に出したProposalが不採択になったので出したProposalを公開します。
Your proposal for RubyKaigi 2026 has not been accepted 🥺
— sue445 (@sue445) 2026年2月28日
あとで不採択Proposalの供養します... pic.twitter.com/HljihDm9k6
出したProposal
Title
Managing 100+ repositories with OSS
Abstract
I'll talk about an OSS tool I built specifically to maintain a massive number of other OSS repositories.
I currently maintain 80+ OSS repositories. Including private ones, that's 100+ repositories in total, spanning various languages like Ruby, Go, and Terraform across both https://github.com/ and https://gitlab.com/ .
For example, every year on December 25th, a new version of Ruby is released. Even a simple task like adding the new version to the build matrix requires updating nearly 50 different repositories.
To solve this kind of tedious "grunt work"—or what we in Japan call "sashimi tanpopo"—I created https://github.com/sue445/sashimi_tanpopo .
In this talk, I’ll introduce this tool and the ecosystem of utilities I’ve built to streamline these tasks.
日本語（Geminiで英訳＆添削する前の原文）
大量のOSSをメンテするために作ったOSSの話をします。
私は現在80個以上のOSSをメンテしています。プライベートリポジトリも含めればメンテしているリポジトリは100個を超えます。言語はRubyやGoやTerraformなど様々です。管理してるリポジトリもGitHubとGitLabに分かれています。
毎年12月25日には新しいRubyのバージョンが出ますが、各gemのリポジトリのビルドマトリクスに新しいRubyのバージョンを追加するだけでも50個近いリポジトリを編集する必要があります。
このような刺し身タンポポ作業を解決するために作った https://github.com/sue445/sashimi_tanpopo やその関連ツール群について話します。
Detail
https://github.com/sue445/sashimi_tanpopo というgemを作った話をします。
アウトラインはこういうのを考えてますが変わるかもしれません。
- なぜ作ったか
- 自分の日々のOSS活動について
- DependabotやRenovateだとダメな理由
- sashimi_tanpopoの前身になった https://github.com/sue445/ci-config-itamae や https://github.com/sue445/myapp_version_upgrader について
- 言語やライブラリの採用理由
- なぜRubyを採用したのか（なぜGoを採用しなかったのか）
- なぜ https://github.com/itamae-kitchen/itamae を使わずに独自DSLを作ることになったのか
- 独自DSLの実装話
- gemを各種CIで使いやすくするために作った https://github.com/marketplace/actions/sashimi_tanpopo_action や https://gitlab.com/explore/catalog/sue445/sashimi_tanpopo-components について
- sashimi_tanpopoのあるOSS生活と実践的活用例
https://sue445.hatenablog.com/entry/2025/10/26/121451 に書いたことがベースになりそうですがブログ公開から時間が経ってそれなりにsashimi_tanpopoを活用してきたのでその辺の知見も話せると思います。
sashimi_tanpopoだけだと時間が余りそうな気がするので、時間が許すなら複数のリポジトリでコピペしまくってたGitHub Actionsのworkflowファイルを一元管理していい感じにした https://github.com/sue445/workflows についても話そうかなと思ってます。
Pitch
OSS活動をしてる人には大きく分けて「1つor少数のOSSを深く狭くメンテするタイプ」と「たくさんのOSSを浅く広くメンテするタイプ」の2種類がいると思っています。
私は後者のタイプです。浅く広くと言っても自分の代表作の https://github.com/sue445/rubicure は毎年新機能を追加しつつ10年以上コツコツメンテしてます。
前者の人の話はRubyKaigiなどでもよく聞きますが、後者の人の話はあまり聞かない気がします。
たくさんのOSSをメンテする人にはその人なりの問題があるので https://github.com/sue445/sashimi_tanpopo を作って解決しました。
たくさんのOSSをメンテしてる人にしか分からない苦労を共有しつつ、自分のようにたくさんのリポジトリをメンテしてる人やチームに解決策を持ち帰ってもらおうと思っています。
また、Detailにも書いた https://github.com/itamae-kitchen/itamae は僕がメンテしてるOSSの1つなので、内部実装やメリデメを熟知してます。
Itamaeのメンテナ自ら「こういうケースではItamaeは向かない（だからこそ再実装する必要があった）」ってのは説得力があると思います。
