shaver

Mark blogged about the new Firefox -app switch, which I think is a pretty interesting thing. Of course, it’s not a substitute for XULRunner, which gives the application developer complete control over important things like the update cycle and process, and it’s definitely not something that we’re recommending people use without a lot of careful study.

This is something that we’ve been asked to provide for quite some time, and even with the tight coupling to Firefox in versioning and launch syntax I think it’s going to be a valuable addition to the repertoire. Here’s how I now see the platform spectrum for our technology:

• Web applications. If you can do it here, you should. We’re working with other browser developers to develop and standardize new web-platform capabilities all the time, because being able to put your app in this bucket brings a ridiculously large number of benefits for users and developers both. With webrunner you’ll have a way to give users an optional desktop-launch experience that they may be more comfortable with, even.

• Firefox extensions. There are thousands of them that have been able to build great experiences (and, in some cases, great businesses) with products that are tied to the Firefox maintenance-update rhythm, and we’re seeing more great stuff all the time.

• Firefox “-app” apps. This is a nice little hybrid where you are still coupled to the Firefox update cycle and so forth, but get more isolation from the browser process and end-to-end control over the UI. As Mr. Finkle said, this is a sharp tool with its handle loosely attached, so please use care when using it. If extensions aren’t suitable for your project because of the update cycle model, then this very much won’t be either. For prototyping, or some extension-like uses, it’ll be killer, though. (I like that the apps are started with “firefox -app”, because it’s another hint that the thing you’re doing is dependent on Firefox, and that changes to Firefox could hurt it. I think it would be more confusing to have it be called “apprunner”, f.e.)

• XULRunner apps. I need say little more on this topic; Joost and Songbird and Komodo and Miro and…yeah.

By no means do we expect, recommend or condone XULRunner-grade apps being moved to this model without extreme care, but a lot of people building such apps, especially smaller ones, have been asking for a way to piggyback off Firefox’s awesome update story while still having their own top-level chrome.

Mark had it exactly right: Mitchell’s post about XULRunner (and other things) was not an announcement that we are killing XULRunner. It was a statement about what the Mozilla Foundation is planning with respect to some very specific capabilities and deployment plans, due to our analysis of effort and return with respect to our primary mission.

To help people who might have been confused either by the original post or some of the reactions to it, I offer this summary:

• The Mozilla Foundation will not be working on the a shared, system-wide XULRunner deployment capability in the Gecko 1.9 timeframe. This means that applications which are built on top of XULRunner will need to ship a copy of XULRunner with their apps, or otherwise ensure presence of an appropriate one (version, build flags, etc.). This is, to be clear, what every XULRunner-based application is doing today. Many applications in fact ship with small patches to XULRunner in their distributions anyway, taking advantage of the open source nature of our platform to make different impact/value trade-offs than we do for Firefox, and on their own schedules. This is not to say, by any means, that we do not see the value in a future that includes a universal XR runtime, with appropriate versioning, update, profile-sharing and other wonderful capabilities. It is to say, rather, that we feel the investment required and the risk of destabilization isn’t appropriate for us to undertake directly during this development cycle.
• The Foundation will very likely not ship a “reusable” XULRunner as part of Firefox 3. While it’s still quite possible that Firefox 3 will be built on top of a private XULRunner, as outlined above, we will likely not take the schedule impact on Fx3 that would be required to make that private XULRunner usable easily by other applications.
• The Foundation is interested in supporting the production and distribution of “naked” XULRunner builds suitable for application authors to take, customize, and distribute. This is an area in which virtually any member of the XULRunner community (including those who are apparently very invested) can make a very helpful contribution, as members of the Eclipse AJAX group have done already in providing contributed builds. I believe that the SeaMonkey project, which the Foundation supports not through directly-tasked developers but instead through infrastructure and enormous investment in shared platform work, provides an excellent example. XULRunner’s very origin is from “outside the Foundation” in bsmedberg’s early work, and given the presence in the XULRunner community of funded companies like Songbird and Joost, I am confident that both the interest and ability to assist themselves and others in this area are present.

