Opinion: The public beta subverts the symbiotic relationship that should exist between a company and its customer.A few months ago I wrote a column about the instability of Google's applications. Google's apps and I weren't getting along that week.
My Gmail access was down for some inexplicable reason, Google Reader wasn't working properly, and a lot of folks were upset (and continue to be upset) about the performance of Google Analytics.
After that column, a few readers wrote to say that I didn't understand that Google's products were beta products. Looking back, I should have made it clearer that I understand that Google brandished the beta disclaimer.
So it's that disclaimer—whether used by Google or any other company—that I'm taking issue with today.
The vicissitudes of the public beta have been thoroughly discussed on the Web this year by Webloggers, columnists and reporters alike. I think 37Signals' Jason Fried put it best in when he e-mailed me to say: "Release your damn product, take responsibility for it and constantly improve it. The 'Public Beta' flag is a cover-your-ass mechanism that needs to go."
I couldn't agree more. So before we ring in the new year, I'd just like to say: In 2006, first thing we do, let's kill all the betas.
Who benefits from the beta?
The word beta is a disclaimer that, when used in an ideal scenario, says, "Hey, we're still working on this. If there are some glitches, our bad. Don't say we didn't warn you." Traditionally, the beta follows the alpha release, which is tested internally at the developer's office or lab. What are the benefits of releasing a beta product?
- Company gets early exposure
- Product gets traffic
- Company gets feedback on how the product works
- Consumer gets the use, usually free, of an online service
Who gets screwed?
Of the four benefits I listed, notice how only one of them applies to the consumer. Therein lies the biggest problem. The public beta, when taken advantage of, subverts the symbiotic relationship that should exist between a company and its customer. The only true beneficiary of a public beta is the company.
But the public beta continues to be popular because it's a tremendous way to generate early buzz and drive traffic.
The Internet in general, and the blogosphere specifically, rewards those who are first to market with an initial boost in interest. Witness the "debut" of the AJAX (Asynchronous JavaScript and XML) home page Eskobo.
After Michael Arrington linked to it from TechCrunch, I saw its name pop up on tech-related sites across the Net (including on Publish.com). But man, Eskobo wasn't ready for prime time. Half its features didn't work. And slapped up top, beside its logo, was the disclaimer "beta." In my mind, Eskobo isn't a real product. It's a link honeypot.
Of course, Eskobo is a worst-case scenario. Public betas can (and do) work as advertised. But there needs to be a trade-off. If companies are going to ask consumers to accept the unstable public beta as Internet praxis, then they need to offer something in return.
Some beta proponents argue that the free beta product is what's offered in return. Yes, that's a great start. But what about defining the length of the beta? That would signal that the company is committed to a development cycle and committed to its customers.
The changing development cycle
If a company cannot commit to ending a beta after a specific time period, then it is replacing the needs of the customer with the needs of its development team.
As most of us know, developers are increasingly making Web applications and shipping fewer shrink-wrapped copies of software. The beta, which used to be internal, has migrated to the always-on Web. Obviously, this is another big reason why the idea of the public beta has proliferated—developers are always adding features and fixing bugs and making mods.
Click here to read about the latest beta of Mozilla's Firefox browser.
Back in February, David Berlind made a great point on his blog: "I've yet to regularly use a piece of software (application or operating system), a Web site, or hardware that is bug-free. Indeed, all software is beta."
I agree. All software is beta. At least, to people who develop software. Software users, though, have a different set of expectations. And once software is released to the public, the public's expectations should trump the developer's creed of perpetual beta.
Dependencies, trust, and the offline standard
In her column on public betas, Businessweek's Sarah Lacy makes a great point: A product isn't beta if you've come to depend on it.
Lacy argues that e-mail is a mission-critical service that should not be a beta product. I agree, kinda. I think it's fine for Google to release Gmail in beta. The company made plain Gmail was a beta, and early adopters should have heeded that message.
But in light of the importance of e-mail, does Google have a responsibility to stabilize Gmail? Yes. Imagine if any other product development company released such widespread public betas. What if the entire 2006 Ford product line was a beta? What if your local supermarket was beta?
Should we have different levels of expectation for a Web application than we do for corporeal products and services? Why? Because software is always changing? Should we then retroactively slap a beta sticker on Google.com? If all software is beta, why not just do away with the term? It's been generalized into nothingness.
More often than not, the public beta is simply a banner that means "please lower your expectations." That's not the two-way Web, or Web 2.0, or whatever buzzword is popular this week. It's Web "As Is." And that sucks.
