Safari and KHTML
It had to happen. The strains between Apple and the OS community are showing. I see where the KHTL developers are calling it a failure. I think it may have been, but to me it seems it was a failure expectations more than anything else.
Dave Hyatt blogs a little a bout it. KDE developers answered back.
Reading the posts and comment threads it seems to me the failure is not so much in performance as in expectations. Users expected all the KHTML team would have to do is press a button and the Safari changes could be rolled back into the main tree. As a programmer, I know the merge isn’t that simple. But it also seems to me that this particular failure isn’t all that significant. Yes, it’s tiring to have to keep answering the “are we there yet?” questions, but those questions are going to be asked no matter what’s going on; answering them comes with the territory.
But the more sign ificant failure seems to be what the KHTML developers expected from Apple. Some of the commentary almost reads as if some of them were expecting Apple to simply pay for programmers who worked for the KHTML crew.
There’s always a disconnect when volunteers and paid staff are working. It’s not that either one takes the job lightly, or isn’t willing to work. It’s just that volunteers and paid staff have different goals. Volunteers can afford to be “purists,” they can afford to take the time they feel is necessary. Paid staff are working to deadline for someone who expects a certain amount of production for the money being paid. Sad but true; he who pays the piper calls the tune.
The major complaint seems to be that the bugfixes and other changes Apple’s staff makes to the KHTML code are sufficient to achieve the aims as far as Safari is concerned (evidence: Safari now passes the Acid2 test) but they don’t necessarily “play nice” with portions of the code of other products that use KHTML, and the changes aren’t made according to KHTML standards.
(more…)