Deploying Firefox 2 within the Enterprise: Answering Some Questions

Some questions have already come up about the posts I’ve written, and rather than answering in comments or in a post at the end, I’d like to address some of them now. Note that I’m paraphrasing most of the questions.

Why would you need to build your own custom version of Firefox? Couldn’t you just customize the build that Mozilla produces?

There are a couple answers to this question.

Answer: Custom Fixes

There might be cases where a fix is needed for your enterprise that either will not make it into the source code fast enough, or will not be accepted at all.

Last year we had a problem with a buggy IBM printer driver that caused Firefox to crash printing certain web pages. The most problematic pages seemed to be IBM internal pages. Unfortunately, this particular driver was in use for just about every printer inside IBM. The fix for this problem was unfortunate: it involved putting some exception handling in Firefox to catch the printer driver crash. We weren’t sure it was going to make it into the source code fast enough to meet our needs, so we actually prepared to build a custom Firefox. Luckily we were able to get the fix in and we deployed the next Firefox 1.5 update quickly. But this could have certainly turned into a case where we needed to ship a custom version of Firefox.

You might run into similar cases where you might need a feature or fix that is not available in the version of Firefox you have deployed.

Answer: You Might Need to Extend Support Beyond what Mozilla Offers

A lot of people might not realize this, but the Mozilla Corporation policy is that they will only provide security fixes for software for six months after the release of the next major version. So for instance, Firefox 2 was released on October 24, 2006 so support for Firefox 1.5 will be discontinued on April 24, 2007.

For consumers, this might not be an issue, but for enterprises and educational institutions this can be a problem. Let’s start with educational institutions.

Check out this excellent comment from UK Web Focus. The problem is that educational institutions tend to deploy new software during the summer break. So Firefox 1.5 will be out of support before the spring semester is over. Things would have been even worse if Firefox 1.5 had been released in August or September.

But educational institutions are only part of the story. Let’s talk about the enterprise. I’ve worked with a number of companies deploying applications so what I’m going to talk about here are real world scenarios.

Scenario 1: Piloting and Testing takes six months or more

For a large enterprise to deploy a new web browser, there is a process that must be followed to ensure that the browser works with their internal infrastructure. Usually this involves the IT folk installing the browser locally and doing some initial testing, piloting the browser with some small group of people, and then eventually deploying the new web browser to the rest of their organization. In addition, if there are major changes to the browser (as there was with Firefox 2), there are other organizations that must be involved like the help desk or web application teams. The help desk will need to do things like rewrite support scripts or other training material. The web application teams will need to test the new browser with their applications. If either of these teams run into problems, this would delay the release of the new web browser to the entire organization.

As we mentioned before, Firefox 2 was released on October 24, 2006. If you are in a large organization like mine, you are aware that very little happens at the end of the year whether due to vacation or lack of funding. So if an enterprise were to start the process of deploying Firefox 2, it would not start until probably mid January. So essentially an enterprise has about three months to complete the process that I have detailed above. In my experience this process can take six months to a year.

Scenario 2: Deployment windows

In some large enterprises, there are “deployment windows.” That is to say specific times of the year when new software can be deployed. These deployment windows can be any time during the year, but experience has shown they they are typically in the fall and they are usually once a year or even once every two years.

Right away, you can see a problem. With a once a year deployment window, you will have at least six months where the browser is unsupported.

What can I do?

In theory, you could cherry pick security fixes from Firefox 2 security releases and backport them to Firefox to 1.5. This is clearly not an optimum solution.

Is there a good solution?

The fact is that life cycle for enterprise software needs to be one year at the minimum, two years preferred. If this is something that is important to you, you should at least let Mozilla Corporation know. This also might be a great business opportunity for some enterprising folk…

Why is the CCK a wizard? Why isn’t the information provided in your post a part of the CCK?

The Firefox CCK was designed to look and work exactly like the Netscape CCK. If you were to install the Netscape CCK, you would see that a lot of the text is even the same. The CCK is not a tool that is designed to be used every day. Most organizations would probably only use it once or twice a year. For that reason, it was designed to be minimalist. The CCK was a one man project (me) so I would certainly appreciate any help anyone wanted to provide in helping to maintain the CCK. The source code is available here.

Can I set preferences for extensions within the CCK?

I believe that if you set the preferences and then locked them in the CCK, they would not be overridden when the extension is installed. The problem has to do with load order. If you just set them in the CCK, when the extension is loaded, it overrides the preferences that were set by the CCK.

Bonus Question: What if I just want to rename the browser or change the branding? Do I have to build it?

I needed an excuse to plug my other extension, so here it is. If you ever need to rename Firefox for some reason (like for instance, to call it Iceweasel), I have creating an extension that specifically facilitates changing all the branding in the browser including the product name, the images in the about screen, and the icons. That extension is called Rebrand.

Our next installment is tomorrow, and we’ll talk about building the Firefox installer with our custom extensions.

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

3 thoughts on “Deploying Firefox 2 within the Enterprise: Answering Some Questions

  1. I see your point regarding custom fixes, but would it not have been better to solve the root cause of the problem (the printer driver) rather than work around it in Firefox anyway.

  2. > I see your point regarding custom fixes, but would it not have been better to
    > solve the root cause of the problem (the printer driver) rather than work
    > around it in Firefox anyway.

    Unfortunately it was much harder to get the print team to create a fix and deploy it. As a matter of fact, to this day, I still don’t think it is deployed. And unfortunately, that buggy driver was replicated to Dell printers, Lexmark printers, etc. so people outside IBM were seeing it as well.

    In the end, because we had a much better distribution mechanism (and less users to upgrade inside of IBM), it made sense to put the “fix” in Firefox.