Today we feature a 4-page interview with Nat Friedman, Co-Founder and Vice-President of Product Development at Ximian. We discuss a lot of interesting topics, ranging from Ximian’s products, to Apple, to Linux on the desktop and much more. Four screenshots of the upcoming Ximian Desktop 2 are also included, so come in and have a pick! UPDATE: Eight more screenshots added! Update2: Yaay… one more screenshot for your viewing pleasure!
1. Which version of GNOME is Ximian Desktop 2.0 based on exactly, and what changes have you applied when compared to the vanilla Gnome?
Nat Friedman: XD2, as we like to call it, is based on GNOME 2.2, Mozilla 1.3 and
We’ve spent a lot of time polishing the user experience and making
sure things just work. Our focus is on creating _usability through
consistency_, which lowers support costs for big organizations that
replace Windows machines with Linux.
We have a new desktop theme called Industrial which themes GTK version
1 and 2. It’s also a Nautilus theme, a Galeon theme, an XMMS theme,
an OpenOffice.org theme, a Metacity theme, and an Icon theme. This
means that the desktop looks and feels unified.
One of the big problems we solved was the printing UI. Using CUPS as
the backend, most printers are now automatically detected and
configured, even if they’re on the network. We also added a simple
printer configuration wizard. Configured Printers show up in your
file manager and can be easily reconfigured to change things like
paper sizes, using a familiar interface. Small things matter: your
printer jobs appear on the panel until they are done, so you know when
to pick up the results. Large things matter too: when printing from
an application, just click on the printer you want to print to. For
most people, this solves the Linux printing problem pretty well.
We’ve also worked on file sharing for people in corporate networks.
Users often have trouble understanding why they need to mount network
drives before they can use them. We’ve made NFS and SMB share
browsing easy, and made it possible for most applications we ship to
open files on unmounted shares. It’s pretty slick when you try it the
first time; especially as a demo at a customer site with unprotected
SMB shares ;-).
When GNOME 2.4 comes out, we’ll likely issue a follow-on release not
long after which will be based on the 2.4 modules. We are currently
working on porting our OOo patches to OOo 1.1, which includes a lot of
2. I read on your web page that Ximian Connector supports Microsoft Exchange 2000. Is Exchange “Titanium” support planed? How “easy” is to implement an alien technology like Exchange under Unix?
Nat Friedman: Yep, Ximian Connector does support Exchange 2000. There are a lot of
people who’ve been able to ditch their Windows machines and switch
over to Linux because they can now use their Exchange server for
calendaring and collaboration from their Linux desktop.
We don’t support earlier versions of Exchange because it is really
hard to do all the MAPI/DCE-RPC stuff natively from Linux, and we
expect most Exchange customers to migrate off Exchange 5.5 eventually.
We plan to support Exchange 2003 (“Titanium”) as soon as it is
released. We already have the prerelease versions from MSDN. We
expect the final release to be this summer, and most of the work we’ll
have to do will be testing to make sure the current Connector still
works against the new server version.
The Connector is an interoperability product, and interoperability
software is never really “easy.” Especially when it has to
interoperate with a largely undocumented or misdocumented protocol and
service. You can look at projects like Wine and Lesstif as extreme
examples of the difficulty of building perfect compatibility software.
It’s probably fair to say that the ratio of time our Connector
developers spend in the debugger versus the Emacs buffer is higher
than with most software. It’s not as high as with Wine; Jeremy White
from Codeweavers will tell you that his hackers spend very close to
100% of their time in gdb.
3. Do you plan on broadening your business into other mainstream Unix-based platforms, like Mac OS X for example? How would you feel of a port of Evolution and Connector to OSX (with or without GTK+ and XFree86)?
Nat Friedman: Evolution *does* build and work on OS X with little or no fuss,
especially if you have fink going; there are half a dozen tiBooks at
Ximian HQ all of which run Evolution. Apple is cool. We like Apple.
But we’re not going to spend a lot of time porting and supporting our
stuff on Mac OS X. Someone ran a poll a while ago to try to drum up
support for a Ximian-supported OS X Connector, and the demand just
Why isn’t the demand there? Because Mac OS X isn’t a free platform,
and it runs on expensive hardware. It is not a plausible Windows
alternative for our desktop customers, who are mainly large government
organizations displacing Windows desktops and big enterprise
corporations replacing Solaris workstations. That is where the action
is today for Linux clients. It is not in the consumer space, which is
where Mac OS X plays.
I’m personally working on converting about 250,000 different Windows
machines to Linux desktops, primarily in European government. These
are groups of machines which are in various stages of adopting Linux:
some early, some very advanced (we have a couple big deployments that
I hope we can talk about soon), but all with a lot of pro-Linux
A lot of that momentum comes from the fact that Linux is free
(something not true of Mac OS X, whatever they’ve gotten you to
believe) and the procurement costs for Linux desktops are low
(something definitely not true for Apple, which has a policy of
pricing slightly above the PC — a la Bosendorfer or Harley-Davidson).
You can’t tell a compelling story about cost savings or vendor
independence to European or South American governments and also peddle
I have a G4 at home. They’re great machines for individual users, and
I even know a few core Linux hackers who are having a lot of fun with
them. But if you want to move the needle on the non-Microsoft
desktop, you’ve got to look elsewhere.
Google Zeitgeist has consistently reported Linux user-agents at 1% of
their total searches for the last year. I’d like to bump that number
and cause some shivers in Redmond. That’s what we’re focused on, and
the way to do that is to target the userbase segments where a Linux
desktop can succeed on a large scale.
4. Red Carpet has made inroads in many corporations for software deployment and management. Would you ever consider expanding it to become a front end for apt-get as well, serving as a more elegant synaptic/gselect?
Nat Friedman: Red Carpet has a nice package abstraction layer that allows us to
support RPMs and DEBs transparently. You can use the Red Carpet
end-user client (GUI or CLI) or our centralized Red Carpet Enterprise
product to manage Debian machines just fine. Red Carpet has supported
Debian since its introduction.
One of the things that people like about apt-get is having an
easy-to-use software catalog at their fingertips, so if you want to
install some missing software on your machine, you can do it with a
Red Carpet gives you this too, and on non-Debian systems, with a
commandline and a nice GUI. With Red Carpet, you can type:
rc in <package name>
to install new software from a channel. And you can do this on any
Red Carpet-enabled system, be it Debian or SuSE or Red Hat. (Other
tricks: with the GUI you can bundle a whole transaction of installs,
removals, upgrades, etc and run it all at once; also, try ‘rc mount
<directory>’ to map a directory to a channel).
5. What do you think about the evolution of Gnome in regards of usability and looks when compared to KDE, OS X and the latest Windows? Does the development pace satisfies you? What do you think about the lack of
integration between all X11 DEs and the underneath OS system?
Nat Friedman: GNOME is aiming for simplicity and consistency; we’re the first open
source desktop project to have a documented set of human interface
KDE has way more options (the clock properties dialog has five tabs!)
and Windows migrants frequently find this confusing, especially people
who work in offices. Also, KDE sort of “looks” like Windows, which
people frequently find confusing, since it implies that it will act
exactly like Windows, which it doesn’t (we have partners who have done
UI studies that confirm this).
OS X is sweet: it’s simple and intuitive, and I think GNOME shares a
lot of values with it.
Freedesktop.org has done a lot to improve integration between the
desktop environments. Send love over there if you want to improve
6. How is Mono progressing? Do you have plans to include C# code in Evolution and/or other products?
Nat Friedman: Mono is doing really well. I started hacking in Mono a few months ago
for some personal projects, and was very impressed with how complete
and usable it is. There are a few software houses and embedded
developers who may be using Mono as the basis for their .NET products
soon, too (announcements to come if we get the deals).
One of the really cool things about Mono is that you get a high-level,
garbage-collected language which can wrap C and C++ trivially. For
example, if you want to use the GNOME-VFS library from your C#
application to find the MIME type of a given file, you just do this:
[DllImport (“libgnomevfs-2”)] extern static string gnome_vfs_get_mime_type (string text_uri);
And then you can use the gnome_vfs_get_mime_type() function from your
C# code. That’s it — that’s all the code you have to write. This is
way better than Java Native Interfaces (JNI), which requires you to
compile a wrapper class before you can call into C, and needs some
other boilerplate code. In C#, for many cases, you don’t have to
worry about header files or wrapper classes or anything.
This has two important ramifications.
First, Mono applications can easily use existing C-based GNOME
components and take advantage of all the hard work that’s gone into
them. So as Mono matures, people will begin to use it to write
desktop components that take advantage of all the hard work that’s
gone into some of the meatier GNOME libraries, as well as the nifty
language features of C#. Gtk# is a good example of this, but I think
we’ll start to see things like GNOME-VFS, GConf and the Camel
messaging library being used from Mono more often.
Second, this means that Mono can be the universal component hub,
allowing you to use C objects from Python, C++ objects from Perl, and
so on. This is possible because C#’s language features make it
trivial to automatically bind C# objects into other languages. Check
out Python Scripting for .NET:
http://www.zope.org/Members/Brian/PythonNet/FAQ.html. There’s also a
We’re not going to make Evolution or any of our other products depend
on Mono anytime in the near future. However, we are already
prototyping new functionality in Mono (like the sidebar folder summary
Miguel wrote), and in a year or so, we may feel comfortable enough to
start writing new critical-path code in Mono. Certainly we won’t do
anything like rewrite currently-working components in C#. There won’t
be an all-at-once port of Evolution to Mono, for example.
What is pretty likely to happen in the near future is that we’ll ship
C# bindings for key things like the Evolution backend data stores —
your mail, your calendar, your addressbook, etc. — at some point
soon. This means the community can use Mono to extend Evolution and
the desktop without all the hassle of diving into the web of C-based
7. How is the market responding to your Red Carpet Enterprise product? What do you see as the biggest competitor to this product today
Nat Friedman: Big Linux deployments have reached the point where it’s become a real
problem for administrators that they don’t have nice tools to manage
their servers and desktops.
Red Carpet Enterprise has been really well received since one guy can
install it in about an hour, and it makes it trivial to deal with
software management issues like deploying updates and creating
standard package sets for your various machines.
Amerada Hess is one good example of this, where one administrator is
using RCE to single-handedly administer 300 Linux servers and
desktops. This is what people need: an easy-to-deploy, easy-to-use
RCE also has the nice advantage that it supports pretty much every
major Linux distribution out there; this is especially handy in
environments where you’ve got a few different distros in use.
8. What changes have you made to OpenOffice.org when compared to its vanilla version?
We don’t _want_ to have any delta against the upstream OOo tree, so
we’re going to be working to get all of those changes upstream now
that this release is done.
Here’s a dump of some of the key new features in our OOo:
– ~1,000 new alpha-blended icons that are aesthetically
consistent with the rest of the desktop. We use large icon
mode by default. We also have some other new art in some of
the wizards and of course the splash (which no longer makes
your desktop unusable while each application starts up).
– Shares the Gtk theme elements (“theme chameleoning”). Uses
fontconfig, AA fonts everywhere in the UI now.
– Mapping of MSFT document fonts to Agfa fonts (which XD2
Also, our artists drew a whole new font just to handle the
bullet mappings (which aren’t fully covered by Agfa’s fonts).
– GNOME-VFS integration so you can open any files the VFS can
get to. This includes files on SMB and NFS shares. We even
handle the authentication for these shares (Michael Meeks
redid the authentication layer in OOo), so you get prompted if
the share is password protected.
– Nice CUPS printing integration so you get the same printer
list in OOo you get everywhere else in the desktop.
– Support for the recent files spec so that System->Recent
Files reflects the documents you’ve opened in OOo.
– Uses MSFT file formats by default, reflecting the reality of
most of the documents you will receive. No longer tells you
you’re about to lose all your data when you save in an MSFT
– Removed the non-redistributable GPC library, replaced it
with libart so that we can ship OOo with better support for
importing PowerPoint presentations.
– Integrates nicely with Galeon and Evolution. OOo HEAD
actually does Evolution addresbook mailmerge, which we’re
looking forward to.
– Includes a number of foreign-language dictionaries.
– We’ve also done some performance tweaks and fixed a number
of customer-reported bugs. Our turnaround time on fixes for
document importing issues is actually averaging 24-48 hours,
which is pretty remarkable.
That’s a quick summary; we have nearly 100 patches against OOo. Check
out the .src.rpm for the full list :-).
9. Do you have any plans to move to the Gecko HTML rendering engine for Evolution or are you going to continue to improve and maintain gtkhtml?
Nat Friedman: When we started developing Evolution, Gecko was incomplete and way too
big, and especially ill-suited for editing HTML, which we needed for
the mail composer. That is why we needed to write our own HTML widget.
Gecko has matured a lot since then, but of course so has GtkHTML (it
uses Pango now, and can edit tables and so on). I think there is
still a need for a lightweight HTML widget that does all the things
you need for mail, but we’d certainly accept patches to use Gecko in
Evolution. It would be nice not to have to maintain an HTML widget,
but right now that doesn’t seem plausible. Maybe someday.
10. Ximian is gaining notoriety in the messaging & collaboration enterprise Unix market with its products, but there are more products that could fill some gaps; do you have any plans to deliver a large collaboration product,
similar to Microsoft SharePoint Portal Server, a Conferencing Server, or a more “industrial” version of Gaim or some other IM system?
Nat Friedman: No, not right now. There’s a lot still to do in Evolution :-).