Apple was making updates to WebKit, not the KHTML tree. Apple's fork diverged quite severely for genuine design reasons, and Apple makes its code changes available -- now, even faster than previously. The value Apple has added in its fork is underscored by the fact that WebKit rather than its older cousin KHTML has been chosen to serve as the the back-end of tools like Google's Chrome, Adobe's Apollo, Torch Mobile's Iris (for WinCE), and Nokia's S60 browser.
I understand that taking code contributions from Apple might seem like trying to drink from a fire hydrant, and that Apple's (understandable) practice of making updates against its own tree rather than KHTML's tree is less convenient for KHTML folks, but this isn't an evil of Apple and it's not a slight against KHTML: WebKit is currently more heavily used and is under heavier development, and should be expected to end up exerting the gravitational pull of a planet, despite that the KHTML folks imagined Apple would just be launching a little satellite.
As mentioned in comments to my discussion of Chrome (which I enjoyed using wile evacuated to North Texas for Hurricane Ike), Apple's SquirrelFish javascript engine is already in bake-offs with Google's V8, which can't help but advance users' interests as better performance and more stable code is created to obsolete some of the garbage they've been fed in the browser world from vendors who don't need to be named.
It's not like Squerrelfish isn't also an open-source Apple offering.
Apple seems to have realized that it benefits from standards, and from being able to leverage good code into projects. Apple hasn't violated its open-source obligations with respect to code, even though there are people who wish Apple would spoon-feed fixes back into their trees rather than just release what they have changed in their own trees. Frankly, though, Apple can't afford to do that. Apple isn't getting its code from KHTML in block imports, it's making changes to its own tree.
By comparison, in projects like FreeBSD -- from which Apple does take code imports -- Apple has upstream contributors working on the source project's code base. Some folks actually credit Apple with much more in connection with FreeBSD.
Other Apple projects include the CalDAV implementation it released, its ZeroConf implementation, the CUPS code it helped support until it finally hired the developer full-time, the streaming server, and Apple/Genentech BLAST.
It's fun to blast Apple, sure, but Apple is doing more than nothing for open source. It's not a charity, but it's a definite contributor. Apple has figured out that it benefits from standards, and that works for everybody against single-vendor lock-in.
by The Jaded Consumer — Oct 13
Apple was making updates to WebKit, not the KHTML tree. Apple's fork diverged quite severely for genuine design reasons, and Apple makes its code changes available -- now, even faster than previously. The value Apple has added in its fork is underscored by the fact that WebKit rather than its older cousin KHTML has been chosen to serve as the the back-end of tools like Google's Chrome, Adobe's Apollo, Torch Mobile's Iris (for WinCE), and Nokia's S60 browser.
I understand that taking code contributions from Apple might seem like trying to drink from a fire hydrant, and that Apple's (understandable) practice of making updates against its own tree rather than KHTML's tree is less convenient for KHTML folks, but this isn't an evil of Apple and it's not a slight against KHTML: WebKit is currently more heavily used and is under heavier development, and should be expected to end up exerting the gravitational pull of a planet, despite that the KHTML folks imagined Apple would just be launching a little satellite.
As mentioned in comments to my discussion of Chrome (which I enjoyed using wile evacuated to North Texas for Hurricane Ike), Apple's SquirrelFish javascript engine is already in bake-offs with Google's V8, which can't help but advance users' interests as better performance and more stable code is created to obsolete some of the garbage they've been fed in the browser world from vendors who don't need to be named.
It's not like Squerrelfish isn't also an open-source Apple offering.
Apple seems to have realized that it benefits from standards, and from being able to leverage good code into projects. Apple hasn't violated its open-source obligations with respect to code, even though there are people who wish Apple would spoon-feed fixes back into their trees rather than just release what they have changed in their own trees. Frankly, though, Apple can't afford to do that. Apple isn't getting its code from KHTML in block imports, it's making changes to its own tree.
By comparison, in projects like FreeBSD -- from which Apple does take code imports -- Apple has upstream contributors working on the source project's code base. Some folks actually credit Apple with much more in connection with FreeBSD.
Other Apple projects include the CalDAV implementation it released, its ZeroConf implementation, the CUPS code it helped support until it finally hired the developer full-time, the streaming server, and Apple/Genentech BLAST.
It's fun to blast Apple, sure, but Apple is doing more than nothing for open source. It's not a charity, but it's a definite contributor. Apple has figured out that it benefits from standards, and that works for everybody against single-vendor lock-in.