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 them.
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 fragmentation.
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, F-Spot and 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 Desktop System.
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 Longhorn's WinFX.
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.
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 market.
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 you support.
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 components.
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 CDs.
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.
Posted on 21 Mar 2004