Firefox is an open source and free web browser made by the Mozilla project team. The Mozilla project started years ago when Netscape decided to make their browser open source, after losing considerable market share to Microsoft's Internet Explorer.

Firefox is now closing in on a very important 1.0 release, signalling it's maturity not only to regular users but also to corporations looking for a better and more secure web browser. To increase the adoption of Firefox, several marketing initiatives have been put into place by the Mozilla project to generate buzz.

One of them has been SpreadFireFox, which had a goal of one million downloads of Firefox in ten days. In just over four days, they have already reached that goal and are now aiming for two million.

What's interesting about this marketing push is that this release of Firefox is not 1.0, it's 1.0 Preview Release (some people prefer to call it the 0.10 Preview Release). Why would the Mozilla team encourage widespread adoption of software that wasn't "1.0 stable"? From a release engineering and project management perspective, this is a very good question.

Release engineering (sometimes called RELENG or just RE) is planning for software releases, making the releases (often as installers) that people download, creating and using tools to help them with release processes and monitoring the general health of the project. RE is the single release point of the project, and all of the bits of the software have to go through that team.

The project manager (PM) needs to work with the RE team to make a release schedule that the RE team uses to plan builds and releases culminating in a final high quality release. Often at the end of a development cycle, like Firefox reaching 1.0, several test releases are issued. Sometimes they are called release candidates (RC) or other names.

If you check out the Mozilla project roadmap page, you'll see the milestone schedule near the bottom. 1.0 PR is actually before the RCs in this schedule, meaning that RE has planned a lot more time for testing and code stabilization before the final 1.0 release. There's a big Firefox marketing push is going on right now, so what gives?

It's very possible that the Mozilla team is increasing adoption early to find more bugs before the 1.0 release. There's an automatic bug reporting tool within Firefox that collects stack traces when errors occur. With more people using the product, they'll find more issues with it and be able to fix these issues in time for 1.0.

They'll also be able to get Firefox on a lot of different configurations. This is really important, because they can verify that Firefox does not conflict with applications that users are already using.

The risk they are taking is that if people have big problems with Firefox they could be completely turned off of it. Why would they use a buggy browser when they think IE works fine? They probably already think there is no reason to switch. They don't need Firefox to give them a reason to switch back to IE. Firefox usually doesn't have these quality problems though -- updates are usually for security problems or new features, not major defects.

I think this has a lot to do with the fact that Firefox is open source and many people are interested in the project. In order to get the kind of quality that Firefox enjoys, you need to have a lot of hackers looking at code and a good solid review process like the Mozilla team. Closed-source projects do not have an army of code auditors so they need better formal testing, like unit testing and a quality assurance (QA) team, to compensate.

When you have a high quality product like Firefox it makes sense to increase the number of people using and testing it before a major release. If your product were lower quality and you needed much more testing, you'd be taking a big chance that people would never use your product again because they ran into problems. Even though you might need a lot of testing on a lower quality project, you shouldn't try to get more end users. You should try to improve quality yourself and/or recruit testers that know the product is buggy. It would be a bad idea to displease users with a buggy product.

Is the Mozilla team taking a big risk increasing adoption this early? I don't think so. The quality of Firefox has always been quite high so they shouldn't run into too many quality problems. They will gain much more by increasing the adoption of their product and tweaking it before 1.0.

It really pays to keep your project in a high quality state all of the time with testing (or in Firefox's case, a lot of peer review). You can give it to any one at any time and it will just work and that's a great feeling. Having a high quality project also encourages high quality development, like the broken window theory talks about.

Go Firefox go.

update: I forgot to mention that release engineering teams can use processes like continuous integration (CI) to spot broken windows in the project as early as possible.

The CI process needs the right tools to work well, not just a compiler. You need a good unit testing framework, like JUnit, and a good code coverage analysis tool like jcoverage will help you find areas that haven't been haven't been tested well and are more likely to have defects. Other testing tools can also be used.

This is part of monitoring the health of the project, and it's the responsibility of RE and the project manager to ultimately ensure that the project is healthy.

It might seem as though the developers are working in a highly controlled way, but as PM it's your job to convince them that it's for the good of the project that it's monitored like this. There's still a lot of freedom for developers to do what they need to do, so long as they don't damage the project doing it. In fact because they can see if they break something after they take a risk, they have more freedom to take those risks.