オープンソース活動にフィードバックは必須だ。

ここで言うフィードバックとは，バグを修正してその内容を配布元に報告したり，なにか新しく開発してそのソースを配布元へ提供するだけではなく，もっと広い意味で使っている。感想を言う，改善の意見を言う，バグ・トラブル報告をする，導入事例を報告する，開発だけでなくデザインを提供する，といったあらゆる配布元へのアクションをフィードバックと言っている。

しかしながら，配布側もほとんどの場合ボランティアなので，配布パッケージを開発して提供することで手一杯となり，フィードバックを受けやすくするWEB環境を整えるところまで至らないことが多いように思う。公開掲示板はサポート掲示板として多く見かけられるが，公開された場に書き込むのはなかなか勇気の要るものだし，そういった場ではより本音に近い意見や小さなフィードバックはなかなか出てこない。

Geeklogの場合にはSNSを導入しているので，どういったひとが日々どう活動して，どういう悩みをもっているのか，どんな気づきがあったのかが自然にわかるしくみになっており，コミュニティはいくつも立って，日々いろんな開発がそれぞれ自発的に生まれてきている。

ドキュメントはWikiを導入して，ユーザにも参加してもらっている。なにか成果がでれば，配布サイトのダウンロードセクションに直接ファイルをアップロードして公開してもらうなど，比較的簡単にいくつもの方法でフィードバックできるしくみを提供している。

そういうフィードバックを十分行える場作りができていないオープンソースの場合にフィードバックできないというのもあるだろう。

また，そもそも提供側も元は単なるユーザだった。 ユーザの裾野が広く，個々のユーザにフィードバックできるだけの時間的ゆとりや経済的ゆとりが十分なのか。ソースを公開できるほどの開発能力を持った人材なら十分社会的にも尊重されて経済的にもゆとりを持ててよいはずだと思うのだが，どうもそういう環境には無いようだ。

会社は年功序列，あるいは職務階級により，本人の能力にはほとんどの場合関係ない。いかに社内で上の位置に登るか入社とともにスタートダッシュしなければならない。

オープンソースが日本でより活用されるためには，オープンソース配布元のフィードバック受け入れ体制とともに，フィードバック側の個々のユーザ，多くは開発者なのだが，彼らの社会的基盤が必要なのではないかと思うのだがどうだろう。

だが，そういう自然発生的なオープンソースコミュニティにはぬるいところが必ず出る。

日本で成功しているのは，オープンソースをビジネスの商材として活用している会社が本腰を入れて提供している場合が少なくないだろう。Geeklogもわたしの会社の一番の商材なので，クライアントからの厳しいバグチェックを日々受けながら配布パッケージを開発しているが，もっとも力を入れているのはコミュニティの運営とフィードバックの反映だ。コミュニティで無尽蔵のフィードバック力を最大限活かしてGeeklogに貢献していくことだ。

企業がオープンソースの配布元になっている場合，コミュニティ運営によるフィードバック体制の充実により注力しなければならないのかもしれない。

前回「苦悩するオープンソースコミュ運営」をテーマにしたが，日本でまともなコミュニティ運営がなされているオープンソースは，実は数えるほどしかないのではないか。他のオープンソースのリーダやコア開発者から，オープンソースのイベント等での雑談で直接聞いた中では，ほとんどの団体で，「えっ！」と驚くような運営実体だった。

もちろんうまくいっている団体もある。

Ruby関西は毎月勉強会が開かれているそうで，いつも盛り上がってセミナーも大盛況だが，それはオープンソース自体に魅力があって，しかも運営者の努力とあいまって盛り上がっているように思う。Geeklogもセミナーやオフ会を頻繁に開いて，コア開発者が各種CMSに関わりつつもGeeklogを選んで大変な開発協力をしてコミュニティが盛り上がっている。素材の良さと運営の努力双方があわさって，理想的なコミュニティ運営になる。

重要なのは，盛り上がっている団体というのは，オープンソース自体の良さ，運営努力，この２つが両方ともうまくいっている団体だということだ。

オープンソース自体の良さだけではただ良いように使われるだけでフィードバックが疎かになる。コミュニティとしての動きができない。

一方，運営努力だけでは良い開発者が集まらない。良い開発者というのは， 同類のCMSをよく知っていながら，そのオープンソースを選んで積極的に貢献しようとする開発者だ。もし他のCMSを知って，そちらが良いと思ったら，いとも簡単に歯抜けのようにそちらへ流れていくはずだ。

オープンソースのコミュニティは，コミュニティを軸に，サポートしあったり，オープンソースソフトウェアの開発を共同で行っていく。そうやって情報共有し，情報公開してGPLの精神，オープンソースの精神をみんなで共有して助け合いネットワークを構築していくことだと思う。

そういう性質のコミュニティにおいて，中心になるオープンソースのリーダは非常に重要な役目を背負っている。全体の動きを把握して対外的にどう動くのか，主に，どのイベントに出展してセミナーを開催するのか，本をだれが執筆するのか，いつオフ会を開くのか，さらに，コミュニティの理念を共有していけるよう配慮しながらコミュニティを運営していく。自ら直接動く必要はないが，目配りだけは全方向に向いて，それぞれの方向付けをして，必要なときには軌道修正していかなければならないだろう。

技術力が突出してオープンソースに中心的に関わる場合は特に，リーダとしての立場を自覚してコミュニケーション能力を最大限に高めてネットワークを築き，良好なコミュニティ運営をすることを努力する必要があるのではないか。

また，オープンソースの場合，中心にいた開発者がボランティアで行っていたリーダの仕事を半ば放棄して仕事に専念する場合も少なくない。 しっかりと後継者を決めたうえで引退することだ。リーダにその実行力がないのなら，セカンドの人材がコンセンサスを得て引き継ぐことだ。

本家が英語で開発したオープンソースの場合，共通して言語の壁がある。これはプログラムの問題に留まらない。本家が英語圏にある場合には，プログラム内に言語ファイルが多数仕込まれていて多言語化が難しくなる傾向がある。ドイツなど，ヨーロッパ圏から配布されている場合には比較的言語が切り分けられているので安全だ。

さらに，本家における開発と日本における開発の歩調をどう合わせるか，これは英語によるコミュニケーション能力になるわけだが，日本のコミュニティに英語と開発両方の達人がどうしても必要になる。英語の能力，説明能力自体に自信が持てないのでどうしても躊躇してしまいがちだ。もちろん，わたしも含めて英語が苦手な開発者も本家の掲示板には書き込みをしたり，言語ファイルの提供など，精一杯フィードバックしているが，他の開発者と異なる意見の場合に説得していく技術が必要だ。このような場合，英語も説明能力も開発も達者なメンバーに頼ることになる。本家が主催している英語の開発者メーリングリストの量は半端ではなく，それらの情報を日本のメンバーにつたえたり，そこで日本のメンバーたちの考えを発言してフィードバックしていく。

こうやってできうる限りのフィードバックを行うことにより，本家とさらに良好な関係を築くことができる。翻訳を含め，卓越した人材が必須だ。

また，デザインのセンスは英語圏と日本語圏ではかなり違う。英語圏でのデザインをそのまま日本語圏で適用するだけでは本当に日本語化したとは言えないだろう。そこで必要になるのがデザイナーの参加だ。

つまり，コミュニティには，様々な層からできる限り多くの開発に協力してくれるユーザが必要なのだ。

その貴重なユーザを集める努力，そのユーザの声を満遍なく聞き取って意見調整してコミュニティを維持し，コミュニティを割れさせたりすることのないように調整する能力が，オープンソースのリーダに課せられているのではないか。

しかしながら，そういったリーダの役割の認識は，現在ほとんどコンセンサスが取れているとは言えないようだ。

