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.

old school

In 1998, a documentary team followed the adventure of releasing the first Mozilla source code. The resulting blockbuster was called “Code Rush”, and features Stuart Parmenter in his breakout role. A pretty fun little movie, and it does a decent job of capturing the energy and challenges of “Project 3/31″.

Or so I’ve been told. Though I was of course devoting myself utterly to the project at the time, and appear on screen in at least one key scene, I’ve never actually seen Code Rush. I mean, I know how it ends, right?

So today, eight-plus years later, I’m with Chris Beard at the Harvard Business School, for the inaugural presentation of a case study about the launch of Firefox 1.0 and subsequent creation of the Mozilla Corporation. As part of the presentation, the professor (Siobhan O’Mahony, whose class I quite enjoyed observing, I should say) played a clip of Code Rush showing the actual source-code push and announcement by Jim Barksdale.

I have to say that I was pretty affected by it. Might even have been a tear welling, though some of that could have been my headache. I looked so young, and had such bad hair, but it truly was an amazing opportunity, and I was so ridiculously lucky to have been able to be a part of it. Still am, really.

This session, part of an Executive Education programme, was extremely interesting in a number of ways, and I might write more about them later, if things line up correctly. I was very grateful for the opportunity to sit in a room with 80+ CIO/CTO/VP folk from all around the world and a wide range of industries, discussing their perspectives on open source and Firefox. Enterprise suitability is of course a very interesting topic to these folks, and was to me as well. By no means does such a conversation produce an all-triumphing Truth about what enterprises want or need, but I was certainly surprised by how nuanced many of the positions were. We often abstract “the enterprise” away into some prototypical administrator focused on group policy and deployment capabilities, but there are a lot of other strategic issues in play, many of which are related more to the long-term effects of our project than to specifics of the product itself. (I don’t mean to tease, I’m just not sure what the norm is for sharing the details of these sessions.)

It’s definitely flattering — personally and als on behalf of the project, if you will — to be invited to participate in such a presentation and exploration. Another opportunity for which to consider myself quite fortunate.

(I’d link to appropriate things here, but it’s hard to dig them up from my Blackberry, so I’ll have to go back and edit them in later.) [tags]mozilla, harvard, code rush, netscape, pavlov, enterprise[/tags]