Re: Blocking Gmail ads
On Fri, May 16, 2008 at 07:34:19AM -0500, Jordi Guti?rrez Hermoso wrote:
> On 16/05/2008, Gregory Seidman <gsslist+debian@anthropohedron.net> 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
Reply to: