タグ: メール

【抄訳】
Mozilla Foundationは今後、Firefoxブラウザにより焦点を絞って力を注ぎ、Google Chromeなどのコンペティタからシェアを奪い返す努力を強化したい意向のようだ。Mozilla自身が確認した会長Mitchell Bakerの今日（米国時間11/30）の全職員宛てメモによると、メールクライアントThunderbirdをMozillaから完全に切り離したい、という。チャットやNNTPニューズ機能もあるこのメールクライアントは、すでに2012年にMozillaによる直接のアップデートを停止していた。

“Thunderbirdは、Mozillaの開発系から分離し、場合によっては、Mozillaの技術への依存からも解放された方が、より強力になれると信ずる”、Mozillaのパブリックガバナンスフォーラムに公開されているBakerのメモはこう述べている。“その現在のあり方は不安定であり、われわれとしては、ThunderbirdとFirefoxの結合関係のない未来への移行を、積極的に検討すべきである”。

Thunderbirdを独立のオープンソースプロジェクトとして切り離すのか、それとも、この大きな里子を引き受けるビジネスパートナーを探すのかについてBakerは明言していないが、それはまだ時期尚早な話題だろう。

むしろここで明らかなのは、Firefox再活性化戦略の一環として、Mozillaの組織体制をスリム化し、焦点を絞りたい、という意志だ。そしてその観点から見ると、Thunderbirdはお荷物に感じられる、Bakerの言葉では“まるで税金を払っているようだ”、となる。Mozillaとしては今後、全力をFirefoxに注ぎたい。

“一つの組織内に、その技術力に対する、競合する複数の需要があることは、どちらのプロジェクトにとっても良くない”、と彼女は書いている。“Thunderbirdを担当している技術者たちはいつも、FirefoxのWeb関連の変化に合わせる努力をしなければならない。一方Firefoxやそのほかの関連プロジェクトを担当している技術者は、ときどきどうしても、Thunderbirdの面倒を見なければならない状況を抱えるが、そんなときでも、どこまでThunderbirdに深入りすべきかという迷いを抱える。どちらの技術陣も、自分の仕事にとって最良の条件を確保できない”。

Mozillaが2012年にThunderbirdの開発サポートの大半を切り離して以降、Thunderbirdにはどことなく、古いソフトウェアというイメージがつきまとっていた。

Thunderbirdがローンチした2004年には、デスクトップのメールクライアントソフトからメールサービスにアクセスすることが、コンピュータユーザのいちばん一般的な慣行だった。Thunderbirdはローンチ後の10日間で100万回ダウンロードされるという、好調なスタートを切った。

しかしその後は、多くの人がモバイルのメールアプリやWebベースのクライアントへ移行し、Thunderbirdの人気は衰えた。そしてMozilla自身の努力も、主力のFirefoxブラウザのプラットホームの拡大に、その多くが割かれた。また、検索でYahooやGoogleとパートナーするなど、Firefoxのビジネス努力も、忙しくなった。

Mozillaが2012年に、Thunderbirdの開発をボランティアのコミュニティに委ねて以来、Mozilla自身はThunderbirdのセキュリティとメンテナンスのための拡張サポートだけを担当することになった。それは、ユーザにとっては大きな変化だったかもしれないが、Mozillaにとっては当然の成り行きだった。

以下が、Bakerのメモの全文だ:
〔以下、英文ママ〕

This is a long-ish message. It covers general topics about Thunderbird
and the future, and also the topics of the Foundation involvement (point
9) and the question of merging repositories (point 11). Naturally, I
believe it’s worth the time to read through the end。

1. Firefox and Thunderbird have lived with competing demands for some
time now. Today Thunderbird developers spend much of their time
responding to changes made in core Mozilla systems and technologies. At
the same time, build, Firefox, and platform engineers continue to pay a
tax to support Thunderbird。

2. These competing demands are not good for either project. Engineers
working on Thunderbird must focus on keeping up and adapting Firefox’s
web-driven changes. Engineers working on Firefox and related projects
end up considering the competing demands of Thunderbird, and/or
wondering if and how much they should assist Thunderbird. Neither
project can focus wholeheartedly on what is best for it。

