Mozilla is a huge project, now cursed with success. It did not start that way. To think about where to go, we should mull over how we got here.
Over the years since the first major roadmap, I’ve tried to steer the project toward the shortest path to the next port of call that was not going to leave us cannibalizing the ship and ourselves, for want of supplies and fresh crew (more contributors). Doing this without running out of stores and existing crew along the way required good luck, along with a hard-nosed attitude about what to keep and what to throw overboard.
Some paths were long, for instance the reset in late 1998 around Gecko, XPCOM, and an XPFE. This was a mistake in commercial software terms, but it was inevitable given Netscape management politics of the time, and more to the point, it was necessary for Mozilla’s long-term success. By resetting around Gecko, we opened up vast new territory in the codebase and the project for newcomers to homestead.
More recent journeys to better ports were much more in tune with the Internet zeitgeist. The best example was FIrefox as the new model application.
Firefox changed everything for us, for the industry, and most important, for browser users. We have heard repeatedly from people who feel as though their computers are friendly tools again, instead of spyware-ridden zombies infected via the default browser. These folks now see the web as fun and empowering, not static or even degrading over time.
Now, having given the default browser a little competition, and helped advance the causes of simple yet powerful UI, web content standards, and user innovation toolkits and networks such as XUL extensions, their own extensions (e.g., GreaseMonkey’s user scripts), and AJAX/DHTML/whatever new-style web apps, we must journey again to an even better place, with another hundred million downloads, and even more users worldwide.
We see the Web outpacing traditional desktop and operating system software development. Great web services and mashups abound in the new, over-hyped era. In spite of the hype, these new Web apps usefully point to the immense, hardly-realized value of people connected by the Internet.
Firefox is “just a browser”, but it has an evolving role to play in this world. The browser is a platform, as threatened in 1995 and dismissed with the death of Netscape. Yet every web app is hobbled by stagnant content standards from five or ten years ago. There is no good reason for this.
There is no reason why browsers should not innovate, along with plugins, applications, and operating systems, to support modern hardware-assisted graphics, dynamic programming languages, and richer content types. The reach of the web still favors the browser over any particular OS or non-Web platform.
Therefore in order to innovate nearer to “Web time” on the Firefox user interface and extension fronts, we propose to develop the front end of Firefox 2 and the platform for Firefox 3 concurrently, with Firefox 2 releasing in less than a year. The details have been drafted in a product roadmap that Chris Beard has written. (Many of you know Chris as an active driver and product manager in the project since Firefox 1.0 launched. He’s been a huge help, and I’m very grateful for his contribution here.)
The back end code, Gecko and other modules such as the JavaScript engine, will occupy the Mozilla source tree “trunk” development during the Gecko 1.9 milestone, which is already under way. The major efforts are to:
- rearchitect our rendering layer to support hardware-accelerated graphics;
- selectively improve architecture in the layout engine, to fix longstanding bugs;
- improve web author productivity with better content languages and debugability;
- move XUL to the next level in concert with the rendering and programming improvements;
- make XULRunner the embedding vehicle for Firefox and all modern XUL applications.
Mike Shaver and I have gathered together the requirements and plans of many folks in a new platform roadmap.
These roadmap drafts are rough, and although much work has already been done in the directions outlined by these documents, much more remains, and our plans will change as needed. But plan we must, perhaps more than ever in the project’s history. We have reached the big time now, and there is no turning back or coasting along.
Your comments are welcome.
Well, first of all I’d like to congratulate all the people in Mozilla (and outside it) that made all of this possible 🙂
Secondly, it’s really great to see that, right now, Firefox is one of the steering forces behind “Web 2.0” (here’s them buzzwords again!).
I wish all the best to you, and keep on innovating! 🙂
Very cool to see a new roadmap published!
Maybe it’s a question I should ask to cbeard, but I wonder why we are moving from a branch+trunk model to a branch+sub-branch+trunk model.
This is not a criticism, it’s just that I anticipate questions that I’ll get in the field 🙂
How important are Web Services (SOAP, WSDL and friends) to you? It needs work to get it working better, and probably a lot of code could be removed and switched over to E4X.
It’s hard to find the right single metaphor for a successful, fast-moving, large open source project. So I mixed freely (ship, homesteading land, road); a failing of mine. Someone help save me here! 😛
Tristan: we have two branches and the trunk because we anticipate doing critical bug-fixing only off the 1.8 branch (1.8.0.1, etc. in the Gecko rv: field in the user agent; Firefox 1.5.0.1, etc. for the delivery vehicle). And we’ll be doing Firefox 2 mostly-front-end work on the 1.8.1 branch. All the while, the 1.9alpha trunk will be undergoing major platform development, and will also receive the stable and long-lived 1.8.1 changes (not any 1.8.1/Firefox 2 short-term fixes).
Doron: it’s hard to say, because the web today is RESTful web apps and plain-old-HTTP page serving. Do you see a need for SOAP/WSDL support in the browser, outside of certain Enterprise settings?
/be
Wow! I can’t believe how far the Netscape code went. It was just a few years ago that I was reading about on how Netscape challenged Microsoft and how Internet explorer brought its demise. But now it looks like Firefox (the resulting code, not necessarily Netscape) can take the majority share of the market. As I look at browser statistics (being a web designer) I can see that Mozilla usage is continually on the rise. I love Mozilla! Keep it up, thanks, good luck, and congratulations!
Could we get a SAX interface to Expat exposed in JavaScript? It would be real useful in the Thunderbird and Mail/News feed parsers.
Your no doubt in the big time now!!
sayrer: do you need SAX in particular, or just the ability to parse XML from JS? If the latter, have you tried E4X yet? See https://developer.mozilla.org/en/docs/Category:E4X for links.
/be
I looked at the platform roadmap, and was wondering about plans for Unified Storage (SQLite, then moving various existing stores over to it.) Are there any specific plans yet?
Fred: best I can cite so far are the links at
https://wiki.mozilla.org/Special:Search?search=sqlite&go=Go
and of course the code itself:
https://lxr.mozilla.org/mozilla/search?string=mozStorage
I’ll ping Vlad about where there is a single doc describing the mozStorage grand plan.
/be
I think we need some new language. Might I recommend the term “limb” for the ongoing development of Firefox along Gecko 1.8 – 1.8.1.
Current thinking is to avoid branch of branch based development, and keep the “dot means [release, possibly in the future] branch point” rule, so 1.8.0 would be a branch off the 1.8 branch which would host security and topcrash fixes only, for patch releases.
Then 1.8 branch becomes free to host ongoing work leading to 1.8.1, just as current trunk is 1.9 alpha without having yet branched for a Gecko 1.9 release via Firefox 3.
Further thinking is to avoid branch-based Firefox 2 development, since it is mostly user-facing front end plus new back end additions, by keeping everyone (Firefox 2, Gecko 1.9) working on the trunk, preserving stability, and delaying the move of Firefox 2 work to the branch.
This has benefits and risks, but it looks like the best compromise to me right now. And no “limbs” required.
/be
brendan: Does E4X read the entire document into memory like DOM? The problem is that people refresh their subscriptions all at once, resulting in many DOM trees being simultaneously built in-memory for data we mostly don’t need (because we’ve already seen most of the entries). Any streaming XML API would work. Expat has its own API that’s similar to SAX, and that would be fine too.
Ah! there’s a new bug I didn’t know about. https://bugzilla.mozilla.org/show_bug.cgi?id=315826
Seems bsmedberg is asking for the same thing.
sayrer: E4X currently does parse into its own all in-memory data structures. If this means too much intermediate garbage for your use-case, that SAX API does look better. We should get that fixed in the trunk soon, to evaluate whether it could be uplifted to the 1.8 branch for inclusion in Firefox 2.
/be
What about Mozilla? I work with a client that uses Mozilla as a base framework for an application. (using html/CSS/JS/XUL ) Will it be maintained with this road map?
Is there really any core difference between the Mozilla browser and Firefox that we even need to use Mozilla for our base framework?
We need to be able to plan ahead, and I’d rather choose Firefox now (if it would work) if the Mozilla Suite is going to be phased out…
Bob: Firefox has replaced the Mozilla Suite as the premier product supported by the Mozilla Foundation. That happened with Firefox 1.0. We put the 1.7.x suite into maintenance mode, and it’s still supported but only for critical security fixes, and only for some yet-to-be-determined duration.
The suite remains a Mozilla project (in contrast to a product, a project does not entail Mozilla investing in trademark, marketing, extra QA, etc.). A group of volunteers from the Mozilla community are tending the future of the suite under the name SeaMonkey, and working toward a 1.0 release based on 1.8, IIRC.
Given the relative Firefox and SeaMonkey community sizes, and the growth rate for Firefox, your best bet to enjoy broad support for XUL app development is Firefox, or rather, the matched-build XULRunner that’s already being used for apps such as Songbird (see https://www.songbirdnest.com/).
For more on XULRunner, see https://devloper.mozilla.org/en/docs/XULRunner. There should be a stable release of XULRunner 1.8 (its version matches the Gecko “rv:” field in the user-agent header sent over HTTP) in January.
/be
“We have heard repeatedly from people who feel as though their computers are friendly tools again, instead of spyware-ridden zombies infected via the default browser. These folks now see the web as fun and empowering, not static or even degrading over time.”
Not to mention an outstanding environment in which to develop and test Web applications. By that, I don’t necessarily mean Mozilla framework apps, rather traditional HTML/CSS/JavaScript driven sites with your favorite backend. And, consequently, the Web is a much better place for it in just this past year+. Congrats for some really outstanding work, and it’s good to see JavaScript really coming into its own.