Other important points from Mitchell’s post, which deserve deeper discussion in other posts, include:

• A desire and commitment to invest in improving interactions with the entire XUL(runner) development community.
• A continued commitment to invest in the powerful and valuable shared platform for the web and beyond.
• A keen interest in improving the process of getting good and appropriate patches and other improvements (hello, docs and tools and build help!) into the common repository or pipeline promptly and predictably. As XULRunner itself is about 1000 lines of code that differs from Firefox, the bulk of the work is likely to be in build, packaging, update and other “meta” areas, I suspect.

There’s going to be a lot of reaction today to Mitchell’s post about Mozilla Foundation investment in XULRunner (Daniel and Alex have already posted theirs, keen folk that they are), and I’m going to be spending the next 7 hours travelling, so I’m going to rush this note out and find out later if it helps or hinders. Exciting!

Hearteningly, I think that people are misunderstanding what exactly is being not done here. Mitchell’s post defines a “standalone XULRunner” as:

[...]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.

When Mitchell says that the Mozilla Foundation (and, by extension, the Corporation) are not going to invest in a standalone XULRunner, that “XULRunner runtime”, à la the JRE or .NET, is what she’s primarily contrasting, IMO. Daniel’s post seems to be more interested in something much more modest, such as a zip file or DMG that you can take, drop your application.ini and custom code into, repackage with some magic dust, and be done with. I do not read Mitchell’s post, nor do I understand our intent, as “waving off” code that would make that process smoother, nor of presenting any barrier to having the resulting code hosted in the Mozilla CVS repository. Her explicit mention that

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

should be noted well here. Daniel’s example of improved installation support for “generic” extensions is an example of work that fits this pattern exactly, in my considered opinion, and I would not expect this announcement or direction of Mozilla employee cycles to add any new impediment to that.

(I think in hindsight that the use of the term “packaged XULRunner” or “standalone XULRunner” in this way is probably not as clear as something like “system XULRunner”, though I have become comfortable with the term myself over the last little while. The expectations for a “system XULRunner” are quite high, and it’s that significant and not-well-understood deliverable that the Mozilla Group of Companies is not investing directly in right now.)

It’s also important to appreciate that projects can be very successful in the Mozilla community without being Mozilla Foundation products. SeaMonkey is a great example of a group within the Mozilla community that has shown leadership and motivation in developing, supporting and marketing a piece of software that doesn’t have any Mozilla Foundation employees tasked directly to help it — though some Employees do indeed work primarily in the context of that product as a personal choice, and that’s a fine thing. A XULRunner community can and must exist independent of, though overlapping with, the Mozilla Foundation’s own direct technical investment.

My cab is here, so I must run, but I don’t think that things are as bleak or hostile as some others do. I think that the next few weeks and months will bear out my understanding and expectations, and I’m committed both professionally and personally to helping that they do.

Mitchell posted earlier about my new focus: our developer ecosystem, and helping people produce great new tools and experiences on top of Firefox and the web both. It’s work that lets me combine technology, communication, and helping people solve their problems, and if I end up being even a fifth as good at it as I am excited about it — well, I’ll be really good, that’s what!

One important part of Mozilla’s support for developers in their work with Firefox and the web is the Mozilla Developer Centre Center, and I’ll be working with Deb and Eric to help MDC grow and thrive. In just over a year, MDC has developed a strong community of contributors and a great base of documentation, so I consider my job here to be helping Deb execute, and staying out of her way. (She is modest about it, and truly MDC is a fantastic example of the leverage that our community represents — and I include web developers in that community, very much — but Deb’s work to catalyze and guide and generally be MDC’s “guiding star” is not to be underestimated.) There are things to be fixed and problems to be solved, to be sure, and anyone who’s worked with me before knows that I can’t help but try to help when that’s the case, but the course we’re already on is very promising.

