clear that the project would play favorites among the software
choices available to it, and that the resulting process would be
painful. You can't say that you weren't warned. But it turns out
not to be particularly painful, except for one issue: the
selection of the GUI used in the system. The selection of GNOME
as the GUI of the UserLinux project has raised a good deal of
opposition from KDE supporters.
GNOME and KDE are both Free Software. Both are developed by
lots of good programmers, with the support of honorable business
people. Many people in the Free Software community have a huge
emotional (or even financial) investment in KDE or GNOME, because
they have put a lot of development into one of those desktops, or
they've just spent a lot of time with one of them as a user.
To many of those people, it's simply unbearable for their personal GUI
not to be the one chosen for our project.
Why play favorites at all? Debian doesn't, and UserLinux is to
be derived from Debian. There are more than 13,000 software
packages in Debian's pre-release at this writing, including at
least three complete desktop GUIs: KDE, GNOME, and GNUStep. The
FreeDesktop.org site hosts efforts to increase inter-operability
between GNOME and KDE, and the Red Hat Bluecurve project
has created a theme that makes the two GUIs look identical.
Applications from KDE and GNOME run reasonably well together
today. And most important: non-programmer users don't care what
GUI toolkit their application is built upon. The GUI issue is a
developer, not user, discussion.
But all of the efforts to unify these two desktops do not
change the fact that there are two entirely different GUI SDKs.
The two competing GUIs are each of a complexity equal to or
greater than that of the Linux kernel. For developers and support
staff, maintaining expertise in both of two GUIs is an expensive
proposition. Many IT shops, when faced with such choices, have
decided to consolidate to fewer options in order to reduce
UserLinux is intended to be a system for business people.
Central to its design is a network of competing for-profit
service providers, who perform engineering and support services
for the system. Because these service providers are basing their
business upon a commodity product, there are already economic
limits upon how profitable they can be. The difference between
one and two GUIs may spell profitability or bankruptcy for some
of our service providers. In a similar vein, internal support and
engineering staff at businesses that employ UserLinux would like
to have only one GUI SDK to develop for and maintain. This is not
to say that choice is bad. Rather, it's bad when people aren't
allowed to choose.
We held about a week of discussion on the GUI issue, on the
UserLinux mailing list - about 200 postings. It drowned out all
other work. It was clear from the discussion that while GNOME and
KDE each exceed the other in some areas, when you weigh them all
together they are of equal technical merit. However there is a
critical business difference between the two GUIs: GNOME does not
require a royalty in connection with proprietary software
development based upon their SDK. Qt, the widget set upon which
KDE is based, does have a proprietary developer licensing fee
connected with it.
It's important for us to get more Free Software into business,
so that businesses will be sympathetic with us when we need to
ask for legislative changes to support the long-term viability of
Free Software. You know the issues: software patents, DRM, etc.
Today these are seen as business vs. fringe-party issues, and
we're on the losing side. The extent to which our software
penetrates the business world will govern our effectiveness in
getting the legislative changes we need.
Enterprise users buy solutions, not systems. And it's a fact
of life that enterprise customers will want to run a mixed Free +
proprietary environment, choosing whatever software is best for a
particular application. The overall viability of UserLinux will
be based upon the size and quality of the ecosystem of solutions
around it, both Free and
proprietary. So, in order to get any Free Software into businesses,
our Free system must promote the creation of a large collection
of proprietary solutions that do not exist today. As we penetrate
the enterprise, we will continue to move Free Software higher up
the application stack, until these businesses make use of Free
Software predominantly. But you need proprietary software to get
in the door.
It is possible for us to make our system entirely royalty-free
for solution developers, both Free and proprietary. This dictates
some software choices: GNOME and PostgreSQL rather than KDE and
MySQL, simply because of the way those products license
proprietary developers. This will support a large ecosystem of
both Free and proprietary solution developers by lowering the
financial barriers to entry all the way to zero. This will be
especially important in third-world countries, where the expense
of an SDK license is much more significant than to a developer in
the US or Europe.
Almost all Linux distributions have been quiet about their GUI
choice, because it does seem to make a few enemies and might
dissuade some customers who have already made a GUI choice. I
felt that attempting to be everything to everyone would be the
coward's choice and the worst possible decision, that
focus would be
appreciated by business users, and that most business users don't
have any GUI preference other than wanting to be able to focus
development and support on only one GUI. Thus, it would be
necessary to select one GUI.
As you can see on our mailing list, most of the software
consolidation in UserLinux is going on by consensus. I saw that
no consensus would be possible regarding the GUI. So, I made a
decision by fiat to get the project moving past the GUI issue.
UserLinux will be GNOME-based, will not include Qt or KDE
components by default, and we'll make it known that project
policy is to develop for, and support GNOME. Obviously, this
caused much emotion: while the formal proposal of the KDE group
was polite, there has been a large amount of personal abuse on
the mailing list. But there is little reason for the emotion. The
decision does not prevent anyone from using KDE and Qt components
on UserLinux, does not prevent anyone from installing those
components from the Debian packages, and does not prevent any of
our support providers from formally supporting KDE. It doesn't
take any choice away from users, who can get KDE on our platform
The plan presented by the KDE supporters is a good one, and I
would encourage them to go ahead with it, using a Debian base.
We'll have no problem sharing work with them, just as they share
work through FreeDesktop.org and Debian today. But the decision
to base UserLinux on GNOME stands. Further personal abuse will be
ignored as cheerfully as it has been for the past week, I've had
a decade of practice at that and do it really well now. It would
be nice if people would allow the mailing list contributors to
continue to work on non-GUI issues, by not spamming the list with GUI
In February, my book series will publish C++ GUI Programming with Qt, the
official Trolltech guide
to Qt 3.2, by Jasmin Blanchette and Mark Summerfield. I have a
minor financial interest in promoting Qt (I don't make much money
from my books), but no such interest in the case of GTK/GNOME at
this time. Because of a miscommunication with my publisher, there
is some non-free software on the CD attached to that book -
Windows Qt and some compilers from Borland. Although that is
against my policy for the books, and I told my publisher not to
allow it to happen again, I chose to allow it to continue this
time rather than create hardship for Trolltech at a late stage in
their book production. I also recently recommended Qtopia to a
consulting customer, for what could be a billion-dollar project.
I point this out so that you might have some clue that I not an
I am carrying on the UserLinux development, and am currently
working on the installer. Others are also pursuing much
constructive work, as is visible now on our mailing list.