Re: KDE Interop [Was: D-BUS background]

[Havoc Pennington <hp redhat com>]

On Sat, Mar 01, 2003 at 04:55:27PM -0500, Miguel de Icaza wrote: 
> It is pretty silly to ignore libxml's strength that it was born and
> nurtured first in the gnome world.  Same applies to orbit. 

I should say that while some people are arguing we're taking the
technical wrong road in order to achieve interoperability, I'm not
saying that. IMO the D-BUS approach is also the right one technically,
on balance.
 
> You could say that.  Or you could say that Fontconfig was a great
> technology that stood on its own.  

Keith spent a *lot* of time asking people what they would be willing
to use, what they would need it to be like in order to use it. He also
provided patches for Qt, GTK, and Mozilla. i.e. it was not a
widely-acceptable technology by accident.
 
> But only a few months ago, you were promoting the concept of `no work on
> the infrastructure, lets work on making the desktop better'.  Which I
> think is a great direction.

Oh for sure. That's why I'm saying D-BUS is not even a significant
factor in GNOME 2.4, other than prototype fooling around; and it's
only worthy of consideration for GNOME 2.6 if it's well-baked by
then. For GNOME 2.4, I posted my wishlist here:
http://lists.gnome.org/archives/desktop-devel-list/2003-February/msg00048.html
No D-BUS there. Lockdown mode is there. I hope to work on lockdown
mode too.

If we phase in D-BUS infrastructure, it should (and as far as I can
affect it, will) be done with the tree always compiling, always
dogfoodable, and always releasing on a regular schedule.

Which isn't to say infrastructure isn't important to end users, it
does have impact. A systemwide event notification service will let us
do some nice stuff, lack of interoperability is the cause of a whole
range of bugs that impact end users, as are the lifecycle/reentrancy
problems. D-BUS is (in part) a proposal for the most
underengineered/easy way to fix this stuff.

> Reading today's Slashdot comments, you can see that our desktop is
> falling behind stability-wise and feature wise to KDE. 

My view is that we're ahead of KDE in a number of areas, in some cases
far ahead. Not all areas of course.

It's easy to listen to Slashdot too much. But those people do not have
the same priorities that an operating system vendor or an "enterprise
customer" has. Usability, simplicity, modularity of the packaging,
accessibility, licensing, applications, interoperability, standards
compliance, development process/visibility, API/ABI supportability,
the list of things that really matter that Slashdot doesn't understand
or care about is long. Frankly Slashdot wildly overestimates the whole
desktop environment thing to begin with; applications and the OS as a
whole are at least as important.

Nick Petreley thought that Caldera would win, IIRC because they had
more corporate-looking graphics and didn't buy into the whole open
source thing. Doh.  While KDE may "win," it's not going to be due to
the rationale that Petreley gives - he ignores numerous relevant
issues and overblows some very superficial points.

I hope your mail won't land on Slashdot or some other web
site. Slashdot (= shorthand for all similar sites) is the most evil
influence possible if we really want to do what it takes for Linux (or
UNIX) to succeed on the desktop.

The reason "enterprise customers" matter is that "enterprise customer"
basically means "customer who deploys lots of seats and pays lots of
money." And this is thus where you win significant marketshare and
make significant revenue. And that's where you can start having some
momentum.

> I probably mentioned this before, but when I went to Mexico in December
> to the facility where we launched gnome, they had all switched to KDE3. 
> I am not sure the reasons they gave me were correct, and they can be
> debated (and in fact, people in #gnome pointed out that those reasons
> might be wrong), but here they are:

On the other hand, this Slashdot post is from a guy Luis knows who
admins computers for a department at a local university:
 http://lists.gnome.org/archives/desktop-devel-list/2003-February/msg00818.html

Not an "enterprise customer" either by any means (university depts
aren't rolling in cash), but another point of view.

> 	* Compiling Gnome is too difficult.

A great example - what is typically called an "enterprise customer"
would not compile GNOME. Some of these guys have a heart attack if
they have to run any binaries that haven't been officially certified
for the *specific version and errata set* of Red Hat Linux (or
whatever OS) they are running. We put out a security patch, they want
to see all their ISVs say "that doesn't break our app." Compiling
GNOME themselves would mean they would have no support at all.
 
On the other hand, GNOME's modularity is clearly better when it comes
to scaling/parallelizing our development process and easing
distribution maintenance - i.e. helping us handle a larger development
team and manage architecture changes over time.

Not to discount the value of promoting garnome/jhbuild.

> 	* Gnome is slower than KDE.

Totally depends on your setup (many people on Slashdot today actually
said the opposite of this), and assuming basic sanity, is no way going
to be the most important factor for anyone who's paying money for the
OS vs. trying to use something cheap on old hardware.  I use GNOME 2.2
on my 266 Mhz laptop, though.

That said, we are on track to be *substantially* smaller and faster if
we kill the duplication of platform in gtk vs. libbonoboui, speed up
pixbuf handling, optimize fontconfig, and some stuff like
that. kdelibs is *huge*, as is Qt, and they heavily duplicate each
other. While GNOME has no fundamental or pervasive reason it's larger
than XFCE, just a few relatively solveable isolated bloat points.
This is a place we could be a lot better than any of the competition
with a bit of effort.

> 	* KDE's file manager acts like Windows: its a browser and a 
> 	  file manager.

However Konqueror is incredibly complex UI-wise compared to Windows
Explorer, and simply does not handle many web pages that Mozilla does
(though sure, it anecdotally works well enough for many people, and
having Safari helping may address this over time).

I believe the real Windows clone distributions are using forks of KDE
2 with their own file manager or control center, plus Mozilla and
OpenOffice.  The Chinese government developed distribution is doing
the same.

Windows XP moves in the same direction as GNOME in terms of
simplifying things rather than adding more complexity; OS X and the
screenshots of next-gen Windows move even further that way.  GNOME 2.2
is *still* more complex than either Windows or OS X in various ways.

> At this point we are not fatally loosing a race for adoption, and a race
> to see our baby and our work be used by millions, but we are lagging
> behind.  In this area, I agree with Jeff, I personally (because of the
> emotional component described before), would like to see more work be
> done on the Gnome desktop and less on replicating infrastructure. 

We have to fix infrastructure that's part of the reason for lag (when
there is lag - I certainly agree we lag in some areas, but on balance
I think we have a solid lead right this minute).

A good reason to fix infrastructure is "I am getting way too many
heisenbug reports in this area" or "lack of interoperability here is
hosing users" or "we could trim 300K of bloat" or "developers are
genuinely not understanding this API and it's causing problems" or
something of that nature. A bad reason to hack on infrastructure is
"well this will be really aesthetically beautiful someday." Judgment
call, yes.

> Maybe ORBit can not be effectively used, but some people like
> Michael (who has a lot of experience in the area) rightly felt that
> d-bus was created and developed without the input that they could
> have provided, or without giving a chance to use an existing
> platform.

Well, I don't want to go there really. Don't see us reaching any
agreement on the facts or rightness.

> Again, not the same.  Some people want gnome because it makes sense
> license-wise (Red Hat and Sun seem to be concerned about *this*
> particular issue).  

This is a misconception, at least for Red Hat. There are 5 or 6 major
bullet points in the "why we default to GNOME" rationale. People felt
we could work around or address the licensing issue, in fact. The
technical and organizational points are the main ones.

(I don't want to list them; it'll just land me on Slashdot and piss
people off. Not that there's anything wrong with the reasons, they are
just a technical/requirements evaluation type of thing, but people
won't take them that way.)
 
> This is not intended as a flame.  Hope the tone here is the right one.

I think it is a good tone, I hope my reply is in the same spirit.

In short, my opinion is that we have done many of the hardest tasks
very well. We've scaled the devel organization and release process to
a large number of people. We've sorted out how to manage corporate
participation/contribution. We've addressed usability and
simplicity. We have nice HIG. We have years of effort completed for
Section 508 compliance. We have best depth of application
functionality. We are on course to have the devel platform
unified/unbloated by GTK+ 2.4, rather than two duplicating layers.  We
have the most credible enterprise OS vendors involved.  We have clean
and maintainable code with strong maintainers for nearly all the key
components. We've properly modularized those components so we can
spread out release cycles and maintenance.

What remains are some relatively isolated and addressable features and
issues, rather than big-picture hard stuff. I have no question we'll
nail a sizeable number of these in the next 6-12 months; we fixed a
ton of them for 2.2, 2.4 and 2.6 should not be different, our process
is like a machine these days. The determinant of our success will be
whether we get the right features and get them done soon enough.

Have faith in the direction we've established during 2.0 and 2.2; it's
a good path, it is the right path, and if we sustain it and don't have
too much bad luck it'll work.

Havoc