この日記はMozillaのプロダクトへの貢献者としての私の成果を中心に、気になったバグやWeb界隈の話題について書いていますが、 断り書きがある場合を除き、いかなる団体のオフィシャルな見解ではありません。あくまでも個人的なものです。 Mozilla Foundation、Mozilla Corporation、及び関連企業の公式情報ではないことに注意してください。
現在、XHTML 1.0 (もどき)から、HTML5なコンテンツに修正中です。古い日記は修正が完了していませんので表示が崩れます。 順次、修正していく予定ですのでしばらくお待ちください。
例の騒動で延び延びになっていましたが、ようやく公開できました。
既に担当の方はパッチを作成し、テストを行ったり、Fx3.0.1での修正のために準備をしてくれています。そんな脇で今更voteとかして、何になるというんでしょう?
あまり無責任な批判や煽りをしないでいただきたいものです。該当のバグは報告されてから1年半ほど経ってからようやく現在の担当の方がパッチを作成してくれています。
その間、このバグで困るはずの、日本人の誰からも(もちろん、norahさんからも)パッチは提出されていませんし、パッチが出てからもテストのフィードバックもほとんどありません。より多くの人がテストを行い、Trunkでもっと早いうちにバックアウトの原因となったバグが分かっていれば、Fx3.0.0に間に合っていたかもしれません。
Mozilla Japanの私が力量不足でバグを修正できなかったことが原因の一つでもあるのでMozilla Japanに何の落ち度もなかったかというと、そんなことは無いのですが、では何も考えずにリリースを優先したかというとそれも違います。また、US側のスタッフも非常に日本には気を使ってくれています。これだけ開発では貢献者の少ない国であるにもかかわらず、です。つまり、norahさんの批判は全く的を射ていません。
あまり内情を知らないのに、決めつけで言いがかりをつけられるのははっきり言って不愉快です。それも何もしていない人から。
ネットワーク越しにコミュニケーションをとろうとするとよく錯覚しますが、ネットの向こう側に居るのも人間です。そういう基本的なところをもう少し考えていただきたいと思います。
パッチが書けなければ文句を言うなというニュアンスが漂っている点残念ですが、パッチが一番効果的というのもオープンソースにとって大きな問題であるというのは紛れもない現実であるとは言えるでしょう。
ニュアンスが漂っているというよりは、そう言ってます。今回に関しては。開発コミュニティで行動を起こそうとしているのですから。
開発コミュニティはエンドユーザのコミュニティとは全く別の世界です。
piroさんの日記のコメントに昨夜、この疑問を投げかけてみました。
私も該当バグに書いたように、影響が思いつくのはustとニコ動ぐらいです。前者は日本では(?)マイナーなので数字的にはほとんど困る人は居ないでしょう。で、よく分からないのが後者。ITmediaに出ている、情報を信頼するなら、一ヶ月の利用者が400万人らしいです。で、ここから単純に数字だけで考えると、Fxのシェアを10%とすると、40万人がFxユーザ、うち、Macユーザを10%とすると、4万人。で、ここに更に制限がつきます。このうち、動画を見るだけじゃなく、コメントを大量に残す人は果たしてどれだけ居るのでしょう? (極めて少数のコメントしか入れないのなら、ペーストというワークアラウンドがあります。) しかも、Fxのユーザ数にしても、拡張やテーマの対応が遅れていて、Fx3.0.0で即座にアップデートする人以外には影響がない(予定の)バグです。
そして更にもう一つ。ここまで騒いでいる人の中でMacユーザは果たしてどれくらい居るのでしょうか? MacのFlashでIMEを利用したことはありますか? ひょっとして、Windows版のように快適にIMEが使える状態を想像していませんか? そのあたりが非常に気になります。騒いでいるのが本当にMacユーザなら、FlashでIMEを使わせようとするコンテンツ側にも冷ややかな意見を出しそうな気もしますが。
対象が明確ではないということで内容に手を入れました。
だからどんどん Vote しようぜと呼びかければそれは「煽り」と怒られてしまうのでしょう．
なんか勘違いされているようですが、こういう人多そうなので補足しておきます。
私が言ってるのは、既に作業が終わっているバグについて、開発コミュニティ内でわめいたって仕方がないということです。また、今回のケースには当てはまりませんが、リスクマネージメントからFx3.0.xには間に合わなかったバグをFx3.0.xにバックポートしろ、というようなのも開発コミュニティ内でわめくな、ということです。
どうわめこうが、間に合わなかったものはもう仕方がない訳です。どうしようも無い状況下で善意で仕事をしてくれた開発者の近くで必要以上に声をあげるのはただのクレーマーでしかない、ということです。こうなった原因を真摯に受け止め、再発防止として建設的な意見具体案を出す人が居ないことに注目してください。批判だけでは何も変わりません。何故、こうなったのか、どうすれば改善するのか、そこをコミュニティ全体で考えようとしない、現在の状態は非常に残念に思います。
もうひとつ補足しておきます。
Linuxでも同様の問題があり、現在も解決しているのかどうか不透明です。
また、Windowsでもwindowlessの場合に同様の問題があり、こちらは修正の目処すらたっていません。また、話題のMac版のバグが修正しても、これと同じ、windowlessの場合の問題はMacでも残ります。
この様に、FlashでIMEを使う場合には問題が多いです。Webコンテンツの作者はFlashを入力フィールドとして使う場合、ユーザに対して、非常に大きな制限を加えていることを知っておくべきです。ブラウザが取り扱えないデータ形式を追加可能なプログラムで取り扱えるようにしよう、というのがブラウザのプラグインの元々の発想なのですが、時代が変わって、プラグインでインタラクティブなコンテンツを処理しよう、と考える人たちが増えました。しかし、GeckoのIME制御がバージョン1.9まで完成しなかったこと、他のブラウザも同様の問題を抱え続けていること、プラグインはネイティブアプリですが、ネイティブアプリの全イベントをハンドリングできるわけでは無い点等を考えると、いかにプラグインを使うことがユーザビリティ、アクセシビリティ的にリスクが大きいのか理解してもらえるかと思います。
今後、OSやブラウザの64bit化など、ますます混迷を深めていくことになりそうなので、Flashを使ったインタラクティブなコンテンツ作りがいかにハイリスクなことなのかを理解しておかないと、デスマーチを体験するハメになるかもしれません。
MacのFlashでIMEが使えない件は、別に日本だけの問題ではありませんので、そのへん誤解無いようにお願いします。中国語や韓国語が駄目なのはもちろん、欧米のキーボードレイアウトであってもデッドキーが使えません。MacのデッドキーはIMEイベントを利用しているためです。
いくつかの誤解を解くために、私の考えを明確にしておきます。
いいえ、かまいません。ユーザが普通に苦情を書く分には私はそれは問題無いと思いますし、また、批判が無いというのはそれはそれで問題だと思っています。
今回の件で私が問題視しているのは、問題の記事が煽った行動の内容と、その効果やタイミングについてです。
海の向こうで、IMEを知らない担当者がIMEを使ってる私たちに助け(テスト)を求めながら今回の仕事をしてくれました。問題の記事はそういった現場の人間が働いている「現場」でその当人の作業が終わってから、組織票を投じようと呼びかけていました。このような注目の集め方をさせてしまうと、bugzillaで炎上し、コメント欄にまでどうでも良いコメントを書き出す人が出てくる可能性があります(過去の経験からするとその可能性は低くない)。つまり、問題の内容は開発現場で、開発者の一員として起こそうとしていることに他なりません。もし、これを飛躍した話だと思われるのであれば、逆にもっと影響を熟慮して欲しいと思います。
bugzillaでコメント欄にコメントを記入すると、それは関係者にバグメールと呼ばれる、メールが送信され、関係者は目を通すことになります。ここで、スパムコメントが続き出すと、関係者はそのバグの内容にそのうち、目を通さなくなる可能性が高くなります。もし、そうなってしまうと、出ているパッチに対してのフィードバックに関係者が気付かなくなる恐れもあります。これは絶対に避けねばなりません。
このような状況は、自分の仕事している机の真横で、既に終わってることを騒がれているような状態と同じことになります。想像してみてください。あなたが担当者ならそれは受けて当然の「批判」ですか? また、今後も日本人が重大に感じるバグと関わりたいと思いますか? 恩を仇で返す行為を私は容認できません。
問題の記事の提案内容は、今後につながるどころか、今回できた新しい開発者間の関係をぶち壊し兼ねない危険なものです。開発はパッチのみで前に進む訳ではありません。その根底には開発者間の良好な関係に基づく連携があるのです。
ユーザの方もOSSではある一線を越えると、開発者として扱われます。これを素晴らしいと感じるか、酷い話だと感じるかは、OSSの開発形態の意味を本当に理解しているか、していないかの差かもしれません。
いいえ、そんなことはありません。個人で、それぞれの意志で的確にvoteすることは問題ありません。
ただし、voteにはほとんど効果はありません。健全に運用されているのであれば、重要な項目なんでしょうけど、今回のように、その意味を組織票で覆そうとすると、ますます信頼のおけるものではなくなってしまいます。
ですが、担当がいつまでたっても決まらない、担当者は決まっているけど、パッチを出す気配がない、そういった場合に各個人が積極的に票を投じるのは良いことだと思います。むしろ、そうすべきでしょう。
この誤解を与えた原因は完全に私の最初のエントリの構成のまずさにあります。お詫びします。
いいえ、そんなつもりはありません。
私自身がプラグインの仕組みと、Carbon時代のイベントモデルと、Cocoaフレームワーク内でのイベントの関係が分かっていないため、パッチを作成できませんでした。IME関連のバグは全て私が修正していますので、事実上、(コンポーネントが存在しませんが)IME関連コードのオーナーとなってしまっている現在、修正ができなかった責任は私にあります。これは最初から否定する気はありません。
では何故、パッチを出さなかった人間が文句を言うなという主旨の記事を書いたのか、ということですが、それは、問題の記事が開発現場であるbugzillaで行動しろと扇動している、つまり、(本人にその気が無くても)開発コミュニティの一員として発言していると考えてのことです。開発コミュニティ内では実力、実績重視の縦社会です。普段の人間関係にそれはありませんが、何らかの意志決定が必要な場合、これが重要になります。voteの数等の数字は決断できる人の判断材料であって、既に決定したことを覆すような強い力はありません。
つまり、開発コミュニティ内(bugzilla)から既存の決定を覆したい場合、地道に積み重ねた実績の山が必要です。
いいえ、そんなことはありません。もちろん、英語圏と比べると流石に「はい」と言わざるを得ない部分はありますが、母国語を優先するというのは、それはそれで自然なことでしょう。ですが、世界の中では日本は非常に重要視されています。
まず、先日も解説したように、このバグはアクセント記号を使うヨーロッパでも問題があります。US国内でもバイリンガルな方等に影響がある可能性は大です。
もし本当に日本が(というか非英語圏が)軽視されているなら、互換性を重視するFx3.0.xで今回のような危険な修正は認められません。このバグが重要だと考えられているからこそ、Fx3.0.1で修正する許可が予め出ている訳です。ちなみに、Mozilla CorporationとMozilla Japanが連携を取りだしてから、重大な国際化バグは仕様を変更したりと、リスクがあるものでなければ、stableでも修正しようという話になりました。Firefox以前に比べれば、格段に状況は良くなっています。
では、何故土壇場でバックアウトという話になったのか、ですが、あのバグはbeta5 (final beta)では修正されていませんでした。逆に言えば、あのパッチが原因で発生していた問題はbeta5では存在しなかった訳です。beta5以降にも大きな修正が大量に入っていますが、それは、危険を冒さなくてはいけない重大な問題だったからです。
リリースのプロセスからいくと、beta5には無かったバグをFx3.0.0に残す訳にはいきません。しかも、そのバグがYoutubeで発生するようなメジャーなものだからです。そのため、バックアウトして、beta5相当のクオリティに一時的に戻す決断が下されています。これは非常に理にかなっています。
また、私見ですが、世界的にFlashでテキストを入力させようというサイトが非常に希であることもこの決断を後押ししているのは間違いないでしょう。もし同じ問題がinput要素やtextarea要素で発生するなら、リリースは確実に止められていたと思います。
we didn't win that gamble, unfortunately.
これは、とある関係者の発言です。この一言が全ての理由を説明してくれていて、非常に印象的でした。
MJ blogの方に例の記事、その4をポストしました。
拡張作者とWebアプリの開発者は要注意なbeta 5後の仕様変更に関して解説しています。
結局問題の根っこにあるのは人手不足です。日本の開発者コミュニティはこれを解決していかなくてはいけません。現在の日本のMozilla界隈では、ユーザ向けのフォーラムが数カ所にあり、それ以外に実際に何らかの貢献をしているコミュニティが数件あります。このうち、プロダクト自体のコア部分の開発をやっているのはBugzilla-jpのみです。
Bugzilla-jpは歴史的経緯やマンパワーの不足から意図的にその敷居を高くしました。はじばぐでルールを明文化していて、ある程度の知識、技術力が参加者には求められます。この結果、活動を休止する等のメンバーの引退ペースはそのままに、新メンバーの増えるペースは大きく下がりました。しかし、その代わりにこの敷居を越えてきてくれた方は皆、レベルが高く、とても大きな貢献を行ってくれています。その証拠に、Firefox 3のクレジットには多くの日本人の名前を見つけることができるでしょう(出てくる日本人名全てがbugzilla-jp関係者、という訳ではありませんが、割合は高めです)。
では、人を増やすためには単純に考えれば敷居を下げれば良いのですが、それはまだ当分できません。現在の貢献者の貴重な時間を無数に報告されるであろう意味不明な報告に割く余裕はまだまだ無いのです。
この問題に対する一つの解は現在のユーザコミュニティ群とBugzilla-jpの間に中間的なコミュニティを置くというアイデアです。これに対するひとつの実践例はもじら組のとおやまさんが開設してくれているFirefox3 問題報告センターですが、今のところBugzilla-jpとはあまりうまく連携できていません。それがbugzilla-jpにエスカレーションされるべきバグが無かっただけなのか、エスカレーションされていないのか、その辺も私には把握できていません。スタッフ間のコミュニケーション不足と言えばそれまでなのですが、他にも理由はあるようです。
Bugzilla-jpでも敷居が低かった時代によくありましたが、報告が投げっぱなしで内容を正確に把握できないという話を聞いています。この辺、報告者がメールアドレスを登録しなくても良いという現在の報告センターのシステム的な問題であるように思えます。
また、とおやまさん自身、多くの作業(SeaMonkeyの日本語化や、も組コンテンツのメンテナンス等)を抱えている方なのでもっと力を貸してくれとはとても言えません。
そんな訳で、私たちに足りないのは新しいコミュニティをイチから作り、時間をかけて仕切ることができる人材なのではないかと考えています。Firefoxユーザの中には「手伝いたいけど、どこで何をすれば良いのか分からない」という人は多いかもしれません。ですが、そういった人は今はまだ必要ないのです。今、そういうレベルの人を活かせるコミュニティが無い訳ですから。今、私が必要だと思う人材は、「無いなら作ろうよ」と言い出せるレベルの人なのです。
もちろん、単純に技術力があり、バグを修正できたり、バグを発見して検証できるレベルの人(もちろん、コミュニケーション能力に問題が無いことが前提ですが……)は直接Bugzilla-jpへ来て頂ければすぐにでも開発者として参加はできます。
ここをご覧の開発者の方ならもう知っている方も多いと思いますが、trunkはCVSからMercurialに移行しました。そのため、このドキュメントの内容は既に古くなっていますのでご注意ください。先日、Windows Vista x64、MacOS X 10.4、MacOS X 10.5、Fedora 9で開発環境を再構築できたので、書こうと思えばすぐにでも書けるんですが、まだ情勢が安定していないので、もう少し更新を保留したいと思います。
trunkの開発環境でお困りの方がいらっしゃいましたら、も組のIRCの#moz-users(深夜なら大抵居ます)か、メールで直接お問い合わせください。しばらくは仕事の都合上、オフラインの日が増えるのでメールの方が確実かもしれませんが、返信まで時間がかかるかもしれません。
よりユーザ寄りの開発コミュニティ、正確に言うなら、Bugzilla-jpや本家Bugzillaのデータベースを充実させるためのフィードバックをより簡単にユーザがポストできる、窓口となるコミュニティはどうあるべきなのか、どういう問題があるのかを、私が過去の経験から思いつく限りのものを列挙してみます。
まずはベースとなるシステムが必要です。最低限必要と思われる機能は、まずはアカウントの作成機能です。これを煩わしい、と思うユーザのフィードバックはノイズとなって開発関係者の労働力を無駄に削ぐことになる可能性が非常に高いのでデメリットは無いと思います。アカウントにはメールアドレスを必須としておき、メールアドレスで最初のフィードバックに対するスタッフからの確認や問い合わせが通知可能である必要があります。
各フィードバックの内容は、ステータスを管理できなくてはいけないでしょう。例えば、フィードバック内容が未確認、フィードバック内容を確認済、Bugzilla-jpに報告済み、Bugzilla-orgに報告済み、Trunkでは修正済み、リリース版で修正済み、フィードバック内容はバグではなかった、等々が必要でしょう。
また、スクリーンショット等が必要になることも多いでしょうから、ファイルの添付機能も必要でしょう。
後は念のためにセキュリティフラグも用意しておいた方が良いと思います。
こういったシステムを作成、管理、メンテナンスしていくことが必要です。サーバ資源はもじら組等と交渉すれば使えると思います。
バグの再現確認は現在のbugzillaよりも手間がかかるでしょう。Bugzillaではリリース版のBranch限定のバグを取り扱う特殊な場合を除き、基本的に全ての報告者が最新のTrunkビルドを利用していることが前提となります。
ですが、ユーザにTrunkを使わせるのは酷ですので、全てスタッフ側で検証する必要があると思います。その場合、報告されたバージョン、最新のリリース済みバージョン、そしてTrunkでの検証が必要でしょう。
エンドユーザと、開発者では考え方等がかなり違います。また、エンドユーザ同士でも、そのバグで実害を被っているか、否かで意見が変わってくるでしょう。Bugzillaはバグの担当者や、コンポーネントのオーナーにその設定権限があるため、基本的にもめることはありませんが、ユーザ主体のコミュニティではそれはもめ事の種となってしまう可能性があります。作らない方が無難というものでしょう。
要望というものは人によって異常に温度差があるものです。
一部の人にはあったら便利なものでも、大多数のユーザにとって不要なものであったり、多数のユーザに混乱を与えかねないものは拡張機能にすべきものです。
また、より最悪な要望は技術的に困難すぎるものです。あれば理想的でも現実的ではない案であれば何の意味もありません。
ですが、要望を出した人というのは、真剣にその機能が実装されることを望んでいることに注意してください。要望を出す人は提案する内容がすばらしいと考えてフィードバックを返すわけですから、その提案を蹴られると不快に感じ、中には炎上する人も出てきます。
不毛な争いが起きないように要望は内容に関わらず一律受け付けない、という方針は必要でしょう。
開発未経験な人ほど、その報告内容は支離滅裂だったり、情報が不十分だったりすることが多いです。ですが、これは自然なことです。開発経験者がなぜ有用な報告を行いやすいかというと、開発者の求めている情報の察しがつきやすいからです。
この差はどうしようもないので、必要となる情報のガイドラインは必要でしょう。しかし、ガイドラインを作ってもおそらく報告者は読んでくれません。そのため、Bugzillaで採用しているような、ダイアログ形式の報告フォームを作らなくてはいけないでしょう。つまり、スタッフが欲しくなる情報を入力してもらえるよう、うまく誘導できるようにすべきです。
コミュニティリーダをトップに据え、システム管理者や、各種貢献者と、その貢献量をはっきりとさせた方が良いかもしれません。相手が一見さんであればあるほど、対応してくれている人がどのようなレベルの人なのか気になると思われます。また、なにか決断しなければいけなくなった時に上下関係がはっきりしているのであれば、その決断を誰が下すべきで、誰が従うべきかがはっきりします。意志決定プロセスを尊重できない人はその組織内での活動には不的確な人と言えます。
また、貢献者の評価をなんらかの形で明確に集計するのであれば、昇格だけではなく、ブランク期間に応じた降格も必要でしょう。貢献を途中で中断した人が、現役の貢献者よりも発言権があると問題だからです。
たぶん、まだまだ出てくると思いますが、今考えついたのはこのぐらいです。これだけでも大変なように感じるかもしれません。それはもちろん間違っていません。コミュニティ運営というのはとてつもなく大変ですし、ボランティアだからと言って、中途半端な覚悟で出来るものではありません。
ですが、これらを全て一人で処理する必要はないのです。良いリーダが名乗りを上げてくれたら、スタッフは自然と集まってくるでしょう。もし、実際にやってみたい、という方が居たら、是非私にメールででも相談してみてください。
ラーメン食べに行く打ち合わせの最中に突然連絡不能に陥っていたも組のroot様の生存を確認しました。無事で何よりです。
どのように答えるべきか非常に悩むエントリでした。
さらに私には、ここではあえて Mozilla Japan の中野さんに対して言うのですが……
Mozilla Japanの
と付けられると私はこの場では何も回答できません。
ですが、あくまでコミュニティで活動している個人として、私の意見を以下に書いておきます。(こう書いてもMJの中の人が言ってた
とか書かれる訳ですが、黙っていたら黙っていたで保身に走ってる
とか言う人も居るので、コミュニティの発展を重視して個人として回答を書くことにしました。)
まず、bugzilla-jp関係者の間では開発者の定義として以下のような内容が暗黙のうちにあります(明文化した方が良いというバグをたてるべきですね)。しっかりとしたコンセンサスがある定義ではありません。そこはご注意ください。
bugzilla-org/bugzilla-jpを中心に、実際にバグを修正している人。そしてそれをサポートする、テスタやバグの管理作業者、開発コミュニティの運営者等、いわゆるスタッフサイドと、さらにbugzilla-org/bugzilla-jpに直接バグ報告をする人を開発者とする。
つまり、今のところ、bugzilla-jpのコアスタッフの中では開発者とユーザの線引きは明確です。bugzillaで報告も含めた活動をしているか、否か、というところです。言い換えるなら開発者のコミュニティであるbugzillaで何か行動しようとするならユーザであると同時に開発者でもある、と考えています。
次に、エンドユーザとの接点についてですが、現時点で私はほとんど行っていません。希に余裕がある時にもじら組のフォーラムで質問に対して何らかの回答を付けているぐらいです。今後もこれを拡大するつもりはありません。
無論、コミュニケーションを図るべきであるという考え方には賛成ですが、それは理想論で現実的ではありません。現在の開発者不足を自分自身のマンパワーで埋めてしまうことに使うことを優先しているからです。私は今回のリリースに際して、問題となったバグよりも、より重要と考えていたバグを大量に含む修正作業を行いました。その件数はバグの数で約150件です。私の修正作業に使っていた時間のうち、三分の一を開発コミュニティの運営やユーザとのコミュニケーション等の新しい仕事に割いていた場合、数字だけで考えるなら、50件のバグをFx3に残してリリースしていたことになります。もし、修正できていたバグを残してでもエンドユーザとのコミュニケーションを図るべきであるという考え方が大勢を占めるのであれば私は考え方を変えるかもしれませんが、そうはならないと考えています。
開発コミュニティに対して期待するのは良いのですが、もっと働くべきであるとは考えないでいただきたいです。コミュニティに居る人間は私以外はフルタイムではなく、ボランティアです。ボランティアで各個人がそれぞれのできる範囲でMozilla JapanやMozilla Corporationではなく、GeckoやFirefoxといったプロダクトに貢献してくれているのだと思います。
今回の件で、貢献者のコミュニティ全体がその体制や実態をアピールする必要性を強く感じました。問題点等を自ら列挙してアピールし、新しい貢献者を募っていくというのが当面、必要な作業なのかもしれません。ですが、そこにもできる作業を犠牲にした、新しい作業が発生することに注意してください(現に、私は今、そのためにこれを書いています!)。現状を駄目だと考えるなら自分で行動をおこし、行動をおこせる新しい人を探すしかないのです。
最後に、voteの効果に関する私見を出しておきます。voteは先日も書いたように、ほとんど効力を持ちません。特に決断が行われた後には全くと言っても過言ではありません。それはなぜなのかと言うと、簡単です。開発に関する決断は開発者自身が最終的に行うからです。もちろん、開発者はその問題に関するエキスパートであることが大半です。リスクやタイミング等、技術的な問題と、修正されることによるメリットとを秤にかけて決断することになります。ですが、もし、開発者が今回のケースのように、問題の内容そのものについてのエキスパートではない場合、その問題の重要性が判断できません。こういった場合、判断時にvote数がその判断材料となるかもしれません。ですが、その程度のものである、ということです。決してvote数の上位からバグを修正していくわけではありません。
この記事と記事に付いてるコメントとその他関連エントリを読んで、もずはっく中野さんが矛盾してるなーと思ったのは、bugzillaが盛り上がってないからバグの影響が少ないと見積もっていて、一方では開発コミュニティであるbugzillaに半端な覚悟の素人が踏み込むなと言っている点。そもそも Firefox2で当たり前に出来ていたことがFirefox3で出来なくなるのだから、問題が顕在化するまで騒ぎは起きないでしょう。「CSSのナントカのプロパティの実装にバグがある」とかならブラウザのバグだと分かりやすいけど、わざわざベータ版を入れているユーザーで、しかもブラウザの問題か Flashの問題からOSかIMEの問題か判別が付かない状態でbugzillaを見に行く人はごく少数じゃないでしょうか。
私は何も矛盾していると思いません。
開発者がある程度の数揃えば(前エントリにあるように、開発者の定義はパッチを書くレベルとは違います)、趣味や嗜好もそれだけばらけます。それだけで十分なサンプルが採れると私は思います(統計学詳しくありませんが、日本人全体の考え方を調査するとき、数千人しかサンプルとりませんよね?)。
それと、報告者が原因を分かっている必要は無いんですよ。私はそんなことは一度も書いていません。Fx3のbetaを入れたら使えなかった、その事実があるだけで報告すれば、分かる人達が検証してくれます。検証の結果、Flash側の問題だとしてもAdobeに対して何らかのフィードバックを行います。該当のバグを読んでいただければ分かるように、Adobeとも連携して開発を行っています。
自分にできる範囲のことをやる人が少ない(母数が少ないのがより大きい問題ですが)、それがMac版の開発者が少ない理由だと思います。
フィードバックが来るのはbugzillaじゃなくてウェブサイトの運営側で、多分「突然日本語入力が出来なくなりました、パソコンの設定は何も変えていません、元に戻してください」というような問い合わせが多数来るでしょう。そうなると対処のしようもないので「Firefox3以外のブラウザを使ってください」と回答するしかなくなります。
このバグを既に知っているなら、「Fx2に戻してください、もしくはSafariを使ってください」と言うのが現実的だし、それで良いと思いますよ。使えないという、バグがあること自体は開発コミュニティの失態であり、そこは否定しません。
あと、先のエントリで述べたようにFlashを使うこと自体に問題があります。それを選択したのはWebコンテンツ側ですし、そのリスクを理解できていなかったのであれば勉強不足と言うほかありません。既にその時点でLinuxユーザを切り捨ててる訳ですし、(Linux版の問題はFx2でも環境限定での問題の様です)そのリスクは十分に分かってないといけません。また、このバグがなかったとしてもインライン入力ができない、という事実があります。Macユーザがそのようなサイトを好むのか、そこに私は相変わらず疑問を持っています。
バグによって直接影響を受ける人の数も重要ですが「バグが残っていることで人に薦めづらくなる」ということも大きいと思います。
もうひとつだけ追記しておきます。
Mozillaの開発コミュニティの判断は残っていても(branchで修正できるんだから)問題無い、という判断です。
この意見に対して異論があることは理解できます。私も以前に述べたように、バグの重要度の判定結果は人それぞれです。現在のコミュニティに対して異論があることは、コミュニティを形成していく上で健全です。ですが、それを外野で述べるだけで、意見が通らないことに不満を感じるのは不健全です。意見を通したいなら開発の中の人になるしかありません。そしてそこでの発言力というの以前から述べているように実績が必要です。今回のように、日本に特殊事情があると考えるならなおさらです。それは日本人以外には分からないことですから日本人以外の開発者は日本人の意見を参考にするしかないわけですが、実績が無い人の意見を聞くというのは無謀極まりありません。
ITmediaでも事実を誤認したまま記事が書かれているので改めて強調しておきますが、問題のバグはbeta5(最終ベータ版)では修正できていませんでしたが、ギャンブルとして修正が行われました。しかし、そのギャンブルに失敗し、RC1ではbeta5のクオリティが維持できていなかったので、RC2直前でバックアウトされているのです。
先のエントリで、
(Flashでテキストを入力させようとする)既にその時点でLinuxユーザを切り捨ててる訳ですし、そのリスクは十分に分かってないといけません。
と書きましたが、私自身も勘違いしていたことがあるので説明しておきます。いい加減な情報流してしまってすみません。お詫びします。
LinuxのFx2ではFlashでIMEが使えない、という理解で書きましたが、どうやら違ったようです。最も早い報告ではFx1.5 + Flash9 beta + SCIM + Anthyという組み合わせで完全に入力できていたようです。
また、uimとFx3の組み合わせでも問題ないことは確認されています(現在最新のリリース版であるFx2は不明)。ただし、まだIIIMFを利用したIMEでの確認報告はありません。
ただし、これらの動作確認はシステムのデフォルト文字コードがUTF-8の環境のものですが、EUC-JPの環境ではまだまともに使えないという話も報告されています。(ほとんどのメジャーなディストリビューションでは既にUTF-8になっていますが)
Linuxユーザの方でまだFlashでIME使えないぞ、というバグに困っている方ははじばぐを読んで、Bugzilla-jpに報告してください。お願いします。
毎日jpのトップページを走るフォクすけがかわいい。
やはりLinuxのFlashでWebサイトの作者がユーザに日本語入力させるのを強いるのは鬼門の様です。
Mac版のFlashでIMEが使えない、という問題についての騒動で、私の書いたコメントで『エンドユーザ』の方に不快な思いをされた方もいらっしゃると思います。そのようなエンドユーザの方にはお詫びします。すみませんでした。
また、私の書いた内容は主に事の発端となったエントリに対する批判と、開発コミュニティに入ってこようとするユーザの方をターゲットとしたものでした。つまり、エンドユーザの方がこの日記を読むこと自体が私の想定外だったので書き方が非常にまずかったです。そして最初のエントリを非常に感情的に書いてしまったために、私の考える問題点を明確にできないまま変な騒動に発展してしまいました。申し訳ありません。
私が問題としたかったのは下記の三点でした。
そして今回の騒動ではっきりと実感しましたが、三番目の問題が一番の深刻なようです。
あらためて書かせてもらいます。私はユーザがユーザの枠に居る限り、プロダクトを批判することについては何の問題も無いと考えています(話題の根拠や、内容が正確であるという前提はあります)。むしろ、そういった意見は出るべきです。
ですが、ユーザが、開発者の立場で行うべきことをユーザの立場のつもりのままで行った場合にはこの限りではないと考えています。だから私は開発者コミュニティの一参加者として開発者であるべき方々に対してメッセージを発信しました(この部分がエンドユーザの方に対する批判や責任の押しつけであると採られたことは非常に残念でした)。そこで、少しでも不快感を与えてしまった方に理解してもらうには、Bugzillaの存在を理解してもらう必要があると考え、このエントリを書くことを決めました。
MozillaはBugzilla上で開発を行っています。Bugzillaでは開発に関するディスカッション等まで公開されています。そしてここにはある意味では自由に開発に参加することができます。これは例えるならMozillaの開発者達が働いているオフィスに、Mozillaの関係者以外も入って来て、プロダクトの開発に参加できるようにしている状態です。つまり、開発者になりたければ、Mozillaに就職しなくても参加できるということです。これがオープンソースの良い所だと思います。ソースが公開されているところに意義があるのではなく、開発体制自体がオープンなところに意義があるのです。そう、つまり、開発者のオフィスをユーザが引っかき回すことができるように公開されている訳ではありませんし、またそれは許されるものでもありません。
ですが、このシステムを誤解している方の多くはユーザとして開発コミュニティに参加しようとします。例えばバグを報告する場合に、報告したらしっぱなし、スタッフからの確認や問い合わせにも応じない、という開発者からすると非常識な行動をとります。また、こういったユーザの行動に対して『ユーザに手間をかけさせるのはおかしい』という意見が出たりします。ですが、その意見は開発者側から言わせてもらえば、『自分はユーザなのだから開発者はユーザの希望を聞くべきだ』という一方的な意見に聞こえます。このような方は開発現場をユーザサポートの場だと考えているのではないかと思います。
開発者のコミュニティでは開発作業を行うために人が集まっています。ユーザをサポートするためではありません。一方はユーザはサポートされるべきだと考え、もう一方はユーザをサポートするために参加しているのではないと考えている訳です。これで話がかみ合う訳はありません。
このような状態では、Bugzillaを理解せずに入ってきた、『クレーマー』と化したユーザがBugzilla上で誤った行動を起こし、それが原因で日本以外の開発者の方に不快感を与えるかもしれない、それが私が最初に懸念したことでした。そして、これを誘発する安易な内容を私は許せませんでした。
今回説明したような、ユーザコミュニティと開発者コミュニティの違いをコミュニティの分裂だと悲観する意見を聞いたことがあります。しかし、私はそうは思いません。これらは分離しているべきだと考えています。現在のコミュニティ全体の体制に問題があるとすれば、これらのコミュニティをつないでいるものがあまり無い点です。だから、私は開発コミュニティに情報をフィードバックする新たなコミュニティを提案し、その概要についても私見を書きました。
Bugzillaがなぜ開発者のためのコミュニティであって、ユーザのためのものではないのか、それは開発者には必要なもので、開発者のために作られ、開発者が中心となって、開発するために運営が続けられているものだからです。決してユーザとのコミュニケーションのために運営されている訳ではありません。ユーザが、その気になれば開発者として活動できるのを容易にするために公開されているのだということを理解していただけるようにお願いします。
最後にvoteについて解説を追記しておきます。
以前も説明したようにvote数は開発現場での一判断材料であり、決断を覆せるようなものではありません。これは事実です。
ですが、ユーザがユーザとしてBugzilla上でとれる数少ない行動のうちの一つであることも事実です。数少ない行動なのに発言力が低い、という不満も理解できますが、開発者の立場に立ってもらえれれば、何故そうなのかを簡単に理解してもらえると思います。その理由については、開発者も好き好んでバグを放置している訳ではないとだけ書いておきます。
voteを適切に利用されるなら是非行ってください。ただし、注意して頂きたいのは、voteするバグの選択は本当にそのバグで困っている場合に利用するべきだということです。一刻も早く修正してくれなくては困る、という方はvoteしてください。
逆に言えば、今回の問題の発端のように変なナショナリズムを元にした、本来の目的とは異なる形での利用はしないでください。そのようなことをすれば、voteはますます信頼できない判断材料と化すのみです。Mac版Fx3のユーザで、このバグで本当に困っている方以外のvoteを私は適切だとは思いません。そのような票が非常に多いのであれば、voteは今以上に信頼できない数値になります。それはユーザ自身がユーザとしての意志の表明機会を失うだけのものになってしまいます。
また、くれぐれもテスト結果等のフィードバックではないコメントは書かないでください。お願いします。
関連するエントリ。
ダビング10対応のためか東芝のHDDレコーダのVARDIAのソフトが更新されました。試しにTrunkでアクセスしてみるとRD-S301のネットdeナビにアクセスできました。対応してくれたんでしょうか?