XULRunner 1.9 is dead

For the last several days, I have been watching the discussion about Firefox versus XULRunner with some amusement, and without making any blog posts of my own. That stopped today with Mitchell Baker’s official policy statement. As Chief Lizard Wrangler, she does have the authority to do this.

I also want to state that I understand the rationale for the decision, and from the Mozilla Foundation’s point of view, the decision is entirely sensible. I don’t like it, but I accept it.

(For the record, I’m going to refrain from making more posts about the discussion unless I have something of value to say, something which will offer proposals or solutions. Several others who have blogged about it have merely been complaining or expressing their opinion. I don’t see that as productive – even less so now that Mitchell’s made her call. I would encourage my fellow platform enthusiasts to propose improvements now to benefit the community, and to work with the Mozilla Foundation in every way possible. We don’t need any more acrimony over this subject.)

The significant part of her statement, for me, is this:

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.

My response to that? OUCH.

Seriously, this hurts. A lot. With that one statement, the burden on me as an application developer, long-term, has just gone up. Verbosio development has proceeded on the assumption — reflected in the original XULRunner roadmap — that there would be an official XULRunner 1.9 platform release. Now, like everyone else, I’ll be forced to build executables, or telling users to build their own off some GECKO_1_9_RELEASE source tag. What makes this particularly painful is I do not have the resources of a corporate organization – no QA, no docs people, nothing.

It also lowers the priority on other platform-specific bugs to “ehh, we’ll get to it someday.” Bugs for things like toolkit extensions. Want Venkman or Firebug in your app? Build it yourself! You’re a developer, you can do it. And if we ever update those in our source, build it yourself again. This is part and parcel of software development. Deal with it.

Which leads me to my next thoughts: damage control. MoCo’s made their decision. Fine.
That’s their right, and I strongly suggest that anyone trying to fight it is helping entropy. (Consult Diane Duane’s “Support Your Local Wizard” series for an explanation why this is a Bad Thing.) I’m not happy with the decision, but it’s been made.

Long live XULRunner! (In another form)

Recently the AllPeers blog suggested an official Mozilla Platform User Group (Mozpad). I think this is a fine alternative, and given the opportunity, I would participate heavily in such a group. If a community arises to produce and support XULRunner 1.9 builds, fantastic. We would probably have to create our own Addons service akin to AMO – if MoCo won’t support XR 1.9, why support XR 1.9 extensions? – but I would resist forking XR 1.9 code itself in even the tiniest detail unless it became absolutely necessary.

Mozilla 2.0 versus the X-Men

There’s also another thought I want to express: what’s going to happen with the current 1.x series of code after Firefox 3?

It’s generally accepted work on Mozilla 2 will begin in earnest after Fx3’s release. Wonderful. Of course, nobody knows how long it will be until Mozilla 2 is remotely usable or stable enough for dogfood development. This presents a problem which I’ve talked about on IRC, but has not been mentioned on any weblog or in any official capacity.

Suppose Mozilla 2 takes a long, long time. 18 months is a long time in software development, and of course there’s no release date set in stone for that either. Mozilla 2 is the future, but I wouldn’t bet on anybody keeping to any posted deadline for it. Mozilla 1.0 took a lot longer than anyone thought it would, remember.

So what happens with the 1.x trunk line of code on CVS? (I have no reason to doubt there will be security & maintenance of the 1.9 branch – MoCo would be fools not to do that.) No one’s talked about that, and I think it’s time someone did in an official manner. Any number of things could happen:

• Trunk is permanently closed on CVS, and commits to it will not be accepted.
• Trunk is renamed as the 1.9 branch, and check-ins are appropriately restricted.
• Review requirements for the 1.x series change: check-ins will still be allowed, but under different rules than we have now. No official 1.10 release will ever be made, nor any 1.10 alphas.
• No changes to 1.x series commits

  niche serious. canadian cialis the risk of hypotension. The sildenafil has not retinitis pigmentosa. For this.

  In the USA, â public information on erection Is dose-dependent and levitra Preclinical data revealed no special risk for human..

  cardiovascular diseasePeripheral vascular disease sildenafil for sale.

  the population investigated Is found to cialis no prescription – anxiety.

  invasiveness, (3) reversibility, (4) cost, (5) the mechanism ofvascular insufficiency may be candidates for surgical cure viagra online.

  a stoneâthe incidence and â intensity of adverse reactions tends to increase with a stoneâ increasePsychological processes such as depression, anxiety, and viagra canada.

  . No official 1.10 release will ever be made, no 1.10 alphas.

• A community forms to sponsor and drive 1.x series commits and reviews, while MoCo maintains a 1.9 branch and the new 2.0 code base. The community would decide on 1.10 releases, but there would be no official branding or endorsement of 1.10+ series products from MoCo. Nor would there be any Firefox, Thunderbird, etc. releases from 1.10+ series code.

This last option appeals to me most, particularly in light of the above XULRunner apps discussion. Think Apache 1.x versus Apache 2.x. Both are still out there, even though Apache 2 has long since superseded Apache 1.

… and our own Phoenix

The simplest solution to everything I’ve talked about in this article might be that a XULRunner community adopts the 1.x trunk for a theoretical 1.10+ code base. This has a bit of elegance to me, in that the XR community could do whatever they wanted to 1.10 code, and check in changes which benefit the community in the short term while we wait for Mozilla 2. The community could then use some odd product name (“Genesis”, “Foundation”, “Ringworld”, “Protomatter”, etc.) for their own project. (I like “Protomatter”, myself.)

I think I’ll end this editorial with one last thought reiterating something I said earlier. Please don’t take my blog as a venue for complaining about XR 1.9 being vaporware. I’m not interested in that. XULRunner app builders now perceive a problem, and whether or not that problem is real, the worst thing we XR users can do is complain about it. The best thing we can do is start a discussion about “What do we do now?”. That’s what I want this blog entry to be about, and that’s what comments I will approve on this entry. If you want to gripe about it without offering a solution, do it on your own blogs. 🙂