Will *any* mobile OS emerge dominant by 2015?

How is that political? How is it nothing more than: uh, why would we spend more resources on this to do something you can do yourself?

Justin states this succinctly: "The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Members of the Chrome team were also interested in helping better incorporate Chrome's model into WebKit. So, I must be misunderstanding you, because it seems like you're suggesting that you expected Chrome engineers to simply do all the work."

From Shooti: "A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A (http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task."

Spinning this to be political when it's entirely a technical issue (specifically, the scale of the technological problem) is specious.

This move has major strategic implications. You think it was made by a bunch of engineers for purely technical reasons, and the strategic outcome it produces is just... what, incidental? I have a bridge to sell you. I'm honestly, even after watching people fall for Google's "We're the good guys! See! Source code!" schtick for years, sitting here with my mouth agape that people are falling even for this.

I think the people buying Google's line on this really, really need to step back and ask themselves: if Apple had just done this from their end, citing the exact same technical justification, would you really just accept that at face value? Because I'd bet almost anything that if that things had happened that way, this forum would be full of posts from people outraged about Apple undermining standards and speculating about how Apple was grabbing control in order to weaken the web as an alternative to its proprietary platform.

Based on the assumption that it can only be fixed by breaking changes. When I asked you to back that up you provided a link that also said some of it was plain and simple implementation bugs. It's like a battery bug or security bug: expected to be fixed in point releases, and it routinely is.

The claim that there's nothing to be done without breaking changes is not supported and not shared, and even if true doesn't justify Apple's behavior.

The same article notes that "many of iCloud’s syncing issues have been fixed". It sounds like Apple is working through and fixing the "simple implementation bugs". It follows that if a couple of years of this hasn't yet brought this technology up to the quality it should achieve, breaking changes might well be necessary to fix it.

Megalodon wrote:

Not seeing the difference. The issue is unacknowledged and unmitigated. Time to stop the bleeding.

Again, there are developers using this stuff in production. These are not showstopper bugs for every possible implementation. Somehow this argument has gone from "Apple's problem is that they try to polish things behind closed doors rather than letting people bang on them and provide feedback" to "Apple needs to pull this technology and polish it up behind closed doors rather than letting people bang on it".

Chrome had at the time of its launch a unique process model, so Google have only used Webkit for parsing and rendering. Now Webkit2 is mirroring some of that work but going about it in a way which conflicts with Google's approach. So reasonably enough Google are forking Webkit. That's exactly what is meant to happen to open source projects when different groups have different aims. Reading about what Google hopes to do with Blink it does make sense, particularly when considering that Google is using a lot of this work as the basis for an OS, not just a browser.

I think it's fairly clear that the decision to fork here is political, not technical.

How is that political? How is it nothing more than: uh, why would we spend more resources on this to do something you can do yourself?

Justin states this succinctly: "The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Members of the Chrome team were also interested in helping better incorporate Chrome's model into WebKit. So, I must be misunderstanding you, because it seems like you're suggesting that you expected Chrome engineers to simply do all the work."

From Shooti: "A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A (http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task."

Spinning this to be political when it's entirely a technical issue (specifically, the scale of the technological problem) is specious.

And as you could read in the rest of that thread, private conversations were more of a direct No according to the developer. Enough that he believed contributing it back would be like a 'hostile fork'. Not surprised you ignored that part, though.

Anyone that thinks if FB succeeds wildly with this and the majority of ad revenue on Android starts running through FB, that Google won't walk away is kidding themselves.

I think the chance of that is negligible.

Maybe in any one particular case, but it's not one case, is it? Facebook is hardly the only party attempting to co-opt Android. At some point Google could very well tire of enabling its competitors. If that happens, Google's involvement with Android, or the terms under which Google releases Android, could change significantly.

And now the personal experience for mobile that isn't constrained by being just another app on your phone is available only on Android.

I see the potential, why don't you see the potential for others to do the same.

What's so impersonal about the experience now? It's great that Facebook has build a great UI so your FB IM and news feed are always in your face. The design of the app is far more impressive than the task it completes IMHO. Let me be clear I think Facebook has started something very important that many other companies will follow. I'm sure they will get a decent amount of their users using Home but not the majority. FB reports to have over 1 billion active users and until someone shows other wise I don't think most of those users want to live in a FB world. For the users that do want to live in an FB world, I have no doubt that FB Home will be a great way to monetize them.

FunkTron wrote:

This is a slippery slope fallacy. The FB Android App, for instance, ain't going anywhere...

There's nothing that should logically lead you to believe that any of these companies are going to stop making the apps and start making launchers only.

Success. If this is successful for Facebook why would Twitter, Amazon, Tumblr, or any other service want the way their users interact with their app to go through an FB-centric UI. You can't on one hand act like this could be the next big thing and then on the other hand act like no one will follow them. The success you claim to see is the guarantor that others will follow them. This isn't a _slippery slope_ argument it's a _if this works others will copy them_ argument and I don't think that's a highly speculative thing to say.

FunkTron wrote:

B: I don't see a problem with that. It doesn't have to be "dueling" launchers, it can be "complementary" launchers.

I'm not saying it has to be duelling launchers but it will be because most companies are dicks. I'm sure as of right now there are many Android users that have more than one launcher on their phone and it causes them no issues. In part because they have knowingly downloaded more than one launcher and when they switch launchers they know they are _switching launchers_. However when most of the big media/social companies start shipping their own launchers because I assure you they will here from their customers a _desire for a more personal experience_. There will be novice users with more than one launcher on their phone because they won't distinguish them from apps. And because companies are dicks they will assume that a user that wants to use their app also wants to use their launcher. So some users will find themselves in changing environments based on the last app they used.

If FB succeeds with Home they will be but the first company to built a _company centric UI_. Amazon is clearly the main contender to follow and make a _Amazon Home launcher_ in fact I think they are way ahead than everyone else because they have already condition their users to accept ads on their home screen. FB still has to work towards that. If you think about it douche bag personal media companies trying to collect your personal info aren't even the best fit for _company themed launchers_. They are a much better fit for sports leagues in particular MLB. I can see a launcher centred around keeping an MLB fan up-to-date on their team and the league but not so intrusive that it gets in their way of using the phone doing very well.

If you really think the big brake through here is a more "personal experience for mobile that isn't constrained by being just another app". I don't understand why you can't see why everyone not just FB would want this kind of interaction with their service. The newsfeed on your home screen is meh IMHO. Facebook showing everyone that yes without out a doubt you can bend Android to your will and make it about your companies services and priorities. That's bad ass on FB's part. Someone might dismiss it as just another launcher, well I say FB has change the way other companies will look at Android development.

Google made this decision not in order to be able to reduce the complexity of a codebase, but in order to be able to assert more power over the future direction of the web.

That's the opposite of what they have said publicly, and I note that not everybody at that link agrees with the "facts".

When I read the exchange it seemed as if they were not talking about the same thing.

Loose Summary wrote:

Apple guy: We asked Google about using their code and we got a non-answer.

Google guy: The Chromium architecture was public and available.

The Google guy gave another non-answer IMHO, to me it kinda comes off like a talking point. You might ask why Apple would want a definite yes. I can only assume that because they keep a lot of Mobile Safari code to themselves, they would feel uncomfortable co-opting somebody else's code. Basically I think they're trying not to look and feel like hypocrites.

The Google guy gave another non-answer IMHO, to me it kinda comes off like a talking point. You might ask why Apple would want a definite yes. I can only assume that because they keep a lot of Mobile Safari code to themselves, they would feel uncomfortable co-opting somebody else's code. Basically I think they're trying not to look and feel like hypocrites.

More practically, it just seems like if a downstream project (Chromium, in this case) makes changes in project-specific code, the upstream project says "Hey, we'd like to pull those upstream", the downstream project says "Nah", and the upstream project goes ahead and does it anyway... collaboration probably stops at that point. The downstream project likely wouldn't simply accept the upstream project's implementation.

It seems fairly clear that Google wanted multiprocess support as a competitive advantage for Chrome, and that's what caused the technical split that Google is now using to justify what is, effectively, a massive power grab.

How is that political? How is it nothing more than: uh, why would we spend more resources on this to do something you can do yourself?

Justin states this succinctly: "The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Members of the Chrome team were also interested in helping better incorporate Chrome's model into WebKit. So, I must be misunderstanding you, because it seems like you're suggesting that you expected Chrome engineers to simply do all the work."

From Shooti: "A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A (http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task."

Spinning this to be political when it's entirely a technical issue (specifically, the scale of the technological problem) is specious.

This move has major strategic implications. You think it was made by a bunch of engineers for purely technical reasons, and the strategic outcome it produces is just... what, incidental? I have a bridge to sell you. I'm honestly, even after watching people fall for Google's "We're the good guys! See! Source code!" schtick for years, sitting here with my mouth agape that people are falling even for this.

I think the people buying Google's line on this really, really need to step back and ask themselves: if Apple had just done this from their end, citing the exact same technical justification, would you really just accept that at face value? Because I'd bet almost anything that if that things had happened that way, this forum would be full of posts from people outraged about Apple undermining standards and speculating about how Apple was grabbing control in order to weaken the web as an alternative to its proprietary platform.

