enterprise

Supporting enterprise deployments has always been challenging for Mozilla (and for enterprise deployers), but we’ve nonetheless had some success; one Forrester study from 2010 indicated that Firefox has 20% or more market share within whatever they consider to be enterprises. That success has involved assistance from enterprise IT and OS vendors, both to represent their needs and to contribute actual work. If we want to expand on that success, then we will need to push farther ahead still; we need to be humble enough to know that we need help both understanding and doing.

what do enterprises need?

To my mind, there are two different elements at play here: supporting enterprise users, and supporting enterprise IT.

Enterprise users ask for Firefox to operate fully in their environment. Examples of things that fit in this category include NTLM, proxy auto-discovery, SOCKS proxies, running on Windows XP, and smart card integration.

Enterprise IT ask for a pretty different set of things, though they’re sometimes also the ones who present their users’ requests. Requests include deployment tools like MSI packaging, non-admin updating, preventing updating, pre-installing extensions, filtering/vetting/preventing extension installation and update, control over user settings via things like Group Policy, running quickly from a network share. There are probably many more, since I am mostly inferring now, and details like “control what exactly via GPO?” contain many devils. One proposal was to just provide support for all the knobs that IE (then 7) supported; when I saw that one of the knobs was to disable tabbed browsing, I think I used the word “unlikely”.

I don’t know how much of the enterprise IT checklist is necessary and how much is desirable. Similarly, I don’t know where the value curve and the difficulty curve cross, and it’s been very difficult to find out in detail.

when do enterprises need it?

Enterprise IT and internal app owners (but I think not very many enterprise users) also need varying amounts of time to absorb new versions of software into their environments. I’ve heard tell of 18 month cycles for that sort of thing, which boggles my mind a bit, and makes me weep for the people who are spending a year and a half doing that validation. Adapting to a world where you can get 4-8 browser updates in a year will be challenging for some organizations, though in truth they’ve already been in that world for some time: 3.6.4 with out-of-process plugins on Windows was probably a bigger content-compatibility risk than going from Firefox 4 to Firefox 5.

Chrome and Firefox both now use major version numbers to indicate “checkpoint that we pushed to our users”, rather than a specific amount of nature of product change. Again, though, we’ve been in that grey area for some time, with 3/3.5/3.6 being minor-with-major-characteristics sort of releases.

Our policy prior to FF5 was that we supported releases for a maximum of 6 months after the next release. Some Linux distributors needed to support their customers for longer, and weren’t (yet?) comfortable with bumping along to the next “major”; a couple of them got together and took responsibility for backporting security patches to the branches in question. If an “enterprise-friendly” lifecycle is needed, then that would be one way for enterprises to share the load of supporting their community’s unusual-at-the-scale-of-the-web needs.

why is this so hard?

One aspect is that Mozilla is mostly not composed of enterprise IT staff. This means that we rely on prospective deployers to tell us what their specific needs are, and hopefully to contribute help in meeting them. We’ve tried on a few occasions to collect this information — what sets of features would lead to which deployments with what user impact? — but have had a lot of trouble getting that information into our product planning in a usable way. A surprising (to me) number of institutions will not talk on the record about what they need, which makes it pretty hard for them to join a community conversation about what is worth investing in, and what the results are likely to be.

how can we make progress?

As I mentioned above, we’ve made some slightly successful attempts in the past to engage with enterprise representatives to identify the specific things that are barriers to their deployments. If enterprise deployments will have meaningful impact on the future direction of the web then we need to try another tactic. I don’t know what that is, but we are hearing more about enterprise needs now than ever before, so we have a new opportunity to figure it out.

(People like to point at the long, ugly tail of IE6 as an example of why we should want to make it easy for an administrator to deploy Firefox. Yet administrative ease is not enough, as those on IE6 didn’t even move to IE7 or IE8, which had all the administrative bells and whistles imaginable.)