いったいどんなオープンソースがあって，それぞれのコミュニティがどういう動きをしているのか，中心となって積極的に情報を集め，オープンソースの運営に協力しようとする動きがまだまだ鈍いように思う。

そういう動きを期待したいのは，たとえばNPO法人であるオープンソースソフトウェア協会だったりするのかもしれない。オープンソースソフトウェア協会では最近ではGPLセミナーなどよくセミナーが開かれており，リーダ同士で情報を交換するのに最適だ。

オープンソースソフトウェア協会にはGeeklogやOpenPNEなど，オープンソースのリーダが参加し始めており，Geeklogとはお互いに協賛団体として連携することになった。

そういう動きがさらに広がることを期待したい。

Geeklogの日本ユーザ会であるGeeklog Japaneseは，コア開発者の複数体制にはじまり，SNS 800名体制で，セミナー・ブース出展協力など万全だ。このように，オープンソースの運営には，できるだけ多くの利用者を巻き込み，その中から開発者・協力者を見出して連携をとっていくのが理想的だし，他でもそれをやっているものだと思っていた。

だが，オープンソース自体がボランティアで技術者がそれぞれの思いで関わることとなるので，グループ運営のリーダーシップを取らない，あるいは自然発生に任せて，もっぱら開発に専念してしまっている，あるいは主要開発者が興味を失うか次第にコミュから離れた後，だれが引き継いでリーダシップをとるのか遠慮しあって運営が行えていないところ等など，必ずしも順調に運営できているとは言えない様だ。

だれが本を執筆するのか，だれがイベントに出展するのか，だれがセミナーを開催するのかがなかなかコンセンサスが取れず，コミュニティとして動けない場合も少なくない。

だれもが知っている巨大オープンソースなのに日本でたった20人とか，たくさんのユーザがいるはずなのに開発者1人で日本語化を行っているとか，各々オープンソースコミュの運営自体，スタートラインに立てているとはなかなか言いづらい状況もあるようだ。

また，オープンソースの場合，英語版は本家から配布されて，それはかなりの確率でドイツのようなのだが，そのオープンソースは，日本語化作業や携帯への対応など，日本ならではの開発を行って配布する。そのため本家とどう良好な協力体制をとるかは実は非常に大切なのだ。が，オープンソースによっては， ロゴ利用の規制にはじまり，様々な場面で本家から制限を受けて，自由に動けないものも少なくない。

マルチバイトへの対応も，本家の開発者グループがどこまで対応してくれるのかもネックだが。

オープンソースをユーザに紹介する場も限られており，現在は企業のある一部門のオープンソースへの貢献事業というかたちで無償でブース出展が可能になっているが，十分とは言えない。(参考：オープンソースを支えるコミュニティ活動（イベント編）)

オープンソースがこれからの日本の産業に大きな影響を与えることは明白なので，国の事業として考えても良いくらいなのに，個々の企業が自主的に行っている数々のイベントに国が直接なんのサポートも行っている形跡がない。

国が主体となって，個人のボランティアや企業の善意にたよりがちなオープンソース活動をもっと側面支援してほしい。

支援する方法としては，オープンソースを発表する場の提供だ。

特定企業だけに頼ることなく，こころおきなく，ネット環境がそろった環境で思い思いにオープンソースを展示・発表していきたいものだ。

そうして国ももっとオープンソースを利用していくことで費用対効果をあげていける。

オープンソースを使うことにより無駄に重複してソフトウェアを開発しなくて済むことになるので，多くの国に頼った既存企業は倒れていくことになるかもしれないが，そこに囲い込まれていた優秀な開発者を救い出すことにもなるかもしれない。

そうして，無駄な開発を必要な開発へと集中させて，日本の技術力をオープンソースで結集し，SOHOのワーキングスタイルをも推進させることにより，ライフスタイルを改善して住みやすい日本に移行して世界と技術で貢献し，連携していける社会を築けるのではないか。