When O’Reilly talked about Web 2.0 and perpetual beta he was tryng to say (I think) that the classic software release cycle is becoming too slow and self-focused for modern companies and that companies should never stop to enhance their applications and services with help from the community.

This is linked to the idea that the software is not a product, but a service… who wants a service that becomes outdated in few months? Companies should improve their services constantly… and this means release new functionalities every few weeks.

Now, this gives a big competitive advantages to web application.

• users do not have to download the new version to get the new functionality… (it’s simply there, that’s the new lime green button)
• companies do not have to maintain backward compatibility (no one will never run an obsolete version)
• users are more involved in development, and can suggest new feature to be added (you can really think to write to writely dev team to suggest a feature… would you ever write to MS Word dev team?)
• companies can try new features every day and choose how much to invest on each of them depending on the community feedback
• users can reach the service from anywhere
• companies can deliver a service available everywhere
• …

What scares me is that the use of the term “Beta” seems to have misled some companies… giving the impression that they can build buggy services, put a colorful Beta logo and think they are cool and “so web2.0″.

There’s a big difference between releasing a service built with components that are still in beta and releasing a service which architecture is still in beta.

The architecture of a service can be in Perpetual Beta, because users can provide important feedbacks and feature requests, and companies should add and remove tools and services depending on the feedback and their intrests, what can (and should) be in Perpetual Beta is the way small pieces links together, not the small pieces itself.

Web 2.0 it’s like LEGO.
You have small, simple and colorful pieces, and you build platforms and services with this pieces. You can build something that change every day, but the small pieces you use must be solid.

Small and solid pieces are what give web2.0 companies the capability of fast response and fitness for their niche. If this small pieces are released too early they won’t be enough solid to build valid services… if you are tempted to release an api or a feature that you feel it’s not solid, maybe you’ve just find something you can split into smaller pieces, and release each one separately.

Some companies are inclined to view the users as free debuggers, while they are far more than this: users are the ultimate resource to discover the best possible way to deliver a service, because only users can tell you how to link the LEGO pieces.