Definition “Permanent pre-release” What is a perpetual Beta?
29.12.2021By Gedeon Rauch
If a product is never completed, this could cause discomfort. This is usually the case with the Perpetual Beta. If such software is always under development, this is not its greatest weakness – but its greatest strength.
Related companies
Just as the axolotl never outgrows its larval stage, a software delivered as a perpetual beta is never completely finished.
The term perpetual beta is a strange artificial word from the Latin – perpetuum – (meaning a state for eternity) and the second letter of the Greek alphabet, beta. The latter is often used in software development for the unfinished version, which is shortly before the final release and is already being intensively tested before it is finally released to the public.
But the Perpetual Beta works according to the so-called banana principle and matures in the consumer. It is therefore both a release version and a beta version, which is constantly being further developed. This is an advantage for both developers and users.
Perpetual Beta – Definition and History
Historically, behind the mantra of the Perpetual Beta is also – at least in part – the ideology of open source software. Releases should be done early and often, the development is incremental. Finally, users can choose which version and which degree of stability is desired.
But most perpetual betas are not really unstable, on the contrary: even large companies rely on long, extended or eternal beta versions in order to be able to further develop complex software during use.
Finally, the perpetual beta in the user area allows development teams to integrate new features into the software or to change existing features and to collect ongoing feedback from the largest possible number of testers. If the perpetual Beta should end at some point (and this is by no means a given), the product has already gone through several years of robust testing.
In this application, the users are not only the target group, but also part of the development team. Through their share of work (testing), they collect data on the actual application and robustness of features, additional feedback functions can give developers even more information about the functionality of a software.
The limits of the Perpetual Beta
Some applications are much better suited for a perpetual Beta than others. In principle, perpetual betas should not be used at critical points by organizations, companies or private individuals. ?Any point that jeopardizes the operational capability of a company, protects sensitive data or limits the ability of other critical software to run should rest on stable foundations.
Examples of Perpetual Betas
The Perpetual Beta is not a development model that is used exclusively by smaller companies that rely on the swarm intelligence of their base. Even Google left software such as Gmail, Google Maps or Google Earth in a beta version for years in order to openly improve features and deliver new versions. Most users probably didn’t even notice that there were very frequent updates and that they were in an open beta test at all.
Precisely because the above-mentioned examples were so widely distributed, the perpetual beta was even decisive for their development and popularity. The users did not have to wait long for new major releases, but small improvements were integrated immediately.
Of course, Web 2.0-based applications also facilitate this process on the development side, since the software is played from the browser, thus guaranteeing the latest beta version. The image service Flickr also operated in a perpetual beta for years.
Further development of the term and software as a service
In modern app development, almost all larger apps should theoretically fall under the collective term perpetual beta. Faster Internet connections make it possible for apps (and operating systems) to immediately install even minor improvements. Larger versions are then in a year-long, possibly never-ending phase of constant improvements.
The fact that mobile applications such as Facebook, WhatsApp or Google Maps receive updates so often does not entail any disadvantage for users. The boundaries between a release version that is constantly receiving new updates and a perpetual beta are fluid in this case.
Software as a Service also guarantees development teams the opportunity to continuously develop their software incrementally for a large customer base. Systems such as the Adobe Cloud even ensure that users always use the latest software version. As long as new releases do not endanger the stability of a software, there is nothing against the open source mantra: Release early, and release often.
Positive and negative examples
Used correctly, the Perpetual Beta is a great way to collect feedback and usage data and integrate it into the development process. Neither the term perpetual beta nor the banana principle are valuable in principle.
A perpetual beta, which provides users with stable and functional software, but is always improving thanks to the extended beta use, is certainly the best possible example. Users are involved in the development here and the software adapts to the target group. At the other end of the spectrum are releases that have to be sold according to the banana principle and adapted to the user group by constant patches.
