Although Mozilla is still readying Firefox 4 for its official release, the organization is already laying out its plans for subsequent versions of the open source Web browser. In a roadmap published earlier this year, Mozilla revealed plans to issue three more major releases during 2011--bringing the browser's version number up to seven.
As we discussed in our coverage of the roadmap, Mozilla's plan is ambitious and will require a dramatic overhaul of the Firefox development process. Mozilla—which has historically had lengthy development cycles and protracted beta testing—will have to transition to a faster and less-conservative approach to release management. The organization has authored a document that describes how such a transition could potentially be achieved.
The document is still in an early draft stage and should be regarded as a proposal—not a finalized product plan, but indicative of the organization's thinking. Although it leaves some questions unanswered and there is still room for refinement, the strategy articulated by the document is compelling and illustrates the importance that Mozilla places on properly executing the procedural overhaul. Mozilla is clearly putting a lot of thought into this effort and is laboring to ensure that the transition will best serve Firefox's audience.
The document describes a 16-week development cycle in which software improvements will flow down through several tiers. The tiered model appears very similar to Chrome's channel system. New code will initially land in mozilla-central, the repository that hosts the tip of the code base. As new features solidify, they will roll through "experimental" and "beta" channels before arriving in a stable release.
Each of those tiers will be backed by its own code repository. Features will have to be implemented in a more compartmentalized fashion so that Mozilla can easily disable or withdraw functionality that is deemed unready for the final release. The proposal draft estimates that roughly 100,000 users would run nightly builds based on the code in mozilla-central. This group would likely consist of Firefox developers and contributors who are willing to tolerate some breakage and day-to-day changes to the user interface.
The experimental channel, which would have an estimated test base of roughly 1 million users, would be ideally-suited for Web developers who want to test the latest standards and Firefox add-on developers who want to experiment with new browser APIs. Beta releases, which will be suitable for widespread testing, are expected to attract a broader user base—as many as 10 million, according to the proposal.
It's worth noting that Mozilla already publishes nightly builds and beta releases. There isn't, however, anything that is quite analogous to the experimental channel in Mozilla's current pr-release lineup. Interestingly, the number of users actually running prerelease builds today is seemingly a great deal smaller than the estimates in the proposal.
The document describes a powers-of-ten pattern of audience growth between the nightly, experimental, and beta channels, but it's not really clear where that is coming from. To put it into perspective, it's worth comparing against a chart that Mozilla highlighted in November which cites 20,000 nightly build testers, 800,000 Firefox 4 beta testers and approximately 400 million users. Keep in mind, of course, that the proposal document is still a draft and there could be any number of possible explanations for the odd discrepancy.
One of the challenges posed by faster iteration is the intrusiveness of the update process. Frequent updates would be especially disruptive to users running the experimental and beta channels. The proposal document suggests silent background updates as a potential solution to the problem. It's worth noting that Mozilla is already transitioning to silent updates for minor fixes in Firefox 4. It will be possible for users to opt out if they prefer to manage updates themselves.
Arguably the biggest challenge for faster iteration is going to be the question of extension compatibility. The proposal document acknowledges that the problem exists but doesn't provide any suggested solutions. It's an area where Mozilla is going to have to do some serious problem-solving.
Firefox's robust add-on ecosystem is one of the browser's strongest differentiators, but keeping add-on developers aligned with the latest version of the browser is already a big challenge. Shortening the development cycle is going to exacerbate that issue profoundly. Users tend to not want to update until their favorite add-ons are compatible. Before moving forward with an incremental development strategy, Mozilla is definitely going to have to flesh out a plan for dealing with the extension issue.
Again, we want to emphasize that the proposal document is an early draft and there is still a lot of space for changes and improvements before Mozilla puts a plan into action. The real value of the document at this stage is that it shows how Mozilla is thinking about the transition. I still remain skeptical that Mozilla can deliver four major releases in one year, but the process proposal is a good first step that adds credibility to the existing roadmap.
Update: Mozilla's Mike Shaver has clarified the apparent discrepancy in the beta user estimates. He explained that the number of Firefox 4 beta testers has gradually increased to 2.5 million. When the new development process is instituted, Mozilla anticipates having a large consistent beta test group throughout the 16-week cycle rather than the current situation where the number of beta testers grows towards the end of a cycle and then drops off after a release as testers switch to the stable version.
reader comments
46