Publickeyが紹介した、Redditの「[whining] Ruby evolution is taking TOO long」に対するまつもとゆきひろ氏のツイートを読んだ。僕はRubyistではないのでRubyについては何も言えないが、最後の部分には触れておきたい。

「ではどうすることがコアチームの負担を軽くし、より貢献できるのか？」との問いがあり、まつもと氏は具体的な方法として次のように返答しています。（Rubyのまつもと氏、「気分を害することもある。だからどうか建設的であってほしい」 － Publickey）

まつもと氏のリプライしたことはこうだった。RubyのRedmineトラッカーに課題提起（Issue）や提案（Proporsal）を書くこと、Githubにプルリクエストを送ること、開発者ミーティングのイシューとしてコメントすることでリマインドしてくれること（この三つは順不同）。

企業のプロジェクトがそうであるように、オープンソースプロジェクトも有限のリソースで活動している。ただ、そのリソースは個々人の持ち寄った作業時間で、その出どころは個々人の生活時間だ。だからプロジェクトが無理なく捻出できるリソースを超える負荷をかければ、プロジェクトか、参加者の生活か、どちらかが壊れることになる。プロジェクトを大切に思う人が増えるほど、その人たちは生活を犠牲にしかねないから、まつもと氏はこうつぶやいているのだと思う。

私たちはみんなに黙っていて欲しいわけではない。意見はつねに聞いている。しかし私たちはただの人間であり、気分を害することもある。だからどうか建設的であってほしい。私たちの生活を壊さないで。（Rubyのまつもと氏、「気分を害することもある。だからどうか建設的であってほしい」 － Publickey）

ではなぜそれが投稿内容についての話ではなく、Redmine上でのイシューまたは提案、Github上でのプルリクエスト、開発者ミーティングでのリマインドという「手続き」「手順」の話になるのか。それは、それがコミュニティが参加者全員の「全体最適」を目標に導入した手順だからだ。もっと平たく言えば、決まった手順があることは外部の人にはとっつきにくいけど、そのかわり手戻りとか重複とか衝突とかでムダを生まないので、みんなの持ち寄った作業時間でコスパよく物事を進められるからだ。

その課題提起だか提案が「[悲報] Rubyの進歩はあまりにも遅すぎる」と題されていても、その内容がMatz（まつもとゆきひろ氏）が優しい独裁者として一人だけで変更提案の決済をしているとボトルネックだから数人のコンソーシアム制にしようというものでも構わない。ただそれをコミュニティに参加して、コミュニティの手順でやってほしい。

それはホーム（提案者にとってはアウェイ）に来いと言っているように聞こえるかもしれないけど、そうじゃなくてコミュニティのリソースをムダ遣いしないようにしてほしいということだと思う。コミュニティのコスパを損なわないこと、そのためにコミュニティの流儀（とツール）を身につけることは、それ自体が「建設的」なのだ。そのコストを払わないことは、コミュニティにコストを押し付けるフリーライドである、ということかもしれない。

僕はいま、Githubで業務が回っている会社に入ったので、GitとGithubの基本を勉強している。この会社では、セールスやマーケティングチームの人も、経営層も、Githubに参加する。Githubを見ればわかることを、経営者やセールス、マーケターのために開発者にエクセルやワード文書化させることは、開発者のリソースへのフリーライドだと思われているようだ（ただし自分でできるようになるために教えを乞うことはするし、歓迎される）。

それは僕の会社では技術力が会社の強みで、開発者のリソースが大切だと考えられているからだと思う。ではRubyコミュニティの主要プロダクトはなにで、そのためのコミュニティにとって大切なリソースはなんだろう？開発者の作業リソース？それとも優しい独裁者Matzの作業リソース？どちらも、これをムダ遣いしたりコスパの悪い使い方をしないために、まず必要なのはコミュニティの流儀（とツール）で提案をすることだと思う。ただそれだけで、それは「生活を壊す」ことから「建設的」なことに変わるんだ。