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.
The community can go XPCOM/PyGtk if they choose to (btw,
same legal problems apply related to patents on COM ;-), but
it is unlikely that the larger projects will pick on this.
You are right that a "wrapper" could encapsulate Longhorn.
But I think it will be a useless effort.
No ISV will pick a layer on top of the Longhorn layer on
Windows today or tomorrow: .NET is simple, easy to use as
opposed to older APIs. ISVs will demand native support for
Perl and Python directly support COM and .NET APIs today
for interop. Am sure others will agree that why wrap
everything in Longhorn, when you can just use your favorite
language interop to use those features?
As I said, I still believe that the "Open Source Desktop
Components" is a better way of going, more than the
"Linux-based Open Source Desktop".
Underestimating Longhorn: Also, we should not
under-estimate Longhorn. This is not a traditional OS
anymore. This is an OS, that exposes .NET APIs as well as
plugin interfaces for classes at every layer of the stack:
file system, synchronization, transactions, communications,
presentation and a miriad things more. "Wrappers" will
hardly cut it here.
Not surprisingly, I think that Mono is the best possible
path for ISVs: it allows them to share plenty of code (not all
of it if they are aiming at "perfect" integration) between the
various platforms with a high-level programming language.
With a runtime environment that will let developers take
advantage of the APIs in the major market.
So the core of Havoc's thesis can be summed up as:
We need to avoid fragmentation as various Unix desktop
companies pick up a platform to develop software.
Sun is a major Linux Desktop player that will never ship
Mono, but is using Java. So we should use Java to avoid
Legal and technical details, while interesting topics,
are not at the core of this debate.
Novell: At least from this side, there has not been
a company mandate to pick Mono over Java for any projects.
Individual teams and projects inside the company have picked
up on its own merits: iFolder,
a few other internal projects which are not public yet. Some
other internal projects picked Java for their own efforts.
The community has picked up on Mono/Gtk for a few
applications on its own as well, the Gnome Foundation had no
saying on this.
In a few areas, we believe that we should use Mono, but
avoiding a community splint is an important consideration to
us. Our plans to adopt Mono on Evolution are on hold, as well
as integrating Mono with OpenOffice (notice that OpenOffice
already has hooks for .NET though).
Sun: I will just assume that Sun developers have
enough experience, and visibility into Java, that to them it
is a natural fit to pick Java for projects, and that there is
some degree of company mandate to use it. Am assuming this
based on the naming of their Java
Longhorn: Microosft jokes aside, an important
consideration for some projects is the fact that Longhorn
will be released, will get deployed and the OS
APIs have switched from C/C++ to CLR-based API.
In the Longhorn world, APIs are no longer your C/C++
grandmother APIs. Every new API introduced for the operating
system is built on top of .NET. If you want to take advantage
of it, you must write .NET code.
Writing code in Java is nice for writing code that is
portable and uses to the lowest common denominator. But
living in this bubble is not an option on Windows.
So the rationale for using Mono in some cases internally
has been the fact that in Longhorn, you will have to
write code in C#. Even if we have to write different GUIs
(like iFolder: it will have three implementations:
Windows.Forms, Gtk# and in the future a Cocoa# based one), we
still get to share a lot of the functionality below.
Maybe the community does not need this kind of
functionality, but most ISVs will, and that I think is a
pretty big setback for Java and its Java ways. To survive in
the desktop ISV market, Java will have to break with the
write-once-run-anywhere mantra, and deeply integrate with
If I were Sun, I would be retargetting my JVM code
generator on Windows to generate CIL and making sure they can
use every single Longhorn API.
Who are we and what are we building?
I personally think that we should move away from the "Linux
Desktop" view of the world, and more into the "Open Source
Desktop and Components" (I first heard this idea from Nat a few months ago).
It may sound like a trivial difference, but it is not. As
much as I love the Linux desktop, and as much as I love our
tools, the most successful desktop components today are
OpenOffice and Mozilla because of their cross-platform nature.
Windows NT, XP, MacOS X and Longhorn will be with us for a
long time. The best possible outcome of open source will
likely be a segmented market like 33/33/33 for the desktop
In my opinion Java, Swing, Gtk+ nor Qt address effectively
portability to all these systems. And by that, I mean that
you always end up with an alien application: either the look,
or the integration into the platform is substandard.
Mozilla and Abi to a larger extent got this relatively
close to right. The botttom line is: no technology today
gives you transparent portability.
The best bet today is to share as much as possible on your
"engine" and redo the OS integration components for each OS
Today there is already a major fork on the road.
Audio/Video: Today we got Xine, GStreamer and Helix
as platforms for doing audio/media playback with different
angles on the problem and no clear way of uniting them any
time soon. Not to mention all the different player-level
I would love to see a standardized C-based interface that
every one of them exposed and allow people to pick one over
the other. I for one am not excited about requiring 160 megs
of GStreamer code on my machine to essentially play mp3s and
And having an interface for the above is probably more
important than any amount of Gtk+, Java, C# or Python skin on
top of it.
Office Suites: We got plenty to choose from here:
OpenOffice (in my opinion the only contender for the next
three years) and the two smaller open source solutions.
Still, when it comes to engaging the community and pushing
in a single direction, we got half the Gnome community pushing
for Gnumeric/Abiword. If we can not reach concensus at this
level with the community, I think we are going to have a hard
problem selling anyone into agreeing into Java or C#.
Ok, gotta catch a plane.