All software has one or several release cycles. Even if it’s not planned, there is always an underlying concept of a release cycle. A discussion around the when’s and where’s. Another discussion around the who’s and when’s. And so on.
A pretty and linear release cycle might look like this (at least in the mind of the project manager or sales):
The above diagram isn’t a circle (to demonstrate a cycle) but I think you get the point. The startup I’m working for are in Beta stage. We got there a few weeks ago from Alpha. The major change for us was allowing customers that had signed up for the ‘experimental’ track (our SaaS is a two track system) to start using the product. At Beta stage (for us an open-by-invite beta stage) we feel confident in the accuracy of our calculations and data management, but there is a lot of testing left and we are still tweaking performance. The feedback from the customers has been extremely valuable, as they report issues and expectations we haven’t picked up on before. That requires a lot patience and understanding from the customers, and a vulnerability from our side as we are exposing the system at such an early stage. Our RC (release candidate) is planned for mid-November, and RTW (release to web) early next year. But we might not get there.
Because we might end up with a system that will for forever be in perpetual beta. I’ve got a feeling we are one of ‘those’. And it’s not a bad thing.
But what is a perpetual beta?
Do you remember Google mail? Being in beta for years? That’s perpetual beta. It’s a stage during open beta that sort of also becomes GA (general availability) at the same time. And the system is there for a long time. A long, long time. Maybe ‘forever’. Why on earth would anybody do that? For as long as software has existed and available to the general public people have complained about the slowness of releases. Features not representing expectations. And all that comes with lack of communication and adding lots of time to get to the ‘tada! -its perfect! Let’s let it out’-stage. Perpetual beta takes care of that (not all of it of course) by releasing the software while it still has bugs and is undergoing feature updates. It is considered stable enough to stand on its own two legs, as well as being usable. The customers become co-developers as they take part in the development process by reporting issues and requests. There is no traditional ‘final’ release and subsequent ‘hello maintenance and support stage’.
The reason why I’m thinking that we might end up doing so is because we are exploring the domain and ways to extend and adapt the system together with our customers. Additionally, our setup on Azure allows us to easily maintain a perpetual pipe. We cannot predict and explore what would bring the most value without a proto. This while neither we or the customers want to pay and wait only to discover that its useless. Although we target enterprise companies at this stage the number of actual users is fairly scoped, predictable and we are able to have direct dialogues with them. We, as a company and team, are transparent and embrace the positives of sharing early – with faults and all.
I’ll let you know by next summer if we end up ‘Google-Mailing’ it.
What is your take? How does your company/you deal with releases?