6 ms·

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contribute

As long as we are recapitulating history - the main reason we built a new multiprocess architecture is that Chromium's multiprocess support was never contributed to the WebKit project. It has always lived in the separate Chromium tree, making it pretty hard to use for non-Chrome purposes. Before we wrote a single line of what would become WebKit2 we directly asked Google folks if they would be willing to contribute their multiprocess support back to WebKit, so that we could build on it. They said no. At that point, our choices were to do a hostile fork of Chromium into the WebKit tree, write our own process model, or live with being single-process forever. (At the time, there wasn't really an API-stable layer of the Chromium stack that packaged the process support.) Writing our own seemed like the least bad approach. If Google had upstreamed their multiprocess support, we almost surely would have built on it. And history might have turned out differently. I'd also add that I disagree with Mike about the architectures being really different. In fact, they are quite similar in broad strokes, but with many differences in details (and with the significant difference that the Chromium model isn't in WebKit per se).

Me1000 14y ago
I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.
- itafroma 14y ago
  A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project. It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split. Compare to forking to solve a very specific or specialized problem that doesn't make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case. In such a case, it's common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don't diverge too much.
- deleted 14y ago
  [deleted]
- othermaciej 14y ago
  If we took Chromium's multiprocess code and put it in the WebKit tree after the Chrome folks specifically said they did not want to do that, that would have been super rude. Don't you think? That's why I say "hostile fork". I am judging our own path not chosen, and do not mean to cast aspersions on Google's actions. To be clear, I do not consider Blink to be a hostile fork. I wish the Blink developers good luck & godspeed.
  - ferongr 14y ago
    >that would have been super rude. Don't you think? As long as the license allows it and the maintainer is not burdened in any way, no?
    - r00fus 14y ago
      Just because you can do something, doesn't mean you should. To do an action without considering the consequences is foolhardy.
- PuercoPop 14y ago
  You could see the history between xMule and aMule for a hostile fork. Or the history between ffmpeg and libav, where some contributors where denied access to the repo.
justinschuh 14y ago
I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration. I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated. http://goo.gl/KH1Sr http://goo.gl/KH1Sr Eventually all non-Apple contributors were cut off entirely from WebKit2 as a matter of policy. http://goo.gl/iTDAR http://goo.gl/iTDAR
- othermaciej 14y ago
  We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. I don't know if the contents of these conversations were ever shared with the whole Chrome team as som Chrome people seemed super surprised at our announcement. It is true that when we announced our effort, it came with a rough working prototype and not just an empty directory. Basically because we did not know if we could do it until we tried. BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was. Google had the right to make their choices and we had the right to make ours.
  - justinschuh 14y ago
    >We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. Yes, I'm aware of that, but the work had been underway for a long time and was about to be dropped by the time there was a real heads up. So the core of the architecture was already being frozen from a larger perspective. >BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was. I don't interpret Mike's comments that way. Chromium's architecture was public and available, but we assumed it wasn't used because it didn't fit the needs of WebKit2. There's no malice in that. We designed Chromium from the beginning for SFI (as Adam tried to convey), and that incurs quite a bit of complexity. I'm comfortable that the divergence was simply a result of different needs. I just don't see how it could be presented as something malicious or anti-collaborative.
bazaarsoft 14y ago
Open always wins.
amsjohns 14y ago
This is a sad day. I always believed (hoped) you guys would never be corrupted and do the right thing for the world and not be swayed by organizational affinities / commercial gains. You have a greater responsibility than to your company or country to keep the web open. Think on that before you have a further public 'kiddy debate' on she said / he said and throwing the rattle out of the pram. Disappointed.

Me1000 14y ago

I'm no stranger to open source, but can you please explain what a "hostile fork" is? Especially in this context, it just seems like diction for the sole purpose of making Google look like they were 'in the wrong' in that situation.

itafroma 14y ago
A hostile fork is one done unilaterally, generally without consultation or the blessing of the main project. It generally causes acrimony and community fragmentation, and usually no code changes are shared between the forks after the split. Compare to forking to solve a very specific or specialized problem that doesn't make sense to merge upstream, like a set of changes that only apply to a very narrow audience or esoteric use-case. In such a case, it's common that changes that do affect the main project are still merged upstream and special care is done to make sure the forks don't diverge too much.
deleted 14y ago
[deleted]
othermaciej 14y ago
If we took Chromium's multiprocess code and put it in the WebKit tree after the Chrome folks specifically said they did not want to do that, that would have been super rude. Don't you think? That's why I say "hostile fork". I am judging our own path not chosen, and do not mean to cast aspersions on Google's actions. To be clear, I do not consider Blink to be a hostile fork. I wish the Blink developers good luck & godspeed.
- ferongr 14y ago
  >that would have been super rude. Don't you think? As long as the license allows it and the maintainer is not burdened in any way, no?
  - r00fus 14y ago
    Just because you can do something, doesn't mean you should. To do an action without considering the consequences is foolhardy.
PuercoPop 14y ago
You could see the history between xMule and aMule for a hostile fork. Or the history between ffmpeg and libav, where some contributors where denied access to the repo.

justinschuh 14y ago

I don't understand this claim. WebKit2 was landed with effectively no notice and no attempts at collaboration. I saw repeated attempts to work on a shared architecture in WebKit2, but none were reciprocated. http://goo.gl/KH1Sr http://goo.gl/KH1Sr Eventually all non-Apple contributors were cut off entirely from WebKit2 as a matter of policy. http://goo.gl/iTDAR http://goo.gl/iTDAR

othermaciej 14y ago
We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. I don't know if the contents of these conversations were ever shared with the whole Chrome team as som Chrome people seemed super surprised at our announcement. It is true that when we announced our effort, it came with a rough working prototype and not just an empty directory. Basically because we did not know if we could do it until we tried. BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was. Google had the right to make their choices and we had the right to make ours.
- justinschuh 14y ago
  >We talked privately with particular Chrome folks before we started (as described upthread), in the middle, and shortly before landing to mention that we were landing soon. Yes, I'm aware of that, but the work had been underway for a long time and was about to be dropped by the time there was a real heads up. So the core of the architecture was already being frozen from a larger perspective. >BTW I am not trying to pick a fight here. I think mikewest's comment gave the impression that Apple built a multiprocess architecture out of cussedness or NIH. But that's not how it was. I don't interpret Mike's comments that way. Chromium's architecture was public and available, but we assumed it wasn't used because it didn't fit the needs of WebKit2. There's no malice in that. We designed Chromium from the beginning for SFI (as Adam tried to convey), and that incurs quite a bit of complexity. I'm comfortable that the divergence was simply a result of different needs. I just don't see how it could be presented as something malicious or anti-collaborative.

bazaarsoft 14y ago

Open always wins.

amsjohns 14y ago

This is a sad day. I always believed (hoped) you guys would never be corrupted and do the right thing for the world and not be swayed by organizational affinities / commercial gains. You have a greater responsibility than to your company or country to keep the web open. Think on that before you have a further public 'kiddy debate' on she said / he said and throwing the rattle out of the pram. Disappointed.