Havoc's Blog

Better judgment > /dev/null

Sorry to see this come up again, but I guess it will be a hot topic
at GUADEC, so I may as well lay out the current status as I see it.
(Summary: not much has changed…)

It won’t show on Planet GNOME, so here is Mark
Wielaard following up on Christian’s
post. Also earlier he posted a
chart of Classpath development progress. More people should read
Planet Classpath as I’ve
hinted a couple times in the past.

Responding to Christian, he says “Java’s mindshare in the wider GNOME
community is close to non-existant today and there aren’t really
anything on the horizon that could plausibly alter that.” This is
potentially true. I said as much in my talk at the open source Java
summit, where I was trying to clue in Sun (among other goals). At the
same time, I think GNOME has it wrong (or at least is leaving those of
us at Red Hat unable to contribute to GNOME), so I find the situation
depressing.

Let’s talk about technology first.

Graydon’s
analysis pretty much shows what a non-technical-issue this Java
vs. C# thing is. And as Jeffrey
Morgan says it would be nice to preserve choice for app
developers.

The velocity of open source Java development, and sheer quantity of
open source libraries and tools for Java seem to be discounted.

Just one thing I’ve been very impressed with is the Eclipse
plugin system: this is in no way tied to Eclipse or SWT, and it is
just a better way to think about extensibility than our historical
fixation on “component systems.” There’s a very similar open standard called OSGi that I think is
pretty neat, with at least two open source implementations (Oscar and Knopflerfish). I should do a
separate blog post on why these are interesting sometime.

Screw its plugin system: when I used Eclipse itself to write Java for
a few days, I was impressed with the increase in productivity. Most of
the wins were because of the IDE, not because of the
language. Like Emacs, Eclipse has awful usability engineering, but it
has great features and functionality that save time once you discover
them. If you’ve never used a serious IDE with a language like Java or
C#, you should try it. The most important language features are the
ones that enable a great IDE.

Another place to look at the size of the open source Java community
is JPackage; the package list is
down the side. And those are just the packages someone cared enough
about to maintain in RPM format.

Or let’s look at Apache’s Java
community, where Lucene was
born – and then ported to C# to become the Beagle engine.

Obviously C# has lots of software out there as well, and it has more
GTK+ software due to the focused effort to create same. I’m not trying
to exhaustively belabor the Java vs. C# technical comparison but I am
trying to point out that Java has a hell of a lot going for it
including open source developer tools and libraries and huge momentum
(largely open source) on the server side. Java 5 has some cute
language features, too, and Tromey has
shown how to make native code bindings easy.

Enough on technology. On the crux of the issue, what I wish GNOME
would understand: Red Hat not shipping Mono is currently a
can’t rather than a won’t. Making it worse, we are not
able to spell out all the facts on why we can’t. In fact, none of the
Red Hat engineers (including myself) knows all the facts (and
we couldn’t share them in public if we did). We continue to try to
get this issue resolved and there are serious efforts in progress,
but, well, they have been in progress for quite a while. At some
points it felt close to resolution, at the moment it doesn’t really,
at least not to me.

Please don’t ask for more details here. I can’t give them. You can
take this as evidence that I’m lying, and that’s fine, but I can’t do
anything about it.

I believe we have legitimate and non-evil reasons why we can’t
ship Mono. And I think open source Java looks plausible and a lot
nicer than C; Java and Classpath will even run on Mono, and if C#
becomes more viable later, experiments such as Graydon’s or the Lucene
port show that it isn’t hard to do a Java to C# conversion. And guess
what, we need open source Java in the desktop anyhow for
OpenOffice.org and the browser plugin at minimum.

I don’t know what people expect Red Hat GNOME developers to do. We
can’t roll over and say “OK, we’ll start hacking in C#, even though we
don’t see a path to shipping any of the stuff we’re hacking on” – does
anyone seriously expect that?

If people don’t believe us, then the right action is for GNOME to just
require Mono and let Red Hat sort it out. Let’s not blame a faceless
company here for the sorting out. At the moment Red Hat’s desktop
strategy is largely set by me and other community members you know. I
can tell you what I would advocate faced with Mono as a GNOME
requirement: initially try to reimplement or live without the Mono
bits, maybe using language-translation hacks to port stuff to Java;
while finding a non-GNOME or forked-GNOME path to get out of this
losing approach in the long term. It’s ugly but true. We would
probably stall as long as possible, hoping to find a way to ship Mono
or that GNOME would change its mind, but that’s all we could do. I
can’t think of a way we could justify hacking on software we can’t
ship.

If anyone has a better suggestion then let me know what it is.

Here’s what I ask. Give the Java and Eclipse talks at GUADEC a
chance. Try out some of the Java technologies I mentioned earlier in
this post. Try Java 5. See if this is really such a clear-cut
technical issue.

Eventually though GNOME should just decide what to do and proceed. If
people think we are lying, or that something will happen to let us
ship Mono, or simply think that Mono is more valuable than Red Hat’s
contributions, then so be it. These are decisions that have to be
made. GNOME got stuck on the “Bonobo war” for a while, and the “Mono
war” today, both at their heart ridiculous distractions from the real
point, which is implementing a desktop environment.

(This post was originally found at http://log.ometer.com/2005-05.html#10)