Slashdot Mirror
Safari vs. KHTML
Johnny Mnemonic writes "CNET has a story that describes the divergence between the code base of Safari and KHTML. Although there were high hopes that Apple would contribute significantly to the OSS project, that optimism has all but disappeared. Is an unrealized danger of OSS that others may take your project in a direction you didn't intend? Can OSS code and goals harmonize with the goals and needs of corporation designed code? Is it that Apple mismanaged the relationship, or that the KHTML guys expected too much? Interesting warning for other OSS-corporate marriages." We've previously reported on the frustration in the OSS community on this issue.
As long as they're abiding by the terms of the license, does Apple, any corporation, or any entity for that matter, have any obligation to contribute anything back to the project? Who gets to decide when someone is contributing "enough"?
Additionally Apple posts all of its open source code; here's the page for WebCore, which states:
WebCore is a framework for Mac OS X that takes the cross-platform KHTML library (part of the KDE project) and combines it with an adapter library specific to WebCore called KWQ that makes it work with Mac OS X technologies. KHTML is written in C++ and KWQ is written in Objective C++, but WebCore presents an Objective C programming interface. WebCore requires the JavaScriptCore framework.
The current version of WebCore is based on the KHTML library from KDE 3.0.2. Changes that are specific to WebCore are marked with #ifAPPLE_CHANGES. Other changes to improve performance and web page compatibility are intended for integration into future versions of the KHTML library.
Sounds like a case of sour grapes to me. I'm sure the level of cooperation and collaboration that the KDE/KHTML/Konqueror folks had hoped for wasn't there, if only because Apple keeps everything secret before its release (including everything related to Safari 2.0 in Tiger). Another example of a corporate need butting heads with a contrary OSS philosophy. And I'm sure Apple's main priority is not developing an infrastructure to cohesively and voluminously contribute changes back to projects. It's more like, "Ok, here's our stuff..."...it's all there for anyone to see.
In the article, Apple engineer Maciej Stachowiak said,
"One thing you may want to consider eventually is back-porting (WebCore) to work on top of (KDE)... We'd be open to making our tree multi-platform."
I wonder if that means they are looking to port Safari to Windows. It would give Windows users another taste of the Mac, and I for one would use it.
Lars T.
To the guy who modded me down from perfect to terrible Karma - Apple haters still suck
Is an unrealized danger of OSS that others may take your project in a direction you didn't intend?
Isn't that point of OSS, hoping that someone will take interest in your project and do something with it you couldn't do yourself?
And what's dangerous about that?
The LGPL says that changes have to be returned in the "preferred form" for exactly this reason
OK, I'm trying to figure out a definition of "the preferred form" that means "compatible with a toolkit they're not even using". Because that's a huge problem... the changes Apple's made involve porting what started out as KHTML to a completely different API, and no matter how frequently Apple released the patches, or in what sized chunks they released the patches, they'd still be full of changes related to the fact that Apple's APIs have evolved along a completely separate path from X11 for their entire lives. Carbon's API can be traced all the way back to the original Macintosh, and Cocoa is based on the NeXT ObjectiveC + Adobe Display Postscript code... and there's only one X11 toolkit that either of those APIs have any relationship at all with, and it's neither of the Big Two.
The only way to keep that from being a problem would be to have both projects agree to a common API for the GUI, and stick to it.
Do you honestly see that happening? Especially since the best compromise technically would involve the KDE people switching to GNUstep.
Right, and I've already merged those that applied. Now if only we got all patches divided up like that, rather than as the once a year code bomb.
The KHTML devs would like Apple to either make it clear that WebCore and KHTML are now very different, despite the common ancestor, or to help merge things back. Either way, they want something to hit the idiots with that makes sense to a clueless type, rather than stick with the current "Apple says", "KHTML says", "But Apple says!" back and forth.
I appear to have a blog. Odd.
The KHTML team have (AFAIU) only limited access to the Webcore bugtracking system, with some bugs not visible at all. From the story: "[KHTML] suddenly found themselves dealing with bug reports Apple deemed too sensitive to share, new requirements for auditing code before releasing it, and demands that developers sign nondisclosure agreements before looking at some Apple code."
Most commercial companies have to deal with customer information privately and that means restricting access to versioning systems, bug databases, trouble tickets, and code comments. I know I work for a company that uses a lot of open source code in our products. That does not mean we can allow access to privileged information that inevitably finds its way into the aforementioned systems. WebCore is as open as any open source project, but that does not mean the internal workings of the company making it or their customers has to be open to public scrutiny. Apple has to do business in the real world with government agencies and large corporations.
You can't see changes as they're made, you can't track the development trunk. All you can do is take the occasional slabs of code that they release - and the whole point is that that makes it difficult to port interesting code changes into the KHTML codebase.
Even so, Apple has gone out of their way to try and make it easier, above and beyond what is required by law. Changes that are specific to Apple technologies or that effect Apple only interfaces are commented as such.
Added to which, the Safari/Webcore developers have entirely different (ie. commercial) priorities to the KHTML project.
Actually I think this is the major problem. Apple wants a flexible web library, easily accessible using their dev tools and that is usable for the general public. KDE wants a browser for technophiles. Apple needs something that runs on OS X using their own window manager, and runs quickly. KDE needs the same for KDE of course.
And the Apple developers have done another thing which makes things even more difficult for the KHTML devs to use their changes - they're using significant closed-source functionality from Mac OSX system libraries.
Gee, I can't imagine why they would have done that. KDE has used significant KDE only libraries. Both groups want them to run on their own system, that is not a surprise.
Wow, you really haven't read any of the background on this at all, have you? The KDE/KHTML team did ask (many, many times), and the Safari/Webcore team weren't willing to (or weren't allowed to) accomodate them.
That's funny I heard the acid test patches were broken up into small chunks and had comments specifically for the KDE team telling them what applied to what as far as the codebase was still the same. I also heard that the lead Apple developer was soliciting suggestions for how they could make things easier, in fact it is still up on his blog. They can't release the bug reports, nor the versioning system, but Apple is certainly trying to be a good neighbor on this one.
They would probably also be happy to answer questions and explain particular changes. :-)
Weren't.
Got any source to back that up? What particular change was asked about that Apple developers refused to answer?
They're not running an opensource project with Webcore, they're building a closed-source project (Safari) and making occasional monolithic code releases of the one major open-source component of that app (Webcore).
Bullshit. WebCore is an open source web engine and there are even several new open source browsers based upon it as well as at least one other proprietary one (Omniweb which I'm using now). There is nothing wrong with closed source applications using open source ones. It violates neither the law nor the spirit of open source.
Apple marketing trumpet Webcore as a good wholesome example of Apple contributing back to the opensource c
A note on zealotry (not directed to parent post ... it is a general complaint).
1) It is quite funny that when I was discussing this on osnews, a bunch of people jumped on my posts calling kde devs names (whiners, zealots, whatevers) and praising apple for their huge contribution to OSS. And no matter how hard I tried, I couldn't get them understand that the main problem of khtml developers is not that Apple didn't contribute back enough (although that is part of the problem). Their problem was that - the result of Apple's marketing campaign about being first class citizens of the OSS community - users thought that they don't implement features present in Safari because they are lazy or they just don't want to or whatever. In other words, their gripe was with clueless users.
2) Check the asnwers to Carewolf's post. Apology, apology, apology... like "users DO NOT CARE if your code is 'elegant' and 'easier to mantain', users WANT THINGS TO WORK whether or not they are 'elegant' or 'adequate'." (why is he shouting? - and most importantly, why is he modded insightful?). IMHO, this kind of APPLE can't do wrong does disservice to APPLE - one of the keys to do successful business is to recognize the mistakes one makes in order to avoid them in the future. You can love APPLE and be critical at the same time!
Shit it's hard to handle appropriate levels of contextual quoting in slashdot-HTML - at least for this long a post *wry grin*.
And that's fine - Apple is well within their rights to do that. But doing that makes it a hell of a lot harder to consider Webcore a genuine open source project.
As open as a project like KDE, which has a completely open source control system, a wide array of open and searchable development mailing lists, and an open bugtracking system? No, I though not :-). See below.
You misunderstand my point. I didn't say that Webcore wasn't under an open source license, nor did I suggest that Apple was violating the license in any way.
What I did say was that Apple wasn't running Webcore as an open-source project. A serious OS project should first and foremost have the source developed in an open and freely accessible source control system (though this is not an absolute - many less active OS projects can achieve much the same result with infrequent tarball releases, mainly because updates to the project are infrequent). Less important, but also good, are openly accessible development mailing lists (though again there's some degree of variation here - some projects have a closed "core team" list - but the vast majority keep all lists open). An open and freely accessible bugtracker is also a big plus (though again, there's a fair amount of scope for restricting access to important security-related bugs, as does the Mozilla project with Bugzilla).
Regarding the different priorities between Webcore/KHTML:
Well, it certainly seems to be a big part of the technical problem :).
As far as I'd heard, that was a case of too little, too late and I seem to recall another KDE dev suggesting that Hyatt only did it because he (the KDE dev) dared him to (as they'd been asking for lightweight atomic patches for ages with no response). I hope that's wrong and Hyatt is genuinely trying to help the KHTML project - it certainly looks as though he is, going by his blog.
Re: a comment I made about the Apple devs not being willing to answer question or explain changes:
Actually, no. Dammit. I thought I'd seen a couple of references on the KDE dev blogs regarding the Apple Webcore devs being "unresponsive" to requests for information, but I can't find those references now - I might even have misremembered them. I hereby withdraw that comment.
You're dead right on the opinionated count :). And I'm sorry, I didn't mean to imply I was that well informed :).
My main objection to the "Webcore is a genuine open source project" is covered above - the lack of an openly accessible source control server is a bit of a deal-bre