Firefox development dilemma: Tweak or overhaul?
Programmers are considering beefing up a version of Firefox 3.6 with some features planned for 3.7. Will that speed or slow the browser advancement?
- Shankland covered the tech industry for more than 25 years and was a science writer for five years before that. He has deep expertise in microprocessors, digital photography, computer hardware and software, internet standards, web technology, and more.
Mozilla is building a number of features into the upcoming Firefox 3.7 browser--but the organization now has begun stewing over whether to introduce some of them in a significant update, as planned, or to rewrite some sooner for a variation of the current browser.
Programmer Benjamin Smedberg proposed the retrofit approach with a version called Lorentz on a Mozilla mailing list in late December. In the resulting discussion, developers and observers weighed the tactical advantages to each approach and wondered whether the quickening pace of Firefox development is ill-suited to browser users among businesses.
Firefox is based on a browser engine project called Gecko. The nearly complete (but somewhat tardy) Firefox 3.6 is built on Gecko 1.9.2, and Firefox 3.7 is set to use Gecko 1.9.3. The question afoot is whether to "backport" significant Gecko 1.9.3 features to 1.9.2 and release the new Lorentz version of Firefox based on it.
"With the [Lorentz] project branch, I believe we could go to beta in the middle of January and release in late March/early April," Smedberg said. In contrast, "doing a release from Mozilla-Central/1.9.3 presents a lot of schedule risk without matching reward."
One design change in question is the implementation of out-of-process plug-ins, which would move plug-ins such as Adobe Systems' Flash to a separate computing process--and a project in which Smedberg is involved. The work, the first phase of a Mozilla project called Electrolysis, is expected to improve stability; many browser crashes are the result of problems with Flash programs. Another feature he'd like is a less disruptive browser update process--a particularly relevant technology, given Mozilla's attempt to move to a more frequent release cycle.
Chris Blizzard, who runs Mozilla's developer relations, sounded supportive of the Lorentz plan in a mailing-list message. He added some features he'd like to implemented sooner rather than later, including faster Direct2D-based graphics for Windows machines, CSS transitions that can add pizazz to some graphic elements, and Web Sockets for communication between a browser and a server.
But, he added, delay is a risk of new features. "We need to make sure this train doesn't get too big, though, or it will stretch out into a pretty long release," Blizzard said. Indeed, that's what happened with Firefox 3.5, which began as a quick 3.1 update but arrived months later, as more features were added.
Added L. David Baron, "I have bad feelings about this plan, based on the last time we did this: Firefox 2.0 sucked resources away from the trunk [the development of new version of Gecko] and allowed it to become extremely unstable, and it look a long time to get things back together for Firefox 3."
Eventually, the Mozilla mailing-list discussion turned to how well corporate users are able to deal with a fast development cycle.
"The nature of the Web doesn't really lend itself to long-lived stable browser branches, IMHO," programmer Robert O'Callahan said. "A lot of the security issues we discover in the Web itself require proactive security measures such as UI [user interface] and architectural changes that one normally wouldn't apply to a 'stable branch.'"
John J. Barton, an IBM programmer involved with the Firebug extension to Firefox to aid Web developers, made the case for relatively rapid changes.
"IBM and our customers are all moving to faster development cycles," Barton wrote. "That's why I urge [the] Firefox team to continue to lead in that direction."