We would also have benefitted from better communication about the release and update model, and what version numbers now mean (basically nothing). That would have given enterprises an opportunity to involve themselves in the process much earlier, and probably won us some advice about how to explain things even better.

To be successful, I think we’re also going to need enterprises to be more than just consumers of the software and tools. We need to build a framework for enterprises to contribute to the things they care about, and we need for enterprises to make contributions.

Enterprises may also need to change how they think about software rollout, if they want to keep pace with browser development and the evolution of the web platform. This is similar to managing the update cycle of a hosted application like Google Apps or Office 365, which could help the conversation. Some organizations will not be able to adapt, or not willing. If an organization stays on Debian stable for half a decade, they are just going to be left behind by basically all modern software. For less-severe cases, though, there is likely some meeting in the middle that’s possible. It could even lead to more agile deployment of their whole software stack, and more productive and happy users because of it!

Jay has written about this as well, and we’ll post more as we get set up for those conversations.

10 comments to “enterprise”

  1. Ben Basson
    entered 28 June 2011 @ 12:36 pm

    It seems to me that one key way both Mozilla and Google could support enterprise IT is to adopt the same policy as Ubuntu and have Long Term Support (LTS) releases.

    Yes, this means an overhead in back-porting security fixes to an older branch, but there’s literally no other way you’re going to see enterprise adoption without either doing this, or having a slower release schedule as before (which even then is pretty rapid for enterprise).

  2. sieciobywatel
    entered 28 June 2011 @ 2:12 pm

    Are there really regular and corporate users such distinct target groups? I would rather say that in many cases these are the same people. By making it easier for enterprises to adopt to the new release cycle, Mozilla is giving regular users chance to be able to use Firefox at work as well. That’s more fair view on this issue IMHO.

    What I also miss in this conversation is point of view of small business, who doesn’t necessarily have in-house IT staff to deploy updates, relying on outsourcing or just knowledge of more tech-savvy employees. I understand why they choose IE (which just updates with Windows Update) over Firefox. In company with dozen of employees updating every six weeks is additional trouble. There are also educational institutions where updating all machines is often done by hand, given their IT staff is usually underemployed and more focused on just keeping network going (that’s my personal experience) and handling unusual pupils activity…

    Last but not least there are developers. The more IE domination in companies, the higher chance that technologies like “native HTML” gain friction in enterprise. Which results in more juice flowing in this direction instead of real Open Web technologies. That’s rather not what Mozilla would like to see, isn’t it?

    Thus all this enterprise issue is not just about big corporations. It would be great if all sides kept this in mind.

  3. Simon
    entered 28 June 2011 @ 6:49 pm

    It’s not just that it takes time to absorb new versions – it’s also that enterprise customers don’t upgrade anything unless it’s either approaching end-of-life, or if the new version has some compelling new features that make it worth the cost of an upgrade cycle. Which is why some of the customers I deal with are only now in the process of upgrading to IE8. Yes, 8 – because that’s the latest version supported on XP, and they’re not yet willing to upgrade desktops.

    As to the 18 month cycles, that does seem steep, but consider that for something like a browser, they need confidence that the new version will work for all of the web apps they run. Some of those apps are maintained internally, so they need internal resources available to test and fix problems. And some of them are external, which means they need to coordinate with an external vendor – the vendor then has to go through the same process, and it might take a few months before they can start (they’re busy with other clients too). The vendor then needs to release the new fixed and certified version, which might be the next bi-annual release. And the client then needs to test that, and get it into production. Depending on the scope of the release, doing so might require waiting for the next long weekend to schedule an outage.

    Short version is, large businesses operate very differently from either small businesses, or regular home users. Some of that’s just slow management, but a lot of it is unavoidable in terms of risk management – if they put an untested patch in and it prevents a thousand people in a call-center from answering the phones for a day, that’s expensive. And not only expensive, it’s bad PR when your customers start complaining about how hard it is to get answers. Enterprise customers are very risk averse because of the amount at stake.

  4. Francisco
    entered 29 June 2011 @ 1:36 am

    What we need for starters is something really simple:

    when there’s a change that will break things in the enterprise (read: disabling remote XUL, no more security updates for current major versions…) make a proper announcement in advance. Let me bold that: clearly, properly announce a mess is coming for IT, and soon enough for IT staff not to endure sudden change.

    Not just a blog post, bugzilla comment or mailing list message prior to the break.

    Read bug 546857 (Drop support for XUL on web sites (remote XUL)) for how not to do things. The developer page showed no warning until the complaints in that bug.

  5. Steve
    entered 29 June 2011 @ 3:25 am

    As someone who has to use IE to deal with in-enterprise sites, I know the harsh truth: if IT managed FireFox, it’d be stuck on version 1.5.

    That said, enterprises do need to move beyond IE, and ideally replace Acroread with something secure. Saying “Enterprises must stick to IE” means “Enterprises only need to write webapps that work with IE”, which becomes “Enterprises only need to write webapps that work on windows”. Inflexible and wrong.

    Firefox could adopt the LTS model: security backports, no new features, and 3.6.x could become that version. As for the IT-admin features, there’s a good answer there: please, help implement and test them!

  6. entered 29 June 2011 @ 4:07 am

    A better mechanism for announcing strategy changes is also needed. Lots of people were taken back by the decision to EOL Fx4 with the release of Fx4 as they simply didn’t know that was the plan. I’ve seen several responses to the effect that “all our discussions are done in the open, so there’s no excuse” – but that’s exactly the problem.

    With discussions spread between newsgroups, blogs, planet and bugzilla (and possibly others), there’s just too much open discussion for most IT personnel to follow – given that it’s not their main concern. It’s hard to hear the important announcements over the murmuring of the crowd. More closed companies don’t have this problem, because it’s only the important messages that are allowed to escape.

    I’m not sure what the right strategy is, but official press releases, and perhaps an announcements mailing list would help. And timeliness is vital. Announcing a change of policy that will take effect in three months won’t help IT departments who are on a 12 month cycle – the more notice, the better.

  7. entered 29 June 2011 @ 6:03 am

    s/release of Fx4/release of Fx5/

  8. Chris
    entered 30 June 2011 @ 12:53 am

    Thing is, as an admin I can’t afford to put lots of effort into an application that changes every six weeks. I’m hardly done with testing and packaging and then it’s “back to the drawing board” again. OK, I’m stretching my point a bit here but in the end I don’t mind Mozilla’s patching policy but AFAIK they initiated their new schedule in order to get more new features out into the public.

    IT pros, on the other hand, prefer rock-solid, proven and reliable software. In this respect we’re a bit like NASA: We can do without most of the cool new features since we follow best practices which tell us to wait and see instead of jumping onto the bandwagon.

    From a professional point of view I can do without Panorama, the new addons manager, Firefox Sync and lots of other stuff since the release of –say– Fx 3.6. Personally, though, I encouraged all of my friends and family as well as lots of my colleagues to make Firefox their primary web browser because I believe in it.

    What I as an admin need and want is a highly reliable, secure, easily deployable as well as customizable, fast and rock-solid browser with as low a footprint as possible that behaves like a work horse.

  9. entered 2 July 2011 @ 11:44 am

    [...] of enterprise IT staff,” Mike Shaver, vice president of Mozilla’s technical strategy, wrote in a June 28 posting on his blog. “This means that we rely on prospective deployers to tell us what their specific needs are, and [...]

  10. rpr
    entered 4 July 2011 @ 9:39 am

    Maybe most users in many companies don’t need “the most modern software”, but just solid software which works properly. And probably the % of enterprise IT staff that knows this is much larger than the % of enterprise users that knows it.

    Don’t forget that we are talking about browsing the web, one of the human activities that requires a lowest level of thinking.

    A Debian stable user (in fact, I keep some oldstable repositories in order to avoid thunderbird 3 and stay at version 2).