I remember people being down on Apple for the code dump they did on the KHTML guys when they first shipped Safari. I remember people being pissed at Apple for making WebKit their own thing. I remember people being pissed at Apple for not writing WebKit code in such away that it was easily merged back into KHTML.

This Google guy may have misspoke but he seem clear on what he was saying. From the video Metasyntactic linked to.

Translation Google didn't give back their code to WebKit, I'm sure this too in some way makes them more open than Apple.

The Apple guy in the earlier linked thread stated that Apple asked if they could use the code. Google in this Q/A gets around that simple question by talking about the work they would have to do to integrate. This seems to be part of their talking points. But if Apple was willing to rewrite from scratch why should we believe that they were unwilling to do the integration work themselves. It seems to me that Google is talking pass the issue and continuing to not give a direct answer. Google has an advantage and they wanted to keep it to themselves, this is cool by me Apple is doing the same with Mobile Safari. Why Google continues to get away with this we are open BS is beyond me.

The Google guy gave another non-answer IMHO, to me it kinda comes off like a talking point. You might ask why Apple would want a definite yes. I can only assume that because they keep a lot of Mobile Safari code to themselves, they would feel uncomfortable co-opting somebody else's code. Basically I think they're trying not to look and feel like hypocrites.

More practically, it just seems like if a downstream project (Chromium, in this case) makes changes in project-specific code, the upstream project says "Hey, we'd like to pull those upstream", the downstream project says "Nah", and the upstream project goes ahead and does it anyway... collaboration probably stops at that point. The downstream project likely wouldn't simply accept the upstream project's implementation.

It seems fairly clear that Google wanted multiprocess support as a competitive advantage for Chrome, and that's what caused the technical split that Google is now using to justify what is, effectively, a massive power grab.

The only thing really interesting about Facebook Home is the chat heads. We might see this message UI pop-up in other skins, like HTC, Samsung or even stock android, iOS and windows phone if the concept prooves popular.

But I dont think Facebook Home will go anywhere for the reasons mentioned by many. It's one thing to browse your Feed, but to have it plastered all over your homescreen and lock screen. No thanks. Even with photography friends there that make the Facebook arty pictures look pretty tame.

I wonder how many Facebook employees will use it. I think they will be a minority, and that will tell FB more than enough.

Facebook should invest their resources into making a lean, light Facebook app for android. It crashes my phone more then once. And it's slow.

HTC's blinkfeed has more potential IMO, as it will bring a feed from different sources incl news outlets and is (and most likely will remain) without ads. It's also just one homescreen and not your entire homescreen + lockscreen. I would really be interested in this service if it would offer the feeds seperated: so i could have a few homescreens with my apps, one with a FB feed, one with a normal news feed, one with a tech newsfeed, and if you're a twitter user, one feed a twitter feed. Having them all lumped into one stream doesnt really work that well for me.

What I think is more important about this launch is perception. Perception is more and more that innovation takes place on the android platform. The last perceived innovation for iOS was Siri, which was an acquisition. If iOS 7 isnt fresh, with some new UI innovations and new features that turn heads instead of people shaking them, the perceived lack of innovation can start to reflect in power users dropping the iOS platform. And when the power users leave, the rest will follow sooner rather than later.

That said, I fully expect Apple to move iOS forward more aggressive this year, and the cheaper iphone will make the platform more accessible. I don't think Apple is in the danger zone but they will have to be more aggressive, and can't take their reputation for granted anymore.

My Gmail just got hacked, Google really needs to take security more seriously.

More seriously? Pinned certificates, DKIM, defaults to HTTPS, two factor authentication, activity monitoring, top-notch spam filtering, security notifications sent to mobiles, and that's just off the top of my head there may be more security features. Google has lead the way on securing webmail. Nothing's perfect, but I don't know of a better free webmail service.

My Gmail just got hacked, Google really needs to take security more seriously.

More seriously? Pinned certificates, DKIM, defaults to HTTPS, two factor authentication, activity monitoring, top-notch spam filtering, security notifications sent to mobiles, and that's just off the top of my head there may be more security features. Google has lead the way on securing webmail. Nothing's perfect, but I don't know of a better free webmail service.

My Gmail just got hacked, Google really needs to take security more seriously.

More seriously? Pinned certificates, DKIM, defaults to HTTPS, two factor authentication, activity monitoring, top-notch spam filtering, security notifications sent to mobiles, and that's just off the top of my head there may be more security features. Google has lead the way on securing webmail. Nothing's perfect, but I don't know of a better free webmail service.

Doesn't help if the computer has a trojan keylogger.

There is no security measure that works with user error.

