I’ve been thinking a lot about Firefox in the enterprise and I wanted to capture some of my thoughts. This two part article will first cover obstacles to enterprise adoption of Firefox (with some possible solutions) and then cover specific benefits to Firefox in the enterprise.
Before I get any complaints, I am aware that there are large enterprises that are already using Firefox (including IBM). I believe that most of these are supporting Firefox as a secondary browser as opposed to switching to Firefox as the primary browser. Also, I’d love to open up more discussion on this subject, so please comment and correct me if I’m wrong.
As Firefox gains marketshare, there comes a point where increasing that marketshare depends on the adoption of Firefox in large enterprises. This article investigates what type of issues arise when supporting Firefox in a large enterprise, and what can be done to solve those issues.
The primary areas I will address are:
- Release Lifecycle
- Service and Support
- Business Value
- Third Party Applications
- Intranet Applications
- Deployment issues
Simply put, the current Firefox policy of supporting prior versions of Firefox for six months after the next release is just too short, especially considering the time of year when new versions of Firefox are typically released. Many companies only deploy new software once or twice a year, and the process to get that software deployed takes many months.
I know of a company that deploys software once a year, in September. In order to be a part of that deployment, you have to start piloting your application in June. If this company wanted to move from Firefox 1.5 to Firefox 2, they would have had to pilot it in June, for deployment in September. This means that they would have had an unsupported browser for over five months.
In addition, Firefox so far has been released in the fourth quarter (Firefox 1 was release in November, Firefox 2 was released in October). If you work in IT, you know that new software does not get deployed in November, December, or even January. So three months of the six month Firefox support cycle was simply a wash.
Either Mozilla Corporation needs to step up and extend the lifecycle of Firefox to one year, or some enterprising company should take this opportunity to provide better release lifecycle for Firefox.
Service and Support
When a piece of software is an integral part of a company’s business, it is imperative that they have someone to call when they have problems. “Open a bug in bugzilla” or “we accept patches” are simply not good answers when companies are experiencing problems. Certainly companies can staff developers that can build and deploy custom versions of Firefox, but this is the exception, not the rule. In addition, companies that have their own internal help desk need training on how to support Firefox.
This problem is more difficult to solve. Mozilla’s role is not to provide one on one support for customers. This is, however, an excellent opportunity for someone to step in and provide enterprise level phone support for Firefox, as well as to create education modules to train internal help desks.
Every organization is in business to provide value to their customers. For a publicly traded company, it’s about shareholder value. For a nonprofit, it might be about reducing overhead so that more donations can go to their primary cause. Unfortunately, it is difficult to show that supporting two browsers or switching to a completely different browser adds business value.
While I don’t have a good solution to this problem, it is worth noting that, for many companies, the move to support Internet Explorer 7 will be just as much work as supporting Firefox. From that perspective, the best way to increase business value
would be to move towards an internal infrastructure that uses open standards so that dependencies on particular platforms are diminished. In addition, if a company ever wanted to move to a platform where Internet Explorer was not available, using open standards would make it easer to move.
Third Party Applications
When most of us surf the web, we don’t tend to find a lot of web pages that simply don’t work in Firefox. This problem has mostly been solved. Companies, however, use third party applications that may or may not work in Firefox. While the current version of a lot of these applications may work with Firefox, older versions of these applications are deployed in many companies with no plans to upgrade in the foreseeable future due to cost (see Business Value above).
There are a few ways to solve this problem. First off, third party application providers should provide free or low cost upgrades to companies that have software that doesn’t work with Firefox. Secondly, when purchasing third party applications, companies should ensure that the software they are purchasing uses open standards. Finally, application vendors should ensure they are using open standards to create their applications so they don’t lock their customers into a particular browser vendor.
Third party applications aren’t the only place where support for Firefox can be a problem. What tends to happen in companies is that internal applications get written, deployed, and then forgotten about. In addition, because it might take years to write an internal application, by the time it is deployed, it might be designed for an older browser. Fixing these applications can be some of the most difficult problems to solve, due to lack of funding and even lack of interest by the developers.
Your company should have policies in place to ensure that internal applications are written using open standards so that they don’t depend on a particular browser. In addition, when applications are created, it is imperative that funding be set aside so that if problems are encountered with a particular application in the future, that there is a way to get the problem fixed.
One of the main things I’ve tried to do in my job is help with deployment issues. In addition to working on the CCK, I’ve worked with some smaller entities to deploy Firefox using things like the Firefox Release Repackager. But these things simply aren’t enough. Companies already have existing deployment infrastructures using Tivoli or Microsoft Active Directory. In addition, the types of customizations that a lot of entities want to do are outside the scope of the CCK.
While there are third party solutions that provide a customized Firefox to use Active Directory and Microsoft installers, there needs to be more work in the community to make Active Directory support and Microsoft installers an integral part of Firefox. While Firefox developers do not want to make MSI the primary ship vehicle for Firefox, work could be done to make the MSI installer on par with the Nullsoft Installer. In addition, there needs to be more of an ecosystem around customizing Firefox for certain types of deployment.
So there you have it. Some quick thoughts on enterprise deployment. In the next installment, I’ll talk about the benefits of Firefox in the enterprise, and in particular some things we’ve found out inside IBM. As always, I’d love to here your thoughts, and if I’ve missed anything.