Mozilla Looking to Forge Alliances with GNOME and Other Open Source Projects to Combat LonghornTuesday April 6th, 2004 By Brendan EichBoris Zbarsky wrote:
(I'm going to refer to this second item 6 as (7) below.)
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:
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:
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! |
![]() |