Fork Webkit

[Daniel Hendrycks]

Hi, could you please fork WebKit? When Chrome/ium did not go with
WebKit's JS engine things turned out great, and now V8 is the fastest/
second fastest (V8 and Carakan are too close) engine out there, this
shows great things can come from the Chrome team and developers when
they work together. Forking WebKit would make Chrome free from Apple,
since Apple could make it proprietary http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=85041789
. Additionally, Chrome would make the web better by doing this; this
would better prevent a monoculture (remember Flash and IE6?).

Competition is absurdly good for the web. Thank you for listening!

[Aaron Toponce]

On 11/25/2010 11:23 AM, Daniel Hendrycks wrote:
> Hi, could you please fork WebKit? When Chrome/ium did not go with
> WebKit's JS engine things turned out great, and now V8 is the fastest/
> second fastest (V8 and Carakan are too close) engine out there, this
> shows great things can come from the Chrome team and developers when
> they work together. Forking WebKit would make Chrome free from Apple,
> since Apple could make it proprietary http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=85041789
> . Additionally, Chrome would make the web better by doing this; this
> would better prevent a monoculture (remember Flash and IE6?).

You must not be familiar with how software licensing works, specifically
with regards to Webkit.

First, Webkit is licensed under the GNU LGPL and BSD licenses. This
means Apple can take it proprietary anyway, and no one will care. After
all, the licenses specifically allow for this to happen.

Second, Apple isn't the only developer of the product. KDE, Nokia,
Google, RIM, Palm, Samsung and many others have their hands deep in the
code. If Apple does take their code closed, they'll be forking Webkit,
not the other way around. Everyone else will continue pushing forth with
the open code already in the repository, and Apple will be the one that
suffers with their Safari browser, and other applications that rely on
the Webkit base.

--
. O . O . O . . O O . . . O .
. . O . O O O . O . O O . . O
O O O . O . . O O O O . O O O

[Daniel Hendrycks]

On Nov 26, 11:11 am, Aaron Toponce <aaron.topo...@gmail.com> wrote:
> On 11/25/2010 11:23 AM, Daniel Hendrycks wrote:
>
> > Hi, could you please fork WebKit? When Chrome/ium did not go with
> > WebKit's JS engine things turned out great, and now V8 is the fastest/
> > second fastest (V8 and Carakan are too close) engine out there, this
> > shows great things can come from the Chrome team and developers when
> > they work together. Forking WebKit would make Chrome free from Apple,

> > since Apple could make it proprietaryhttp://tarr.uspto.gov/servlet/tarr?regser=serial&entry=85041789

> > . Additionally, Chrome would make the web better by doing this; this
> > would better prevent a monoculture (remember Flash and IE6?).
>
> You must not be familiar with how software licensing works, specifically
> with regards to Webkit.
>
> First, Webkit is licensed under the GNU LGPL and BSD licenses. This
> means Apple can take it proprietary anyway, and no one will care. After
> all, the licenses specifically allow for this to happen.
>
> Second, Apple isn't the only developer of the product. KDE, Nokia,
> Google, RIM, Palm, Samsung and many others have their hands deep in the
> code. If Apple does take their code closed, they'll be forking Webkit,
> not the other way around. Everyone else will continue pushing forth with
> the open code already in the repository, and Apple will be the one that
> suffers with their Safari browser, and other applications that rely on
> the Webkit base.
>
> --
> . O .   O . O   . . O   O . .   . O .
> . . O   . O O   O . O   . O O   . . O
> O O O   . O .   . O O   O O .   O O O

Thank you for that clarification, that still does not diminish the
pluses for forking WebKit; but it eliminates that one. Still,
monoculture.

[Peter Beverloo]

--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
   http://groups.google.com/a/chromium.org/group/chromium-discuss

What monoculture are you talking about? There are two engines which are larger than WebKit: Trident, used in Microsoft Internet Explorer, and Gecko, used in Mozilla Firefox. There are two other large engines around as well, being Presto, used in Opera and KHTML, still being used by the KDE project. Even though WebKit was based on the latter, internally both have changed significantly in the past eight years.

