Recently there’s been a fair amount of discussion about platforms for building “Rich Internet Applications.” Adobe’s Apollo demo and Microsoft’s Silverlight (WPF/E) effort generate significant attention. And Mozilla’s XUL offering is ever more widely used, in both relatively high profile projects like Joost and Songbird and in less well known but very interesting applications.

Here’s an outline of where the Mozilla Foundation plans to spend resources with regard to XUL and XULRunner. The plans below relate to the next 18 months or so as we develop an updated version of core Mozilla technology known as “Mozilla 2.” One of the goals of Mozilla 2 is to make it an easier technology to embed. We will revisit our XUL and XULRunner plans as Mozilla 2 comes to fruition.

Overview

• The Mozilla Foundation will continue to invest significant amounts in XULRunner and the Mozilla “platform.”
• The Foundations’ focus for XULRunner work for the next 18 months or so will be on browsing, Firefox and the Firefox ecosystem.
• In addition, the Foundation will work to increase communication with XUL developers – both general understanding and specific API requests – and drive relevant information into our overall planning process.
• Contributions that broaden XULRunner are more than welcome; these will be managed according to Module Ownership and other Mozilla policies.

Terms

• “XUL” (pronounced “zool”) stands for “XML based User Interface Language” and is the language in which Mozilla applications like Firefox, Thunderbird, Sunbird and the multitude of extensions are written.
• “XULRunner” is a packaging of the core Mozilla codebase including XUL, HTML, XML, CSS, Javascript and the rest of the Gecko rendering engine. In other words, XULRunner is the core runtime, including a set of libraries and APIs that provide basic functionality required by Web applications, but which does not include any actual user interface or “application” layer.
• “Pre-packaged” or “productized” or “stand-alone” XULRunner. These are terms that have been used to describe an instance of XULRunner that various applications would expect to find on a machine and would share once found. This would allow distribution of a thin “application layer” only, which would then take advantage of a stand-alone XULRunner already on the target machine.
• “Mozilla Foundation” as used here includes the Mozilla Corporation.

Mozilla Foundation Plans and the Role of Module Ownership

The Mozilla Foundation plans outlined below live within the content of Mozilla policies relating to Module Ownership, code review, source code commit access, etc. These policies state that individuals to whom authority has been delegated have responsibilities to the Mozilla project itself, unrelated to employment.

The policy on Module Ownership is particularly relevant to this discussion. Module owner responsibilities are outlined in the Module Owners Roles and Responsibilities document. I’ve excerpted a particularly relevant paragraph below:

Module owners are not tyrants. They are chartered to make decisions with input from the community and in the best interests of the community. Module owners are not required to write code because the community wants them to. (Like anyone else, the module owners may write code because they want to, because their employers want them to, because the community wants them to, or for some other reason.) Module owners do need to pay attention to patches submitted to that module. However “pay attention” does not mean agree to every patch. Some patches may not make sense for Mozilla; some may be poorly implemented. Module owners have the authority to decline a patch; this is a necessary part of the role. Mozilla.org asks the module owners to describe in the relevant bug their reasons for wanting changes to a patch, for declining it altogether, or for postponing review for some period. We don’t ask or expect them to rewrite patches to make them acceptable. Similarly, module owners may need to delay review of a promising patch due to an upcoming deadline. For example, a patch may be of interest, but not for the next milestone. In such a case it may make sense for the module owner to postpone review of a patch until after matters needed for a milestone have been finalized. Again, we expect this to be described in the relevant bug. And of course, it can’t go on very often or for very long without some review . . . .

It is an explicit expectation of the Mozilla Foundation that all its employees (whether employed by the Foundation directly, the Mozilla Corporation, or any other Mozilla entity) who are module owners or have other authority (super-review, etc.) exercise this authority as stated in relevant policy documents.

Mozilla Foundation Plans

1. XUL as language

