KMC活動ブログ

京大マイコンクラブの活動の様子を紹介します！！

YAPC::Asia Tokyo 2015に参加しました #yapcasia

イベント

皆さんこんにちは。KMC-2回生のid:hnagaminです。 8/20-8/22に東京ビッグサイトで開催されたYAPC::Asia Tokyo 2015に参加してきたので個人的な参加の記録をここにシュッと書きます。 yapcasia.org

シュッ

0日目(前夜祭)

お昼くらいに新幹線で京都から東京に向かって夕方頃KMCのメンバーと合流した。 この日は前夜祭だった。ビール飲んでる人がたくさんいたけど残念ながら当日はまだ成人していなかったので無限に水とお茶を飲んでいた。 yapcasia.org

タイトル通りOSS(Open Source Software)製品を開発したりOSSコミュニティを育てたりするときの心構えというか、行動規範みたいなのを解説している。前夜祭のこの発表がYAPCを通じてずっと印象に残ってて、それは今でも続いている。この記事の最後に今思ってることをちょろっと書く。

OSSを育てる

開発方針を明確に知らせる。OSSが発展するためにはより多くの開発者から貢献してもらう方が大抵良いのだけど、開発者が投げたpull requestをどんなプロセスで評価して本体に取り込むのか、誰かが提起したissueをどう処理するのか、そういう方針をちゃんと示しておくと貢献のハードルが下がって良い。 そしてとにかく英語を使う。世界の開発者の多くは日本語が読めないので日本語でドキュメントやコミットコメントを書くとそれだけでターゲットを絞ることになる。また、英語で開発に関する議論がされているという状況を見せるのは、世界中の開発者に対して「あなたのcontributionはちゃんとレビューされますし受け入れられますよ」っていうメッセージになる。

OSSコミュニティを育てる

OSSのユーザーや開発者がつくるコミュニティが大きいと良いことがいっぱいある。 そもそも多くの人に使ってもらいたいからOSSにするというのももちろんあるけど、コミュニティがしっかりしてると導入事例をたくさん蓄積できるし、製品を洗練させたり新しい機能を追加したりできる。 多分この辺のメリットっていうのは相互に密接に関連してて、contributionが活発だと安心して(放置されてないんだなと思ってもらえて)導入してもらいやすいとか、導入事例が蓄積すると製品の改善点が明確になるとか、そういう相乗効果があるんじゃないかと(個人的に)思う。規模は強み。 そしたら、どうすればコミュニティを育てられるか。講演では特に開発者が作るコミュニティの育て方について話してうた。前節と被る部分も少しあるけど、

  • ちゃんと使えるが、発展の余地もあるという現状を見せる
  • contributionのプロセスを明確にする
  • プラグインで機能を追加できるようにする

などを行うとコミュニティの発展にすごく良い。これは講演で話されてた事項のごく一部でしかないのでぜひリンク先の動画も見てください。 個人的に面白いなと思ったのはプラグインを導入するというもの。「プラグインがあるとユーザーコミュニティが開発者コミュニティの性格を帯びる」という指摘をしててああ確かに、と思った。

でも結局結論として良いOSS製品を開発するには継続的な努力しかない。らしい。そこはやっぱり積み重ねでどうにかするしかないのかな。

1日目

まつもとゆきひろを初めて生で見て驚いて「すごい！目の前にいる！」ってなった。周りの人が全然「すごい！目の前にいる！」ってなってなかったのでそのことにも驚いた。皆大人だ。

この日は発表もした。これについては PietでLISP処理系を書くのは難しい - YAPC::Asia Tokyo 2015とかLisp.PNG - hnagaminとかを参考にしてください。

yapcasia.org

WebAudioの紹介、そしてWebAudioをただの音声の提供に使うのではなく信号処理に使っちゃおうぜという試み。

前半ではWebAudioの提供する機能をいい感じに紹介している。 WebAudioの提供するインターフェースはたとえば信号源とフィルタをケーブルで繋げるとかそういう処理をしてて、すごくオブジェクト感が高い(オブジェクト感が何を指すのかよく分からないけど、とにかくオブジェクト感が高い)と感じた。ソースコードがそのまま実験手順書みたいになっている雰囲気。 オブジェクトとして提供した方がスマートな実装になるのかな。

