As I mentioned in part one, we tried this before under the aegis of Mozpad with disappointing results. David Boswell of Mozdev and the Mozilla Foundation has an excellent post outlining some of the reasons why Mozpad “ran out of steam.” In my opinion the biggest problem was the lack of clear goals, something I have mused about at length. There were a number of isolated projects, to be sure, but no overarching vision of what the organization was trying to achieve. I even went as far as to question the long-term potential of XULRunner as a developer product, speculating that the shift of applications onto the web made Prism a more compelling platform.

This concern was probably overblown. The success of Adobe AIR, the launching of the iTunes App Store and ongoing development of products like Songbird (hard to imagine as a web app) are evidence of the continued relevance of native applications. In fact, one of the most compelling things about XULRunner is that it can be used to develop sophisticated native apps or as a deployment vehicle for web apps on the desktop (serving, as it does, as the foundation for Prism).

One area that is gaining momentum is the push for a common XULRunner runtime, shared by Mozilla and third-party apps. The Linux community is taking the lead in driving this forward, and Firefox is already delivered as a XULRunner app on distros like Ubuntu. The problem here is that any self-respecting XULRunner app uses at least some patches that have not yet made their way into the official Mozilla source repository. Their XULRunner is thus different from that of Firefox. Since the Linux folks don’t seem anxious to ship multiple runtimes, the end effect is that apps like Songbird can’t be deployed using the operating system’s package manager, the primary vehicle for distributing software on Linux.

This gives us a useful starting point for relaunching a XULRunner advocacy group in the Mozpad vein. App developers complain, often with frothing mouths, of the difficulty of getting their patches accepted by Mozilla. MoCo developers, in turn, point out that many of these patches are simply unacceptable in their current form. Sometimes they cause performance regressions or automated test failures. Sometimes they are just bad patches, not generic enough to be of general interest.

In my view the real issue is one of communication. No one is particularly happy about the current situation. But developers of XULRunner-based apps are busy. They don’t have time to jump through hoops to get their patches accepted, so they are content to ship their own forked XULRunner runtime. (Or they were, until those pesky Linux people started making waves.) And MoCo developers are busy shipping ever more awesome versions of Firefox. They don’t have time to hold developers’ hands to get changes that are of no obvious benefit to Firefox into the repository.

One important step would be to state more clearly the criteria for getting patches accepted. The Mozilla Developer Center article on this topic is pretty good, but it doesn’t explain the common reasons why a patch might die on the vine. Are any performance regressions acceptable? Apparently not, but this isn’t stated explicitly. Some discussion of the platform’s goals would make it easier for developers to determine whether their changes are appropriate for general use. There is a wide array of opinions about this, so drafting some sort of text would bring differing views out into the open and help to converge on one official position.

More generally, I think we need someone who is officially charged with helping third parties to get their patches committed. This would be, to a large extent, a diplomatic mission. Geeks tend to be brash, and having two stressed and sleep-deprived developers yell at each other in Bugzilla comments about why a given patch should or should not be approved is a recipe for the kind of frustration that is evident on both sides of the fence. It would be of great value if someone with the right personality type were available to help outside developers understand why their patches are languishing in limbo. This person could work for MoCo, for the Foundation or perhaps for some special XULRunner-focused organization. I’m interested in opinions about whether this idea makes sense and, if so, who would be best place to take responsibility.

Creating a single XULRunner runtime for major apps, including Firefox, would be a giant step forward. It’s also a nice bite-sized goal that would help to get some renewed momentum behind XULRunner in general. I still think that the more ambitious goal of turning XULRunner into a major RIA player is worthy of discussion, and in part three I’ll present some ideas about what this would mean and how to make it happen.

It is an undeniable fact that there is considerable frustration in the community over XULRunner. For one thing, developers of XULRunner apps complain a lot about the difficulty they experience getting their patches checked back into the Mozilla repository. This means that they have to continue to maintain a library of patches as they bitrot over time, and it makes them feel like second-class citizens. (Not that this should be construed as a criticism of Mozilla Corporation. Getting a patch into Mozilla is difficult by design, even for those working on Firefox.)

