I've been beta testing a lot of unfinished software products in the past years. Not surprisingly most of these were Microsoft products. (and mostly unknowingly also many products from other vendors…) Let's dive into the world of alphas, betas, release candidates and other test versions, because I suspect seemingly more people using beta software isn't just a result of Beta marketing; there are multiple factors at play.

Beta Usage

I think there are five main reasons why a lot of people use Beta software nowadays:

• It's everywhere nowadays
• Beta software is getting more exposure
• New software is mostly built on top of existing software
• Development times have increased
• Virtualization makes it easier to experiment

(I also think not all five reasons might apply to all beta software products.)

It's everywhere

Did you know that a lot of products from Google are still in beta development fase? If you look at Google Blog Search, Google Book Search, Google Video and even Google Mail you can clearly see the 'beta' thingy in each of these logos. And what to think of Joost, Corel WordPerfect Lightning and of course parts of the Live family of products? It's not just limited to 'big companies' though: Many Web 2.0 start-ups like GENi, Scrybe, GrandCentral, nsyght and many others prominently display the B word on their pages.

All these services and software are beta and some of us use (some of) them every day, like they consider them to be finalized products. They're not.

No wonder we don't get scared from the 'beta' word anymore – We're surrounded by it, we've come to love it (and in Microsoft terms: come to 'live' it) and we are made to believe using beta software is as easy, comfortable and hassle-free as the 'finalized' product.

Exposure

Back in the previous century it was considered 'a cool thing' to test unfinished software. You could brag to friends you were running a beta version of some new Windows version and only big companies had access to the beta bits to prepare them for the new technologies. I guess everyone wants to brag to their friends once in a while and every company wants to make its software ready for the next big product. It has become a way to differentiate between IT Professionals more than a way to differentiate between software manufacturers.

Let's look at the Windows Operating System. Windows 2000 Beta and Windows XP beta were only available to roughly 500.000 people. Windows Vista Beta 2 was available to millions of people in 2006. I feel Microsoft made a good decision there. Windows Vista was looked at closely by IT Pros, but also by customers in the TAP and RDP programs. At the same time Microsoft picked up on the many blogs and websites surrounding Windows Vista.

A newer form of "showing off" beta status was Microsoft's IIS7 Go Live initiative. It was an easy way. You could be part of a Beta incrowd, whilst you don't need a luminescent light bulb above your head in the form of a new revolutionary Web 2.0-style sociological experiment accompanied by start-up capital.

Evolution instead of revolution

Let's look at the situation most software manufacturers find themselves in. They have a good piece of software, a nice place in the market, customers know how to work with it and they've managed to eliminate most of the bugs. Of course they'd be stupid to re-engineer the whole piece and write all the code again. The risk of introducing new bugs, harming the reputation of the company and losing customers is just too high. Unless the current strategy or architecture of the software is really becoming a threat software will just evolve further.

Software users seem to know this and they receive help from IT Professionals. From Windows 9x or Windows NT4 to Windows 2000 is a revolution, from Windows 2000 to Windows XP is an evolutionary process. (looking at NT versions this makes even more sense)

If you'd know the next version of Windows is just Windows Vista with some new features you would find the risk of beta testing more acceptable in contrast to the situation where you'd know the project team for the new version of Windows is going to be lead by a Jim Allchin-like manager, which isn't scared of really changing the product to make it something.

Development time

We live in an age of complex technology. We have 24bit color screens instead of monochrome screens, calculators that rival the computing power of the early mainframes and use software, consisting of millions of lines of code.

Imagine a software company wants to make big changes to a software product. To make these changes the company will have to hire a lot of people (if these people are available for hire) or these changes will take a lot of time.

Looking at Windows Vista I saw a lot of people wanting to testdrive the new version of Windows, just because it took five years. They were still looking at the same Windows interface, while Mac enthusiasts worked with the spiffy new MacOS X environment.

Virtualization

Virtualization is useful for server consolidation. It's also widely used for testing purposes, because it allows to easily put a machine together to run a specific piece of software on. Various products from VMWare, Microsoft and Xen (among others) allow you to test something quickly without having to mess with physical hardware, physical installation media and space.

Developers use these products as well. As a tester you can expect most of the beta products to run smoothly on (at least one of) these virtualization platforms. Testing on the same platform as the developer provides a hassle-free beta experience most of the time: You don't have to worry about unsupported drivers or unsupported hardware. It'll all work out of the box.

Virtualization won't allow you to test anything though and your experience won't always be as painless as I described above. Jorge had a hard time getting certain Windows Vista builds to work on ESX. DirectX, 64-bit and Ubuntu are things you won't be able to experience in Virtual PC or Virtual Server guests.

Beta Marketing

Beta used to be a way to quietly test products amongst a defined universe of users before making them public. I guess marketing teams have adopted the B word and made it a marketing phrase.  Clearly 'Beta' got bombarded as a Web 2.0 buzzword. Buzzwords are fit for marketing purposes.

How can a technology developer benefit from using Beta exposure? I can think of five good reasons:

The Hype scenario

In marketing lingo 'Hyping' a product before release is called creating a pull-market for your product in an sensational way. When there's no-one actually 'working' with your stuff (Beta of course) creating a hype or buzz will be far more difficult: A hype tends to be coming from others places than just your marketing department. It's about enthusiasts getting excited by a concept (or not) and promoting it. What better way than 'leaking' some screenshots and then making a beta available to hype your technology?

The Exclusivity scenario

You can make the use of a product feel 'exclusive' by letting it get tried out while it isn't ready for the public, regardless of whether or not the beta is accessible to everyone. Exclusivity tends to create strong customer preference for a brand. Invite systems seems to be mandatory in this scenario.

The Complexity scenario

I can think of a lot of situations where things have to be tested "in the wild" by a lot of people. Service-Oriented Architecture and Microsoft's Hyper-V sure have the potential to create such situations. When you read along you'll find this scenario is closely tied to the quality scenario.

The Business scenario

Shareholder Value, Start-Up Capital and Market Relevance are three main keywords for businesses. These keywords might compel you to  show yourself to the outside world. A beta product might show what's coming, while still unfinished.

The Quality Scenario

Software testing costs money but plays a vital role in quality management. A beta program might provide you with free beta testers. On the other hand you can't expect a thorough or specific test by someone you're not paying… I think the only way to successfully engage in this scenario is to first hire some testers and make them perform specifically targeted quality tests before you do it publicly. Of course you need to keep a tester on staff to specifically test the enhancements you make according to public beta feedback.

The Perma-Beta scenario

When you have a product, but no way of making money from it or the inability to take responsibility for it, you can leave a product as a beta product permanently. This will stop complaints or at least give you a reason for not acting customer friendly when people complain.

One might argue Google's policy is a form of Perma-Beta.

Concluding

Beta is a marketing game. Both customers and technology developers seem to play it. Technology developers seem to be using "Beta Marketing" and customers seem to be falling for it since the reputation of Beta products has improved dramatically.

For a product to become hyped however a technology developer needs to make sure enthusiasts jump on their bandwagon. (besides having some strong Unique Buying Points)

Further reading

Wikipedia on Web 2.0
Beta as Marketing Tool
Welcome to the IIS 7.0 Go-Live Program!
Windows Server 2008 Virtualization and Consolidation
Jim Allchin, (Former) Co-President, Platforms & Services Division

Disclaimer Beta Software

The information on this webpage applies to software that was in testing phase but utilizable by experienced users by the time the webpage was written. This software has not been released for sale, distribution or usage for the general public. The information on this webpage and the beta software are provided "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.