The web of today is characterized by the “Endless Beta”, a new marketing rule stating that any product worthy of our attention will bear a “Beta” tag for years after its introduction. Flickr is still in “Beta”, after being bought! by Yahoo! and Google counts more Beta-enabled services than it sports Os in its iconic logo.
The theory is very seductive: by keeping a product malleable enough until the last minute, a company can closely answer the needs of customers and polish any rough edges they may find during the first weeks of public use. A Beta program also suggests openness, breaking free from the monolithic corporate procedures of yesterday and implies your technology is so cool, so new, so wonderful you cannot get it just right the first time — but it doesn’t really matter.
Up to a certain extent, I agree with all that and I value public Betas — they are an integral part of any large scale testing process. Customer feedback is important and public Betas are the best way to solicit it, especially when the product already works smoothly and that the “Beta” side of it is reduced to a tag underneath (or above for the most innovative companies) the left-aligned logo.
There is however something deeply wrong about never finishing a product and, in the end, I feel it is insulting to consumers. We as consumers are not Beta testers. If we are paying for a service, we expect it to work and be supported. Beta testers, quality assurance people perform an essential work in the software world and nothing could really exist without them. They are however a very distinct group from consumers: whenever I Beta test something, be it my own software or someone else’s, I expect things to break, explode or melt at any moment. I backup, backup, backup, until the mere mention of the word makes me break out in an unsightly rash, I spend my time filling bug tickets and reports. Then, through some magical process called Quality Assurance, the company decides the software is ready to use and I install it on my main machine. Backup continues, attention stays high, but I can now be confident that an application is stable enough to take me through the day — at least theoretically.
That is all very well but neither Google Maps nor Flickr are a messy pulp I hear you say. They are usable day-to-day. Exactly, I couldn’t agree more. And because of that, these are not “Betas”, they may be “version 1 something” but they are not Betas — and for a very good reason: no company could, for simple legal reasons, afford to put a truly Beta product out there. They don’t ask real Beta testers to sign 20 pages-long waivers of liability for nothing. So, what are we supposed to make out of that? That these products are falsely labeled as Betas to mislead the consumer and suggest an openness that does not exist? That companies have gotten mad and are actually asking consumers to Beta test something? That the meaning of the word “Beta” has evolved over the years to designate a product that is in its first stable release?
Probably a bit of everything. If anything, none of the popular “Beta” services of today match the definition of the world “Beta”. They are therefore knowingly mislabeled, as part of a marketing plan — not that it is wrong or anything. The definition of “Beta” has changed and some consumers now take it to mean a company is looking for feedback — while asking for money in many cases, might I add. Online ventures have also gotten better at market segmentation and can risk offering less stable products to an audience they know will manage better than it would have years ago.
This however does not change a fundamental rule of commercial development: a beta is not for consumers. You never buy beta washer and driers at Sears, your anesthesiologist does not use a beta anesthetic when you are operated on and I hope Air France does not put me in Beta planes — “let us know if the wings hold up”. Keeping a product in an endless beta stage will not make it easier to update, especially as the beta is only a facade in many cases, it only shows an unwillingness to assume responsibility for potential accidents. Business is about making money but the counterpart is that it also is about having responsibilities.
Differences in Importance
The interesting thing here is that Google and Flickr and other web service people provide quality services, often for free, in exchange for the testing rpocess that they get from the users. They're exploiting (and wisely) the mental denotation of Beta as "not quite done yet" and using that to their advantage.
By my calculations, if you could count Gmail's open launch as 1.0, we're around Gmail 1.2 today. Who knows where we are with Flickr. But web applications don't have version numbers like other products, and they shouldn't be held to the same standards. Because you can change the code of these applications literally at any time, version numbers don't apply to external users. Version numbers were great to delineate to tech support which exact build of the product you were using. However, with the web, it's very, very different.
I don't think it's insulting to use a beta product, even pay for a beta product with extended features (as I do with Flickr), because at the end of the day what matters is how useful the features are to the user. If they're useful to me, I pay for them. Beta, Delta, Gamma, none of that matters to me anymore. If it works well, they could title it in Kanji.
Differences in Importance
Hi!
First of all, thank you very much for taking the time to post, I really do appreciate it!
I agree with you that the nature of web services allows for easy silent upgrades and, therefore, makes the use of a solid versioning system seemingly irrelevant. However, modifying and upgrading applications without warning users has potential downsides — as recent issues with many services have shown — and the many synchronization problems that can exist over the Internet — notably because of caching and proxying — do call for solid references.
I also agree that there is nothing wrong with inviting users to participate in a "Beta" program. What worries me is that some applications seem intent to stay in "Beta" form for a long time, therefore diminishing their writer's responsibility — whether moral or legal. This, in itself, should be kept in mind by the community who wishes to rely on such services.
FJ
Differences in Importance
Software makers are not exempt from responsibility here, nor have I found the makers of, say, Flickr, responsible for the length of their beta. I signed up for a service, I paid them for that service, and the service has, 99.9% of the time, lived up to exactly that billing. It's not that I expect less of services I pay for, it's having a degree of tolerance appropriate to the code.
I pay nothing for Google Maps, or various other web services, how can I expect to have them beholden to me?
Endless beta?
When I read your article's title, I though you'd be talking about iCab…
Differences in Importance
Hi again!
This may sound very conservative but I consider that any service provider, even if the service is free, has a responsibility to its users. The responsibility may not be legal but, at the very least, it is moral.
Having a degree of tolerance for a certain code is indeed essential. There is however a fine line between having tolerance (always needed) and accepting issues that should not be. Where we place that line is, obviously, up to us.
FJ
Endless beta?
Hi!
LOL! iCab is actually one of the few applications I am dying to see out of beta one day! It is unfortunately showing its age as of today but there are some great ideas there!
FJ
Endless beta?
Great ideas indeed. I haven't used it for ages, but among others, the idea of saving a page as a web archive as a zip of all the files needed to display it was a great idea. It's a pity Apple didn't steal it for Safari.