October 04, 2011, 9:47 AM — Mitchell Baker, Chair of the Mozilla Foundation, has just updated Mozilla's progress on the transition of Firefox development to a six-week rapid-release cycle.
The move to a rapid-release cycle has been met with some resistance, particularly among enterprise IT departments, who want to use Firefox, but cannot meet the demands of a six-week release cycle for testing and deployment. Initially, Mozilla's response to enterprise qualms was, well, less than enthusiastic, thanks to comments from Firefox Product Manager Asa Dotzler in June:
"Enterprise has never been (and I'll argue, shouldn't be) a focus of ours. Until we run out of people who don't have sysadmins and enterprise deployment teams looking out for them, I can't imagine why we'd focus at all on the kinds of environments you care so much about."
Which, as one might expect, went over like a ton of bricks.
Mozilla has gotten a little more customer-friendly of late, especially to the large deployers. In her blog yesterday, Baker highlighted four areas where the comments about the rapid-release cycle seemed to focus:
The aforementioned enterprise deployment problem Add-on compatibility Update notice fatigue General frustration in the handling of the transition
Baker does a good job covering the current response status to this issues, and I came away from her post thinking that Mozilla seems to have regained its footing after stumbling on rapid release a bit. There will still be some bumps in the road ahead, I think.
I was particularly interested in how Mozilla was going to handle the issue of add-on compatibility, which still seems to be the most powerful pain point in a new release of Firefox. This is purely anecdotal, of course, but my current method for tracking a new release of Firefox is when my Twitter feed lights up with complaints of add-on problems when the release is installed. That's a sign that there are still problems with this process.
It may be a tough nut to crack. According to Mozilla add-on team lead Justin Scott, "97% of add-ons compatible with Firefox 5 were still compatible with 6. And we're on track to launch Firefox 7 tomorrow with 99% compatibility from 6."
With compatibility in the high 90s, what's the problem? Scott continues:
"Our compatibility plan has two notable shortcomings: it doesn't work for add-ons with binary components and it doesn't work for add-ons not hosted on [addons.mozilla.org (AMO)]. The vast majority of add-ons don't contain binary components, which must be recompiled with every version of Firefox in order to continue working. And while we know a lot about add-ons that are hosted on AMO, we didn't know much about the other add-ons in Firefox's ecosystem."
After researching the enrich metadata in the add-ons for Firefox, Scott and his team learned that a staggering 75 percent of Firefox's 600 million add-ons were not hosted on AMO. That's 450 million add-ons getting tacked onto Firefox in the form of third-party bundling, for example. (Think search toolbars and Java Console, Scott highlighted.)
"While some of these add-ons are keeping up with our release compatibility, many use their own update mechanisms instead of the built-in update service that works with Firefox's compatibility checking, so in order to get a compatible add-on, you must update the third party software separately," Scott wrote.
Mozilla is working on this issue, as are others. Mike Kaply, the same fellow that touched off the enterprise argument with Dotzler last summer, posted an interesting approach for non-AMO add-on developers to better communicate with Mozilla's compatibility-checking tools back in June.
Looking at this from an outsider's perspective, I almost wonder if an app store framework might not be a better idea for Mozilla add-ons. Not something as closed up as Apple's model, mind you, but perhaps something a little more open, such as Android's multiple-market model. I realize that app stores are sort of against the grain of open deployment, but if the main product (in this case, Firefox) is really going to be rapid-release product, wouldn't it make sense from a compatibility and quality standpoint to get all add-ons coming into Firefox using the same method?
As it stands now, when these "outside" add-ons break, people aren't going to necessarily blame the add-on developer--they're going to blame Firefox for breaking something that worked for them just the other day.
Then there's the quality issue. While many of these add-ons are useful, I suspect a great many of them fall into the category of "crapware"--software that no one really needs that just takes up screen or processor resources. That's at best: I also suspect some of these add-ons are out-and-out spyware.
The quality issue is a tricky one, but I have often wondered about the "free range" mentality some of these add-on developers have. Yes, they are certainly within their rights to not want to conform to any one set of rules for their add-ons--that's a prevalent attitude in the FLOSS community. But how many of these developers are resisting a centralized approach because they know full well that in a user-reviewed system, their add-on would fall hopelessly short?
Again, I am not suggesting One Central Mozilla Add-on Store. There could be many apps stores, with their own rules of the road. The main requirement would be that add-ons would need to be sure to communicate compatibility and install the same way, no matter which store they were in.
Something to think about as Firefox plows on.
Read more of Brian Proffitt's Open for Discussion blog and follow the latest IT news at ITworld. Drop Brian a line or follow Brian on Twitter at @TheTechScribe. For the latest IT news, analysis and how-tos, follow ITworld on Twitter and Facebook.
Source:
