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 a few months? Companies should improve their services constantly and this means release new functionalities every few weeks.
Now, this gives a big competitive advantage to web applications.
- 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 features to be added (you can really think to write to the 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 in which the 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 themselves.
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 changes 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 these small pieces are released too early they won’t be solid enough to build valid services. If you are tempted to release an api or a feature that you feel is not solid, maybe you’ve just found 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.
Bookmark Murdok:
Francesco is an Italian software engineer currently working on Java mobile applications. He is a passionate blogger, you can read his thoughts about SEO, technology and www social trends at www.mapelli.info or add his feed to your feedreader.