Regards,

Peter Beverloo

[Daniel Hendrycks]

On Nov 27, 2:28 pm, Peter Beverloo <pe...@chromium.org> wrote:
> On Sat, Nov 27, 2010 at 18:59, Daniel Hendrycks

> <danielhendry...@gmail.com>wrote:

> > Chromium Discussion mailing list: chromium-disc...@chromium.org

> > View archives, change email options, or unsubscribe:
> >    http://groups.google.com/a/chromium.org/group/chromium-discuss
>
> What monoculture are you talking about? There are two engines which are
> larger than WebKit: Trident, used in Microsoft Internet Explorer, and Gecko,
> used in Mozilla Firefox. There are two other large engines around as well,
> being Presto, used in Opera and KHTML, still being used by the KDE project.
> Even though WebKit was based on the latter, internally both have changed
> significantly in the past eight years.
>
> Regards,
> Peter Beverloo

Presto is only used in Opera Products, its source has never been
public. I am talking about the potential monoculture, given Webkit
keeps rising, thanks to Chrome and Safari. WebKit's domination is
becoming more apparent, having a fork would mean Safari would use
WebKit and Chrome would use its fork, making a monoculure less likely.
While Gecko and Trident continue to lose share. Look at Flock, it is
now going to use WebKit, look at new browsers (e.g. Rockmelt), they
are using WebKit; look at the web space, all browsers (other than
Opera's Mobile and Mini and Mozilla's Fennec) are using WebKit, since
it is the only proper engine (that is free, not saying Presto is bad,
it is wonderful). The stage is set for WebKit to dominate, given its
rise. Much like how V8 was a success, I think a fork of WebKit would
be, too.

[Frank]

Daniel, what benefits are you envisioning here? I don't even think Apple can close source WebKit at this point since it has a LOT of contributions from elsewhere. Basically every mobile device uses a form of WebKit these days, and a lot of large companies are quite committed to it going forward, including Sony, Nokia, Google, Apple, Intel, Samsung... it would not be cost effective at all for any of these companies to fork the code just to maintain by themselves.

Improving this rendering engine improves the internet for everyone, so it is in each of their interests to work together for the long term. Until one of the major companies involved does something radically bad with the code base, there is absolutely nothing to gain from what you suggest. Everyone wants HTML5 to succeed - even Microsoft is committed to it over Silverlight now.

Each company can maintain their own javascript engine etc, but it simply makes absolutely no sense to maintain your own renderer. Google is doing plenty to value-add on top of WebKit - NaCl, their own process separation API, etc - but it is VERY good for the internet that the main technology is maintained by many market leaders together. 

Chromium Discussion mailing list: chromium...@chromium.org

[Frank]

WebKit is under the LGPL due to its history via KHTML - no one can take the current code base and simply not make it available anymore.

On Sat, Nov 27, 2010 at 2:11 PM, Daniel Hendrycks <danielh...@gmail.com> wrote:

Chromium Discussion mailing list: chromium...@chromium.org

[Daniel Hendrycks]

>WebKit is under the LGPL due to its history via KHTML - no one can take the
>current code base and simply not make it available anymore.

Aaron already corrected me on this.

>it would not be cost
>effective at all for any of these companies to fork the code just to
>maintain by themselves.

I was not suggesting all of those companies fork it, I was/am
suggesting a fork.

>Improving this rendering engine improves the internet for everyone, so it is
>in each of their interests to work together for the long term.

