Mozilla Looking to Forge Alliances with GNOME and Other Open Source Projects to Combat Longhorn

Tuesday April 6th, 2004

Boris Zbarsky wrote:

[Posting to this newsgroup for lack of a better one; if there is a more appropriate place, please feel free to set Followup-To accordingly.]

As the subject says, what are the goals of Mozilla.org? I see several possible answers:

• 1) Create a good web browser. (What definition of good?)
• 2) Create a web browser that can successfully compete with IE.
• 3) Successfully compete with IE.
• 6) Create a platform for delivering apps over the network (not quite the same as a web browser, but close).
• 4) Create an embeddable rendering engine to enable creation of web browsers.
• 5) Create a technology platform on top of which applications (not just web browsers) can be written.
• 6) Something else I'm missing.

(I'm going to refer to this second item 6 as (7) below.)

These are not mutually exclusive, of course. Which of these are actual goals (as opposed to accidental byproducts), and what are their relative priorities?

Inquiring minds want to know,

Thanks for writing — you're asking exactly the right questions. Some of what I write below follows from the slides I presented at Developer Day (http://www.mozilla.org/events/dev-day-feb-2004/mozilla-futures/).

I liked dbaron's followup where he brought up "utility", something from the Dismal Science that hints at the true nature of our problem (scarcity, subjective value). Goals and requirements sound all scientific, or bureaucratic. Life isn't that simple, but people often would rather it were; Armies are great simplifiers, in this sense.

Mozilla is not the Army. That's the good news. The bad news is that we have Redmond's army ants arrayed against us. We need strong leadership and external allies, if we are to preserve much of the utility (however subjectively valued) of open standards.

Mozilla can't be a laissez-faire anarchy where staff just resolves conflicts, because we face not only built-in conflicts, but what's more, competition from aggressive monopolies and near-monopolies. Although Mozilla code will be around for many years, it may become increasingly irrelevant without two things:

1. Browser user agent market share.
2. Useful, efficiently implementable, easily authored open standards co-evolved with killer applications, such that those standards compete with counterparts in the proprietary systems (Windows Longhorn, Macromedia Flex, etc.).

If we do only "the browser thing" (1-3 from your list of goals), we are likely to be irrelevant in approximately five years. Not unused, but trailing-edge; not built upon as a platform, not invested in even as a hedge. Yet (1-3) are necessary, even if not sufficient.

Note that (2) and (3) may imply, for certain enterprises and reprobate sites, supporting the IE DOM, Active X plugins, and other things we'd rather not support. If we don't support some of these things, we may not in fact succeed in competing with IE enough to get sufficient (A).

Why will we likely be irrelevant without more than a good web browser? The answer is involved; bear with me.

First, Longhorn formats such as XAML will leak onto the web, satisfying your goals (5-6). We can predict this with high confidence based on the IE4 experience. In 1997, IE4 shipped a better browser, with non-standard CSS bugs, DOM quirks, and DHTML features, and of course things like Active X. By 2000, when IE was crossing the 50% market share barrier, sites were (intentionally or not) restricting interoperation to IE clients only.

Another Windows predictor: Windows XP took ~2.5 years to pass 40% according to Google zeitgeist.

Second, Linux is poised to rise just by being cheaper. "Total Cost of Ownership" compared to Windows is hard to assess currently, with many variables, confounders, and hidden costs on both sides. Some experts claim Windows has lower TCO right now. But assume Linux improves and wins. This seems a fairly safe prediction, as predictions go — especially in other parts of the world.

The problem I foresee is that Linux may very well not ship a default Mozilla browser, relegating Gecko to the category of web-content engine, soon to be "legacy" web content engine. In this light, we might make (4) an anti-goal. Given trends in at least the GNOME world, the likely result of the default-browser decision favoring a GNOME browser is that GNOME/Linux desktops and apps evolve to compete with Windows Longhorn by solving roughly the same problems in different ways (Mono or no Mono).

The long-term result would be not only a lack of cross-platform apps — there would be a lack of new cross-platform contents and protocols needed to countervail XAML and other Longhorn formats, protocols, and languages. We can see the beginning of this fragmentation, although not along OS lines so much as proprietary client lines, with Flex from Macromedia, Laszlo's XML-based language, and similar children of XUL from the "rich internet application" platform players.

If Miguel and company clone XAML and Avalon (the harder part to clone), perhaps in three years Linux will be able to match most of what we can see coming in Longhorn in the way of open-standards-threatening content. But that content will still be relatively or completely closed, under the control of Microsoft, subject to revision at its discretion. Not a pretty picture, even if Mono eventually helps apply de-facto or even de-jure standardization pressure.

What seems worse, though, is the likelihood that XML-based content types might proliferate and speciate along platform lines: some for Linux, others for Windows. Without cross-platform browsers implementing the same standards everywhere, including the new, non-legacy, ones, the likelihood of interoperation bugs and outright incompatible/non-portable formats grows.

In all this, I'm discounting the Mac. It's an important and influential niche, one that Mozilla values, but not one likely to grow enough to make a difference compared to Linux and Windows. If the OS and especially the multimedia apps were to be ported to PCs and opened up to developers on other platforms, maybe — but those steps would undercut a lot of Apple's profitability, its platform's strengths, and its appeal (yes, including its snob appeal).

Here's an alternative that I'm working hard to promote:

1. Build cross-platform apps from the ground up, using Gecko, native theme-based rendering, and good desktop/OS integration.
2. Promote these apps, starting now — think Mozilla-the-suite, Firefox, Thunderbird, Open Office — on Windows, especially in enterprises that wish to avoid lock-in, virus hazards, and high license fees.
3. Let those enterprises migrate to Linux if it makes sense, or defer the hefty Longhorn upgrade tax by sticking with downrev Windows for as many years as makes sense.
4. At the same time, starting now and working closely with other open source hackers, build a new, unified desktop/web application platform from pieces of Mozilla and GNOME code, starting now. Share code and effort; avoid big rewrites. Use standards where possible, including the parts of XUL that are being specified now. This new platform might even deserve the "Mozilla 2.0" title.

This new platform must include an advanced rendering layer with hardware acceleration, fancy effects, animation, video, etc. We should use what works now, with as much cross-platform leverage (OpenGL), filling in gaps on some platforms, and again (always) avoid long-pole scheduling dependencies where the entire subsystem must be rewritten.

Another characteristic of this new platform: high-level programming language independence, with a good choice of "managed code" runtimes (Java, Mono C#, JS2, ...) for type-safe buffer-overrun-free programming. We must not keep losing fingers and toes to C and C++; that approach is a money loser compared to .NET.

A crucial features of this new platform: the GUI toolkit must be able to blend in among native apps, at least on Windows and Linux, ideally on Mac too. There should be a well-specified XML syntax and semantics for creating user interfaces (XUL) and graphics (SVG or something like it, but unified), and for composing tags from DOM trees (XBL). There must be a low-cost migration path from XUL today to this future language.

I've been busy laying groundwork, building bridges between different open source projects. It's still too early to say exactly how things will turn out. I don't want to make promises that I can't keep, and a lot of planets have to align still. But there is interest among other key projects' leaders. I think a number of smart folks see the need for alliance against the hegemon.

This platform play would address (5-6) by marrying, as much as allying, GNOME, Mozilla, and perhaps Mono — bringing cross-platform code and development to the Linux side, and native next-generation GNOME look and feel to Mozilla. It would build something we've been unable to build in a compelling or complete way by ourselves: a development platform for arbitrary third party web and desktop apps.

The time frame for this plan is now, with working code by 2nd half of this year. Otherwise we're sliding into next year, in danger of being too late to gain mindshare before Longhorn's inevitability wins the day for XAML, etc. So, if this is to succeed, we have major concurrent development challenges ahead.

I'll answer any questions I can here, and I encourage all comments. If something in the analysis above rings false, please say what and why. If you're following up just one point, feel free to change the subject to start a sub-thread.

Got a response? TalkBack!