coding, photo, plant and demo

*webkit-devで見るBlinkのフォーク

webkit 20130406 101009
ついにWebKitからGoogle勢が分裂してBlinkという新しいフォークが出来てしまった。
折りしもmozillaがレンダリングエンジンをRustで作り直すという挑戦的なニュースも重なり、
新年度早々Web業界ウォッチャーには衝撃が走った。

さて、このBlinkのフォーク騒動だけど、理由は大きく2つあると思う。
一つは、性能や安全性向上のためのリアーキが現状のWebKitのtrunkでは難しいから。
二つは、WebKitのコミュニティ上でのApple勢とGoogle勢の信頼関係が崩れたため。

一つ目の性能に関する理由は明白。Blinkの公式サイトにもあるような、iframeのsandbox化、ネットワークコードの簡潔化、DOMをJSヒープに移動させることによるDOM操作の高速化などを、様々な移植層に適合した形で実現するのは技術的にも政治的にも非常に難しいためだ。

そういったドラスティックな変更でも無くても、多くの移植層やビルド環境を維持しつつ開発を進めるのは、もはや現実的ではないともいえる。少なくともこれだけの環境を維持しなくてはいけないようだから、本当に開発は大変だと思う。


二つ目のApple勢とGoogle勢の信頼関係の揺らぎは、最近webkit-devで散見されていたのでそれを少し長くなるが書いておく。
まず年初にあったのが、AppleのAlexeyのコミットがchromium移植層でビルドブレイクを起こしたのに対して、GoogleのAdam Barthがブチぎれた件。

https://lists.webkit.org/pipermail/webkit-dev/2013-January/023509.html
[webkit-dev] Breaking other ports
Adam Barth abarth at webkit.org 
Tue Jan 29 17:46:50 PST 2013

I understand that the new "rules of the road" for WebKit2 are that
contributors are allowed to break non-Apple ports.  However, those new
norms do not extend to WebCore.

どうやらWebKit2(mac)の新しいルールってやつは、コントリビュータはアップル以外の移植層を壊しても良いってことのようだな。けど、そんな新しい基準を勝手にWebCoreにまで拡げるな。

In <http://trac.webkit.org/changeset/138962>, Alexey broke form
resubmission confirmation in the Chromium port.  In
<https://bugs.webkit.org/show_bug.cgi?id=108214>, he is refusing to
fix the regression.  I don't view that as acceptable behavior from a
member of the WebKit community.

r138962 でAlexyはchromiumポートのresubmission confirmationという機能を壊しやがった。
その上、bug108214 で彼はそのリグレッションの修正を拒んでいる。これはWebKitコミュニティのメンバーとして有るまじき行為ではないか。

補足すると、WebKitのソースコードは共通のWebCoreと環境ごとの移植層(ポート)の2つに分かれている。Googleはchromiumポートしか自社に関係ないし、Appleはmacポート(WebKit2)しか関係ない。しかし、WebKitにコミットする限りは、自分と関係ないポートの動作も維持し壊さないようにする必要がある。

だから、Adam Barthが「Appleの奴らがchromiumポートを壊しやがった上に、直しもしねえ!こんな奴がWebKitコミュニティに居ていいのか!?」と怒鳴り込んでいる理由も分からないでもない。
しかし、現実的な問題として、自分の専門外のポートのリグレッションを直すのは難しい。Alexyが件のbugで修正を拒否した際に述べたのは「私はクロスプラットフォームのマナーに沿って礼儀正しく実装しただけだ。chromiumポートがWebKitの流儀から外れた他のポートを無視した独りよがりな実装をしているのが問題なのだから責任が持てない」という内容だ。これはこれで一理あるように思えるが、双方、普通に考えたらもうちょっと友好的に物事を進められると思う。そうはいかないのは、コミュニティにそういった下地が既に在ったということだ。

続くメールでは外野が「わざとリグレッションを起こしたわけじゃないんだから」とか「逆にGoogleのコミットがAppleのポートを壊した事例もあるよ」等と理性的に相互理解を進めようともするが、円満解決とは行かなかったようだ。


その直後、GoogleのEric Seidelが「WebKitに望むこと」と題してポストした長文メールが印象的だ。
最初の2項目だけ引用する。

https://lists.webkit.org/pipermail/webkit-dev/2013-January/023530.html
[webkit-dev] WebKit Wishes
Eric Seidel eric at webkit.org 
Wed Jan 30 13:28:49 PST 2013

I wish we only had one build system (it were easy to add/remove/move files).