If every browser moved to WebKit, hackers would focus their attention
to one place. Additionally, forking it would better prevent a
monoculture. If WebKit were on top, it would not be pushed to compete
with other engines, much or at all. This benefit can be easily seen
with V8. When Google introduced V8, the JavaScript speed games were
back on, pushing Opera's Carakan, Mozilla's Jaagermonkey, Idiot
Explorer's Charka, and Safari's Nitro to strive for first. If browser
developers were all to shift their development toward V8, we would
probably be at 700ms on sunspider rather than 200ms. The benefit of
competition can be empiracally proven;=: when Opera showcased Carakan
in Opera 10.5, it was ahead of V8, then V8 got some large speed
improvements, before Carakan there were not many large strides by V8,
the months before. Summation: Competition = Absurdly Good. Quality
Fork brings more competition.

[Daniel Hendrycks]

On Nov 27, 3:56 pm, Daniel Hendrycks <danielhendry...@gmail.com>
wrote:
> *my response*
Sorry, I got a bit repetitive.

[Frank]

If every browser moved to WebKit, hackers would focus their attention

to one place.

Not really, since there are many different browsers all using WebKit, all with different security functionality. I think creating a fork would make it easier to target because there would be specific stacks per client. Not to mention, with the developer power of each of the companies involved, it would make it easier to find and fix the flaw, thus your point here actually works against you moreso than for.

 

Additionally, forking it would better prevent a
monoculture. If WebKit were on top, it would not be pushed to compete
with other engines, much or at all. This benefit can be easily seen
with V8. When Google introduced V8, the JavaScript speed games were
back on, pushing Opera's Carakan, Mozilla's Jaagermonkey, Idiot
Explorer's Charka, and Safari's Nitro to strive for first. If browser
developers were all to shift their development toward V8, we would
probably be at 700ms on sunspider rather than 200ms.

I think Google is genuinely motivated by making webapps faster, thus again I disagree. Google is paid through advertising primarily, and thus they don't want people leaving the internet, and so they want to make it as compelling as possible to ensure that is the case. Others are catching up, and even passing by current V8 in bench marks, but Google keeps trotting on because it is in their best interest. That others are walking the same path only serves to benefit them even more.

 

The benefit of
competition can be empiracally proven;=: when Opera showcased Carakan
in Opera 10.5, it was ahead of V8, then V8 got some large speed
improvements, before Carakan there were not many large strides by V8,
the months before. Summation: Competition = Absurdly Good. Quality
Fork brings more competition.

Again, most of the speed ups that happened in Opera were them playing catchup to the stable Chrome. The beta channel was already seeing speed improvements when Opera's stuff went public. Also, graphics card rendering stuff was in the beta channel far before Microsoft did any of that work too.

I simply think it is more beneficial having multiple large companies paying teams to make WebKit faster and more secure than forking WebKit and having two groups spending half their time integrating what the other has done back into their branch. If you actually have any ideas as to features not permitted in mainline WebKit that you think are interesting, sure, go ahead and fork. You seem to be suggesting a fork just to fork though, which is simply not how things work. 

[Daniel Hendrycks]

On Nov 27, 6:38 pm, Frank <francis.e...@gmail.com> wrote:
> > If every browser moved to WebKit, hackers would focus their attention
> > to one place.
>
> Not really, since there are many different browsers all using WebKit, all
> with different security functionality. I think creating a fork would make it
> easier to target because there would be specific stacks per client. Not to
> mention, with the developer power of each of the companies involved, it
> would make it easier to find and fix the flaw, thus your point here actually
> works against you moreso than for.

In a possible world where everyone used WebKit and an exploit
happened, they would all be effected by the exploit. Do take note of
PWN to Own 2010, where there was a vulnerability in WebKit, affecting
both Chrome and Safari, sure they use different methods of protection,
but the exploit was still there. Forking is measure against such a
possibility. Your assuming that the companies would take long to fix
an exploit if forked. I am suggesting Google fork, not everyone, since
they (everyone else) could not handle it.