そして後半は信号処理の基本的な知識とWebAudioによるモデムなどの実装、今後期待される応用について。本当に面白い。とにかく動画で見てほしい。 モデムの動作デモを行ったときは会場が一体感に包まれてて良かった。

僕は電気電子工学科に所属していて、(一応)電気系を専門にしているので、変調とか波形とか単語が出るたびにすごく高まっていた。 講義で習ったときは、交流の電気信号を周波数ごとにいい感じに制御する目的でハイパスフィルタとか色々なものを説明されたんだけど、確かに音も信号だし周波数ごとにいい感じに制御できるねと当たり前のことに一人で納得していた。 WebAudioを使ってWebができることはすごく幅広そう。夢が広がる。

2日目

yapcasia.org Node.jsとそこからforkしたio.jsの歴史を解説しながら、2つのプロジェクトの開発やメンテナンスの方針の違いを紹介してる。

もともとNode.jsは優しい独裁者モデル(BDFL)という開発方法を採用していた。 これは中心となるリーダーをプロジェクト内に1人すえてissue管理とか開発とかをやってくモデル。 たぶんBDFLだとチームで意思決定するよりもフットワークが軽くてプロジェクト全体の一貫性も保ちやすいみたいな利点があるんだろうけれど、Node.jsの場合はリーダーが変わっていくうちにうまくいかなくなりcommitも停滞してしまった。さらにNode.jsに求められるものが増えてきて、特に最先端の機能を求めるユーザーと安定性を求めるユーザーの間に溝が生まれた。

この状況を打開するためにio.jsはBDFLではなくオープンガバナンスモデルを採用した。 オープンガバナンスモデルにはBDFLと違い明確なリーダーが存在しない。代わりに十数人のコアとなる開発者が緊密に連携してissue管理とかメンテナンスとかをする。さらに目的別に色々な部門を作って(webサイトを管理するとか)各部門ごとに活動する。またio.jsを発展させるたびに互換性が壊れていないかなどをちゃんとチェックして正しいバージョニングを行う機関もある。「まるで政府」って言ってたけど本当にそうだと思う。大きい製品だからこそこういう開発形態がうまく機能するのかな。

結果としてio.jsの刺激を受けNode.jsの開発方針がしっかり定まって、Node.jsに求められてきた色々なものに答えること(io.jsで先端の機能を提供し、Node.jsで安定した環境と長期サポートを提供するとか)ができるようになった。YAPCが終わってからこのブログを書くまでにNode v4.0.0が公開された。めでたい。OSSの理想的な開発形態だなと思った。

OSSのあり方みたいなの

YAPCに参加してから、抽象的なテーマだけどOSSでどうやってプロジェクトを進めていくかみたいなのがすごく気になってる。 オープンソースっていうのはただプログラムを誰でもアクセスできるような場所に置くことだけを指してるんじゃなくて、ちゃんと使ってもらうためにドキュメントをしっかり書いたり外部の人のcontributionや議論をスムーズに受け入れられるような環境を作っておく、そういう努力を全部含めてオープンソース活動っていうんだと思う。 翻って自分の行動を考えてみると、書いたプログラムは1995hnagamin (Hideaki Nagamine) · GitHubで公開してるものの、ライセンスがなかったりREADMEが雑だったりしてうーんあんまりよくないですねという感じ。動けばいいや的価値観の人間だ。 良くない例

もちろんGitHubにある全てのパブリックリポジトリがOSSという訳ではないんだけど、自分ではない他の誰かに使ってもらえたら嬉しいなっていう気持ちがあるのならドキュメントとか、issue管理とか、そういったプログラム以外のコンテンツを充実させるのはすごく生産的なことだと思う。

最近はとりあえず(tagomorisさんも前夜祭の発表でめっちゃ強調してたけど)コミットログやissueをできるだけ英語で書くようにしてる。 ほかにもドキュメントちゃんと書いたりテスト設置したりしたいなとか考えてるけどあんまり進めてない。考えてるなら実践しろという感じだけど。 時間かけて行儀の良いリポジトリを増やしていけたらいいなあ。