3. These competing demands will not get better soon. Instead, they are
very likely to get worse. Firefox and related projects are now speeding
up the rate of change, modernizing our development process and our
infrastructure. Indeed, this is required for Mozilla to have significant
impact in the current computing environment。

4. There is a belief among some that living with these competing demands
is good for the Mozilla project as a whole, because it gives us an
additional focus, assists Thunderbird as a dedicated open source
community, and also supports an open source standards based email
client. This sentiment is appealing, and I share it to some extent。
There is also a sense that caring for fellow open source developers is
good, which I also share. However, point 2 above — “Neither project can
focus wholeheartedly on what is best for it” — is the most important
point. Having Thunderbird has an additional product and focus is *not*
good overall if it causes all of our products — Firefox, other
web-driven products and Thunderbird — to fall short of what we can
accomplish。

5. Many inside of Mozilla, including an overwhelming majority of our
leadership, feel the need to be laser-focused on activities like Firefox
that can have an industry-wide impact. With all due respect to
Thunderbird and the Thunderbird community, we have been clear for years
that we do not view Thunderbird as having this sort of potential。

6. Given this, it’s clear to me that sooner or later paying a tax to
support Thunderbird will not make sense as a policy for Mozilla. I
know many believe this time came a while back, and I’ve been slow to say
this clearly. And of course, some feel that this time should never
come. However, as I say, it’s clear to me today that continuing to live
with these competing demands given our focus on industry impact is
increasingly unstable. We’ve seen this already, in an unstructured way,
as various groups inside Mozilla stop supporting Thunderbird. The
accelerating speed of Firefox and infrastructure changes — which I
welcome wholeheartedly — will emphasize this。

7. Some Mozillians are eager to see Mozilla support community-managed
projects within our main development efforts. I am also sympathetic to
this view, with a key precondition. Community-managed projects that
make the main effort less nimble and likely to succeed don’t fit very
well into this category for me. They can still be great open source
projects — this is a separate question from whether the fit in our main
development systems. I feel so strongly about this because I am so
concerned that “the Web” we love is at risk. If we want the traits of
the Web to live and prosper in the world of mobile, social and data then
we have to be laser-focused on this。

8. Therefore I believe Thunderbird should would thrive best by
separating itself from reliance on Mozilla development systems and in
some cases, Mozilla technology. The current setting isn’t stable, and we
should start actively looking into how we can transition in an orderly
way to a future where Thunderbird and Firefox are un-coupled. I don’t
know what this will look like, or how it will work yet. I do know that
it needs to happen, for both Firefox and Thunderbird’s sake. This is a
big job, and may require expertise that the Thunderbird team doesn’t yet
have. Mozilla can provide various forms of assistance to the
Thunderbird team via a set of the Mozilla Foundation’s capabilities。

9. Mark Surman of the Mozilla Foundation and I are both interested in
helping find a way for Thunderbird to separate from Mozilla
infrastructure. We also want to make sure that Thunderbird has the right
kind of legal and financial home, one that will help the community
thrive. Mark has been talking with the Thunderbird leadership about
this, and has offered some of his time and focus and resources to
assist. He will detail that offer in a separate message. We both
recognize that the Thunderbird community is dedicated to sustaining a
vibrant open source project, which is why we’re currently looking at how
best to assist with both technical separation and identifying the right
long-term home for Thunderbird. These discussions are very early, so
it’s easy to you can definitely think of a lot of questions for which
there are’s no answers yet。

10. The fact that the Foundation is facilitating these discussions does
not necessarily mean that the Foundation is or is not the best legal and
financial home for Thunderbird. The intent is not to make technical
decisions about support of Thunderbird by Mozilla employees, or merging
repositories, etc. Point 6 above is the shared organizing principle for
both of us。

11. I understand from recent discussions that merging mozilla-central
and comm-central would provide some reduction of effort required to ship
Thunderbird, at least in the short term. This would make sense if our
path was long term integration of the projects. As i noted above, I
believe our path has to be the long term separation of these projects,
so that each can move as fast as possible into new things. Given that,
I’m not sure that merging them makes sense. I have to learn a bit more
about the cost / benefit analysis of merging repositories given the need
to separate these project. I’m asking the platform and release folks to
comment on this。