> > Additionally, forking it would better prevent a
> > monoculture. If WebKit were on top, it would not be pushed to compete
> > with other engines, much or at all. This benefit can be easily seen
> > with V8. When Google introduced V8, the JavaScript speed games were
> > back on, pushing Opera's Carakan, Mozilla's Jaagermonkey, Idiot
> > Explorer's Charka, and Safari's Nitro to strive for first. If browser
> > developers were all to shift their development toward V8, we would
> > probably be at 700ms on sunspider rather than 200ms.
> I think Google is genuinely motivated by making webapps faster, thus again I
> disagree. Google is paid through advertising primarily, and thus they don't
> want people leaving the internet, and so they want to make it as compelling
> as possible to ensure that is the case. Others are catching up, and even
> passing by current V8 in bench marks, but Google keeps trotting on because
> it is in their best interest. That others are walking the same path only
> serves to benefit them even more.

Your whole response is contingent on the fact that speeds did not
dramatically increase when Carakan started winning. Of course Google
made gradual gains, but not as much when they were forced to fight for
their crown. And now look at us, Sunspider has reached the bottleneck.
Now we can optimise for things like Guassian Blur, etc on the Kraken
Benchmark (not topical).

> > The benefit of
> > competition can be empiracally proven;=: when Opera showcased Carakan
> > in Opera 10.5, it was ahead of V8, then V8 got some large speed
> > improvements, before Carakan there were not many large strides by V8,
> > the months before. Summation: Competition = Absurdly Good. Quality
> > Fork brings more competition.
>
> Again, most of the speed ups that happened in Opera were them playing
> catchup to the stable Chrome. The beta channel was already seeing speed
> improvements when Opera's stuff went public. Also, graphics card rendering
> stuff was in the beta channel far before Microsoft did any of that work too.

The speed ups that were from Carakan were faster than that of the dev
builds of Chrome, people tested preview against preview. The speed
improvements from V8 greatly increased when Carakan was released. (You
can see many of the tests with a search) Your graphics comment is not
topical.

> I simply think it is more beneficial having multiple large companies paying
> teams to make WebKit faster and more secure than forking WebKit and having
> two groups spending half their time integrating what the other has done back
> into their branch. If you actually have any ideas as to features not
> permitted in mainline WebKit that you think are interesting, sure, go ahead
> and fork. You seem to be suggesting a fork just to fork though, which is
> simply not how things work.
"You seem to be suggesting a fork just to fork though"

I am not suggesting forking for giggles, I am suggesting it for large
reasons.

Engines got much faster when V8 and Carakan went at it; before, V8 was
making great strides, but not nearly as large as later. If you think
what I say is not true, just think about it (and search about it,
too): People are saying Chrome has competition, would you show Carakan
who is boss or would you say "my pase is fine" and lose your crown
(considering the pase of Carakan was phenomenal at the time of
introduction, here are my recordings of it:
http://my.opera.com/DanielHendrycks/blog/2010/03/02/carakans-speed-improvements
.)

Outline:
Monoculure and Security Issues
Competition Is Absurdly Good, everyone working on one thing does not
bring much competition

[John McCabe-Dansted]

On Sun, Nov 28, 2010 at 10:21 AM, Daniel Hendrycks
<danielh...@gmail.com> wrote:
>>On Nov 27, 6:38 pm, Frank <francis.e...@gmail.com> wrote:
> "You seem to be suggesting a fork just to fork though"
> I am not suggesting forking for giggles, I am suggesting it for large
> reasons.

You are not suggesting forking for giggles, you are suggesting forking
for the sake of forking. You are arguing that forking is good because
it provide competition etc. All of your arguments could equally be
applied to pretty much any other project. Indeed, by your own criteria
WebKit is relatively poor candidate for a fork, since it is still a
minority rendering engine and hence unlike many other projects it is
not currently a mono-culture. So your argument rests on the assumption
that forking for the sake of forking is a good idea because the
standard benefits of forking outweigh the costs.

However, anyone who is familiar with software development knows that
forking is generally a bad idea as it basically doubles the
development effort for little gain. It is kind of like hiring two
chefs to make the same dinner twice when you only need one dinner;
sure it may induce competition but is it worth the waste? See for
example:
http://en.wikipedia.org/wiki/Fork_(software_development)#Forking_free_and_open_source_software