The XUL language remains fundamentally important to Mozilla. The Mozilla Foundation will continue to invest in the development of the language. We will also continue to work towards standardizing key aspects of the language, such as the “flexibile box layout” which is in process with the W3C. Our focus with XUL language development will be what’s necessary for Firefox, but of course all Mozilla module owners have a responsibility to respond to contributions that address other products and broader needs. That responsibility is described above. Specific examples of how this works in practice have been the inclusion of thread-safety patches and graphics patches beyond Firefox requirements in order to meet the needs of the Songbird project.

2. XULRunner to Support Firefox and Browsing

XULRunner also remains fundamentally important, both for Firefox itself and for our efforts to keep the web itself competitive as a platform against closed / proprietary platforms. The Mozilla Foundation will continue to invest quite seriously in developing XULRunner. The primary focus of Mozilla employees will be developing XUlRunner as a robust platform for the open web as viewed via the browser. In other words, on developing XULRunner to meet the needs of the Firefox ecosystem. XULRunner improvements should benefit a range of other applications but the focus of Mozilla employees will be on browsing. This focus will remain for the next 18 months or so.
3. XULRunner to Support Other Applications

For the next 18 months or so the Mozilla Foundation plans a targeted investment here. (This is not a commitment to invest heavily here after 18 months, it is a statement of what we know today.) For the next 18 months or so, we plan to do the following in addition to work related to Firefox needs:

A. Develop a mechanism to:

• Improve two way communication with the XUL application developer community.
• Gather undocumented requirements, information about bugs and desires for new or improved APIs for XUlRunner.
• Help developers get these bugs, API and feature requests into the Mozilla development worldview. In more concrete terms, get this information turned into discussions in the appropriate Mozilla newsgroups, and /or turned into “bugs” in our bug tracking system.
• Monitor progress and response level of requests, prod developers when appropriate. For example, clearly understood bug fixes should be a good candidate for immediate check-in whether or not the bug affects Firefox or any other Mozilla Foundation application.
• Assist XUL developers to evaluate whether their work could / should be contributed back to the main development effort and if so, how to do so effectively.

B. Utilize this information in planning and implementation of ongoing platform development work, including Mozilla 2. Note that this does not mean all wishes are valid, or even if valid will be undertaken directly by the Mozilla Foundation. This is a focus on learning and evaluating requests, not on necessarily meeting everyone’s wish – lists. And of course, participation by XUL developers will help make things faster.

C. Make incremental improvements and accept contributions that module owners believe are understood, move XULRunner forward and don’t include undue risk.

D. Revisit these plans periodically (but not constantly) to see if changing circumstances should cause a change in plans.
4. Stand-Alone XULRunner.

The Mozilla Foundation does not plan to invest in a pre-packaged or stand-alone XULRunner at this time. We plan to re-evaluate this as we approach the release of Mozilla 2. Specifically this means we are not producing supported XULRunner builds and we do not plan to ship Firefox3 on top of a stand-alone XULRunner. (If someone contributed the patches to make this happen we would evaluate them, but anticipate the risk associated with such patches would almost preclude their incorporation into Firefox 3 unless they landed and tested well during the alpha release cycle.)

The rationale for this decision is that the primary advantage of packing XULRunner as a runtime is to allow for the download and distribution of small applications that can use a pre-installed copy of XULRunner. However, several problems prevent this from being a viable solution in practice:

• As we’ve seen with the JVM, CLR, and DLL settings it is often the case that applications will need to bind to a very specific version of the runtime. In this case the application may still require downloading its own XULRunner version.
• Many existing users of XULRunner are adding their own extensive customizations to the platform and thus could not use a standard build. We are eager for developers to contribute back generally useful customizations so that their work improves XULRunner for everyone. However, we anticipate some patches will be particular to a developer or class of developers. These may not be contributed back, may not desirable for a general distribution, or may involve enough risk that extensive testing and timing requirements will be necessary.

A stand-alone XULRunner is a potentially significant and disruptive amount of work and the practical benefits in the real work setting of the Web are difficult to assess given the versioning problems described above. The Foundation will focus its resources on problems where we’re more certain of the scope of positive impact.

* Original posted at: http://weblogs.mozillazine.org/mitchell/archives/2007/05/xul_and_xulrunner_investment.html