(As an aside of sorts, the recent newsgroup re-re-organization is a problem to which I owe a karmic debt, and I’ll post about that here and there this week, hopefully today.)

A bigger part of what I’m going to be working on, though, is what my favourite MBA calls “the extensions space” (my favourite trapeze artist would call it “the extensions piece”, I think). Working tirelessly, though again with an energetic and powerful community, Mike Morgan has been driving addons.mozilla.org through growing pains and scaling demands — popular stuff is hard! — and policy grey areas and likely some fire-breathing sharks or something too. He thinks deeply about the risks and hard decisions that we face as we try to make extensions — or, more broadly, a personalized web experience — attractive and appropriate for a broader portion of our users, and the users we don’t yet have. Working out a strategy for how to fit extensions into our product plans, how to help extension developers be even more productive and successful and happy, and how to maximally leverage the power of our platform, community, and brand to the benefit of the Web at large is an enormous and, I admit, somewhat daunting challenge. I look forward to drawing on my Mozilla knowledge, impeccable taste, and, especially, the experience and wisdom of people like morgamic to improve this part of our world materially. And I look forward to doing it very soon: while there are definitely long-term projects that deserve our attention, I’m starting to believe that there are some small (hopefully!) but significant changes that can make a positive change in the rather near future.

I’m trying to avoid letting “write a thorough and Frank-worthy post” be the enemy of “write a useful and, you know, posted post”, or something like that, so I think I’ll stop here. I want to thank everyone who has already sent me their (varied, and thought-provoking) thoughts on what’s good and bad today in with our world of extensions, and apologize pre-emptively for what will no doubt be rather tardy replies. I have a lot to absorb here, and nobody is bothering to ask easy questions.

Daniel Glazman has written about the pain he’s experienced trying to update his splinter NVu tree to track the significant Gecko development. It’s a very difficult task, and not one that I would have signed up for. There are a number of suggestions that others have made that might have made the task easier, but that’s for another post. To be perfectly frank, I have little personal interest in making the “maintain a fork of Gecko in another CVS repository” use case materially easier, let alone adding cost to already-difficult Gecko development to support it.

(I had a huge section here about the details of internals-vs-platform and some excellent responses that others have made to the post, but I just moved it to another draft because this post is about something else, dammit.)

What I really want to write about is this passage in Daniel’s latest post on the topic:

Let me first give you an example : suppose you are an experienced c++ coder but a true beginner in Mozilla, and you need to build a xul standalone front-end for an app of yours; you can’t rely on xulrunner yet, because it’s said to a bit immature for the time being. So you want to build a standalone toolkit-based app like Nvu, Firefox or Thunderbird… You start looking at mozilla/browser, mozilla/mail and then you cry. The makefiles are incredibly complex and almost not commented, most of the files in app directory are hard to understand so you don’t really know how to tweak them[...]

If you are a software developer faced with the choice between

• a piece of software that is designed to solve your exact problem, which is not yet release-quality, but is already being used by other people for their projects in exactly this way; and
• writing your own such piece of software on the basis of code you don’t understand, and which was never intended to be anything more general than “the startup code for Firefox”

then you might have some reasons to choose the latter, I suppose, but I can’t for the life of me understand how “maturity” is one of them. XULRunner is farther towards its stated goal — which happens to be completely identical to the goal that Daniel uses in his example — than anything you’ll find in the directories that Daniel lists, as evidenced by the fact that a number of people are already using it in service of that goal.

Even if XULRunner falls short of some subgoal today, investment in improving it to suit the needs of your own app is almost certainly the wiser course, as you reduce the need to maintain your own private fork of the firefox/thunderbird/whatever code — back in the early Mozilla days, we used to refer to this as “the stupid tax”, and talk about how it was often a strong disincentive to keep patches private instead of integrating well-designed hooks into the core app.