User:Monkeyblue/sandbox/Perpetual beta

Prerun

Possible first sentences

1. Perpetual beta is a nonsense term used to describe software or a system which never leaves the development stage of beta
2. Perpetual beta is a nonsense term used to describe software or a system which is always in Development.
3. Perpetual beta is a nonsense term used when computer software appears never to leave development.
4. Perpetual beta is a nonsense term used when computer software or systems appear never to leave development.

To Build off

[1]

Examples

• Gmail
• Google Maps
• Flickr
• del.icio.us

Article (01:30, 26 April 2007)

Perpetual beta is a nonsense term used to describe software or a system which never leaves the development stage of beta. It is often used by developers in order to allow them to constantly release new features that may be unstable. As a result perpetual beta software is not recommended for mission critical machines.

Like most technical concepts, new frames or modes for using the concept germinate and take root in parallel arenas of thought. Perpetual beta is no exception to this mutability of technical application and language. Perpetual beta has come to be associated with the development and release of a service in which constant updates are the foundation for the habitability/usability of a service. Recently, Web 2.0 Guru Tim O'Reilly touched on this concept in his Sept 30th, 2005 article:

"Users must be treated as co-developers, in a reflection of open source development practices (even if the software in question is unlikely to be released under an open source license.) The open source dictum, "release early and release often" in fact has morphed into an even more radical position, "the perpetual beta," in which the product is developed in the open, with new features slipstreamed in on a monthly, weekly, or even daily basis. It's no accident that services such as Gmail, Google Maps, Flickr, del.icio.us, and the like may be expected to bear a "Beta" logo for years at a time."

Used in the larger conversation of what defines a Web 2.0 habitat in relation to the Web 1.0, O'Reilly re-set the concept of perpetual beta in light of a more customized Internet environment with these applications as distinguishing characteristics:

• Services, not packaged software, with cost-effective scalability
• Control over unique, hard-to-recreate data sources that get richer as more people use them
• Trusting users as co-developers
• Harnessing collective intelligence
• Leveraging the long tail through customer self-service
• Software above the level of a single device
• Lightweight user interfaces, development models, and business models.

When software delivers its service over the web, we can do business differently. Our ability to control our software’s environment—all of it that runs on our servers, anyway—is helpful. The ability to fix the software without distributing updates is helpful. Since interactions between users and servers go over the net, they can be recorded and replayed. All of these things can be exploited to support much better bug analysis and performance monitoring. Software just got easier!

On the other hand, being able to monitor users is complicated by their huge numbers on the net. What do you do with millions of traces of interactions? To begin with, the application should be seeded with exception conditions for which the programmer would like to receive a report. These reports can catalogue bugs or any other condition the writer considers noteworthy; e.g. a particular feature has been used in an unexpected way. Performance data should be aggregated.

An application should evolve to better serve its purpose. So, aside from providing a service that attracts users, it should be gathering information about what else the users might want or need. Thus, the tough decisions that product managers make about which features to include in the next release can be made in a more informed way. The product management team implements features in a rudimentary form and then tracks what the users do with them. In this model, features can be tried on small subsets of users until they prove dependable and popular.