In any case there is already a fork of WebKit called KHTML (well
technically WebKit is a fork of KHTML). This fork caused more pain
that it is worth, leading to KHTML being marginalized as people jumped
ship to the dominant WebKit to avoid the difficulties forking causes,
see e.g.
http://arstechnica.com/open-source/news/2007/07/the-unforking-of-kdes-khtml-and-webkit.ars

However, if you want to avoid a mono-culture feel free to use
Konqueror (which uses the KHTML engine by default):
http://www.konqueror.org

--
John C. McCabe-Dansted

[Aaron Toponce]

On 11/27/2010 02:11 PM, Daniel Hendrycks wrote:
> The stage is set for WebKit to dominate, given its
> rise. Much like how V8 was a success, I think a fork of WebKit would
> be, too.

You don't fork software, just for the sake of forking it. Failure will
be your constant companion if that's the case. You don't fork software,
because of the software's success. You'll certainly spell your own doom
if you do. You only fork software when the project is heading a
direction that many don't agree with.

Icecat was forked from Firefox, because the GNU project didn't like that
some long-standing bugs remained unpatched, and that its Addons system
recommended non-Free Software. LibreOffice was forked from
OpenOffice.org, because of the lack of responsibility Oracle has with
its open source community, and what it did to Open Solaris. Claws Mail
forked from Sylpheed to add new functionality and patches upstream
wasn't willing to accept.

Forking can be healthy, if it's done right. Forking Webkit, just for the
sake of forking it, isn't a smart move. If Webkit is making decisions
the community doesn't agree with, then a fork is likely. But right now,
Webkit's success is due to hundreds of contributors from all walks of
life, and many different organizations.

--
. o . o . o . . o o . . . o .
. . o . o o o . o . o o . . o
o o o . o . . o o o o . o o o

[Aaron Toponce]

On 11/27/2010 10:59 AM, Daniel Hendrycks wrote:
> Thank you for that clarification, that still does not diminish the
> pluses for forking WebKit; but it eliminates that one. Still,
> monoculture.

There is no monoculture with Webkit. It's developed by a massive
community, as well as several organizations:

* Apple
* Nokia
* Google
* Palm
* Rim
* Samsung
* Bitstream
* Torch Mobile
* ...

Your fear is paranoia due to ignorance, and it's not based on any
foundation. However, if you still feel strongly about forking the
source, download the latest commit, and start building. You can get
everything here: https://webkit.org/.

Good luck.

[Daniel Hendrycks]

On Nov 28, 8:01 am, Aaron Toponce <aaron.topo...@gmail.com> wrote:
> On 11/27/2010 10:59 AM, Daniel Hendrycks wrote:
>
> > Thank you for that clarification, that still does not diminish the
> > pluses for forking WebKit; but it eliminates that one. Still,
> > monoculture.
>
> There is no monoculture with Webkit. It's developed by a massive
> community, as well as several organizations:
>
> * Apple
> * Nokia
> * Google
> * Palm
> * Rim
> * Samsung
> * Bitstream
> * Torch Mobile
> * ...

Which use WebKit, all using the same engine. "A single, homogeneous
culture without diversity or dissension." There are many companies
developing it, but that does not in any way WebKit, if gains 99%
share, is not in a monoculture since there are many developers.

> Your fear is paranoia due to ignorance, and it's not based on any
> foundation. However, if you still feel strongly about forking the
> source, download the latest commit, and start building. You can get
> everything here:https://webkit.org/.

Personal attacks are always good for conversation, please be kind. It
is a suggestion, and additionally, one person cannot code a successful
fork that will work and be superior to WebKit. Please, quit putting
forth silly suggestions for it is waisting everyone's time.

>You only fork software when the project is heading a
>direction that many don't agree with.

No, did WebKit fork because it disagreed with KDE? (honest question)
Since many fork for those reasons, that does not mean it should never
be done for a different reason. I see no basis against that.

