TOMOYOは、SF.jpのプロジェクトとして発足して、今もSF.jpで活動しています。プロジェクトの発足から、メインライン（Linux標準への提案活動）までの歩みについて、下記の資料で参照できます。

• http://www.slideshare.net/haradats/tomoyo-linux
• http://www.slideshare.net/haradats/realities-of-mainlining-case-of-the-tomoyo-linux-project

TOMOYOは、もともとは「日本で開発したものだから、日本で使ってもらえば良い」と思っており、「国際化」は全く考えてなかったのですが、CELinux ForumやYLUGなどで「Linuxの開発成果はメインラインにすべき（しろ、ごるぁ）」というご意見をいただき、そこから急遽「国際化」である「メインライン化」を目指したという経緯です。

もともと国際化を意識していたわけではないので、「メインライン」という言葉も知らなければ、当時のLinuxの主要な会議である「Ottawa Linux Symposium」について名前すら知らないし、開発メーリングリストであるLKML (Linux Kernel Mailing List)も購読していないというかなりオワタ的な状態からスタートしました。語学（英語）的な課題について振り返るとき、個人的には「最初に何をどう発言（提案）すれば良いのかわからない」が一番悩んだところです。他の方のコメントで「半年ROMれ」というのがありますが、開発にかかわらず新しい世界と交流をしようとするとき、「どんな人たちがいるか」「どんなふうに話をすれば良いか」「どんな（暗黙の）ルール、あるいは文化があるか」がわからないと、発言はできません。まず、その世界を知る、知ろうとする努力が欠かせないと思います。始めてしまえば（交流が始まれば）なんとかなるのですが、最初の合流、最初の提案が、難しい、そう思います。

ということがあったので、TOMOYOの最初の提案からメインラインにマージされるまでの全提案とそのスレッドを他の人があとから読んで参考にできるようにしています（実際、読む人がいるかはわかりませんが）。それを含め、LKMLにおけるやりとりからの教訓を読みやすい形で、Japan Linux Symposium 2009で発表しています。

• http://www.slideshare.net/haradats/kernel-development-drawing-lessons-from-mistakes

Linux開発における語学（英語）の重要性についてですが、自分の経験からは、「発音や文法が多少おかしくても通じる」ので、「とにかく伝えたいことを伝える」ことが大切だと思います。日本人には「英語が弱い」という人種的？コンプレックスがありますが、英語が弱いのは日本人だけではありません（笑）。Linux界隈のネイティブの人は細かいことはいいから、主張を説明して欲しいという視点で待っているので、「これ正しいかな？」とか「伝わるかな？」とかはあまり気にしないほうが良いです。

「国際化」についてですが、実は世界はもともと国際化しているわけで、要は視点や活動範囲を自分が制限するかどうかだと思います。知らない世界や英語がメインのコミュニティと交流することは大変といえば大変ですし、疲れるといえば疲れますが、視野が広がり経験が増えます。物理的には日本という国にいても、気持ちや活動内容では、自由に世界と交流ができます。すべてがうまくいくわけはなく、時には挫折や失敗もありますし、行き詰まることもあるでしょう（TOMOYOも実際そうでした）。でも、そこには確かにそこにしかない喜びがあります。多くの人に勇気をもって踏み出して欲しい、そう思います。

コード書く。

君たちが難しそうに議論してる事って、こういうことかい？てな感じでヘタな英語付けときますけど、その瞬間、議論がピタと止むのが快感ですね。

＃いや、そう何回もあるわけじゃないけど。

OSS開発で異なる言語話者同士が同じ仕事をすることで接触言語が生まれたりしたら面白いですね。
グロービッシュやらSimple Englishがそんな感じなのかもしれませんが。

国際的プロジェクトというと、CMSの XOOPS の開発とコミュニティの流れが面白いというか参考になるところが多いです。

まず PHP-Nuke というCMSがあって、それを元に日本人のリーダーが中心になって多国籍開発陣でXOOPS1/XOOPS2を作成しました。XOOPS2はヒット作でした。2002年ごろの話です。
XOOPS2の開発から日本人リーダーが一時的に抜けたあとに、日本からのパッチが本体に取り込まれなくなりました（セキュリティー上の問題が無視されたりなども）。そんな経緯や拡張性の問題から日本人が中心になって XOOPS Cube が作られます。XOOPS Cubeは日本人XOOPSコミュニティーではたいへん大きな支持を受けます。
XOOPS（本家）はその後も分離を繰り返します。

次期バージョンのXOOPS Cude はディレクターが日本人以外の人、メインプログラマーは日本人、デザイナーは日本人以外と多国籍になっています。

  XOOPS（本家）は今は、中国の人がリーダーをやっているとちょっと前に聞きましたが、また変わっているかもしれないです。

※聞きかじりが多いので間違いがあったらすまそ

英語メールの例を見つけてきました。

