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.

First of all, it’s understandable, if perhaps disappointing, the changes don’t follow KHTML standards. But then Apple has it’s own internal coding standards, and were I on staff, I’d be conforming to Apple’s standards, simply because they’re paying for the work. (Now, this whole line of thought is moot if the coding isn’t up to Apple’s standards either. Frankly I haven’t had the time or inclination to do an analysis so I’m open to correction on this from anyone else who has had them.) They’re not being paid to make KHTML work, they’re being paid to make Safari work, and they’re forwarding the changes to the KHTML team because making them work with the rest of KHTML’s clients (for lack of a better term, I’m referring to the applications that use KHTML) really isn’t their responsibility.

Yes, that means KHTML is being used. Rather like the BSD folks got used, and, for that matter, rather like most open source development teams get used at least once during their time. And that doesn’t feel good, necessarily.

But some of the complainers I’ve read seem to be offended because Apple didn’t pay for the staff to go back and revise all the changes to make them compatible with everything else that uses KHTML. I think those expectations are out of touch with reality. Yes, wouldn’t it be nice if every corporation in the world would chip in and pay for a development staff to give away software. But the world doesn’t work that way.

And the framers of the GPL knew that. They knew it when they crafted the license. They knew that if those we going to be the terms, then they wouldn’t get much from the rest of the world. So they allowed corporations to create forks, insisting only that the forks must be documented and the code available, so that if anyone wanted to take the trouble, they could implement the changes in the main tree.

No one’s a saint in this discourse. Apple has specific goals in mind for its use of KHTML, and those goals may not be the same goals as the development team. It’s not all that far removed from stupid to expect them to change their goals, just to satisfy the aesthetics of a staff they don’t control and have little influence with. It’s folly to build a commercial enterprise on top of something you have no control over. What if the KHTML team decided to go in a completely different direction and it would break some things that Apple has spent lots of time and money on?

So there’s heartburn in KHTML-land. The development team has no interest in becoming drones, transcribing Apple’s changes, and I can tell you from experience that it can be a real headache trying to interpret someone else’s approach to solving a problem in code, and understanding it well enough to make it useful elsewhere. It’s not always fun, children. Especially when you’re not going to get much credit for doing it. The development team feels helpless; like they’ve lost control of the train and now they’re just staff working for someone else’s specs (and in this case, doing so without pay, even).

It could be that the KHTML engineers are a bit miffed that Apple isn’t treating them like the Samba engineers. I can’t say as I blame them for it if they are, but still samb a is more of a complete product, while KHTML is a component of a product.

It would be easy, and asinine, for me to give advice to either side in this; I’m completely unfamiliar with the amount of work it would take to implement an Apple change in the KHTML tree. But if it becomes too much trouble, there’s a time-honored tradition to follow: fork the source trees. It wouldn’t be the first or the last time this happened. In fact, it’s almost normal when two groups of engineers have irreconcilable differences.

I’d not like the fork; I like the idea of having fewer rendering engines to test web designs against. But if all it’s going to do is eat the insides of one of the developer teams, it may be the only reasonable course of action open.