Every time I'm associated with a beta I'm reminded how weird the reactions can be about it. You can count on comments that the software isn't even ready for alpha, let alone beta. You can count on premonitions about the end of the world due to the horrible bugs and insufficient features. Finally, you can also count on people trying to extrapolate long term corporate strategy from small things, and go off into strange and sometimes entertaining directions that have little to do with reality.
Why is this?
What a beta is, what state you should expect the software to be in, and how much it is likely to change before release are not objective things that can or should be true for all releases and products. Some people make comments that they think there is one objective definition of what a beta is (or should be) and it is true about all products.
If the software project is so far along that there aren't any known bugs and all the features are completely done and baked... why would you release a beta? I would just ship it, because I'm done. Clearly doing a beta means you aren't done, there's got to be some reason to put it out there and spend the time and effort instead of, for instance, spending that time fixing bugs and/or adding features. For that matter, working on the next version.
You may not be done due to bugs, stability, or performance reasons. You may not be done due to feature completeness. But you aren't done, so the obvious question is: why put the product out there for criticism if you know you're not done?
One of the biggest reasons I've seen is that no matter how big your test team (which for most products is a lot smaller than ideal) and how much hardware you have available (which again is usually much less than you'd like) there is no way to realistically simulate all the things that real users will do with your software on all the hardware configurations possible with all the other software they might have installed on their machines. Getting the product out means that people can try it on real systems and try to do real stuff with it, which will find bugs you could have never found solely by relying on your own team.
In the course of trying to do real work they're going to find holes in your features and functionality, as well. If you get this feedback early enough you can get this fixed before putting the final version out, which can make all the difference between an interesting program with some good features and one that really solves problems in a deep way.
I think these are the most important reasons to do betas. Additionally they are marketing opportunities, allowing you to start people talking about the product and get a buzz going. This is at odds with the desire to get early feedback and find bugs, so the balance must be carefully managed. Do you want to show the warts in order to make the product better, or do you want to show something much more polished to generate buzz? How do you get to the point where it is more polished, and how dangerous is it to release something you considered polished but find out there are a large number of real world issues you didn't find because your testing was necessarily limited?
One balance is to do more limited pre-releases to iron out the kinks before doing a wide publicity aimed beta. There is still risk, the wider the release the more likely that obscure issues are going to be found, but there is a good chance that you'll find much of the low hanging fruit that might be the most embarrassing while gaining the harder to find data to improve the final released product.