The other source of frustration is that XULRunner is seen as something of an underachiever: a platform with the potential to have a far bigger impact than it has. If Mozilla were to announce that it was stopping all development and support of XULRunner, this would raise a big hullabaloo, but at least their position would be crystal clear. As it stands, XULRunner is 90% of what it needs to be to be a competitive software development platform with many advantages over existing contendors. The missing 10%, along with the seemingly ambivalent attitude of Mozilla Corporation (despite a valiant attempt last year by then CEO Mitchell Baker to clarify the situation), is what causes tempers to flare.

Mozilla’s ambivalence is understandable. The platform has a lot going for it. The vast majority of the code it uses is shared with Firefox anyway, so most of the development effort is highly leveraged.  A number of exciting projects, both commercial (Songbird, TomTom, etc.) and otherwise (Miro, ChatZilla, MobiDVD, etc.), enhance public perception of Mozilla. The Corporation itself is also increasingly using the platform for projects other than Firefox, such as Prism and Fennec. And there are a number of MoCo employees who are strong proponents of platform use by third parties.

On the other hand, Mozilla has a huge hit on its hands with Firefox. Products with such a tremendously large and positive impact on the web don’t come along every day. There is a real risk of the organization trying to take on too much and endangering its strong position in the web browser market, and with it the potential to do much good in the future. When you’re working frantically to release a major new browser version, as was the case with Firefox 3, the last thing you need is to spend cycles on unrelated platform work. Rave reviews for Firefox 3 support the argument that Mozilla should keep its sharp focus on the browser.

There are, nonetheless, at least four good reasons to revisit Mozilla’s decision not “to invest in a pre-packaged or stand-alone XULRunner at this time.” The first is the potential for a strong independent XULRunner to strengthen the Mozilla platform (and thus, indirectly, Firefox). Firefox 3 has ushered in major platform improvements such as enhancement of JavaScript performance, a cleaner threading API and consolidation of functionality into a single “libxul” library. The more individuals, companies and other organizations who are using XULRunner for serious projects, the more momentum can be built up behind future improvements that will benefit Firefox. Some appealing changes, such as moving from result codes to exceptions in C++ and porting portions of the platform to JavaScript 2, would require large engineering investments. The more these changes can be leveraged, the more resources will be available to implement, test and maintain them. This consideration could be decisive in whether such ambitious efforts are even taken on.

Secondly, a more widely used XULRunner will broaden the base of developers with Mozilla development skills. This will, in turn, increase the pool of developers capable of creating quality extensions for Firefox. Considering that the extension ecosystem is arguably Firefox’s biggest asset, this could be of considerable importance to the browser’s ongoing success and market share growth.

Thirdly, a strong platform commitment will provide Mozilla with some measure of future-proofing. The annals of business history are littered with companies who foundered because they were hesitant to endanger existing product lines. (IBM’s relunctance to jeopardize its mainframe and typewriter businesses with a strong move into the microcomputer market is a classic example.) Firefox is king right now, but who knows what the future will bring? Already we are seeing new browser directions like Prism and Fennec that rely on Mozilla-as-a-platform (and are experiencing some pain when the platform functionality is not as generic as it could be). By commiting to a strong independent XULRunner, Mozilla will be better prepared to take appropriate action as the browser landscape evolves.

Finally, there is a clear market need for an open development framework for multiplatform internet-enabled applications. Microsoft is pursuing this market with .NET and Silverlight, but the company is hardly known for its openness, and it will always favor Windows even if some support is provided for other operating systems. Adobe’s offering is also proprietary and crucial components are not open source. As this space heats up, many of the applications that would traditionally be deployed in the web browser will be implemented instead as so-called Rich Internet Applications that run directly on the desktop. Turning XULRunner into a truly competitive offering would be of great benefit to the web at large, in the same way that Firefox has brought more vigor and openness to the browser space. It would also be a great way to promote the principles outlined in the Mozilla Manifesto.

