Despite the widely held belief that rapid release spells the death of Firefox in the enterprise, I still believe that its a blessing in disguise.
Enterprise apps have been absurdly brittle for years. This in and of itself is a huge risk, but beyond that, its a trap and a money pit. By passing problems down the line we might see lower costs here and now, but in reality we just wrote a whole book of blank checks that will eventually get cashed in one at a time.
Rapid release introduces change into Firefox at a rate that seems staggering, especially to IT departments that are already gunshy about changes from dealing with brittleness all the time.
The only answer to this kind of volatility is to build more robust applications, and to rely on standards rather than release numbers. You see, standards are a sort of contract with the future – you may not know what direction the browser world will take, but in 5 years its a safe bet that the html5 family of technologies will still be there, and that a site using them will still function more or less as intended.
Besides needing to test applications for compatibility though, there are other issues, as Mike Kaply points out. Documentation has to be updated, sometimes including a lot of screenshots. Support staff may have to be trained. Deployment plans have to be developed.
These aren’t minor problems, and I totally agree it’s a concern. There are a few possible solutions already there, and enterprises have no further to look than Mozilla’s own development and QA processes for answers. You see, these aren’t new problems, Mozilla had to address them to even be able to implement rapid release.
Mozilla has a much smaller budget than many enterprise IT departments, but they have a widely used product, that’s used in an environment that’s anything but heterogeneous. The “tier 1”, or fully supported operating systems include at least 5 different versions of Windows, numerous Linux distributions, and 3 major version of MacOS X. Mozilla also has community support for as many as several dozen other platforms to stay busy – including Solaris, FreeBSD, and OpenBSD, and an emerging mobile effort using the same codebase to support Android and Maemo users.
How do they do that kind of testing within the short time tables of rapid release? Automated testing is a large part of it, but here are some highlights.
The QA process starts with the developers – strict code review requirements, and a culture that chastises developers for “breaking the tree” with code that fails tests. As soon as code is checked in to version control, automated tests start to fire off, with builds for every platform triggering. As soon as a build finishes, automated tests are triggered to assess basic functionality, insure regressions don’t return, and makes sure performance doesn’t suffer.
These tests are just a start, tens of thousands of users follow nightly builds and report bugs. The QA team performs verifications as bugs are fixed to validate the fixes. The QA team also performs more automated tests. Both manual and automated tests are crowdsourced also, through Litmus, and MozMill Crowd.
As each version moves closer to release through the Aurora and Beta stages, testing efforts become more intense, and the number of users on early versions increases dramatically.
Now, how this applies to the enterprise is that there is no reason why enterprise adopters can’t benefit from the same automation that Mozilla uses – in fact, I’d say by now the Mozilla QA team are automation experts.
MozMill is a good tool to drive automated testing of Firefox itself. Selenium is good to drive automated tests of your web applications themselves. Litmus can be used to drive and organize your manual testing process for both new versions of Firefox and your applications themselves.
MozMill could probably be easily adapted to being used for documentation purposes too – scripting all the dialogs and dropping screenshots as it goes would make it possible to update screenshots very quickly, and would also validate your documents – documentation probably doesn’t need to be changed until the documentation screenshot scripts fail.
Training is still an issue, but it doesn’t have to be a big issue. The benefit of small, but frequent changes is that the user impact will also be small, so training can just focus on the highlights of the changes.
As it stands now, enterprises will have to start their testing at the moment that a new version enters beta to get 6 weeks of testing time. While this should be enough, that still leaves one major enterprise need – a backout plan. Right now, they don’t have it unless they deploy at beta. That’s understandably unacceptable. N+1 might be realistic for security support for Mozilla, but just as enterprises have a fear of change, Mozilla has a fear of LTS becoming “the version that won’t go away”, as happened with Internet Explorer 6. Remember that Mozilla’s mission isn’t market share or necessarily to push a browser – it’s to push open web standards forward. Given this mission, having the web be stuck at a particular level of technology goes against everything they stand for.
Hopefully, the rift between the enterprise and Mozilla will work out, and it’s good to see the Enterprise Working Group back on the radar, but it’s going to take compromises and ongoing effort on both ends to make this work. Fortunately, being an open source project, enterprise customers don’t just have to be customers – they can be developers as well – and hopefully this encourages them to contribute the resources Firefox needs for more enterprise adoption.