Re: Blocking Gmail ads
On Fri, May 16, 2008 at 01:40:30PM -0400, Brian McKee wrote:
> On Fri, May 16, 2008 at 9:09 AM, Gregory Seidman <gsslist+debian@anthropohedron.net> wrote:
> > 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.
>
> This is the one statement I think could be modified - Apple doesn't
> care about about integrating with KDE, and thus lost the opportunity
> to keep reaping the benefits that the KDE guys could have provided on
> going. I'd like to think that the companies that try harder to work
> with the existing community will do better in the long term -
> spending some of their resources on things they didn't care about
> would return them effort by others on things they do care about.
Why do corporations contribute to FOSS? Because (in their analysis) the
benefits of doing so outweigh the costs, including the opportunity cost of
pursuing another option (see my previous post on the options Apple had).
At a finer granularity, there's some analysis about *how* they will
contribute. Is the benefit of potential future improvements to the code by
the current developers worth the cost of working within the KDE community?
Remember that while cost ultimately boils down to dollars, time to market
and PR can be measured in dollars as well. Will an acceptably functioning
adaptation of the code be unacceptably delayed by going through the
existing community? On balance, is the PR issue with walking into a
community and trying to change its focus (even bearing the gift of code)
greater than the PR issue of forking it?
Also, remember the crucial difference in focus. If what the KDE guys are
working on for the foreseeable future (i.e. their stated priorities) is not
of interest, the potential future benefit of their improvements to the code
goes way down. In addition, giving up that benefit isn't really giving up
that benefit.
Just as the KDE guys can expend some effort to take improvements from
WebKit and port them to KHTML, Apple can expend some effort to take
improvements from KHTML and port them to WebKit. If there is some
improvement that is of sufficient value and is easier to port than
reimplement, you can bet that's what will happen. That kind of
cross-pollination is one of the beauties of FOSS. If KHTML is consistently
improving in ways that matter to Apple, I wouldn't be surprised to see
Apple making an effort to make the codebases converge.
Right now, cost/benefit analysis recommends a separate codebase (and
community). That can change, but it's only going to change if the KDE guys
are working on things that matter to Apple. If KDE's and Apple's interests
become aligned, there could be a convergence. Since they weren't initially
(and still aren't), there is a fork.
> There's nothing illegal or immoral about it - it's just short sighted
> to believe that the code was worth taking, but the coders weren't
> worth the effort required (in a direction they didn't care about) to
> keep them on board.
I don't think of it as taking the code without the coders. It's taking the
code without the agenda. Apple has their own agenda. Anyone willing to
follow that agenda, including people working on KHTML, are welcome; on the
other hand, Apple expects to have to pay people to follow their agenda,
which is why paid Apple employees are working on WebKit. This is the only
way they could work with the code without treading on KDE's agenda.
While many authors feel strongly that they have the right to set the agenda
for their code, that is specifically what the (L)GPL seeks to avoid. Just
as we object to being told what we can do with closed code, so should we
object to being told what we can do with Free code.
> Brian
--Greg
Reply to: