Havoc's Blog

Miguel writes:

Havoc, you are skipping over the fact that a viable compromise for the
community is not a viable compromise for some products, and hence why
you see some companies picking a particular technology as I described
at length below.

To be clear, I don’t mind if companies unilaterally choose a
technology to use in their own company-specific products — that is
expected. The question I’m asking is about what we do with the open
source desktop stack. What can we use today in GNOME, Evolution,
Mozilla, OpenOffice.org, and so forth?

You guys have Mono on hold in Evolution to avoid fragmenting this core
desktop stack, which is absolutely the right thing to do. What I
don’t want to see though is language/component-related progress on
hold forever, if there’s something that is viable today. Is
there some way Mono can become viable upstream in GNOME? If not, let’s
move on to another option for the desktop core.

Let’s move from “on hold” to “starting the process of
deciding,” though who knows how long it will take once we start.

To me step one is to enumerate the options and then see which are
realistically viable. At that point we have a primarily technical
decision between the options that remain.

Here’s a concrete question: how do you want to proceed with getting
Mono “off hold” in the Evolution project? What is the plan for getting
the necessary buy-in?

Linux desktop vs. Open Source desktop

I agree that cross-platform apps are useful as a matter of sound
modular engineering, migration path, and getting a lot more users and
developers working on the apps. But my end goal is definitely to get
people using a 100% open source solution — i.e. Linux.

I’m not convinced the “Linux” vs. “Open Source” desktop strongly
affects the issue of what languages to use in the core desktop;
because we can certainly run C++, Java, Python, and many other
languages in a Longhorn environment, and access the Longhorn APIs
either on the backend of a cross-platform toolkit such as XUL, or
directly in a framework similar to AbiWord’s. Both of those are
possible no matter what language we choose.

It does matter how we write our cross-platform apps. One way is to
simply reimplement Windows — say that WINE and .NET are our
platforms. The problem is that you can never be better than Windows.

The other way is to have our own platform which is our native platform
and can have Linux-specific advantages in manageability, security,
usability, and other aspects. And then application authors can choose
whether they want to be optimized for both Linux and Windows
(AbiWord-style or Epiphany/Camino-style); or whether they want to be
slightly out of place on each but write their code only once, using
some cross-platform API.

