2004-03-21 (Sunday)
by havoc
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)