I believe changes like http://trac.webkit.org/changeset/74849 are an
unhealthy sign for the project.  Adam is not the only person who has chosen
to empty files instead of removing them.  The pain of updating 8 build
system is so great, we jump through hoops to avoid it.  Which means it took
us months to move JavaScriptCore/wtf to WTF, and will take us years to kill
WebCore/platform.

ビルドシステムを統一したい
1つファイルを加えるだけでも、ビルドシステムが8つあるから8つもプロジェクトファイルを更新しなくちゃいけない。
この調子じゃディレクトリ構成を変える作業は一体何年がかりになるんだろうね。

I wish I felt like reviewers understood/trusted each other more.

I’ve worked at both Apple and Google.  The WebKit community is full of
brilliant engineers.  Yet I frequently feel a lack of trust in my (or
others) judgement, or witness hot-headed remarks on bugs, lists or IRC.  I
don’t think it’s that people don’t trust me after nearly 8 years (!?) on
this project, but rather that we forget, or fail to communicate trust among
ourselves.  Social problems are perhaps harder to solve for us technical
types, but I worry that for many of us it’s just become “us” and “them” and
we’ve stopped trying.

もっとお互いに理解して信頼しよう
私はAppleとGoogleで働いたことがあるけど、WebKitコミュニティは凄いエンジニアだらけだ。
ただ、お互いに信頼関係が欠けた判断や、すこし短気なコメントをしばしば見かける。
8年近く!?も一緒にやってきたんだから信頼関係が無いわけじゃないと思うが、
それを忘れたら今の私たちの緊密な関係は崩れてしまう。
ソーシャルな問題はもしかすると、技術的な問題より解決が難しいのかもしれないけど、
それを我々が諦めて分裂しないかが心配だ。

引用していない部分ではApple側に対する苦情も含まれるものの、総じて建設的で良いことを言うなあ流石だなあ、と思いきや、このスレッドも炎上気味になる。

ビルドシステムの統一に関して、AppleとGoogleではどうも意見が平行する。Appleはxcodeを死守したいし、Googleはメタなビルドシステムで頑張って統一したらいいじゃん、という風潮。これに関しては僕はGoogle側の考えが正しいと思うが、Apple側の気持ちも分かる。

そしてまたすぐに問題が勃発する。
おそらく、これでGoogle側はフォークすることを決意したのではないだろうか。

https://lists.webkit.org/pipermail/webkit-dev/2013-February/023703.html
[webkit-dev] WebCore and interlocking threads
Adam Barth abarth at webkit.org 
Fri Feb 8 13:41:02 PST 2013

Context: https://bugs.webkit.org/show_bug.cgi?id=109071

Adam Barth said:
> It's not clear to me that running WebCore on multiple interlocked threads is a good idea.  That
> seems like a pretty major change to WebCore's architecture.  Is that something that's up for
> discussion?

Darin Adler said:
> I agree that it’s not something I’d do if I was starting a project now.
>
> In the iOS context, it’s fantastic for discussion as a possibly multi-year major architecture
> change, but if we take a hard line on this, then we won’t have the iOS port in the tree for
> years, and I think it would be good if we do. iOS WebKit has worked this way for the entire
> history of iPhone, so it’s not a change that can be made easily.

Darin Adler also said:
> I think where you and I may differ is on whether a good solution to the problem would be
> valuable to the WebKit project. Is there some way I convince you of the value of fitting
> an important existing port of WebKit into our tree in as clean as possible a way?

I don't really know how to respond to this thread.  I feel like I'm
being offered the following choice:

1) Give up the ability to have technical input to how WebCore works
and simply accept all the design choices made in the iOS fork, whether
they be good choices or bad.

2) Keep the iOS port in an Apple-internal fork for a number of years.

I feel like I'm being asked to make this choice in the context of a
growing trend of unilateral action by Apple in this project.  Given
that trend, I don't see how I can choose option (1).

As much as I would like the iOS port merged into trunk, I'm not
willing to give up having a technical say in the project.  Therefore,
reluctantly, I'm forced to choose option (2).

流れを要約すると、Appleの人がiOSポートのスレッドモデルの変更に関するコミットを入れようとしたところに、いつものGoogleのAdam Barthが「おいおい、新しいスレッドモデルなんて聞いてないぞ。webkit-devでちゃんと説明すべきじゃね?」と待ったをかけるも、Apple的には「外からは分からないiOSの都合で入れるものだから細かいことはいいんだよ、今までもこうだったし」というスタンス。Chromium特有のコミットは却下されている経緯もあり、そのダブルスタンダードとAppleのDarin Adlerの売り言葉にぶち切れてGoogleのAdam Barthが「それならもう全部iOSベースの設計にして他の技術を入れるの諦めたら?(つまり俺たちGoogleは出て行くぞ、ということ) それが嫌なら、iOSポートはAppleの内部フォークから出てくるな!」という趣旨の発言をする。Darin AdlerもAdam Barthも重鎮で、そこが修繕困難な言葉の応酬を始めてしまったわけだ。