(This post was originally found at http://log.ometer.com/2004–03.html#21.2)

Christian writes:

As for the (l)ongoing language debate I think we need to allow for
people to both use Java and C# (or any other language) that has a big
enough community around it to ensure that bindings are kept up to date
and follows the development of the rest of the desktop.

I agree with that, but you’re answering a different question: “what
languages can you write third-party apps in?” My question is, what
technologies and languages do we use to implement the desktop core
itself. We have to make a decision here, if only “stick with
C and C++.”

(This post was originally found at http://log.ometer.com/2004–03.html#21)

Lots of good replies to my
post on higher-level language support in the desktop, including other blogs,
private mail, and a lively discussion in the halls and internal lists at Red
Hat. I want to try to summarize some of the feedback and answer the details, but
not enough time tonight. I do want to make a high level point though.

What exactly is the issue here?

If you go back and read my original post, I referenced legal and
technical issues and gave brief opinions, but I did not get into all
the details or try to resolve them exhaustively.

To me the technology gives us a spectrum of options — some status quo, some 25%
or 75% or 90% improvements. But technology isn’t the only factor.

Similarly, the legal issues rule out some options (such as non-open-source
software), and indicate lesser or greater levels of risk. Miguel is right to
point out that any significant program probably violates someone’s claimed
patents, for example. However, the law is not black and white — one patent is
not the same as hundreds, all patent owners don’t pose equal risk, some patents
have clearer prior art, and judges and juries look at the clarity and intent of
any infringement. So on the legal front as on the technical front, we have a
spectrum from status quo to various degrees of increased risk.

On a third dimension there are strategic issues, both for the open source
desktop community as a whole, and for each company.

To me the problem we face is more than stacking up Java vs. Mono vs. C/C++ on
legal and technical and strategic dimensions and picking one. Here is the big
issue:
forking and fragmentation are the outcome if current trends
continue. Novell has started coding desktop components in Mono and Sun has
started coding stuff that requires the proprietary JDK.

At present, many Linux desktop backers are also strong Java backers and
would refuse to ship anything based on a .NET clone; Sun obviously, but also I
would guess IBM, Oracle, and so forth. From the other side, for many
desktop components a proprietary JDK dependency is either illegal (due to the
GPL) or simply counter to the founding principles of the project.

Slow down and consider for a while what it means for the desktop
projects to force this issue and allow “platform wars” to be played
out with those projects as battleground. Instead, we need to find a
compromise or course of action that most interest groups can at least
conceivably buy into.

I tried to propose one such compromise, that is, using the subset of
the Java specification available in open source form. But it was
probably distracting to mix this opinion with simply posing the
problem. What I’d like to see is enumeration of the possible
compromises, and a serious look at whether the compromises
genuinely get broad enough support. “.NET clone” and “proprietary
Java” to me are both obvious nonstarters and all but guarantee desktop
Linux forks.

Possible Courses of Action

Many of the replies I received suggested alternate compromises. I’ll try to
summarize some possibilities raised so far.

• Stick to C/C++ for the forseeable future; possibly enhanced
  by UNO or XPCOM or equivalent.
• Build a third language and platform set based on Parrot, Perl, Python, and other
  open source technologies.
• Open source Java subset as I proposed.
• C# plus GNU Classpath — Java platform with C#/Mono
  syntax/VM.
• C# plus third platform — C#/Mono syntax/VM plus a new open
  source platform.
• C# and IKVM — choice of syntax, running on Mono, with
  either GNU Classpath or a new open source platform.

As I understand it nobody is advocating C# plus .NET platform,
as this is widely understood to be legally and strategically out of
the question.

It’s unclear that everything I’ve enumerated here is viable. We don’t
know yet whether C# in any form (even just the ECMA core) can get
broad acceptance. We don’t know for sure that Java can either. The
only thing we know for sure to be viable is the status quo: Stick
to C/C++. To me, I would rather accept that than see the current
trend toward fragmentation. However, I do think it would be better if
we can find a way to move forward.

The reason I like Open source Java subset: it’s a subset of Mono (due to
IKVM), a subset of the proprietary JDKs, and a subset of gcj. It can run on any
of these implementations. Because of this, there should be no new legal
and strategic concerns introduced if a desktop project uses
Open source Java subset: everyone is already shipping a VM that supports
it. Moreover, if in the future we decide we can start to use C#, this
strategy would not preclude it; we switch to the C# and IKVM
compromise at that time.

Java offers enough technical advantages to be worthwhile, and has the nice
property that it pulls together the desktop and the server side of
Linux.

Urgency

BTW, regarding panic and urgency; I am immediately worried about the
fragmentation issue, which seems to be in progress already; and
longer-term but seriously interested in the technical competitiveness
of open source platforms. Callum says similar worries were expressed
about Visual Basic — but IIRC Visual Basic has the largest marketshare
of any language by far… so perhaps the worries were pretty valid.
Whatever the real urgency, I don’t see how delaying a discussion of
these issues is going to make them any clearer or easier.

(This post was originally found at http://log.ometer.com/2004–03.html#19)

I decided life was too boring, we need to finally discuss Mono, Java,
and the Linux desktop. Here are my
thoughts, hopefully a productive start.

(This post was originally found at http://log.ometer.com/2004–03.html#17)

Maybe everyone but me already saw this, but Sun rewrites Evolution in
Java Swing. Yay, an “open source” mail/calendar client with a
dependency on a proprietary JDK. Yay, let’s rewrite a couple million
lines of code and fragment the Linux desktop platform; clearly the way
to beat Microsoft.

In other news, increasing dependencies on the proprietary JDK in
OO.org, which forces the codebase shipped by Red Hat, Debian, and
other companies who won’t rely on a JDK license from Sun to diverge
more and more from the mainline. Not to mention the StarOffice
vs. OpenOffice.org delta.

Let’s not talk about forking the window
system on a fundamental level — I’m curious how they plan to use
this, because GTK+ and GNOME sure as hell aren’t taking patches to use
a proprietary window system. Oh, rewrite everything in Swing! 😉
Or fork the GTK+ API?

Of course, this is probably good for everyone else; Sun has to fund
proprietary-size development teams while everyone else benefits from
the open source model. Sun JDS — your nonstandard proprietary desktop
solution. Buy it today.

(This post was originally found at http://log.ometer.com/2004–03.html#8.3)

Mike Loukides
missed the point of my last post. The virtues of Swing aren’t relevant.

Right now you can install Red Hat and Sun JDS and you get the same
major components by default: GTK+, GNOME, OpenOffice.org, Evolution,
Mozilla. Plus the same choices for some of the smaller apps. Ximian
was also in sync with this, though Novell has not yet taken a
position.

This has a couple of implications. One, ISVs and customers have a
single standard client side platform and application suite. Two,
these companies are using the power of the open source model to pool
resources and compete with Microsoft on the desktop.

Often, apps are part of the platform; in Evolution for example,
the address book and the PDA interfaces. The browser and office suite
are more obviously and extensively platforms, but the email app is as
well. Something like Looking Glass simply is platform, it
isn’t an app at all.

Every vendor has to add value, and that’s fine. However, doing so by
replacing the major platform components has negative consequences for
both the vendor and the overall effort to unseat Windows. It’s even
more problematic if the replacement requires proprietary components
owned by one vendor, because none of their competitors will be willing
to use those components, assuring fragmentation.

Up to now I’m talking pragmatics or “open source,” but there’s a “free
software” or principled angle as well. Most large projects such as
GNOME and Mozilla would never consider a dependency on a proprietary
library. Of course this is why no interesting part of the Java Desktop
System today uses Java, because there’s no GPL-compatible Java
implementation and thus no wide usage of Java in the open source
desktop community.

Net effect: to use Java in their Java Desktop System, Sun has to
rewrite code wholesale and maintain it themselves. The traditional
open source community simply won’t accept proprietary Java
dependencies.

I support using Java throughout the open source desktop; we need to
move to a high-level programming environment. I’d push hard to start
writing almost all new code in Java if we could and gradually refactor
the apps to a high-level language without feature regressions. But we
need an open source Java implementation to make this possible.

Sun is in a hard position. 1) Keep proprietary ownership of
Java or 2) make Java open source and thus a standard feature of
the Linux desktop. If they choose 1), then they have a second
choice: a) Don’t use Java in the core Linux desktop or
b) reimplement much of the core Linux desktop in Sun-specific
ways.

