Beta versions kind of lost their purpose lately. In the market where so much is offered for free, it’s tempting to use beta to cover yourself and never take full responsibility for the product you are shipping. If customer complains, you can always point out that product is in beta and that customer is using it at their own risk. Or not reply at all – why even bother with technical support?

This behavior, including perpetual betas where software never goes out of beta, is pretty common this days and it gave betas a bad name, even when they are good, old, “honest” betas. The other extreme are the people who suggest that you should never release beta versions, but release and take full responsibility for the product you shipped.

activeCollab 2 beta was somewhere in between these two extremes. First, it was relatively short beta period – only 2 and a half months. That’s nothing compared to years Google keeps most of their products in beta, but it’s enough time for hundreds of customers to download and test the new version.

Apart from having short test period, there’s another important thing we do with our betas – we make them available to everyone who already have a valid upgrade license. This means that whole beta process is transparent and everyone can take part in it. There is no special group of people and discussions behind the closed doors. Majority of feedback regarding the beta we got through publicly accessible activeCollab Community forums.

There are a couple of interesting lessons we learned with activeCollab 1.1 and 2 beta versions that we would like to share:

• Never add new features while in beta. The purpose of beta is to make the release stable, not to use that time to add more stuff before the launch. Just make sure that release is complete before entering the beta and work on making what you have stable. Leave new features for new releases.
• Take your time and don’t give in to pressure. Having a rough idea when you want to launch is OK, but don’t make an exact date. We found out that we are not able to predict how much time the beta will take, but we don’t see this as a problem, on contrary…
• Launch only when you feel the release is ready. Test it well, remove all the bugs you can find and than launch. Rushing things will most probably result in unstable “stable” version and a lot of support later on.
• Be prepared to support beta release just as any other. Customer will expect the same level of support and just because release is in beta does not mean that you can support it poorly. Quite the contrary, beta will most probably require more support resources than other versions, simply because it’s not stable enough.
• And finally – have fun and enjoy the process. Having something you worked on for months finally being used by people is great. Receiving feedback and making improvement based on it can be really exciting. Sure, there are bugs, problems with upgrade, questions how come feature X didn’t make it in this release, etc. but all these “annoyances” make the whole process fun and interesting.

Beta is about good communication with users and delivering a better software. It should not be used to cover your ass and provide unstable, poorly supported software. Such behavior gave betas a bad name, even though it is essential step in shipping great software.