A while back I asked a question about how companies deploy/update Firefox in the corporate environment. I got a fair amount of feedback on the issue. I wanted to post this a while back, but got sidetracked. Anyway here’s what I’ve put together after reading comments and emails about the topic.
Based on what I’ve read, and looking at where apps like Firefox and Thunderbird stand, I see a few possibilities to improve:
Provide MSI’s as a download
From what I’ve read, and some email’s, MSI’s seem to be the vehicle of choice for most looking to deploy an application because it’s fairly easy to use, and pretty common.
Better Documentation for Corporate Deployment
It seems part of the problem is corporate IT departments don’t see clear documentation on “how to”. A fix for this would be some good documentation on “recommended practices”. Some topics to discuss:
- How to disable auto update
- Prohibit installing extensions
- How to deploy updates with popular deployment tools and enterprise tools and technologies like Group Policy
- Discuss how the CCK could be helpful
Upgrade Recommendations
A big problem seems to be keeping things up to date. There are several complicated issues here. To discuss them briefly:
Policy Restrictions
In some cases, computers are locked down enough that auto update in Firefox won’t work since it can’t update files. This means an admin must interfere, and must know that they need to take some sort of action.
Internal Testing
Companies have strong testing policies in place because of internal apps that are business critical. As a result before something like a browser can be updated, it must be tested against these applications. How do we minimize the time from the release of the new version, to when a company actually deploys this. Obviously the less time involved, the better.
Update Notification
With auto-update disabled, how do companies know a new release has been issued? How can they easily keep up to speed, with low noise?
Solution
The first step has already been taken. Mozilla products have a very good versioning scheme and maintenance update release pattern. It’s also good that stable branches live for a while. This is essential for corporate deployments. It allows for some time between moving between versions (such as 1.0.x to 1.5.x). The release cycles work rather well.
There seems to be a need for an IT mailing list, that would notify IT professionals when a release reaches the RC (Release Candidate) stage, allowing them time to test the new version against their systems. Such notification should also contain changes made since the last release, but written in terms of “what to look for when testing” or “what impact these changes could have” (for example a change in how plugins are loaded/handled, requiring testing where Java applets are embedded in web pages). By sending these notifications first during the RC stage, it would allow for some time to do testing, and quicker deployment once the release is official. This is important in the case of security bugs being fixed, when exploits could quickly follow an announcement. The low noise of the mailing list would ensure IT professionals get notifications they need.
Conclusion
I’m curious how these proposals would work for IT departments, from what I’ve read and feedback I’ve received I believe this would allow for much easier adoption, without adding too much of a burden.