12. This message is about the future and there’s a lot to work out。
It’s explicitly not to announce changes in daily activities at this
point. People using Thunderbird will not see any change in the product
they use. We have started this conversation early because Mozilla
works best when our community is engaged. This is how we gather the
people who are interested, and enable those folks to engage productively
within the process. It also of course allows those who prefer a
different course of action to be vocal. We’ve seen this before with
Thunderbird. Building a positive response and a positive conversation
will be a very useful first step in making a good future for Thunderbird。

Mitchell

[原文へ]。
（翻訳：iwatani(a.k.a. hiwa）。

Googleは、全ての広告主が購入できる新しいGmail用の広告フォーマット を今日から展開する。数年前、GoogleはGmail用の新しいネイティブ広告をローンチした。これは受信箱の一番上に設置され、通常のメールのような形で表示される。広告の表示方法としては、あまり邪魔にならない形だと言える。（もちろん不快に感じた人もいる。）

今日から全ての広告主は、Gmail広告を簡単に購入することができるようになった。

広告主は、新しいGmail広告をAdWordsから購入することができる。Gmailのユーザーにとって、この広告はこれまでのGmail広告とは少し違う仕組みで、モバイル版のGmailにもウェブ版のどちらにも表示される。

ネイティブ広告はデフォルトでは閉じている状態だが、ユーザーがクリックすると、ページが展開する。Googleによるとこの広告のコンセプトは「ランディングページのような、豊富な情報と画像を再提供すること」だそうだ。Googleは広告主に、ユーザーが広告を展開した回数に応じて課金するという。（その後の広告のクリックは無料。）

興味深いのは、これらの広告を転送することが可能な点だ。全ての広告の下には「転送」と「受信箱に保存」のオプションがある。「受信箱に保存」をクリックすると、広告メールは受信箱に移動し、普通のメールのように扱うことができる。

受信箱にこの広告を見つけた。（私がネットワークサービスプロバイダーから帯域幅を毎月大量に買っているのが知られていて、私をターゲットとしているのは明らかだ。）

Googleは、Gmailで多様な種類の広告フォーマットを検証し「受信箱の体験に違和感なく合う」高品質の広告を少量、表示することにしたという。

広告主は、通常のAdWordsのターゲットオプションを利用できる。広告自体はいくつかのテンプレートから選び、自社のネイティブGmail広告を作成することができる。この広告には、一つの画像、動画、入力フォーム、電話番号とコールトゥアクション（CTA）ボタンを設置することができる。

Googleは、ユーザーに引き続きどのような広告を表示するかの設定機能を提供する。（興味関心に基づく広告からいつでもオプトアウトすることも可能だ。）また、Google Apps for Workに登録している人の受信箱には広告を表示しないそうだ。

Gmailで広告をクリックした覚えはないが、受信箱から外に誘導されないのなら、広告をたまにはクリックしてみようかと思う。（ターゲッティングが上手く機能しているだろうから。）

原文更新：私はこの広告をこれまでクリックしたことがなかったが、GoogleによるとGmail用の広告フォーマットは2013年からベータ版を検証していたそうだ。これに基づき記事を更新している。

[原文へ]

（翻訳：Nozomi Okuma /Website/ twitter）

[筆者: Travis Bernard]
本誌TechCrunchは、なんと、新しい週刊ニューズレターを発行します。しかも、一度に7種も発行します（既存の日刊2種と合わせてニューズレターは計9種になります）。購読申し込みはここでどうぞ。

多くの人がメールを殺そうとしましたが、メールは不死身です。それどころか、メールは今、再び元気を取り戻しつつあります。日刊のニューズレターがあちこちで人気者になり、とくにモバイルで読むのに合っているからです。その最大の売り物は、適切なターゲットセグメンテーションとフレッシュなコンテンツです。というわけで本誌も、メールによるニューズレターという古くて新しいメディアに、乗らないわけにはいきません。

まずセグメンテーションですが、本誌TechCrunchで主にスタートアップに関する記事を読みたい人がいるかと思えば、モバイルアプリについて読みたい人がいます。ソーシャルメディアやガジェットの最新ニュースだけに興味がある人もいます。ですから、読者がいちばん読みたいと思っているカテゴリーに、記事を分類して提供する必要があります。そこで、今度の新しい週刊ニューズレターは7種類もあります。これらの週刊ニューズレターは、日曜日に、ひとつのカテゴリーに7つから10の記事を集めてお届けします。その7種の週刊ニューズレターは、次のとおりです：

• TC Week-In-Review（総合）
• Europe Week-In-Review（ヨーロッパ）
• Asia Week-In-Review（アジア）
• Gadgets Week-In-Review（ガジェット）
• Mobile and Apps Week-In-Review（モバイルアプリ）
• Startups Week-In-Review（スタートアップ）
• Social Media Week-In-Review（ソーシャルメディア）

これらのニューズレターは、これまでの日刊と違う、フレッシュな衣裳をまといます。とくに、速報性とモバイル上での読みやすさに留意します。読者のデータプランを乱費せず、また高速なロードを可能にするため、画像のサムネイルは省略します。同じ目的のため、記事のヘッダのデザインは、今のよりも簡素なやや古めのを使います。

ニューズレターはここで申し込めますが、デスクトップではtechcrunch.comからでも申し込めます。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa）

モバイルデバイス上のメールを、あらためてなんとかしよう、という試みがこのところ山ほどある。でも、優勝者決定どころか、出場選手登録が締め切られたわけでもないから、これからも続々現れたとしても不思議ではない。

ベテランの起業家で、自分の会社をAmazonやZyngaに売ったこともあるチームが、WeMailと名づけた新しいモバイルアプリでメールに挑戦した。

Y Combinatorの初期の育成事業に参加したこともある二人、Philip YuenとGerald Yuenは、今では成功している同窓生たちから100万ドルの資金をかき集めた。Twitchの協同ファウンダJustin KanとEmmett Shear、ParseとScribdの協同ファウンダTikhon Bernstam、FlurryのファウンダSean Byrnes、RedditとHipmunkの協同ファウンダSteve Huffman、と最近のスタートアップ世界の名士たちが顔を揃えている。

でも、なぜ、今さらメールを？

Philip Yuenによれば、このアプリには、携帯電話の上でメールを扱いやすくするための工夫がいくつかある。データドリブン型のデベロッパである彼らは、WeMailではメッセージを読むための画面スクロール量が従来より80%少ない、特定のメールを画面上に出すためのタップの回数は33%少ない、という。

“われわれは、アプリをダウンロード/インストールするたびに、ユーザが各アプリの操作方法などを勉強しなければならないなんてだめだ、と思う。うちのアプリは、誰にも、なんにも、教える必要がない。ユーザに、勉強を強制しない。誰でも、すぐに使いはじめることができる”、とPhilipは語る。

WeMailはすべての会話を送信者別にグループ化する。それによって受信トレイのサイズは従来品の1/3以下になる。メールの作成は音声でできる（TencentのWeChatふう）。どんなメールにも音声メッセージで返信できる（最大20秒まで）。メールというより、メッセージング的な機能だ。

彼らが工夫したサーバ上のインフラにより、メッセージを直接送れる。だから両サイドがWeMailのユーザなら、メールはふつうのeメールよりも速く、素早く送られる。相手が返信を書いていることが分かる機能もある（これはoffにできる）。これまた、メッセージング的な設計だ。

検索も効率的だ。検索の結果が出たとき、そのメッセージをいちいちクリックして呼び出す必要がない。メッセージ中の、検索語の使われ方を見ることもできる（下図）。

ユーザと誰かとのあいだで使ったアタッチメントはすべてグループ化されるので、ある人と交換したPDFや写真などが、いわば、ソーシャルなフォルダの中へ入れられて共有される。

Yuen兄弟たちは、一緒に仕事をした経験が長い。彼らはTextPayMeという会社を始めたが、それはAmazonに買収された。PhilipはAmazonでモバイルのeコマースプロダクトの開発を担当した。その後Philipは、シアトルのZyngaでプロダクト担当のディレクター、Geraldはデザイナーとして働いた。二人は一緒にZyngaを辞めてWeMailに取り組んだ。

[原文へ]
（翻訳：iwatani(a.k.a. hiwa)）