Years ago, someone proposed the following definitions:
Alpha = Software that is feature complete, but has not completed QA, so it may have bugs.
Beta = Software that is feature complete, has been through one QA cycle, and has no known bugs.
I have yet to see a development effort that kept pace with those definitions. Usually, there's one or two late features that haven't come in by the time planned to declare Alpha, and there's lots of bugs (and maybe even a couple of missing features) when it comes time for Beta.
If developers could keep with the above definitions, we'd see no grief with distributing Beta software, even for a profit. The real issue is short-cycling both the development (eg QA) and the revenue cycle at the same.
by Bill Coleman — Jan 03
Alpha = Software that is feature complete, but has not completed QA, so it may have bugs.
Beta = Software that is feature complete, has been through one QA cycle, and has no known bugs.
I have yet to see a development effort that kept pace with those definitions. Usually, there's one or two late features that haven't come in by the time planned to declare Alpha, and there's lots of bugs (and maybe even a couple of missing features) when it comes time for Beta.
If developers could keep with the above definitions, we'd see no grief with distributing Beta software, even for a profit. The real issue is short-cycling both the development (eg QA) and the revenue cycle at the same.