Language Advocacy Followup
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
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
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
- C# plus third platform – C#/Mono syntax/VM plus a new open
- 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
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
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)