NaCl東京支社の早川です。
Rubyエコシステム開発入門ワークショップが2026年8月5日(水)に開催されました。
本社から前田が、東京支社からは後藤、早川が参加しました。
前田、後藤がサポーターとして、私はビギナーとしての参加です。
この記事はRubyエコシステム開発入門ワークショップの私視点での参加レポートとなります。
今回の会場は株式会社ギフティさんの本社の一室でした。
Rubyエコシステム開発入門ワークショップとは
「Rubyエコシステムの開発に参加する」を実際に体験するワークショップです。
Rubyアソシエーションによる情報発信の一環として、OSS Gate協力のもと企画・開催されました。
ワークショップでやること
簡単に言うと、『OSSのREADMEを読みながらインストールして、気になった点をフィードバックとして送る』です。
バグを発見したり、コードを修正したり、新機能を提案したり、難しいことを求められているわけではありません。
OSS貢献の第一歩は、「ドキュメントをちょっとだけ良くできないかな？」から始まります。
全体の流れ
当日の全体の流れは以下のような感じでした。
- OSSの説明
- 作業の準備
- 対象OSSを決める
- フィードバックする内容を考える
- 昼食
- ふりかえり・チームでやったことを共有
- 実際にフィードバックする
- 発表
- スポンサーLT・お知らせ
- 生成AIの話
- アンケート
- 懇親会
OSSの説明
OSSとは？
初めに、OSSとは何かという説明がありました。
OSS(Open Source Software)とはOpen Source Initiative（オープンソース・イニシアティブ、略称: OSI）の承認を受けたライセンスで配布されているソフトウェアを指すということでした。
OSIの承認にはOSIの定義した『オープンソースの定義（OSD）』に準拠する必要があります。
RubyはOSSじゃない？
Rubyが採用しているRubyライセンス（Ruby's License）はOSIの承認申請をしていません。
ではRubyはOSSではないのかという疑問がわきます。
実はRubyはRubyライセンスと2条項BSDライセンスのデュアルライセンスです。
2条項BSDライセンスはOSIに承認されているので、RubyはOSSということになるそうです。
RubyライセンスはOSI承認申請しないのか？
Rubyライセンスは以下の事情から、あえてOSI承認申請をしていないそうです。
- RubyライセンスはPerlのArtisticライセンスをベースに作られていてArtisticライセンス同様の問題があるため、一般的なソフトウェアでの使用を推奨していない
- デュアルライセンスの2条項BSDライセンス(1.9.2以前はGPLライセンス)がOSI承認されていて実用上の目的は達成されている
参考:
[OSS]RubyライセンスとOSI承認 - Matzにっき(2003-06-07)
作業の準備
作業ログをつける
初めにOSS Gateのリポジトリに作業ログ用のIssueを立てます。
作業中は自分が何をしたか、何に詰まったか、何ができたか、何ができなかったかという作業ログをこまめに残します。
対象OSSを決める
興味のあるOSSを選ぶ
今日フィードバックを送る対象を決めます。
基本的に自分が興味のあるRuby関連のOSSなら何でもOKです。
Ruby、PicoRuby.wasm、Hanami、Kaminariなど、参加者によって選ぶものが全然違って面白かったです。
対象がOSSであることを確認する
対象のリポジトリでOSSであることを確認します。
LICENSEファイルやREADMEに記載されていることが多いようです。
フィードバックする内容を考える
READMEを読みながらインストールする
対象が決まったら、フィードバックする内容を考えます。
まずはREADMEを読みながらインストールしてみます。
READMEのとおりに進めてもうまくいかなかった、わかりづらかった点があればそれがフィードバックの種になります。
インストールがうまくいっても、README自体をより良くする方法が見つかることもあります。
例えば、サンプルコード内の変数名が一貫していない、改行位置がずれているといった内容です。
昼食
ここまでの作業で前半が終了しました。
参加者同士で誘い合ってお昼ご飯を食べに行きました。（写真を撮り忘れましたが、私は焼き肉を食べました！）
食事中は来年のRubyKaigiについてやRailsアップデートが大変な話などなど、Rubyトークが盛り上がりました。
ふりかえり・チームでやったことを共有
前半で何をしたか、どういう風にフィードバックしようとしているかなど、同じテーブルのメンバーに共有します。
参加者の多くが「フィードバックする内容としてふさわしいのか？」「こんなこと言ったら失礼では？」という不安を感じているようでした。
「こういう言い方なら歓迎されそう」「そこは好みの問題かもしれない」など周りの意見を聞くことができ、サポーターからもお墨付きをもらえるので、「じゃあフィードバック送ってみるか～」となります。
初心者にとってこの背中を押してもらう時間がとても重要だと感じました。
実際にフィードバックする
Issueを立てる、PRを出す
チームの意見を聞き、フィードバックする内容が決まったら、Issueを立てたりPRを作ったりします。
PRを作るときはフォークしたリポジトリにプッシュしてPRを作るという流れになるのですが、forkボタンを押したことがないという方も多かったようです。
IssueやPRの内容もサポーターが最終チェックしてくれますが、最後にCreateボタンを押すときはみんな「本当に押していいの！？」とドキドキしていました。
発表
どんなフィードバックをしたか
短い休憩を挟み、実際にどのような内容をフィードバックできたかを数名が発表しました。
なんと発表の時点で既にマージされていた方がいました。
小さなドキュメント修正でも歓迎されていることを感じることができました。
スポンサーLT・お知らせ
ギフティさんによるスポンサーLTと北陸Ruby会議2のお知らせがありました。
会場を提供いただいたギフティさんには大変感謝いたします。
生成AIの話
須藤さんによる、生成AIとOSSのお話がありました。
OSS活動でAIを使うのならば意識すべきことがあるという主張でした。
大まかに分けるとポイントは3点です。
- AIの出力した内容はまず自分でレビューし、理解する。
- AIの出力した報告やPRは冗長で大きくなりがち。見る側に負担をかけるので丸投げしない。
- 開発チームの一員として振舞う。
特に重要なのは『開発チームの一員として振舞う』ということだと感じました。
AIに開発を丸投げして、PRのレビューはメンテナーに任せる。返ってきたレビューをまたAIに投げる。
これではメンテナーにAIの相手を任せているだけで、チームの一員として活動しているとは言えません。
『メンテナーはAIではなく、PRを送ってきた人の意見、考えが聞きたいんです』という須藤さんの言葉もありました。
PRを送る側も受け付ける側も、お互い気持ちよく開発するための大切なマナーだと思いました。
アンケート
今回のワークショップについてアンケートを記入しました。
記入したアンケートについて、どうしてそう思ったか、どうしたら良くなるか、という議論がされました。
懇親会
ワークショップ終了後に懇親会がありました。
ギフティさんの会場で飲み物や軽食が用意され、当日の感想や地方のカンファレンス事情などの話が盛り上がりました。
感想
私自身もこれまでOSS活動をしていましたが、Rubyエコシステムにコントリビュートすると聞くと身構えてしまう部分がありました。有名なライブラリはすごい人たちがすごい会議の末にすごいコミットをしている、みたいなイメージがあり、近寄りがたかったのです。
ワークショップに参加してみて、Rubyエコシステムと言ってもそんなにハードルの高いものじゃない、貢献は小さなことから始められると気づくことができました。
私が今回出したPRはまだメンテナーからのレビューはいただいていませんが、今後も積極的にIssueを立てたりPRを出したりしてRubyエコシステムに貢献していきたいと思います。