- Related Stories
-
Mac malware door creaks open
May 9, 2005 -
Apple office software seems likely
January 4, 2005 -
Mozilla upstart looks up to Safari
February 19, 2003 -
Apple on safari
January 10, 2003
In an e-mail seen by CNET News.com, a leading Apple browser developer suggested that architects of the KHTML rendering engine--the heart of a browser--consider abandoning the KHTML code base, or "tree," in favor of Apple's version, called WebCore. KHTML was originally written to work on top of KDE (the K Desktop Environment), an interface for Linux and Unix operating systems.
"One thing you may want to consider eventually is back-porting (WebCore) to work on top of (KDE), and merging your changes into that," Apple engineer Maciej Stachowiak wrote in an e-mail dated May 5. "I think the Apple trees have seen a lot more change since the two trees diverged, although both have useful changes. We'd be open to making our tree multi-platform."
What's new:
Two years into its Safari Web browser, Apple has proposed dumping open-source rendering engine KHTML in favor of its own code base.
Bottom line:
KHTML developers, who initially hailed Apple as a white knight, are now calling the relationship between their group and the computer maker a "bitter failure."
The suggestion, which KHTML developers said they were unlikely to accept, comes as Apple tries to quell rising dissatisfaction among the original architects of KHTML. Two years after hailing Apple as a white knight, those developers are calling the relationship between their group and the computer maker a "bitter failure."
In a conflict some call emblematic of what can go wrong when corporations embrace open-source projects, developers are airing longstanding gripes against Apple, accusing the computer maker of taking more than it gives back to the open-source group.
Apple declined to comment for this story. But Safari engineer David Hyatt did acknowledge KDE complaints in his blog, defending the scope of recent patches and soliciting suggestions on improving Apple's relationship with KDE.
"For what it's worth, the patches I posted...are not solely KHTML patches," Hyatt wrote. "What do you think Apple could be doing better here?"
The subsequent dialogue, played out in public mailing lists and blogs, led to the e-mail exchange in which Stachowiak suggested that the KHTML group start fresh from WebCore.
KDE said complaints about Apple had been brewing for some time, and attributed some of the tensions to the inherently at-odds priorities of corporations and volunteer coders.
"Business is constrained in ways that open source prides itself on not being constrained," said George Staikos, a software consultant, KDE developer and spokesman for the open-source group. "There have been problems all along in the sense that Apple had their own internal issues to deal with (that) did not mesh well with the model used by
See more CNET content tagged:
KDE,
Apple Safari,
code base,
Hyatt Hotels & Resorts,
open source
From my own experience that's not always a good idea. Apple has its own priorities, KDE has its own priorities.
It could be possible point of cooperation if user bases have had overlap. But that's not the case here: most KDE users are not Apple users and vice versa. There is minority of people (like I'm) who run Linux on Apple's hardware - so they happen to use both Safari and Konqueror. But this is exception just confirming the rule.
It looks very similar to BitKeeper/Linux (Larry mcVoy/Linus Torvalds) divorce: needs of open source developers who used free version of bitkeeper differ so much from needs of proprietary software developers who pay license fees.
Looking from POV of open source domain, it is hard to understand patch made in closed source domain: ****** piece of code that patches whole and makes two new. Piece of code made under pressure. Open source solutions are always in win position - you pressed ony by your own ego to fix problem - and ego is best driver. And to not to harm ego, OSS developer will his best to find proper solution. He is not obliged formally - but only by heart. Such driving will never be rivaled by corporate pressure.
I've seen some OSS projects which were getting quite good cooperation from R&D departments of software companies. Only in few situations that was any fruitful: when user base was same; when software design was restricted by some standards. IOW, relationships were dictated by "third party" - user base, stadard body (*), etc.
P.S. W3C, thou standard body, has only loose control - thanks to M$ who made W3C standards some exotic variation of de facto standard M$ Internet Explorer. Sad, but true.
>control - thanks to M$ who made W3C standards
>some exotic variation of de facto standard M$
>Internet Explorer. Sad, but true.
Not only does MS have representatives on the W3C, the W3C itself clearly states in its specifications that companies are EXPLICITLY allowed to add their own extensions to the spec and still be considered standard-compliant.
You should probably do a little reading before you go around just spouting the party line.
Like all their change they looked around for free stuff and used id, since they could not make it on their on, with all their briliant engineers. Except a cool GUI which dries your CPU, they aren't capable of anything else.
The changes that Apple has made to F/OSS projects cause more bugs in other areas and open up more exploits. This is a complaint that KHTML developers have with Apple. I'd imagine Apple does the same with Darwin/OSX source code as well. Before you know it, OSX will have security flaws like Windows, and then crackers will take advantage of them. All because Apple isn't following the F/OSS development philosophy.
something.
Besides why development ANOTHER browser? Just use firefox and spend your money and resources on something worthwhile... like lowering the prices of your hardware!
The hardware is expensive because its worth it. Either learn to cope with Pro-level machines or go by a crapped out Dell.
I'm so sick people bickering over the cost of machines when the price for these machines has been stable for so many years, and quite frankly, is worth every single penny. I've used My PowerMac for 3 years now. Still works just fine. And yes, they're hardware HAS decreased in price.
Have you not heard of the Mac Mini?
"The bitterness of poor quality lingers long after the sweetness of
low price is forgotten"
Ask anyone who owns a Mercedes, a Rolex, or an Apple.
Please take your negative comments elsewhere, and go and remove
a virus or something.
In this case, the open source development model simply failed. It couldn't keep up with commercial development, and produced a slower, buggier, less compliant product, and one that is, by comparison, getting more so every day. Despite the fact that Apple publishes their changes with each release to KHTML, the team still couldn't keep up.
This may sound like a flame, but it's how I feel: Too bad for KDE, but it's hard to feel sorry for them. Perhaps they need to do some soul searching of their own and see if creating a third-rate browser in their spare time is worth doing.
was obviously good enough for Apple! They
evaluated several alternatives, and they felt
KDE's work was the best of the bunch. so
clearly: how is it "third-rate"?
Of course, since Apple has several paid
developers developing KHTM/Webcore, and
since they are not interested in the "purity" of
the code, they can get results faster. But that
doesn't mean that KDE-team effort are
somehow sub-standard. They have done very,
very well. And Apple can and does take
advantage of their improvements, while
KDE-folks can't really take advantage of
Apple's improvements. So is it really all that
surprising that Apple seems to be moving
faster than KDE is? Right now, the flow of
improvements is more or less a one-way
street.
Both Apple and FOSS can benefit from this cross-fertilization, and there is no need to synchronize the products if both are viable.
If Apple neglects security and KHTM does not, then Apple can backport functions with bad security to the KHTML approach. If Apple focuses on standards, and KHTM does not, then KHTM can backport functions with bad standards compliance to use the Webcore approach.
The competition will benefit both, and because the source is open, neither will be blocked from using improvements made by the other. This is much the way the Linux kernel works. The only problem is the Not-invented-here syndrome, which is rapidly being weeded out of FOSS, because it leads to loss of software leadership.
ran with it. They abide by its license, contributing their code.
Because they went a different direction, does not make them
criminals. The KHTML people are merely tired of being asked "If
Safari can do xyz, why can't Konqueror? Surely this is coming
soon?" In other words, they are big, whiny babies.
Why can't Apple write a browser from scratch? Why can't Apple write almost anything from scratch? Apple has to borrow or steal from other projects, to make their own projects.
level commercial OS and bundled media apps for less.
professional video and music editing. Do you also run a DTP
shop or an ad agency?
You are the one who is ignorant of the fact that I can use any
system I find the most useful. To me it's a Mac. So by the same
stroke that you paint all Mac users as ignorant and clueless, it's
you that comes out that way.
Just because you have never used it or had no use for it, it
doesn't mean it is without merit.
Let's remember that IE didn't get 95% of the browser market only because MS included it in it's OS. They got that market share because Netscape/Mozilla went into the corner and played with itself for three years without responding to the improvements coming out of Redmond. Even after they had rewritten the rendering engine, they still piddled around for another year and a half while Rome was burning.
To say that open source sometimes fails isn't exactly true though, because some open-source developers don't mind if the only people using their software is themselves. Different priorities.
By the way, is this the same KDE that can't play well with GNOME either?
from the article, but the gist of the issue was
that Apple and KHTML developers intended to
share share-alike, originally. Ultimately, the
KHTML team was focusing on compartmentalizing
the functionality, validating code, etc.
Meanwhile, Apple focused solely on meeting the
requirement of passing the Acid2 test. Both
branches evolved at the same rates, but in
different directions.
It's not that the KHTML developers had a problem
with this per se, or that Apple outpaced them
(they didn't). The issue was that in order for
Apple to achieve their goal, it involved cutting
some corners and breaking a slew of the
requirements of the original KHTML renderer
(yes, there are requirements other than passing
the Acid2 test). The Apple branch now passes the
Acid2 test at the expense of breaking much of
the other functionality pre-existing in the
code. Moreover, they introduced lots of
unnecessary dependencies on Apple's own
proprietary code rather than follow the original
KHTML component design.
From Apple's standpoint, Acid2 was the end all.
Component reuse, DOM compliance, the whole
component model concept, the method of
interfacing with Javascript, etc. was all
unnecesary to them and left on the cutting room
floor. The KHTML team would very much like to
have benefitted from the improvements in the
renderer, but they still need to meet the full
requirements of the specification for KHTML. In
order to benefit from Apple's work, they now
need to rewrite the bits that contain
dependencies specific to the Apple code, and
change the rest to adhere to the coding
guidelines to assure that it's multiplatform,
etc.
Basically, they're just miffed that Apple both
ignored the coding guidelines and provided them
with code that doesn't meet their (more
rigorous) coding standards.
forumID=1&threadID=6695&messageID=43971&start=-162
The complaints KDE developers cited go back waaay before the Acid2 test was designed. And the number of changes needed for Acid2 were surprisingly small -- it's just that KDE's KHTML code and Apple's KHTML code had already diverged to the point that the changes for Acid2 could not easily be merged, because the changes were made to code that was *already different*.
Really, the issue has *nothing* to do with Acid2. The only reason that test is involved at all is that the publicity brought the resentment to the foreground.
So tell me, what's the difference between proprietary and open-source when open-source only lets you use their code if they're in the mood and you show the apprpriate amount of fawning defference to sooth their delicate egos?
Answer: there isn't one.
If they're following the license, at least be happy the code found some use. That would be in the original spirit of open-source too.
The KHTML gang seems to have a very insular attitude towards their product, which naturally won't mesh well with a large company who makes their reputation at being fast on their feet.
They tried; it failed. No huge story here; just a partnership that didn't work out.
"That issue flared in recent weeks as Apple trumpeted Safari's ability to pass the Acid2 standards-compliance test."
Say WHAT?!?
Apple did no such thing. Dave Hyatt kept notes on his continuing development for patch to Safari to pass Acid2 in his blog: http://weblogs.mozillazine.org/hyatt/
Upon his notice of completion, *I* (TigerX) submitted the story to Slashdot since I thought that it was of interest to those who follow standards issues.
The Slashdot story I submitted is here:
http://it.slashdot.org/article.pl?sid=05/04/28/1215227&tid=95
So Apple didn't trumpet anything and neither did David Hyatt. Hyatt simply kept a blog with his continuing progress and when he finished I submitted it to Slashdot.
I'm not affilated with Apple in any way. The only Apple product I own (an iPod) was given to me by a friend who replaced his.
Frankly, I think this whole issue to blown WAY out of proportion. The build with the Acid2 fixes STILL isn't avaliable to the public to my knowledge. Hyatt has posted the code and fulfilled his end of the licence.
Yours,
Matt Lemieux
("TigerX" & PC user since age 6)
working. BOTH browsers are far better browsers than IE. Period.
Safari IS faster than FireFox. And I have not had one problem with
my version of Safari, which I believe is the latest version.
Use FireFox, use Safari, use IE, who the --ck cares!
commitment than their agreement stipulated. They forget, that
at the bottom of it all, that Apple is a business. They play in an
arena that allows them fewer mistakes, glaring scrutiny of their
decisions, maintenance of departmentalized costs, and
intellectual property to protect.
Asking a corporation into the open-source market has its
pluses. What they gain from it can only be measured by their
agreement. No matter what any individual might want to do in
that corporation, the larger body will never ask itself to lay down
on it own sword.
The KHTML expected more contributions from Apple, but they
forgot that KHTML was only a small piece of a much larger
picture of what Apple, or any corporation has to look at.
agencies (namely MacMinute) have woefully misunderstood, and
as a result there is a fair amount of Fear, Uncertainty, and Doubt
being sown; as such, I feel the need to correct them. Let's start
with the title. "Open source divorce for Apple's Safari?" This
may be taken to imply that Apple is considering abandoning
KHTML in favor of its own proprietary technology. In fact this is
completely incorrect. WebCore, the technology in question, is
based on KHTML -- Apple already uses WebCore for Safari, and
has since its inception. To say that Apple is going to abandon
KHTML for WebCore is a nonsense statement, tantamount to
asserting that it is going to abandon WebCore for WebCore.
As the text of the email quite clearly conveys, the real
suggestion was that the developers of KDE should consider
adapting WebCore (the version of KHTML containing all of
Apple's enhancements) for their needs, rather than grafting on
Apple's enhancements to their original, unmodified version of
KHTML. In neither case would Apple's code go away from the
KHTML project, and in neither case would WebCore change in
any way, shape, or form. Any assertion that Apple is
abandoning KHTML is a blatant untruth.
The rest of the article details the conflict between Apple's
developers and the KDE developers, and does a decent job at
that task. This discussion reveals the real point of Stachowiak's
suggestion: backporting WebCore's version of KHTML to KDE
might be quicker and provide more functionality than applying
each of Apple's changes to KDE's version sequentially, though it
admittedly does not address the real gripe of the KDE folks --
namely that Apple has not been documenting its changes to
KHTML well enough or generally making it easy for them to
integrate the changes with their codebase. Dave Hyatt is,
indeed, soliciting suggestions for Apple on how to do better at
this.
If you happen to have surfed to this article from a site claiming
that Apple is abandoning HTML in favor of its own proprietary
WebCore, I hope the above clarifications have been helpful.
Also, I don't believe that you have ever used OSX. I have OSX
running on a G3 that I bought in '97, and it works well. That's 8
years old if you want to do the math...
If you're running OSX on an 8 year machine. It's running VERY SLOW and you are CHEAP.
Intel DUO CORE is where it's at!
For the record, it's not the reporter's problem alone. A lot of the articles released here just don't seem to be up to a certain journalistic standard. Sorry to sound so critical.
For your information, that sentence is the product of numerous phone calls and numerous e-mails over two days to numerous Apple representatives.
- This is just the old story...
-
by Michael Grogan
May 13, 2005 9:53 AM PDT
- ...of corporation vs. individuals. Corporations don't invent, corporations don't innovate; it's too expensive. Corporations steal from inventors and innovators. Then they turn whatever they have stolen into crap that's cheap to produce and sell it to an exceedingly gullible public at a premium price. I'll never understand why anyone would give undying loyality to M$ or Apple.
-
Reply to this comment
-
Showing 1 of 2 pages (60 Comments)