Nice of both you guys to ignore that I also posted "Or you know I can live with the fact that everybody gets tagged." I'm clearly not blaming Google here, shit happens even with all the things ev9 listed. As for user error given I'm on a Mac and the account I use on a regular basis didn't get hacked. I think we can safely rule out a trojan keylogger. As for the "security question" it's something I made up and is a non sequitur that would only make sense to me so it wasn't that.

My Gmail just got hacked, Google really needs to take security more seriously.

More seriously? Pinned certificates, DKIM, defaults to HTTPS, two factor authentication, activity monitoring, top-notch spam filtering, security notifications sent to mobiles, and that's just off the top of my head there may be more security features. Google has lead the way on securing webmail. Nothing's perfect, but I don't know of a better free webmail service.

Doesn't help if the computer has a trojan keylogger.

There is no security measure that works with user error.

How does a keylogger get past my phone telling me someone is trying to access my gmail from Romania?

My Gmail just got hacked, Google really needs to take security more seriously.

They take it pretty seriously. They support 2 factor auth and high quality randomly generated application specific passwords if you have stuff that doesn't support 2 factor. Another weak spot can be your backup e-mail getting hacked.

I would recommend reviewing your backup e-mail and enabling 2 factor auth. Use a good password not shared with other sites.

ZnU wrote:

It seems fairly clear that Google wanted multiprocess support as a competitive advantage for Chrome, and that's what caused the technical split that Google is now using to justify what is, effectively, a massive power grab.

The power grab was doing the most work to make the best browser. It's LGPL so they can't keep it locked away, but Google isn't obliged to let their schedule slip to catch everyone else up. Apple is free to use Blink just like Opera will, but somehow I doubt they will.

This is what happens in the open source world when one party does the vast majority of the work.

ZnU wrote:

Maybe in any one particular case, but it's not one case, is it? Facebook is hardly the only party attempting to co-opt Android. At some point Google could very well tire of enabling its competitors. If that happens, Google's involvement with Android, or the terms under which Google releases Android, could change significantly.

I notice the description of this scenario is heavily couched in conditionals.

For this to be a credible threat you'd need companies offering a shit ton of value within their own platforms, to the point where people spend all day on substantially that. The list of companies with something that offers that is pretty short. If you look at Facebook's m-site numbers versus app numbers versus secondary app numbers, it's damn difficult to make the case that they've got the kinds of numbers looking to be even more immersed to make Google take their ball and go home. Same with Kindle.

At every step where Google bets on common infrastructure, they're betting they benefit enough to be worth it even if others benefit too. Chrome, Android, Google Fiber, they all have the potential to benefit competitors.

ZnU wrote:

'Walled garden' platforms help significantly with this problem, actually, though I guess it's anathema around here to point out that they're not pure evil.

The power grab was doing the most work to make the best browser. It's LGPL so they can't keep it locked away, but Google isn't obliged to let their schedule slip to catch everyone else up.

As Dr. M pointed out, the fact that Apple was willing to implement multiprocess support from scratch in the upstream project suggests they would have been willing to do the work to port the multiprocess code from Chromium. And we have a WebKit developer saying this is probably just what they'd have done, if Google had given them the go ahead.

Megalodon wrote:

Apple is free to use Blink just like Opera will, but somehow I doubt they will.

Yeah, imagine declining to follow a hostile fork initiated by a competitor attempting a power grab. Apple is so arrogant.

Megalodon wrote:

This is what happens in the open source world when one party does the vast majority of the work.

It's true that Google commits did overtake Apple commits in the last couple of years, but this makes it sound like Apple wasn't still making significant contributions, which is not the case.

At least you're not trying to push the "It was a purely technical decision made entirely by engineers" line.

Megalodon wrote:

I notice the description of this scenario is heavily couched in conditionals.

It's a statement about the future, in an unpredictable market.

Megalodon wrote:

For this to be a credible threat you'd need companies offering a shit ton of value within their own platforms, to the point where people spend all day on substantially that. The list of companies with something that offers that is pretty short. If you look at Facebook's m-site numbers versus app numbers versus secondary app numbers, it's damn difficult to make the case that they've got the kinds of numbers looking to be even more immersed to make Google take their ball and go home. Same with Kindle.

At every step where Google bets on common infrastructure, they're betting they benefit enough to be worth it even if others benefit too. Chrome, Android, Google Fiber, they all have the potential to benefit competitors.

I think there's a pretty big difference between providing neutral infrastructure (i.e. a browser or an Internet connection that can be used to visit any site) and providing infrastructure that can be actively turned against you (i.e. an operating system on which competitors can build shells designed to divert users away from your services).

How is that political? How is it nothing more than: uh, why would we spend more resources on this to do something you can do yourself?