1)b) is especially harsh due to the GPL; you can’t refactor
Evolution to gradually migrate it to Java, because the GPL forbids
linking to Java. So they have to start Glow from scratch. Similarly if
they want to use Java in GNOME, they will have to replace each GNOME
component wholesale.

Don’t get me wrong, Sun has done a lot for the open source desktop and
GNOME in particular, and I love the developers involved. But as an
empirical matter, I don’t think their approach to Java and their
approach to the desktop are compatible, and when I saw
Glow I felt it was
the most dramatic demonstration of that so far.

(This post was originally found at http://log.ometer.com/2004–03.html#8.2)

Slashdot just posted the DARPA
Grand Challenge, Red Hat desktop developer Daniel Reed is
participating.

(This post was originally found at http://log.ometer.com/2004–03.html#8)

How does Mikael watch 40 Buffy episodes in a week? They were showing
the whole series on TV a while back, 1 per day, and we tried to keep
up. Somewhere in season 2 we gave up in despair at the backlog on
videotape. 😉 Ah, the days before Tivo.

(This post was originally found at http://log.ometer.com/2004–03.html#7)

GNOME Office feels like a huge missed opportunity to
me. OpenOffice.org is clearly the best choice today, but it’s far from
perfect. Still, GNOME Office isn’t even competing.

To compete, I’m convinced the AbiWord and Gnumeric projects have to
merge; it’s that simple. An office suite is a single project. And then
those developers should see the presentation app as part of their
charter. Sure Gnumeric and AbiWord are architected differently and use
a different approach to portability, but why not suck it up for now
and iterate them toward convergence over time.

There are real paying customers that recognize that the Gnumeric
spreadsheet engine is nicer than OpenOffice.org’s spreadsheet. Jody
has done a fantastic job. But a spreadsheet is too huge to support and
develop two, and Gnumeric is a nonstarter because it’s a spreadsheet
only. It has to be the suite.

Sometimes AbiWord does a better job on Word import than
OpenOffice.org, among other advantages. But again, same problem. A
presentation app is on the roadmap, granted, but let’s add the
spreadsheet. Most companies don’t choose a word processor; they choose
an office suite.

Another hard but worthwhile decision would be to use the OO.org file
formats. If GNOME Office decided to compete for real, it would take a
couple years to become viable. In that time people will have collected
lots of OO.org files and migration path will be a requirement
dramatically simplified by keeping the same format. One could even
imagine using big chunks of OO.org code via the UNO framework.

An interesting thought would be to pursue Gobe-style
home-user-focused UI enhancements, to further emphasize the usability wins
over OpenOffice.org.

In any case, I just don’t see the hard decisions and bold roadmap
directions. Which is fair; the hackers working on this have the right
to do what they find interesting and valuable, and I’m not working on
it. But I can’t help feeling disappointed by the lack of alternatives
in the office suite category, so I thought I’d whine a little bit.

(This post was originally found at http://log.ometer.com/2004–03.html#6.2)

Encouraging posts from some of the GNOME Office hackers.

(This post was originally found at http://log.ometer.com/2004–03.html#6)