On Fri, May 16, 2008 at 07:34:19AM -0500, Jordi Guti?rrez Hermoso wrote: > On 16/05/2008, Gregory Seidman <[EMAIL PROTECTED]> wrote: [...] > > That they did it by taking it in-house instead of trying to convince > > the people who tied it to KDE that it should be more general is > > utterly irrelevant. > > No, that's the whole point. Because they didn't work with free > developers, they actually created a lot of strife for KDE. They took the > code and told the kdevelopers to fork off.
There is no strife here. Apple didn't try to take over the KDE project, or the KHTML project. They took the code and ran with it. KDE developers took offense because they expected that anyone who improved their code would do so with the same goals as the developers, i.e. improving KDE. That is an unrealistic expectation. Apple didn't care about KDE and is under no obligation, legal or ethical, to care about KDE. If the KDE developers want to benefit from Apple's improvements to the code then they will have to put in some effort, but they got along just fine (as far as they were concerned) without those improvements before Apple got involved. > > It's easy for people to take offense. Apple did what it did for > > business reasons, > > Ah, here we go. I was waiting for the "profitable==ethical" slant. > Whatever. I never made that implication. Consider that Apple had a motivation (need a web browser component) and had five options to get it: 1) license some non-free code from someone 2) write their own in-house and keep it closed 3) write their own in-house and release it as FOSS 4) bend an existing FOSS project to their needs 5) take FOSS code and adapt it to their needs without interfering with the current maintainers Which of these is best for the FOSS community? #1 and #2 provide no value to anyone but Apple. #3 provides arguable value, but who needs yet another immature, competing browser engine? #4 would piss off lots of people and probably wouldn't even work. Only #5 is both respectful of the FOSS community and actually produces worthwhile software. And remember that the profit motive is what makes the first two choices, which are of no value to FOSS, less viable. > > Is it hostile to fork code? How about creating an independent, competing > > codebase (e.g. KHTML vs. Gecko)? Again, no sympathy. > > Competition is good. Forking fragments efforts. Bullshit twice over. Forking builds on what already exists. Unless your competing codebase is based on designs that are both significantly better than what you're competing against and so fundamentally different that they can't be accommodated by the existing codebase, a whole new codebase is a waste of duplicated effort in *addition* to fragmenting effort. Both forking and entirely new, competing codebases fragment effort, but at least forking minimizes wasted effort reinventing the wheel. > > a problem with bruised egos, > > Did you read the article at all? It's not about egos. It really is > *hard* to put Webkit into KDE. Apple ignored KDE's patches, and gave > the impression that they wanted gratis employees, not collaborators. > They didn't play nice with KDE, whatever other benefits to Webkit may > bring to the world at large, but KDE got a lot of problems because of > the whole thing. Apple had no more reason to play nice with KDE than KDE had to play nice with Apple. Their goals are completely unrelated. Apple doesn't want gratis employees, they want *paid* employees whose vested interests are dictated by their employer. As long as Apple and KDE have different goals then they will not benefit one another by working together except accidentally, e.g. through Qt. The hearts and minds behind KHTML considers it important to be able to embed kparts in web pages to handle various content types. Apple doesn't give a rats ass about integrating with KDE, nor should they. They do, however, consider rich text editing a priority, and KDE isn't as concerned about that. I'm still not feeling sympathy for the KHTML folks. It sounds more like *they* want the gratis employees, but paid by Apple. They want Apple to deal with KDE's turnaround on patches instead of having to deal with Apple's turnaround on patches. Both sides want their own release cycles and control of the codebase. And they both have it! As things stand, Apple has shown itself to be a better custodian of the library, in the sense that it has greater functionality with a broader appeal (note that those are not separate -- the functionality WebKit has over KHTML is of broader appeal than the functionality KHTML has over WebKit; I'm not going to open a can of worms about which one is objectively more functional). More end users benefit from Apple's codebase than KHTML. Should KDE simply give up control of the codebase and go with WebKitQt? Well, it's an option, but it's really up to them. If control of the codebase and the advantages of KHTML over WebKit are worth more to them than the improvements in WebKit, then they are right to hold onto their own codebase and they can put the effort into incorporating WebKit improvements as they have time and interest. If not, however, it is only ego that makes them hold onto KHTML. I'll repeat, for those who skimmed: Apple is under no obligation, legal or ethical, to care about KDE. > - Jordi G. H. --Greg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
