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
--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss
Chromium Discussion mailing list: chromium...@chromium.org
Chromium Discussion mailing list: chromium...@chromium.org
If every browser moved to WebKit, hackers would focus their attentionto 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.
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
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
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.
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.