When a dealing with a piece of beta software, there’s a common understanding that there’ll be a few rough edges, but the software will be relatively solid and, generally, the features that will be included when the software officially ships are all there.
Primarily, beta software is shipped out to a relatively few people (compared to the developer’s full customer base), to get real world feedback on what does and doesn’t work for the customers before the software ships. Maybe they’ll uncover a few or more bugs that didn’t come up in your internal testing. This is great feedback for a developer to get.
The idea can hold in web apps, where the deliverable may be access, as well as more traditionally delivered native applications, libraries, etc. where the deliverable may be a executable binary or whatever.
But, I just can’t abide the perpetual beta idea.
Look, I just don’t see why any of this stuff:
- Services, not packaged software, with cost-effective scalability
- Control over unique, hard-to-recreate data sources that get richer as more people use them
- Trusting users as co-developers
- Harnessing collective intelligence
- Leveraging the long tail through customer self-service
- Software above the level of a single device
- Lightweight user interfaces, development models, and business models.
requires you to stay in beta forever. Shipping doesn’t magically remove your ability to rapidly iterate a design, and leaving software in beta forever just gives you an excuse to not support your users, and they deserve better.
