The site uses cookies that you may not want. Continued use means acceptance. For more information see our privacy policy.

Firefox 5 & New Release Velocity

There’s been a lot of discussion since Firefox 5 was released about the downsides of the new release cycle. There are a number of things that can be done to improve the situation.

Firefox 5 was released this past week, and it’s raised a lot of concerns.  The two biggest (discounting people who care about version numbers) are enterprise support and add-on compatibility.

Enterprise Deployment

Enterprise Information Technology departments go through a lot to keep up with the computing environments that their institutions rely on.  They are one of the major workhorses of the economy and will remain so for the foreseeable future.

To deploy something like a web browser, they must test the browser rigorously to ensure that it meets their needs without introducing any new problems.  They must also spend time educating their users so that users can make the best use of the technology without being stuck on use issues.

The concern raised by the new release cycles is that enterprises will not have adequate time to fully vet the releases, and that coupled with the loss of support for old versions makes the future of Firefox in the enterprise shaky at best.

Bugs in the Enterprise

The first issue worth considering is whether some of the hurdles that they face in deploying a more rapidly evolving piece of software represent problems in their own processes.  This is undoubtedly true for some enterprises, and third parties should not bend over backwards to work around bugs with the end-user unless they are being directly compensated to do so.

Anecdotally, the web developers that charge extra for IE 6 support fit the bill for working around the institutional bugs.

By deciding to fix their own internal bugs, they can already be better off, even without a better browser.  But they can also be proactive.

Going Along for the Ride

In addition to fixing their own internal bugs, the enterprise should look at the new release cycles objectively and use the differences in how the browser is progressing to their own advantage.  That means keeping a subset of users on the Beta channel.

That accomplishes two tasks:

  1. They keep up-to-date on the changes coming that impact them directly, including things like packaging changes.
  2. They keep up-to-date with changes impacting users, including educational needs and bugs in their intrawebs.

So the enterprise can improve their own deployment strategy, but they can also choose to be more involved with browser development itself.

Building Bridges

The enterprise has a choice to partner with the community and with other enterprises to build the tools and make the changes to the browser that better-enable their deployments.

In the past there have been efforts to create such tools, but many have gone into disuse over time and would need substantial rekindling.  It’s hard to blame Mozilla for that, when the tools were made by third parties that wanted to build the effort, but if the community gathers around new tools, it’s conceivable that some level of support can be had from Mozilla.

The other side of this is fixing the bug in the Windows world, whereby everyone is on her own to package such software.  If I ran an IT department on any of the Linux distributions, I would have most of my work done for me by virtue of existing packages to enhance or modify.

Indeed, the brilliance of the distribution model that Linux represents enables me to download any of the free software on my computer right now, make a few changes, and then have a working package with my changes in place.

The enterprises can choose to go down this path and build tools that will enhance Firefox deployment, as well as other deployments in their futures.

Oops, Add-ons

The other big issue with the new cycles is with add-ons.  Mozilla wants some users on the pre-stable channels, but it’s hard to justify giving up extensions to do so.

The good news is that the folks that work on the infrastructure of the add-ons site, Mozilla: Add-ons are working to improve things already.

The better news is that add-on authors have the opportunity to upkeep their add-ons more easily, as the differences between browser versions are less steep (though more frequent).

But a little more can be done.  One change worth considering is the ability to inform users via the add-ons manager, what versions their current add-ons are compatible with.

Another would be some kind of channel adviser.  This would let them get a recommendation based on their installed add-ons, for which channels suit them.  If their add-ons aren’t updated frequently enough, they would be told that they might be better off not going too close to the bleeding edge.