>Forking Webkit, just for the
>sake of forking it, isn't a smart move.

You seem to be diminishing the motive. I am not suggesting a fork for
no reason, I am suggesting one for reasons, not just for the reason
of, "Let's press the Fork button". Basically, if we were to use the
logic that is brought forth. LibreOffice is forking just to fork, one
with the mindset brought forth by you would be ignoring the reasons
why it is being forked, and it would then be called "just forking".

>You don't fork software, just for the sake of forking it.

I supplied reasons, show me why they do not work/improve the web.
Actual counter arguments.

[Daniel Hendrycks]

On Nov 28, 2:30 am, John McCabe-Dansted <gma...@gmail.com> wrote:
> On Sun, Nov 28, 2010 at 10:21 AM, Daniel Hendrycks
>

> <danielhendry...@gmail.com> wrote:
> >>On Nov 27, 6:38 pm, Frank <francis.e...@gmail.com> wrote:
> > "You seem to be suggesting a fork just to fork though"
> > I am not suggesting forking for giggles, I am suggesting it for large
> > reasons.
>
> You are not suggesting forking for giggles, you are suggesting forking
> for the sake of forking. You are arguing that forking is good because
> it provide competition etc. All of your arguments could equally be
> applied to pretty much any other project. Indeed, by your own criteria
> WebKit is relatively poor candidate for a fork, since it is still a
> minority rendering engine and hence unlike many other projects it is
> not currently a mono-culture. So your argument rests on the assumption
> that forking for the sake of forking is a good idea because the
> standard benefits of forking outweigh the costs.

"All of your arguments could equally be applied to pretty much any
other project."

Agreed, however, in WebKit's case the actions requested are plausable
and would be helpful. If we were to fork a project, the fork would
probably not succeed if backed by a small person. The fork would
probably be successful if it has the proper backing, like from Google.
If Google would fork, there would actually be competition created, if
one person forked, then it would just create a mess and no larger
company would go with that petty fork.

>WebKit is relatively poor candidate for a fork, since it is still a minority rendering engine and hence unlike many other >projects it is not currently a mono-culture.

Given its rapid pase and the fact that more and more browsers are
turning to it over Gecko, it is very likely to be the ruler, unless
Presto takes more share, but that is a different discussion.

>However, anyone who is familiar with software development knows that forking is generally a bad idea as it basically >doubles the development effort for little gain. It is kind of like hiring two
>chefs to make the same dinner twice when you only need one dinner;
>sure it may induce competition but is it worth the waste?

Analogy is not proper, for they may both be working on a dinner, but
the dinner is not the same. No one is hiring two chefs to make the
same dinner. Since the owner would be hiring one to cook off with the
other chef that the owner is not employing.

>In any case there is already a fork of WebKit called KHTML

That is backed by a small person. If you are attempting to show that
forking WebKit is wrong by saying "KHTML is failing, therefore, a fork
would fail" is not right, since Google would be backing the project.

>However, if you want to avoid a mono-culture feel free to use
>Konqueror

I'll take this as a snide comment, rather than an actual suggestion.

[Aaron Toponce]

On 11/28/2010 10:47 AM, Daniel Hendrycks wrote:
> Which use WebKit, all using the same engine. "A single, homogeneous
> culture without diversity or dissension." There are many companies
> developing it, but that does not in any way WebKit, if gains 99%
> share, is not in a monoculture since there are many developers.

I don't understand what you're saying here

> Personal attacks are always good for conversation, please be kind.

There was no personal attack. I made no name calling nor did I use any
emotion in the response. If you're referring to me calling your judgment
ignorant, that's because it is. Being ignorant to how software
development works isn't a personal attack.

> It
> is a suggestion, and additionally, one person cannot code a successful
> fork that will work and be superior to WebKit. Please, quit putting
> forth silly suggestions for it is waisting everyone's time.

Wasting time? If you want to fork it, fork it. I've shown you were tho
code is. Quit whining, and get it done. Who's wasting who's time?

> No, did WebKit fork because it disagreed with KDE? (honest question)

Yes. KHTML didn't meet the needs that Apple was looking for, and thus
forked the code, with an agreement to submit patches back to KDE. Webkit
was a fork of KHTML, because KHTML was falling short in Apple's eyes.

> You seem to be diminishing the motive. I am not suggesting a fork for
> no reason, I am suggesting one for reasons, not just for the reason
> of, "Let's press the Fork button". Basically, if we were to use the
> logic that is brought forth. LibreOffice is forking just to fork, one
> with the mindset brought forth by you would be ignoring the reasons
> why it is being forked, and it would then be called "just forking".

> I supplied reasons, show me why they do not work/improve the web.
> Actual counter arguments.

You haven't given a solid reason why a fork should be made, nor how it
would be successful. Your only "reason", is because if Webkit becomes
the defacto standard for HTML rendering, then somehow it's monoculture,
even though I've shown you have massively large and diverse the
community is.

[Daniel Hendrycks]

Sorry, I was unaware that there was a reply.

>Your fear is paranoia due to ignorance

"Don't personally attack me."
"I didn't"
You were calling me ignorant, and you were calling me paranoid. I do
agree you were calling my judgment that, but it is still rude. No
matter, let's drop this.

> >It is a suggestion, and additionally, one person cannot code a successful
>> fork that will work and be superior to WebKit. Please, quit putting
>> forth silly suggestions for it is waisting everyone's time.

>Wasting time? If you want to fork it, fork it. I've shown you were tho
>code is. Quit whining, and get it done. Who's wasting who's time?

*Never responds to the second part of the first sentence, just tells
me to quit whining* Beside, this is a place of suggestion. Is every
request that comes here supposed to be coded before you post a request
for change or implementation? (rhetorical)

>I don't understand what you're saying here

I'll try to change things up:

...which use WebKit, all using the same engine. Definition (since I
see fabrication) "A single, homogeneous culture without diversity or
dissension." It is monoculture in the engine space, there isn't
diversity. There are many companies developing it, but that does not
in any way mean WebKit, if gains 99% share, is not in a monoculture of
engines; since it is the hegemon.

>You haven't given a solid reason why a fork should be made

I haven't heard an address to Security is improved and general
competition is great (look at V8)

>nor how it would be successful.

You have doubt that if Google would fork, the fork would be
unsuccessful?

>then somehow it's monoculture even though I've shown you have massively large and diverse the community is.
The developers are diverse, not the engine. That is like saying V8 is
diverse, the developers may be, but the engine is the same across
millions of computers, or with a small modification. Please address
this point first.

[PhistucK]

I understand what you are trying to say (though I do not really agree), but in the meantime, WebKit is not a really major rendering engine in terms of market share.

Currently, there is no need to break the party.

Once it reaches a high percentage (at least as that of FireFox, but maybe even higher), that might be justifying a fork in some weird sense.

And even then, WebKit might be a monoculture, but the rendering engine world has a few dominant and diverse options, so it is still not enough of a reason to fork it.

Eventually, like Aaron wrote, once there is a conflict in the way things are run or headed at WebKit, there would really be a need for a fork. Until then, it is just a waste of time and resources. Security can be degraded as well as can be improved, it is not a one way street. They fix one thing that matters to them, but not the other, which they have not tested enough.

Forking WebKit now would mean to go back in time to 2008 and start merging the code from WebKit every few hours in a relatively manual way - that was not a good development life cycle, the development suffered from it, it hindered it, it slowed it down.

Until there is a real reason to invest time in actually doing other stuff than WebKit wants to do, there is no real need to fork.

Currently, they share the same targets. Until they do not - this is a fine situation.

☆PhistucK

[Daniel Hendrycks]

>WebKit is not a really major rendering engine in terms of
>market share.
>Currently, there is no need to break the party.

Until then, I will wait to revive this suggestion.