Solving three different problems on the Enterprise Working Group?

(I raised this in the Enterprise Working Group (EWG) call this week, and it resonated strongly with some people. Therefore, I’m posting this out more widely to hopefully get more feedback.)

After all the recent discussions about “what enterprise users wanted”, I found myself wondering if we were all even attempting to solve the same problem, so I stepped back, and re-read *lots* of posts from different enterprises over the last few months.

I now believe Mozilla, and the enterprises in the Enterprise Working Group, are working to solve three overlapping but orthogonal problems.

1) Cost of verifying that a new version of Firefox is safe to deploy.
Some enterprises verify with a quick running of an ACID test. Some SaaS vendors verify by doing wider testing, and deploying bugfixes to their products. One complication for SaaS vendors is that end users may be running on newer versions of Firefox anyway, on non-enterprise machines. This can cause problems that make both the SaaS vendor, and Mozilla, look bad. We havent spent much time on this so far.

(I still wonder if we could design a testsuite compatibility test suites, in the same mindset as HTML5, JavaCompatibilityKit, etc that might help speed up this verification step?)

2) Cost of deploying a new version of Firefox to all supported users
Once an enterprise has verified a specific version of Firefox, how much effort does it take to deploy that new version onto all their machines/users. This discussion typically quickly focuses on MSI and similar technologies for doing widespread deployments, although there are some other options like an inhouse AUS or equiv. Regardless of the technology used, the idea here is to have a centralized way to move forward all users to a newer version of Firefox, without having to walk/drive/fly a human to every computer in order to manually do a new install. Sometimes this also includes discussions about silent updates.

3) Frequency of doing this all over again
The frequency of the Firefox release cadence directly impacts how often enterprises have to go back to do (1) and (2) all over again.

The verify+deploy work is typically so painful that most enterprises only do this for “new feature” releases, and not for “security only dot-releases”. For most enterprises, it seems that Mozilla’s cadence of “new feature” releases every 12-18-24 months was infrequent enough that the verify+deploy work was tolerable. However, Mozilla’s more frequent feature releases means more frequent cost of verification+deploying, which can become a significant business problem.

The ESR proposal is attempting to address this increased recurring cost and this is where most of the discussions have been taking place so far.

(It’s worth noting that everyone involved from Mozilla and different enterprises understands and agrees that Mozilla’s faster cadence of “new feature” releases is important for Mozilla to remain relevant in the browser marketplace.)

Just my thoughts, but I’d be curious to hear what others think.


8 thoughts on “Solving three different problems on the Enterprise Working Group?

  1. Congratulations. You have now reached step 0 in your journey from Moziliian to the land of Real World Users. Others lived here for many years. It’s about time someone from Mozilla started the journey you are undertaking.

  2. Hi,

    I just read your post and was wondering if it might be an idea for Mozilla to enable enterprises to host their own update server? That way the enterprises Firefox versions could have updates enabled and the deployment process would be shorter because once the new version is verified all that needs to be done is release it as an update onto the internal update server.

    Bes regards

  3. Re (2). I don’t see the actual delivering new executables to users desktop bit as that tricky. While I’m sure some people would benefit from pre-made MSIs etc, we’re used to delivering security updates widely and quickly for all sorts of software, and have infrastructure to do it.

    For me the deployment problem comes when it changes the UX, even in quite minor ways. We need to decide if and how the change needs to be communicated to users, if it requires training, and if it requires documentation updates. Enterprise users are quite frequently put off by changes to their interfaces, not all are sophisticated computer users away from work and many have learned particular tasks by rote. They need support if anything changes. Processes are often documented by screenshot walk-through and if the UI changes then the documentation is out of date. For example it seems likely that the file download interface will change in upcoming firefoxes. It’s certainly in need of improvement, but there are very many business process which include a file download, and they could all need documentation updates as a result.

    I didn’t see that covered in your list of problems, but it’s a noticeable burden with frequent updates.

    • hi JohnP;

      Thats a great observation – and you are totally correct.

      While I heard enterprises talking about deployment costs, I’d somehow understood that to be the cost of software install/upgrades. I never even thought of human retraining costs, or the costs of updating walk-through docs.

      I’ll have to find better words for this, but for now, I’ll make sure to say that “deployment” is made up a) software deployment costs and b) human retraining / updating doc costs.

      Sound ok to you?

  4. Its very important to have central deployment. This is major issue raised by enterprises. As far as SaaS is concerned its will break..How about something like compatibility mode ? SaaS can tell FF to switch rendering engine to LTS or vice-versa ? I think that would be the best option. SaaS people will have issues with rapid releases. So I think they will stick to supporting LTS. so normal user who is using SaaS on newer version of FF can switch rendering engine.

  5. Hi John,

    Your suggested wording is fine by me, I’ve no idea whether people generally consider it a separate category or a part of deployment, just thought it should be included somewhere in your useful breakdown.

    I’d also note that more frequent releases with incremental UX changes is not all bad. In many cases it could lead to people adapting gradually without really noticing, whereas a comparatively big jump as with 3.6 -> 4.0 would need explanation. Either way there is a cost to investigating and making these decisions, and a cost where documentation and induction/training needs changing.

    Like so many many of the issues caused by Firefox’s change in release practice, there is room for technical measures to lesson the burden; it’s possible to imagine systems which automate the creation of screenshots and their insertion into documentation, we just don’t have them in place.

  6. Hi JohnP,

    Most of the problems with adoption of new releases by end users comes down to couple of scenarios. Maybe the solution would be to try to identify the most common cases and to provide made by community short tutorials updated when necessary. This way enterprises UA teams could re-use them in their internal documentation (hopefully even updating them).
    It is not very effective that dozens technical writers do exactly the same work with every change. I suppose that such documentation should contain both source files (screenshots, text files, latex/odt documents) and end user files like pdf or html.
    What are chances – from your perspective – that such manual kits be used by enterprises, or even better they would take an active part in developing it?