Some tensions that have been building in the GNOME community for a while came out this week. Havoc Pennington wrote about the language and platform options available to open source development generally, and GNOME in particular.
This sparked a large debate on PlanetGnome, among other places.
Currently the GNOME platform, meaning primarily the libraries available to GNOME developers, is written in C. There are a number of historical reasons for this: C was considered to be the most portable language around, and it allowed for very easy bindings to be written for other languages.
The only real alternative when GNOME was formed was C++, which, at the time, scored lower on both of the previous measures.
Also, some members of the community
generally didn't like C++ as a language.
Times have changed. The Mono project was launched in August 2001 after the folks at Ximian had decided that,
having gone through the pain of developing a large,
multi-component application, enough was enough:
There is a point in your life when you realize that you have
written enough destructors, and have spent enough time tracking
down a memory leak, and you have spend enough time tracking down
memory corruption, and you have spent enough time using low-level
insecure functions, and you have implemented way too many linked
The obvious candidate for an object oriented, statically typed, garbage collected language is Java. Unfortunately, the most widely used, certified Java Virtual Machines (JVMs) are not free software.
Sun Microsystems still maintains tight control over them, and even limits the ability to freely redistribute the free-as-in-beer JVM, even without modification. Currently, to the author's knowledge, the only Linux distributions that ship with either the Sun or IBM JVMs are a few
commercial enterprise distributions. While there are some free software JVMs available, their performance is generally well below that offered by the proprietary ones.
You may be wondering why languages such as Python, Perl or Ruby aren't
in consideration here. Havoc's paper doesn't do much to explain why
languages such as these won't be used for writing system components,
because the audience that he wrote it for probably take that as a
given. Dave Camp's one-liner in this blog post probably explains
the thoughs of most developers on this issue:
I have a soft spot in my heart for Python (although I have a softer spot for static type checking).
- The platforms currently associated with these languages are specific to the language, the sharing of components would be difficult. Parrot, at some point in the future, may unify these languages.
- These languages are not statically type checked by a compiler. To
developers who have been writing primarily in C, this seems dangerously
like leaving certain types of error to happen at runtime, to be
discovered by users. Automated testing can address some of these issues,
but a certain type of C programmer might have trouble sleeping at night
after shipping a large Python application, with the expectation of
receiving bug reports containing NameErrors.
- At least partially due to the dynamic nature of these languages, there are limits to some of the optimizations that can be done, either at compile time or by a Just-In-Time compiler at runtime, as used by the Java and .NET platforms. Thus performance, particularly in platform libraries which need to be fast, is a concern.
Ximian saw the standardized C# language, and the standardized Common
Language Infrastructure (CLI) from Microsoft as the way out: they could
write a GNOME platform with all to goodies of an object oriented,
statically typed, garbage collected language using and extending the
existing GNOME APIs. Since the language was standardized, there were
seemingly no trademark issues, and the parts of the platform that were
Windows specific would be replaced with GNOME components anyway.
So Ximian founded the Mono project, and things have continued with the
GNOME platform itself continuing to be coded in C, with the Mono team
progressing its C# compiler, CLI runtime and class libraries at a
Two things have happened recently to make some in the community start to think about the strategic direction that GNOME should take. The first is that Mono is actually approaching a 1.0 release sometime this year. The second is that the Java compiler and class library that are part of the GNU Compiler Collection (GCC), GCJ, is now considered to be fairly mature.
GCJ treats Java essentially as a subset of C++ with garbage collection and a large class library. Java source code is compiled to native code and then linked against a modified Boehm garbage collection library. Most of the standard class libraries have been implemented, with the notable exception being the windowing packages AWT and SWING.
The GCJ was able to natively compile Eclipse last year,
and it is considered mature enough for Red Hat to ship a GCJ compiled
Tomcat Java Servlet Container in their Application Server enterprise
All of these environments will work quite well together,
until GNOME makes a decision to start writing platform libraries in a managed language, for a managed platform.
Whichever platform is not chosen might have a much more difficult time integrating such components. Many feel that GNOME needs to make some decision about which platform to support officially, otherwise the community will continue to be tied to C for the platform libraries indefinitely, or worse, risk forking.
There are a number of reasons given (by Havoc and others) as to why some in the GNOME community are unhappy with using Mono as the platform of choice, including:
- Patent concerns over parts of .NET
- General distrust of Microsoft, or strategic reluctance to adopt a Microsoft technology
- Not wanting to play "catch-up", since Mono will always be behind Microsoft's implementation
- Not wanting to upset IBM or particularly Sun, who have contributed a lot to GNOME over the past few years
These complaints don't necessarily impress Mono advocates,
however. Software patents, some say
, may well be inside Java
too, either by some third party, like in the
Eolas case, or by Sun itself. Sun, it is claimed,
has never released a general royalty free patent license in relation to its
While Havoc argued that using a C#/CLR combo might "speed up" the adoption of Microsoft's technology, proponents of Mono point out that it allows a migration path away from Windows in the future, something that won't be there if the Windows world is using CLR technologies, and the free software world has no CLR.
The catching-up-with-Microsoft argument is persuasive, but Java hardly presents a better alternative. Java, under the tight control of Sun, has moved much slower than the corresponding pace of many free software projects such as GNOME, Python, or indeed, Mono.
The language has evolved very slowly, with features that developers have wanted for years, such as enums and generics (templates for C++ people),
only just now being added to the language, after they came out as part of C# from Microsoft, a much younger piece of software.
Sun's reluctance to support a native widget based GUI toolkit, sticking
with the sometimes sluggish, alien looking SWING, left developers with no
real option for developing desktop applications. There's a reason why Java
is used heavily on the server, with a devoted following, but very sparingly
on the desktop. To use a contrasting example, Python has evolved as a
language at a much faster rate, with incremental rather than groundbreaking
speed improvements over time as well. The Benevolent Dictator model is used
in Python as it is in Linux, with great effect.
Keeping Sun happy seems like a very valuable goal for some in the community in light of the major contributions that Sun has made
to GNOME. It's ironic, however, that the community seemingly is in this
position at least partly because of Sun's refusal to let go of Java, and
more ironic that one proposed solution to keep Sun happy is to use a
non-Sun-licensed, non-Sun-certified Java platform which doesn't support
Sun's preferred GUI APIs. While it might keep Sun happier than if GNOME
adopted Mono, it would seem unlikely that that's where they'd like to
be. Even if Sun were to make an open source version of their JVM and class
libraries available, as advocated by IBM and others, the interaction between two
competing platforms may still be awkward.
It would be a great step, in any case.
Meanwhile, discussions continue, and there have been some constructive
suggestions as to how to interoperate and leave the community's options as
open as possible. The debate is currently civil, intelligent and
are a number of parties with big stakes involved, however, so things may yet get
A fragmented platform helps nobody, so there's a big incentive to work out the most inclusive solution constructively. It's a debate which will be watched closely by many.
to post comments)