When is a webapp called Beta, alpha, pre-alpha, or none

Question

I've come across many apps on the web that call themselves Beta. I've come across other apps that had an alpha designation. I've even come across some that called themselves pre-alpha, whatever that means (if you know please clarify). Then I've come across some really bad webapps that shouldn't have left the developer's computer and they didn't have any beta designations. I've also seen some well built apps that called themselves Beta, including Stack Exchange (the mother site of SO) which I believe is very full featured to be called a Beta.

I'm a little confused. It seems people are doing it at their whims. Is there an established rule or a checklist that can help decide what stage an app is in (beta, alpha, pre-alpha, or none)?

P.S. Please feel free to retag as appropriate.

Answer 1

Here's my understanding:

alpha = working, but missing some functionality

Beta = all functionality, but there are bugs

Release = all functionality, most "known" bugs gone.

-mcpeterson

Answer 2

Here you have a fast reference

http://en.wikipedia.org/wiki/Software_release_life_cycle

Answer 3

First of all, you're correct - it's basically done on a whim. Google is famous for calling their stuff "Beta".

Microsoft is infamous for releasing what ought to be beta code as production (whether that infamy is deserved or not is debatable and I have no definite opinion :)

However, to provide a different flavor, in a serious corporate environment, this is usually done somewhat differently and more structured:

• Alpha - prototype software. Usually does NOT run on production environment.

• Beta - software which is using some or all of production infrastructure (e.g. it may connect to production database, and/or even run on production web/app servers), but has distinct "beta" code paths and is only accessible to a select subset of early "beta" users.

  Again, the above is not something set in stone, but the usage seems fairly common in corporate development.

Answer 4

As originally used (in commercial, mostly closed-source) projects, alpha testing meant "internal testing" -- i.e. testing by other people within the company, and typically only specifically designated people within the company at that. Beta testing usually meant the first releases of code to anybody outside the developing company, but still (again, usually) only to specifically designated outside people.

That often tied indirectly to what was made available as well: alpha testers often had access to the original source code and possibly development environment. Beta testers typically only had access to the final executable.

Those designations, however, only really mean much when/if distribution of the code is tightly controlled. In a fairly typical open-source project, especially one that's hosted someplace like SourceForge or github, the minute some code is added to the repository in any way, it becomes openly available to essentially the entire world, and source code is always available to everybody.

Likewise, development was classically tied to specifically delineated phases (the "waterfall" model) and phases of testing went along with the phases of development. Most modern development methodologies abolish those phases. Without the phases, the levels of testing that were tied to them become essentially meaningless.

Answer 5

This is the traditional understanding:

• Pre Alpha - Still in someone's editor. It does not run, or barely runs. In some cases, the UI is complete at this point and advertises all of the planned functionality. Not much works, its a prototype. Software at this stage should not be published, at all, except amongst developers.

• Alpha - Something that doesn't crash all of the time and is not yet feature complete. At this point, its probably going to hallway testing and a meeting will be held to differentiate usability issues from feature creep. Software at this stage should not be released for public testing.

• Beta - Stable enough to let loose to a select group of users. Ideally, you know that every single user who receives a copy is capable of finding bugs and reporting them with an adequate degree of articulation. In a perfect world, hallway testing solves everything, but the world is not perfect. Power users are your friend in the beta period. Depending on the overall stability of the software, betas may be public. Unless the app 'just works' 95+ % of the time, the beta should be private.

• Release Candidate (aka RC) - You will often have multiple release candidates. You put it out in beta, got great feedback, fixed a bunch of stuff and everything seems to work. Still, bugs hide well and you don't want an official release to flop. At this point, you want only bugfixes to what exists, you don't want to do any major surgery. Its expected, at this point that any drastic changes have been completed. Any revisions at this point should be trivial, at best.

• Release - It works already, send it out into the wild, then start over again.

• Next - Usually somewhat stable builds of the next version of the app, often called edge. Basically, the same as beta, but perhaps not for the faint of heart. The main difference is, its based off the previous release version.

Please note, while I can't quite remember links well enough to cite references, a lot of start up companies use 'alpha' or even 'pre-alpha', or horridly even something like 'Join our pre-alpha beta' as marketing buzz to try and build a community.

You need only be concerned with marking your app as beta once, and providing a very easy and intuitive means for users to tell you what they think, or what broke. Better yet, handle breakage adequately and provide a convenient place for users to add comments. Anything that is not at least beta quality has no business being out in the wild.

When out of beta, there's no need to put 'beta' anywhere. All risky stuff is in the edge version, which won't become the newest current version until its completely tested (RC versions help here, they can entice users who prefer stable builds to test, provided you give them an easy way out and path back to sanity). At that point (when you move next to stable) you need to make sure users can report issues, but why tag something beta that was previously pronounced as stable? You get one 'golden' beta period, make the most of it. After its done, people expect stable software unless using/running next or edge builds.

Free / Open source software is no exception. If someone pulls down your development repository, they have no reasonable expectation that the resulting build will work. What counts, in that case is what you recommend that people actually use.

If you see a 'pre-alpha' app available to the public, there's a good chance that whoever made it is not following any kind of sensible convention beyond marketing hype, hence throw the Wikipedia definition out the window as they clearly are dancing to their own tune.

Answer 6

My understanding from doing Mac desktop software in the 90s:

• alpha - feature or nearly feature complete. Ready for internal QA
• beta - feature complete. Ready for limited trial with external users.
• golden master - shipped or shippable

The economics were such that you didn't want to ship out something you'd have to send out a bug-fix release for, as this was expensive to dup the disks or CDs, plus the mailings to registered users, etc. Alpha had a cost of having to hire a QA team, and beta has the cost of coordinating with external users.

The web deployment model is so different the same economics don't apply. If there's a bug, fixing it is just pushing a new build-- not much cost or communication effort. The reason to not release to a wider audience largely a perception and marketing approach. With that, some people advocate getting things out there early to benefit from the feedback (Steven Blank, Eric Reis), while others advocate an older model (Joel Spolsky, for one). There are plenty of examples of either one working well.

Anyway, given all that, with modern web development there's not as much need for those alpha and beta milestones, as there is little cost involved in going through them. So they have been adopted as tools to communicate the maturity of the product-- which is really quite appropriate. As there is less rigor around them, they do tend to have a wider range of meanings than the original labels.

I'll admit I have forgotten to slap "alpha" on some mashup I threw up in a couple hours...