eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Guess what? Ive been given the opportunity to try out this new, cutting-edge car design. The car includes all kinds of new features for automatic pilot, collision avoidance and speed control. The auto manufacturer has quietly implied that this car is really just for testing purposes and that I shouldnt take it off a controlled course, but whats the fun in that?
Nope, I cant wait to get this baby out on the open road and see how it handles the busy, fast and often crazy Boston commute. I mean, whats the worst that could happen, outside of the new features failing and causing an accident? I mean, they wouldnt have let me use the car if it wasnt ready, right?
Of course, I dont really have access to such a new car, and, if I did, I probably wouldnt take it off of a track. But, in the software world, people have no problem with doing the equivalent. A piece of beta—or often even alpha—software is released to the public, and people load it onto their systems without a care. Then the same people are indignant when this admittedly incomplete software causes problems with their systems—problems that are often difficult to recover from.
I and the other product reviewers here at eWEEK Labs often use beta versions of applications. Of the thousands of betas Ive tried in my time here, I can count on one hand the number of times I thought beta code was suitable for general use. (And, in all of these cases, this beta code was close to being a release candidate.)
Users do deserve some blame for naively sticking beta code on their important everyday systems, but the lions share of the blame for the overuse of betas goes to the vendors. Many vendors long ago stopped using beta code for its original purpose—as a testing and QA mechanism—and have come to regard it as just another marketing tool.
I see it all the time: A beta of a product comes out, and the vendor very quietly states that the beta is really just for “developers” or “serious testers.” At the same time, the vendor is doing a full-on press to get news out about the beta and is making a prominent download link available on its Web site. With this kind of mixed message, its no surprise that a lot of users who probably shouldnt use the beta will decide to give it a shot anyway.
It wasnt always this way. Not that long ago, most users avoided beta in the same way a diner avoided uncooked chicken. Back then, betas really were intended for developers and advanced users.
I think this changed, along with many other things, during the rise of Netscape. Back in the mid-90s, Netscape was very aggressive about getting betas of its browser in the hands of as many users as possible. Other vendors quickly learned the value of easily accessible beta code, both in terms of marketing and sales, as well as causing FUD about competing products.
All this has led to the current state of software, where, in many cases, its hard to tell if a product is actually shipping or in beta. Some vendors release products as beta, leave them as beta for a long period of time and fully expect regular users to deploy the beta code. Google is a prime example.
Adding to the problem is the often-shoddy quality of so-called shipping code. To a large number of savvy users, a shipping product is essentially beta until the first patch or .01 release comes out.
I really dont expect the vendors to stop pushing their betas onto a naive public, but I do think we need to come up with a way to make users more cautious about beta code. I think part of the problem is the word “beta” itself; I mean, its just a Greek letter.
We need to come up with another word to describe nonrelease code—such as “unfinished” or “incomplete.” Basically, it has to be something that tells the prospective user, “This is not ready to use.” “Broken” might be the most accurate term, but I dont expect that to fly.
How about “uncooked”? Lets see: “Microsoft today released an uncooked version of its upcoming Office suite.”
Works for me.
Labs Director Jim Rapoza can be reached at [email protected].