Justin states this succinctly: "The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Members of the Chrome team were also interested in helping better incorporate Chrome's model into WebKit. So, I must be misunderstanding you, because it seems like you're suggesting that you expected Chrome engineers to simply do all the work."

From Shooti: "A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A (http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task."

Spinning this to be political when it's entirely a technical issue (specifically, the scale of the technological problem) is specious.

This move has major strategic implications. You think it was made by a bunch of engineers for purely technical reasons, and the strategic outcome it produces is just... what, incidental?

So... the G engineers are just beholden to anyone wanting them to do work on their behalf? WTF?

The G code is *open source*. Claiming it's political that people make code available but then don't do the work you want is ridiculous.

Quote:

I have a bridge to sell you. I'm honestly, even after watching people fall for Google's "We're the good guys! See! Source code!" schtick for years, sitting here with my mouth agape that people are falling even for this.

I think the people buying Google's line on this really, really need to step back and ask themselves: if Apple had just done this from their end, citing the exact same technical justification, would you really just accept that at face value?

Of course. You know why? Because i'm a software developer that works on open source software. So G's position makes *complete fucking sense*. It would make sense from any developer.

What do you think open source is? A system whereby people just can be commanded by you to do what you want willy nilly?

The Google guy gave another non-answer IMHO, to me it kinda comes off like a talking point. You might ask why Apple would want a definite yes. I can only assume that because they keep a lot of Mobile Safari code to themselves, they would feel uncomfortable co-opting somebody else's code. Basically I think they're trying not to look and feel like hypocrites.

More practically, it just seems like if a downstream project (Chromium, in this case) makes changes in project-specific code, the upstream project says "Hey, we'd like to pull those upstream", the downstream project says "Nah",

I don't think you understand how open source works. How is the downstream project going to say 'nah' to you pulling those changes upstream? They may say "we're not going to do the work for you". I've had people do the same thing with me. I point them at my sources, give them my best, and go on my way.

Quote:

and the upstream project goes ahead and does it anyway... collaboration probably stops at that point. The downstream project likely wouldn't simply accept the upstream project's implementation.

Right. That's how open source *works*. Different projects decide if they want to take implementations from other projects. You have to decide if the effort is worth it, and if the code itself has enough value to you.

FFS, that's why we have different projects out there. Otherwise open source would be one big repo with every developer checking into one big project.

Do you think Linus (who controls probably the most important FOSS project out there) just goes and pushes and pulls code at any random say so? No. He has to weigh out the technical benefits and the technical costs involved with every request.

Quote:

and that's what caused the technical split that Google is now using to justify what is, effectively, a massive power grab.

The power grab was doing the most work to make the best browser. It's LGPL so they can't keep it locked away, but Google isn't obliged to let their schedule slip to catch everyone else up.

As Dr. M pointed out, the fact that Apple was willing to implement multiprocess support from scratch in the upstream project suggests they would have been willing to do the work to port the multiprocess code from Chromium. And we have a WebKit developer saying this is probably just what they'd have done, if Google had given them the go ahead.

I don't think you understand. Why would google need to "give them the go ahead"?

That very statement doesn't make sense.

