An Interview With Miguel De Icaza
by
Dare Obasanjo
What follows is my interview with Miguel de Icaza, the founder of
GNOME and Ximian, where he talks about UNIX
components,
Bonobo, Mono and .NET.
Dare Obasanjo: You have recently been in the press due to
Ximian's announcement that it shall create an Open Source
implementation of
Microsoft's .NET development platform. Before the recent
furor you've been notable for the work you've done with
GNOME and Bonobo. Can you give a brief overview of your involvement
in Free Software from your earlier projects up to Mono?
Miguel de Icaza: I have been working for the past four
years on the GNOME project in various areas: organization of it,
libraries and applications. Before that I used to work on the Linux
kernel, I worked for a long time on the SPARC port, then on the
software raid and some on the Linux/SGI effort. Before that I had
written the Midnight Commander file manager.
Dare Obasanjo: In your Let's
Make Unix Not Suck series you mention that UNIX development has
long been hampered by a lack of code reuse. You specifically
mention Brad
Cox's concept of Software Integrated Circuits, where
software is built primarily by combining reusable components, as a
vision of how code reuse should occur. Many have countered your
arguments by stating that UNIX is built on the concept of using
reusable components to build programs by connecting the output of
smaller programs with pipes. What are your opinions of this
counter-argument?
Miguel de Icaza: Well, the paper addresses that question in
detail. A `pipe' is hardly a complete component system. It is a
transport mechanism that is used with some well known protocols
(lines, characters, buffers) to process information. The protocol
only has a flow of information.
Details are on the paper:
http://primates.ximian.com/~miguel/bongo-bong.html
[Dare -- check the section entitled "Unix Components:
Small is Beautiful"]
Dare Obasanjo: Bonobo was your attempt to create a UNIX
component architecture using CORBA as the underlying base. What are
the reasons you have decided to focus on Mono instead?
Miguel de Icaza: The GNOME project goal was to bring
missing technologies to Unix and make it competitive in the current
market place for desktop applications. We also realized early on
that language independence was important, and that is why GNOME
APIs were coded using a standard that allowed the APIs to be easily
wrapped for other languages. Our APIs are available to most
programming languages on Unix (Perl, Python, Scheme, C++,
Objective-C, Ada).
Later on we decided to use better methods for encapsulating our
APIs, and we started to use CORBA to define interfaces to
components. We complemented it with policy and a set of standard
GNOME interfaces for easily creating reusable, language independent
components, controls and compound documents. This technology is
known as
Bonobo. Interfaces to Bonobo exist for C, Perl, Python, and
Java.
CORBA is good when you define coarse interfaces, and most Bonobo
interfaces are coarse. The only problem is that Bonobo/CORBA
interfaces are not good for small interfaces. For example, an XML
parsing Bonobo/CORBA component would be inefficient compared to a C
API.
I also wrote at some point:
My interest in .NET comes from the attempts that we have made
before in the GNOME project to achieve some of the things .NET
does:
- APIs that are exposed to multiple languages.
- Cross-language integration.
- Contract/interface based programming.
And on top of things, I always loved various things about Java.
I just did not love the Java combo that you were supposed to give
or take.
APIs exposed to many languages we tried by having a common
object base (GtkObject) and then following an API contract and a
format that would allow others to wrap the APIs easily for their
programming language. We even have a Scheme-based definition of
the API that is used to generate wrappers on the fly. This
solution is suboptimal for many reasons.
The Cross-language integration we have been doing with CORBA,
sort of like COM, but with an imposed marshalling penalty. It
works pretty well for non inProc components. But for inProc
components the story is pretty bad: since there was no CORBA ABI
that we could use, the result is so horrible, that I have no
words to describe it.
On top of this problem, we have a proliferation of libraries.
Most of them follow our coding conventions pretty accurately.
Every once in a while they either wont or we would adopt a
library written by someone else. This had lead to a mix of
libraries that although powerful in result implement multiple
programming models, sometimes different allocation and ownership
policies and after a while you are dealing with 5 different kind
of "ref/unref" behaviours (CORBA local references,
CORBA object references on Unknown objects, reference count on
object wrappers) and this was turning into a gigantic mess.
We have of course been trying to fix all these issues, and
things are looking better (the GNOME 2.x platform does solve many
of these issues, but still).
.NET seemed to me like an upgrade for Win32 developers: they had
the same problems we had when dealing with APIs that have been
designed over many years, a great deal of inconsistency. So I
want to have some of this new "fresh air" available for
building my own applications.
Dare Obasanjo: Bonobo is slightly based on COM and OLE2 as
can be gleaned from the fact that Bonobo interfaces are all based
on the Bonobo::Unknown interface which provides two basic services:
object lifetime management and object functionality-discovery and
only contains three methods:
module Bonobo {
interface Unknown {
void ref ();
void unref ();
Object query_interface (in string repoid);
};
};
which is very similar to Microsoft's COM IUnknown
interface which has the following methods
HRESULT QueryInterface(REFIID riid, void **ppvObject);
ULONG AddRef();
ULONG Release();
Does the fact that .NET seems to spell the impending death of COM
mean that Mono will spell the end of of Bonobo? Similarly
considering that .NET plans to have semi-transparent
COM/.NET interoperability, is there a similar plan for Mono and
Bonobo?
Miguel de Icaza: Definetly. Mono will have to interoperate
with a number of systems out there including Bonobo on GNOME.
Dare Obasanjo: A number of parties have claimed that
Microsoft's NET platform is a poor clone of the Java™
platform. If this is the case why hasn't Ximian decided to
clone or use the Java platform instead of cloning Microsoft's
.NET platform?
Miguel de Icaza: We were interested in the CLR because it
solves a problem that we face every day. The Java VM did not solve
this problem.
Dare Obasanjo: On the Mono Rationale
page it is pointed out that Microsoft's .NET strategy
encompasses many efforts including
- The .NET development platform, a new platform for writing
software.
- Web services.
- Microsoft Server Applications.
- New tools that use the new development platform.
- Hailstorm, the Passport centralized single-signon system that
is being integrated into Windows XP.
and you point out that Mono is merely an implementation of of the
.NET development platform. Is there any plan by Ximian to implement
other parts of the .NET strategy?
Miguel de Icaza: Not at this point. We have a commitment to
develop currently:
- A CLI runtime with a JITer for x86 CPUs.
- A C# compiler.
- A class library
All of the above with the help of external contributors. You have
to understand that this is a big undertaking and that without the
various people who have donated their time, expertise and code to
the project we would not even have a chance of delivering a
complete product any time soon.
We are doing this for selfish reasons: we want a better way of
developing Linux and Unix applications ourselves and we see the CLI
as such a thing.
That being said, Ximian being in the services and support business
would not mind extending its effort towards making the Mono project
tackle other things like porting to new platforms, or improving the
JIT engine, or focusing on a particular area of Mono.
But other than this, we do not have plans at this point to go
beyond the three basic announcements that we have made.
Dare Obasanjo: There are a number of other projects that
are implementing other parts of .NET on Free platforms that seem to
be have friction with the Mono project. Section 7.2 of
Portable.NET's FAQ seems to indicate they have had conflict
with the Mono project as does the
banning of Martin Coxall from the dotGNU mailing list. What are
your thoughts on this?
Miguel de Icaza: I did not pay attention to the actual
details of the banning of Martin from the DotGNU mailing lists.
Usenet and Internet mailing lists are a culture of their own and I
think this is just another instance of what usually happens on the
net. It is definitely sad.
The focus of Mono and .NET is slightly different: we are writing
as much as we can in a high level language like C#, and writing
reusable pieces of software out of it. Portable.NET is being
written in C.
Dare Obasanjo: There have been conflicting reports about
Ximian's relationship with Microsoft. On one hand there are
reports that seem to indicate that there may be licensing
problems between the license that will govern .NET and the GPL.
On the other hand
there is an indication that some within Microsoft are
enthusiastic about Mono. So exactly what is Ximian's
current relationship is with Microsoft and what will be done to
ensure that Mono does not violate Microsoft's licenses on .NET
if they turn out to be restrictive?
Miguel de Icaza: Well, for one we are writing everything
from scratch.
We are trying to stay on the safe side regarding patents. That
means that we implement things in a way that has been used in the
past and we are not doing tremendously elaborate or efficient
things in Mono yet. We are still very far from that. But just using
existing technologies and techniques.
Dare Obasanjo: It has been pointed out that Sun retracted
Java™ from standards processes at least twice, will the Mono
project continue if .NET stops being an open standard for any
reason?
Miguel de Icaza: The upgrade on our development platform
has a value independently of whether it is a standard or not. The
fact that Microsoft has submitted its specifications to a standards
body has helped, since people who know about these problems have
looked at the problem and can pin point problems for
interoperability.
Dare Obasanjo: Similarly what happens if
Dan Kusnetzky's prediction comes true and Microsoft changes
the .NET APIs in the future? Will the Mono project play catchup or
will it become an incompatible implementation of .NET on UNIX
platforms?
Miguel de Icaza: Microsoft is remarkably good at keeping
their APIs backwards compatible (and this is one of the reasons I
think they have had so much success as a platform vendor). So I
think that this would not be a problem.
Now, even if this was a problem, it is always possible to have
multiple implementations of the same APIs and use the correct one
by choosing at runtime the proper "assembly". Assemblies
are a new way of dealing with software bundles and the files that
are part of an assembly can be cryptographically checksummed and
their APIs programmatically tested for compatibility.
[Dare --
Description of Assemblies from MSDN glossary]
So even if they deviate from the initial release, it would be
possible to provide assemblies that are backwards compatible (we
can both do that: Microsoft and ourselves)
Dare Obasanjo: Looking at the Mono class
status page I noticed that a large number of .NET class
libraries are not being implemented in Mono such as WinForms,
ADO.NET, Web Services, XML schemas, reflection and a number of
others. This means that it is very likely that when Mono and .NET
are finally released apps written for .NET will not be portable to
Mono. Is there any plan to rectify this in the future or is
creating a portable .NET platform not a goal of the Mono project?
Similarly what are the short and long term goals of the Mono
project?
Miguel de Icaza: The status web page reflects the classes
that people have "requested" to work on. The status web
page is just a way of saying `Hey, I am working on this class as of
this date' to avoid code duplication. If someone registers
their interest in working on something and they do not do something
after some period of time, then we can reclaim the class.
We are on the very early stages of the project, so you do see more
work going on the foundational classes than on the end user
classes.
I was not even expecting so many great and talented programmers to
contribute so early in the project. My original prediction is that
we would spend the first three months hacking on our own in public
with no external contributions, but I have been proved wrong.
You have to realize that the goals of the Mono project are not
only the goals of Ximian. Ximian has a set of goals, but every
contributor to the project has his own goals: some people want to
learn, some people like working on C#, some people want full .NET
compatibility on Linux, some people want language independence,
some people like to optimize code, some people like low level
programming and some people want to compete with Microsoft, some
people like the way .NET services work.
So the direction of the project is steered by those that
contribute to it. Many people are very interested in having a
compatible .NET implementation for non-Windows platforms, and they
are contributing towards filling those gaps.
Dare Obasanjo: How does Ximian plan to pay for the costs of
developing Mono especially after the failure of a number of recent
venture funded, Free Software-based companies like
Indrema, Eazel and Great Bridge and the fact
that a sizable percentage of the remaining Free Software based
companies are on the ropes? Specifically how does Ximian plan to
make money at Free Software in general and Mono in particular?
Miguel de Icaza:Ximian provides support and services. We
announced a few of our services recently, and more products and
services have been on the pipeline for quite a while and would be
announced during the next six months.
Those we announced recently are:
- Red Carpet Express: a subscription service for those who want
a reliable high speed access to the Red Carpet servers.
- Red Carpet Corporate Connect: We modified our Red Carpet
updater technology to help people manage networks of Linux
workstations easily and to deploy and maintain custom software
packages.
- Support and services for the GNOME desktop and Evolution: Our
latest boxed products are our way of selling support services for
the various products we ship.
We have also been providing professional services and support for
people integrating free software based solutions.
The particular case of Mono is interesting. We are working on Mono
to reduce our development costs. A very nice foundation has been
laid and submitted to ECMA. Now, with the help of other interested
parties that also realize the power of it, we are developing the
Mono runtime and development tools to help us improve our
productivity.
Indeed, the team working on Mono at Ximian is the same team that
provided infrastructural help to the rest of the company in the
past.
Dare Obasanjo: It is probably little known in some corners
that you once
interviewed with Microsoft to work on the SPARC port of
Internet Explorer. Considering the impact you have had on the Free
Software community since then, have you ever wondered what your
life would have been like if you had become a Microsoft employee?
Miguel de Icaza: I have not given it a lot of thought, no.
But I did ask everyone I interviewed at Microsoft to open source
Internet Explorer, way before Netscape Communicator was Open
Sourced ;-)
© 2001 Dare Obasanjo