おそらく、日本人が最初に書く英語メールは最初はバグ報告（日本語が使えません）とか
パッチ（マルチバイト文字を使えるように改良しました）といったものでしょうから、
そういうのを探してきました。

たとえば、このバグ報告の例 [debian.org]では、本文はたった４行です。

> In graphical installer, if I choose "Chinese (Simplified)", "Chinese
> (Traditional)", "Japanese" or "Korean" as the language, there will be
> some missing characters in the next page ("Selection your location").
> Please see the attached screenshots and notice the "unicode squares".
（和訳）
（Debianの）GUIインストーラで、中国語・日本語・韓国語を選んだ時、その次の（場所を選ぶ）
ページで正しく表示されない文字があります。添付するスクリーンショットを見てください。
「Unicode番号の正方形」に注意してください。

といったぐあいです。必要かつ十分な情報を盛り込んだ報告の例だと思います。
この程度の英語を書ければ十分だと思います。あえて言えば最後の行の先頭に
「Please」がついているのに注目するくらい？

日本の英語教育にはキャッチボールが少ないと思うんで
こういうのが練習になるといいなとは思いますが
なかなか踏み出せないですね。
私も何回かバグ報告みたいなのを頑張って書いたけど
かなり思い切りが要る・・

日本人は、野球でいうなら
変化球の投げ方については詳しいけど実際にはキャッチボールすらしたことない
って感じがするので、キャッチボールの練習もすれば伸びるんじゃないかという気がします。

だから君が最初の一人になるのでなければ、英語はある程度、すでにいる日本人にフォローしてもらえると思って大丈夫だ。逆に言うと、その場ですかさずフォローが入れてもらえるような環境からスタートしたほうが良い。その意味ではMLとかはリアルタイムではないのでフォローしづらい。国際会議とか、とにかく「人が直接会う」場からスタートしたほうが良い。
# そうすれば「あいつは英語が下手」というのも含めて解ってもらえる。

逆の言い方をすると、「最初の一人」はものすごくきつい。「最初の一人」に対する感謝を忘れないようにしたほうが良い。

.

一方で。言語問題はたいしたことはない。一番むつかしいのは「文化の差」と言うやつ。
物の考え方、優先順位のつけ方が、日本とアメリカはまるで違う。世界地図でイギリスが中心の(要するに普通の)世界地図があるが、まさに「東の端」対「西の端」ぐらい違う。

で、文化の差を埋めるには、「普段の説明より、1段手前から説明する」気持ちを忘れないこと。「How」は別にその必要はないが「Why need it」周りは特に丁寧に。特にアメリカ人は移民の国なこともあって、「全員共通認識だよね」という所から一段づつ説明するのが説明の仕方の基本パターン。
日本人は「全員の共通認識はいちいち説明しないよ？！そのつぎから行くからね」とやるので『あいつは何を言ってるんだ』と思われる。実際には「2ステップ」ぐらいジャンプしていて、前提が合っていないので議論がかみ合わなくなることが多分にある。

で、説明の文章は「1筋の流れ」のように説明するのがよい。枝分かれして行ったり来たりしてはいけない。聞いている側が迷子になりやすいし、迷子になったときのフォローが入れられるほどこちらも言語能力がないんだから。この点に関しては大前研一の文章は参考になる(書いてある内容ではなく、話の筋道の立て方が、参考になる)。

.

最初から難しいことを言わない。

たとえ目的はややこしい内容の採用であっても、最初は別の、もっと簡単なテーマから入る。
manpageの内容をもうちょっと分かりやすくして、とか。そうやって「傍流」側でちょっとだけ貢献して、味方を作っておく。これは別に国際プロジェクトじゃなくてもそうだけど、言語不如意状態な所ではこの戦略は特に有効。

.

最後に「あいつは日本の文化圏の人なんだ」という事を理解してもらうためのマーカー表現がいくつかある。例としてはこんな感じ:

- 人の名前は xxx-san と「さん」を付ける。判っている人はこれが「日本語の prefix である」事を理解する。
　一方で「xxxさん」は相手が男女どちらでも使えるので、名前から男女の区別がつかないときにはとても便利。

- 一番最初に何かしてもらう場合は、文章の最後に「Thank you in advance for taking your time.」なんてのを
    書くが、その後に「Arigato!!」と書いておく。

これだけでも結構軋轢は減る。

＞これら国際的なプロジェクトでは英語が公用語として用いられるため、
＞英語で説明・論戦・説得・理解・合意などを行うスキルが要求されます。

とりあえずバグレポートとか、改善提案とか、そんなのでも英語で説明したりは
するんだけど。某拡張の日本語化（多国語化）もそんな感じで始まった。
（これは開発者側が乗り気だったこともある。）

最初はそんなレベルから始まったけれど、でもそれは「プロジェクト」とは呼ばないよね。

痛いのは最初だけだよ・・・