So which is more reasonable? We ahve two accounts of the situation. One is someone saying they wanted X to happen, but couldn't because they didn't get the 'go ahead' (even though they didn't need that). And the other says 'sure, we were asked. But it seemed like they were asking us to do the work. We didn't have the time or inclination, so we declined'.

The first position just doesn't jive with how this works in reality. If you want to do something like this, *you just do it*. It happens all the time. And it's one of the positive aspects of open source. The second position *completely jives with reality*. Something is possible, but people want *you* to do the work. You aren't interested, so you say 'no'.

You have two accounts here, one which makes no sense, and which which does. And you're going with the one that doesn't make sense.

At least you're not trying to push the "It was a purely technical decision made entirely by engineers" line.

Occam's razor.

There isn't any explanation that makes any more sense. You've talked about a specific engineer's claims which both:a) have been refuted by others.b) literally don't make sense.

Furthermore, despite this, you've taken this position over the far more likely (and rational) explanation for the events. You're literally pushing the following narrative:

WebKit engineer: We sure would love some of that multi process love.Google engineer: Nope.WebKit engineer: Oh well... guess it can't happen. After all, it's not like that stuff is open source. Right? Right?

Versus:

WebKit engineer: We sure would love some of that multi process love. Can you make that happen for us?Google engineer: Us? Not really. We're busy. But if you like it, you can certainly take it. That's why it's open source after all.WebKit engineer: Oh well... we don't have the time either. And we were really hoping you'd do it. Guess it's not going to happen then.Google engineer: Probably not.

You seem to live in some sort of bizarro reality where not only are there engineers sitting around with copious amounts of free time on their hand to do this sort of work. But that the creators of the work are also somehow beholden to *other* projects. It works the *opposite* way. If the WebKit guys want to pull code into their project *they* need to make sure the appropriate resources are available. This is how *all major open source projects work*.

"Are you aware of the earlier conversation that occurred before we wrote any lines of code or even had a name? Where we talked about the possibility of just using Chromium's model if Google was willing to contribute it back? I have mentioned it twice - maybe you overlooked those parts of my remarks."

He's blatant about it. Justin sensibly responds back:

"The Chromium code is all in a public repository and was already integrated into WebKit via Chrome's platform layer. Members of the Chrome team were also interested in helping better incorporate Chrome's model into WebKit. So, I must be misunderstanding you, because it seems like you're suggesting that you expected Chrome engineers to simply do all the work."

And another followup mentioning what G engineers had to say:

"A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A (http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task."

--

And, here's the rub. You claim the issue is *political* and not *technical*. if things were so technically simple, then WebKit would have simply adopted the chromium process model. This is what Justin already says was a desirable outcome of *having chromium be open source* and having the entire platform layer *anyways*.

You are arguing it wasn't a technical issue, even though *if it wasn't technical* then it would have been done. on hte other hand, you have actual engineers saying *it's a scale/complexity problem*.

So, either it's non-technical, in which case none of the decisions make sense (*and* the G engineers are lying, *and* the WebKit engineers are incompetent). *Or* it is technical, and the decisions are sane, the G engineers were telling the truth about the scale of the work, and it makes sense that hte WebKit guys wouldn't then want to do that work themselves either.

Somehow this argument has gone from "Apple's problem is that they try to polish things behind closed doors rather than letting people bang on them and provide feedback" to "Apple needs to pull this technology and polish it up behind closed doors rather than letting people bang on it".

You're ignoring an additional dimension to this to make it appear to be contradictory, but what they ought to be doing is polishing in broad daylight as part of an escalating test.

ZnU wrote:

As Dr. M pointed out, the fact that Apple was willing to implement multiprocess support from scratch in the upstream project suggests they would have been willing to do the work to port the multiprocess code from Chromium. And we have a WebKit developer saying this is probably just what they'd have done, if Google had given them the go ahead.

This makes no sense. Like none.

-Google never had the ability to deny the code to others. It was always open sourced, just not backported.-You say using it without permission would have scuttled the collaboration. The fork does that with far greater certainty. Meaning the barrier to using multiprocess code is reduced according to how you say things work, not increased.-Webkit2 has multiprocess support. Even if Google said no and even if that was binding, the damage was done then, forking now doesn't advance that alleged agenda.

ZnU wrote:

I think there's a pretty big difference between providing neutral infrastructure (i.e. a browser or an Internet connection that can be used to visit any site) and providing infrastructure that can be actively turned against you (i.e. an operating system on which competitors can build shells designed to divert users away from your services).

Wrong by virtue of the fact that browsers and internet connections absolutely can be turned against you.

It doesn't matter if the code was public if Google didn't submit the code back to WebKit then it wasn't part of the WebKet project. I'm unaware of Apple taking code from the V8 JavaScript Engine also. I am unaware of a history in the open source movement of one project willy-nilly highjacking the work of another project. If someone wants to work with you they submit code like Google did with WebCore. If they don't want to work with you they don't and you move on, you don't start a fight by taking their code. The fact that Google was so prolific with their submissions only adds to the impression that they wanted to keep that particular bit of code to themselves.

Metasyntactic wrote:

"A request for clarification on why they refused was posed to a Chrome engineer in todays Blink Q&A (http://www.youtube.com/watch?v=TlJob8K_OwE#t=13m34s), and according to him the request for integration came shortly after Chrome was released, and the reason for their refusal was the sheer scale/complexity of the task.".

Google clearly new how to submit code to the WebKit project and given that Apple of all companies would not have a leg to stand on if Google did a massive code dump. I see no reason why Google couldn't have submitted the code and leave it up to the WebKit maintainers to decide what to do with it. That's what Apple did to KHTML. Google had an advantage and they kept it to themselves, why is this so hard for people to believe. Do people really think only Apple is capable of this kind of thing.

Metasyntactic wrote:

And, here's the rub. You claim the issue is *political* and not *technical*. if things were so technically simple, then WebKit would have simply adopted the chromium process model. This is what Justin already says was a desirable outcome of *having chromium be open source* and having the entire platform layer *anyways*.

The politics happened when Google kept their multiprocess support to themselves. The moment that happen a fork was inevitable. If they wanted that support in WebKit they would have submitted the code. They didn't submit the code therefore the only reasonable conclusion is that they didn't want to share.

It doesn't matter if the code was public if Google didn't submit the code back to WebKit then it wasn't part of the WebKet project. I'm unaware of Apple taking code from the V8 JavaScript Engine also. I am unaware of a history in the open source movement of one project willy-nilly highjacking the work of another project. If someone wants to work with you they submit code like Google did with WebCore. If they don't want to work with you they don't and you move on, you don't start a fight by taking their code.

WTF? It's Open Source! The entire fucking point of being open is so that your code can be taken!

Quote:

The fact that Google was so prolific with their submissions only adds to the impression that they wanted to keep that particular bit of code to themselves.

We have literally entered bizarro land. A land where a project is open sourced, yet because the maintainers work on it actively, that somehow equates to them wanting to keep the code to themselves.

You know what? I work on an open source project that is prolifically updated by the maintainers. And it's also been forked *dozens* of times. So what?

Quote:

Google clearly new how to submit code to the WebKit project and given that Apple of all companies would not have a leg to stand on if Google did a massive code dump. I see no reason why Google couldn't have submitted the code and leave it up to the WebKit maintainers to decide what to do with it.

Except... you know... the time and resources involved in doing that. Do you not have a job? Imagine if someone just said: oh hey Dr. M, we need you to keep on doing everything you're doing. And at the same time take on all this additional work for this other project. One you're not responsible for.

Quote:

Google had an advantage and they kept it to themselves,

...

They kept it to themselves? Are you fucking kidding me? They kept it to themselves so well that i can just go and browse the sources and incorporate them into my own project if that's what *i* want to do. I just can't go to google and say "yo, G engineers. Would yo umind terribly coming over and incorporating all your code into my project, like now?"

Quote:

why is this so hard for people to believe.

Because it is literally non-sensical.

Quote:

Metasyntactic wrote:

And, here's the rub. You claim the issue is *political* and not *technical*. if things were so technically simple, then WebKit would have simply adopted the chromium process model. This is what Justin already says was a desirable outcome of *having chromium be open source* and having the entire platform layer *anyways*.

The politics happened when Google kept their multiprocess support to themselves.

But they *didn't*. Your sentence doesn't even make sense. How on earth is Google able to keep their multiprocess support to themselves?

Quote:

The moment that happen a fork was inevitable. If they wanted that support in WebKit they would have submitted the code.

Again, that doesn't mean it's *political*. Doing all the work to get that code into WebKit is a large *technical* undertaking.

Quote:

They didn't submit the code therefore the only reasonable conclusion is that they didn't want to share.

[/quote]Gee... that makes sense. They didn't want to share. SO THEY OPEN SOURCED THE F***ING THING.

I am unaware of a history in the open source movement of one project willy-nilly highjacking the work of another project.

In that case, you need to understand Open Source licensing more fully. What you say may be true of the regular GNU license, but WebKit is the the "lesser" or "library" license and it has what it itself proclaims are weaker terms than the regular GPL. Those terms are harder to follow, but they are certainly not the same. Those actually in the field, however, are quite conversant in them. It's been a while, but I found language that seems to permit what you dislike, actually.

Moreover, what you decry is explicitly permitted by the Apache or BSD style licensing. I've seen it happen, too. It's one reason BSD licensing exists. To permit that very thing.

Not all open source works the same way. It is extraordinarily unlikely that Google is violating the license terms. Lots of big companies who violate these licenses have been sued over it and, in fact, have been brought to terms with them. Can you point to anyone suing Google over this? Does the suit, if it exists, appear to have merit?

FSF isn't shy about suing erstwhile friends, if that's what it takes to keep things whole.

The Google guy gave another non-answer IMHO, to me it kinda comes off like a talking point. You might ask why Apple would want a definite yes. I can only assume that because they keep a lot of Mobile Safari code to themselves, they would feel uncomfortable co-opting somebody else's code. Basically I think they're trying not to look and feel like hypocrites.

More practically, it just seems like if a downstream project (Chromium, in this case) makes changes in project-specific code, the upstream project says "Hey, we'd like to pull those upstream", the downstream project says "Nah", and the upstream project goes ahead and does it anyway... collaboration probably stops at that point. The downstream project likely wouldn't simply accept the upstream project's implementation.

It seems fairly clear that Google wanted multiprocess support as a competitive advantage for Chrome, and that's what caused the technical split that Google is now using to justify what is, effectively, a massive power grab.

I actually asked some of the Chromium open source people about this a couple months ago, and their answer is that they disliked the way the Safari implementation worked when combined with how they'd designed Chrome. They said that it had been easier to just develop their own system then try and hack the existing one into what they were already doing.

I guess they could have been lying to me but since this was a private conversation with friends long before any fork was announced I suspect that simple reality of engineering such a complex system determined what they did.

Edit: holy crap I just read a page up and saw this trainwreck. This thread is crazy stupid.

That's not quite right. It's thematically right in the sense that Android incorporated Linux without anyone's permission.

But, in the sense the DR. M seems to be complaining about people, namely playing fast and loose with licensing ("stealing code") in some sense, it's not true. AFAICT, Google's use of Linux is consistent with hundreds of other uses. As long as you do the "give back" for GPL'ed code, you're fine. Never heard anything to the contrary here and there's no reason to expect it.

But yeah, with all those BSD-style licenses out there, it's quite possible and normal for the code (in those cases) to simply be picked up, modified "willy-nilly") and then not given back to anyone.

If we worked at it, we could probably come up with ten or fifteen prominent examples. Everyone and his dog in the embedded world has probably used Free BSD as the basis for something.

That's not quite right. It's thematically right in the sense that Android incorporated Linux without anyone's permission.

But, in the sense the DR. M seems to be complaining about people, namely playing fast and loose with licensing ("stealing code") in some sense, it's not true. AFAICT, Google's use of Linux is consistent with hundreds of other uses. As long as you do the "give back" for GPL'ed code, you're fine.

But he does complain about google giving back too much code so I don't think thats the case. I think hes actually saying that you shouldn't contribute to a project unless the founders ask you to, or at least you should avoid giving back too much code so that the people who were there first can continue to do most of the work? I think his idea of hijacking a project is contributing a lot to it so that you start to shape and lead it. I don't know though, that whole post is basically insane.

The whole concept of 'permission' or 'asking' is utterly bizarre in this conversation. The *central* concept behind Open Source is the *license*. The license specifies *precisely* what someone can/can't/should/shouldn't/may/mayn't do. When i put all the information in my license, there's no need to 'ask for permission'. The license tells you precisely how you are permitted to use my code. And if you follow the license, then things are fine *full stop*. If you do not follow the license, then there is a problem *full stop*.

Hijack: "Illegally seize ... and force it to go to a different destination or use it for one's own purposes."

Illegal? Nope. All completely legal and *acceptable* actions based on the license.Seized? Nope. How the f*** do you seize an open source project?Forcing it to go to a different destination? Nope. You're making your own decisions with your copy of the source. You cannot force the maintainers to do anything.use it for one's own purpose? Nope. You only control your copy. You don't control the original.

FFS. "Hijack"? Really? Just using this term indicates a complete lack of understanding on how Open Source projects and licensing work.

So... the G engineers are just beholden to anyone wanting them to do work on their behalf? WTF?

The G code is *open source*. Claiming it's political that people make code available but then don't do the work you want is ridiculous.

This whole "Apple wanted Google to do all the integration work" thing appears to have been made up out of whole cloth. Again, after being rebuffed by Google, WebKit developers went and implemented their own multiprocess architecture. If they were willing to do the work on that, there's no reason to believe they weren't willing to do the work on integrating Google's code. And we've got a WebKit developer who says that yes, they were willing.

Metasyntactic wrote:

I don't think you understand. Why would google need to "give them the go ahead"?

That very statement doesn't make sense.

It only doesn't make sense if you focus entirely on what the license permitted and completely ignore the collaborative relationships surrounding WebKit.

Megalodon wrote:

-You say using it without permission would have scuttled the collaboration. The fork does that with far greater certainty. Meaning the barrier to using multiprocess code is reduced according to how you say things work, not increased.

This only makes sense if you take Google at its word that a fork was necessary because maintaining support for two multiprocess models was technically infeasible. If you don't buy that, then the situation is that while using the code over the objections of its authors would have likely scuttled collaboration, creating an alternate multiprocess model allowed continued collaboration.

Megalodon wrote:

-Webkit2 has multiprocess support. Even if Google said no and even if that was binding, the damage was done then, forking now doesn't advance that alleged agenda.

It's not my position that Google is forking now to deny multiprocess support to WebKit. It's my position that Google is forking now to wield more power over the future of the web, and the entire multiprocess issue, which Google has used to claim the fork is purely technical, is a red herring.

Megalodon wrote:

Wrong by virtue of the fact that browsers and internet connections absolutely can be turned against you.

Again, there's a difference between releasing stuff users can use to access your competitors' products, and releasing stuff your competitors can highjack and turn into their own products.

(I suppose technically Amazon, Facebook, etc. could have done this with Chrome and released their own browsers, but there were already credible open source browsers they could have done that with before Chrome showed up, so Google wasn't providing them with a new capability in that case.)