AppleからすればWebKitは自分たちが作り上げたもので我々が主筋なのだから、郷に入れば郷のしきたりに従ってくれという感覚であろう。Googleからすれば散々こっちは貢献して既に対等な立場のはずなのに、Appleは相変わらず自分勝手すぎるという気持ちなのだろう。以上から、お互い相容れない主張を政治的に決着させることが難しく、感情的な問題にまで発展していったように見受けられる。


このようにBlinkの出現の2つの理由を挙げたが、これらは完全に独立な問題ではない。
コード上の問題があるから仲が悪くなるし、仲が悪いから融通が利かずさらにコード上の問題が解決しないのだ。これではこのまま一緒に開発を続けるのは難しいという判断になるのも致し方ないだろう。

しかしながら、Ericが言う様に数年間もの信頼関係があったのに、何故このタイミングで崩壊したのだろうか。それに関してはAndroidとChromiumの想定以上の成功が引き金になっているのだろう。ご存知の通り、GoogleがAndroidを始めそれがAppleを脅かす程までに成功した *0 ことによってAppleとGoogleというデバイス屋とサービス屋の蜜月関係に終止符が打たれた。そういえば最初は、AndroidがWebKitのblogで紹介されたり、

Android uses WebKit
Posted by David Carson on Monday, November 12th, 2007 at 5:01 pm
https://www.webkit.org/blog/142/android-uses-webkit

androidのポートがWebKitにマージされる等の牧歌的な雰囲気だったのにね。

とにかく、AndroidとChromiumは直接関係ないとはいえWebKitコミュニティとしては微妙な空気だよね?と誰しもが思っていたところで、AndroidはシェアでiOSを抜き去り、ChromiumもシェアではIEと双璧を成すブラウザとして破竹の勢いで普及してしまった。極めつけは、先月のGoogleのAndy Rubinに対する人事だろう。これにより、AndroidとChromeの統合が濃厚になった。こうなっては、微妙な立場であったChromiumもAppleにとって白黒着いたと言って良いだろう。

Blinkの発表があってから、webkit-devでは直ちに、Google関係のコードをWebKitから掃除する旨が流れた。
https://lists.webkit.org/pipermail/webkit-dev/2013-April/024388.html
[webkit-dev] Cleaning House
Geoffrey Garen ggaren at apple.com 
Thu Apr 4 00:30:10 PDT 2013

Hi folks.

Since we no longer need to support the Chromium port, let's take the opportunity to streamline. Hopefully, this will make development easier and more coherent for everyone. Adam and Eric offered to do some of this cleanup, but I think it's healthier for people who will continue to be a part of WebKit to decide what gets cleaned up, and execute on the plan.

Below is a high-level view of some improvements we're planning over the coming weeks.

Concepts we plan to remove:
Layering violations in WebCore/platform, where a Page* or Frame* is passed to a function
Supplementable and Supplement
#if USE(GOOGLEURL)
#if USE(V8)
#if !USE(JSC)
#if PLATFORM(CHROMIUM)
Skia
DOMFileSystem
WebLayer and its scrolling implementation
Features #defines that haven't gained traction

そしてフォークしたばかりで中身はWebKitそのままなblinkでも、WebKitの痕跡をなくすかの如き改革が一気に始まろうとしている。
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/oF5ziaOlkbk
Proposal: New directory structure for Blink

WebKitとBlinkは袂を分かった瞬間、拘束具が外れたかの如く猛烈にそれぞれの方向に進みだした。
一体これからどうなるのか、性能競争に加えコミュニティの動向も気になるところだ。


といいつつ、どうなるか予想を一応書いておくとすれば、Blinkの圧勝でしょう。
もはや開発力でもGoogleが上と見受けられるし、ChromeとAndroidに載せたらシェアでも圧倒するし。



注意:もっともらしく書いておりますが、あくまで外側から一ウォッチャーが見て思った推測にすぎません。反響が予想外に大きかったため、一個人の勝手な推測とはいえグーグルの方にはご迷惑をおかけしたかもしれません。申し訳ありません。 続く
*0 : Chrome OSのように鳴かず飛ばずだったら、今も関係は良好だったでしょうね...