Just Browsing

Thoughts on XULRunner, Part Two: One XULRunner to Rule Them All

In part one of “Thoughts on XULRunner” I discussed why XULRunner is of strategic value to Mozilla Corporation and the community at large. Assuming (with a rather optimistic leap of faith) that anyone besides me is convinced that it would be worthwhile to turn XULRunner into a fully fledged Rich Internet Application development platform, a much more difficult question is how to achieve this. Tremendous resources would be necessary to compete with the likes of Microsoft, Adobe and Sun. This means either lots of money, which might be difficult to obtain for a developer product without an obvious business model, or a large group of dedicated volunteers.

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.