Perpetual beta is the keeping of software or a system at the beta development stage for an extended or indefinite period of time. It is often used by developers when they continue to release new features that might not be fully tested. Perpetual beta software is not recommended for mission critical machines. However, many operational systems find this to be a much more rapid and agile approach to development, staging, and deployment.
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 or usability of a service. According to publisher and open source advocate Tim O'Reilly:
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.[1]
Used in the larger conversation of what defines Web 2.0, O'Reilly described the concept of perpetual beta as part of a customized Internet environment with these applications as distinguishing characteristics:
However, the Internet and the development of open source programs have changed the role of the (end) user. He often does not receive a finished product, but a service that can be called up via the network. Appropriate adaptations of the programs and regular updates are often included. For some program developers, the terms Continuous Beta or Perpetual Beta[3] (both English/Latin/Greek loosely translated for permanent preliminary version or colloquially for permanent banana product) have become commonplace. The user is to be regarded thereby as Mitentwickler (English Co-Developer) in the process of the advancement of a program.[4]
- 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.[2]