It is worth nothing that, by all accounts, Firefox was not embraced immediately by much of the Mozilla community when it was first released. While practically everyone recognized an increased focus on user experience as a Good Thing, many objected to the sacrifices that this entailed (such as discontinuing support of the Suite, with its integrated mail/news client, HTML editor, chat client, etc.). If too conservative a stance had been taken, Firefox might never have been released and its subsequent success would have never materialized. This isn’t to say that all change is good or all risks worthwhile, but any long-term success is predicated on taking at least some big scary (but calculated) bets.

In part two, I’ll discuss what steps are needed to help XULRunner achieve its full potential as a competitive RIA platform.

This comment was made to me by Benjamin Smedberg, who is the driving force behind XULRunner, Mozilla’s platform for building portable, web-enabled applications. Obviously the remark is largely tongue-in-cheek (and in fact “measly stub” was my own joking characterization), but there is a kernel of truth to what he says. To understand why, some background is in order.

The original architects of Firefox were impressively visionary in building their browser on top of a general-purpose framework that has helped them to manage the complexity of deploying a sophisticated product on dozens of different operating systems. This platform is so powerful that other companies have decided to build their own applications on top of it. Prominent examples are Songbird, Joost and Miro. Benjamin has done a great deal of work to take what used to be the pile of stuff that makes Firefox tick and turn it into a product in its own right: XULRunner.

The current confusion has stems from a blog post written by then CEO Mitchell Baker last May. In her defense, Mitchell devotes the vast bulk of the piece to explaining that Mozilla is planning to continue supporting XULRunner in a variety of ways, particularly as the foundation for Firefox and as a platform that other software developers can use for their own apps. But many seem to have latched onto the last section, where she says that “the Mozilla Foundation does not plan to invest in a pre-packaged or stand-alone XULRunner at this time.” In the game of telephone that is the technology press, this was apparently communicated as “we’re discontinuing XULRunner”.

In reality, nothing could be further from the truth. Benjamin is referring to what is doubtless the least understood but most significant of many exciting innovations in Firefox 3. Previous versions of Firefox used the XULRunner source code but couldn’t share it with other apps at runtime. The upcoming version ships with a complete XULRunner runtime, and actually lets you turn Firefox into XULRunner with a simple command line switch.

This is important because the browser wars are evolving into runtime wars. Players like Adobe and Microsoft are trying to convince software developers to build on top of their RIA platforms (AIR and .NET/Silverlight, respectively). Programmers are understandably wary of doing so if users will have to download a hulking runtime just to use their applications. This is one of the key factors that has prevented Java and previous incarnations of .NET from gaining widespread penetration on the desktop.

The only company that’s been really successful thus far in getting its runtime onto users’ desktops is Adobe, whose Flash player has achieved something approaching ubiquity. It’s a safe bet that they are planning to leverage this installed base to push the AIR runtime, and in fact I made precisely this bet with another Mozillian, Mike Shaver, who will be paying me 100 euros if Adobe finds a way before the end of 2008 to sneak AIR onto surfers’ machines when they upgrade to a newer version of Flash. (And if anyone from Adobe is reading this, there’s 50 euros in it for you if you can make this happen.)

The player with the strongest cards, however, is Mozilla. Unlike Adobe and Microsoft, they have a true killer app in the form of Firefox. When its 150 million odd users upgrade to Firefox 3, they’ll be getting XULRunner as a surprise bonus. This will seed the market and make it a whole whack easier for software developers to deploy XULRunner-based applications. Right now people are focused on the “awesome bar“, a slimmer waistline and other cool new additions planned for Firefox 3, but the platform it conceals under the hood may turn out to have the most revolutionary impact.