8月12日: 多様性と統一性

開発会議の様子

Yamaguchi Mini Maker Faireも終了し、静けさの戻ったYCAM。開発作業も佳境に入ってきました。朝から開発メンバー達は黙々とコーディングを進めていきます。昼前にはメンバー全てがYCAMアトリエに集結。

今日から様々なトピックスについて全員で話し合い、今後の開発の方向性の意思統一をはかります。openFrameworksのベースとなっているC++には数多くの機能が備わっていて、どういった機能をとりこんでいくのが効果的かというのを検討するにも膨大な知識と判断が必要となります。さらに、openFrameworksには2Dや3Dの画像、音声、動画、フォントなどのための多くのライブラリを統合しているため、それら全てに関して今後の方向性について考えていかねばなりません。C++自体の進化や、それぞれのライブラリーの進化、さらには全く新しい機能をどのように取り込んでいくのか、検討することは山のようにあり、なかなか大変な作業です。

この日話し合われた内容の概要は、だいたい以下のようなものでした。

C++11への対応

openFrameworksのベースとなっている言語C++自体も日々進化しています。2011年にC++11という最新のISO標準が策定され、コア言語への機能追加や標準C++ライブラリの拡張などが行なわれました。そうした中で、以下のようなトピックスについて話しあわれていました。

よりシームレスな複数のプラットフォームへの対応

openFrameworksは、Mac OS X、Windows、Linuxだけでなく、iOS、AndroidなどのモバイルOS、さらに最新版のv.0.8.0ではRaspberry PiなどのARMプロセッサを搭載したシングルボードコンピュータへの対応するなど、対応するプラットフォームが多岐にわたっています。多岐にわたるプラットフォーム間での差異を極力感じさせることなく、さらにその機能を最大限発揮させるには、様々な検討する必要があります。

マルチウィンドウ化と、グローバルな状態の保持

現状のopenFrameworksでは、基本的には1つのウィンドウしか扱えません。複数ウィンドウを同時に扱えるようなアプリケーションを開発できるようにするにはどうすれば良いのか、様々な技術的な問題点、改善すべき箇所などが検討されていました。

名前空間

openFrameworksの機能が多機能になるほど、異なるカテゴリーでのメソッド(関数)や変数の名前が被ってしまい、うまく命名規則を策定していかないと様々な問題を引き起してしまいます。名前の衝突の可能性を低減するために、名前の集合を分割する「名前空間(Namespace)」の概念を導入して、類似する名前を区別する手法について検討されました。また、関数名自体の命名規則もより明確にすべきということで、そのルールについて細かな議論が行われていました。

アドオン

openFrameworksのコアを拡張するための機能、アドオン(Addon)の今後についても検討されました。

ドキュメント

openFrameworksのドキュメント資料は、まだまだ十分とはいえません。また、その管理もofSiteという別リポジトリでBlogofileというシステムで管理されていて、あまり更新がやりやすい仕組みにもなっていません。さらには、今後さらにコミュニティーを拡げていくためには、日本語を始めとした様々な言語に対応する「多言語化」も大きな課題です。今後のドキュメントの管理の方法についても多くの議論が行われました。

議論の中で感じたこと

今日の議論は食事や作業を挟みつつも、朝11時くらいから夜の9時くらいまでかなり長期にわたるものでした。なかなか議論の中に入ることは大変だったのですが、同じ場にいて感じたことなどを書いてみます。

一人で占有して喋り続ける人は居らず、また強権的に否定する独裁的なこともなく、とても民主的な雰囲気。お互いがそれぞれをリスペクトしている雰囲気が伝わってきました。

感心したのは、議論の進めかたとその記録について。議論のアジェンダとアウトラインはあらかじめGoogle Driveの書類として共有されていて、議論の最中もその書類を色々な人がどんどん書き込んでいく。複数のカーソルが飛び交い、リアルタイムに議事録が作成されていく仕組み。このやり方は様々な場所で応用できそうなので、今後の参考にしてみたいと思いました。

「openFrameworksとは」という問いに対して「様々な機能を繋ぎあわせる『糊』のようなもの」というたとえが用いられます。これはopenFrameworksの本質をよくあらわしている説明だと思います。しかし、糊だからといってただ闇雲に雑多な機能を貼り合せるだけでは、ただの醜い塊になってしまいます。openFrameworksの優れた部分は、多くの機能を貪欲にとりこみつつも、きちんとそれらを統一された方針で整理して、誰にでもすぐに理解できるように翻訳して提供している部分にあると思います。糊の例えでいうと、同じ糊でも用途に応じて「良い糊」と「悪い糊」があり、それを適切に使用することで元の素材の機能を殺すことなく、openFrameworksのコアにとりこむことが可能となります。その作業は一見簡単なようで、実は多くの仕組みについての深い理解がなければ不可能なことであり、またきちんとした意思統一がなされていないと破綻してしまう繊細な作業なのだということが、話し合いの場にいて感じられました。

また、openFrameworksの開発としてよくいわれるキーワード「DIWO (Do It With Others)」というものも、この場にいるとその本質が見えてきたような感じがします。Zach Liebermanさんや、Theo WatsonさんなどopenFrameworksにはその初期の開発から携わるコアなメンバーが存在します。だからといって彼らが独裁的に全てを決めているわけではなく、そのコミュニティーの運営はとても民主的です。今回の開発者会議では、Kyle McDonaldさんが全体をうまくモデレートし、大勢の意見をくみとりながら会議を運営している様子が印象に残りました。

開発スピードや機能のユニークさを追い求めるのであれば、独裁的に開発する場合の利点もあるのかもしれません。しかし、openFrameworksの目指すものは、一部にだけ尖ったものを追求するのではなく、多様な機能を包括する万能ナイフのようなものなのだとすると、独裁的な開発体制とは馴染みが悪いのかもしれません。

世界中を舞台とした集団的な開発は、Gitを始めとするネットワーク前提として様々な技術があって始めて可能となったものでもあり、開発の手法といった観点からみても、openFrameworksのコミュニティーは面白い存在と思いました。