|Professional Services||Second Signal||Presentations||Andrew's Blog||Support|
Software products are released as complete and supported, or as beta with the expectation of bugs and little support. For now, there is very little between these two paradigms. The idea of “Release Candidates” is getting more common as are “Gold” releases but something is still missing.
IBM launched Domino 7.0 with the DB2NSF functionality marked as “Limited Availability” at the last minute. The name is wrong, really. It’s not the availability that’s limited; it’s more accurate to say that there isn’t enough confidence in the technology yet that IBM wanted to support it for all users in all circumstances. Anyone with Domino can get it, but they can’t expect guaranteed results yet. The problem is, IBM has no way to release something that isn’t 100% rock solid finished enough to work for every large enterprise customer in every supported environment.
Big, complex, enterprise scale products aren’t like browsers and word processors. New technologies being added are themselves very complicated and prone to use in many unexpected ways. Do you hold the release of an entire product suite because a new feature isn’t fully baked yet? Do you withhold that feature even though it may work perfectly well for 80% of the user base and be a fully committed tool for future development?
There needs to be a set methodology and nomenclature for releasing a new version with some features that are “almost there” -- past beta, confirmed to be part of the long term strategy, but not yet battle tested enough to bet the store on without more than the usual amount of testing. In the Linux kernel, these are “Experimental” options but that implies less stability then I’m looking for.
The NAME for this kind of release is really the crux of the matter. You don’t want to call it “Beta” or “Experimental” because that’s not really true. The feature is working and tested, but complex enough that the developers know there will be cases they haven’t considered that will cause problems. They’re committed to resolving those issues and making it stronger and stronger, but cautious about telling you to store the company jewels there. The new tools will probably work perfectly for 99% of the people who try them, but they still need that warning.
I believe firmly that sometime soon someone will get this kind of release methodology right and it will become a de facto standard almost overnight. The naming and marketing of it is the only holdup. Google just keeps everything in Beta forever. Microsoft releases beta after beta followed by release candidate versions in a series until they’re confident that only the least damaging bugs are still in before finally releasing a new product. IBM tried their “Limited Availability” thing with DB2 (and frankly did it very poorly, IMO).
So who is going to get it right first, and what will these “almost there” features be called? Would you try them if you knew the score?
Please wait while your document is saved.
than 100% bulletproof they risk damaging the image of the entire brand or
anything 'tainted' with the same name. It's a very difficult question - would
having these add-ons available via optional download be the way of addressing
it? If for instance I download something from Sandbox (even something generated
by IBM) I know it's a case of buyer beware.
Maybe the solution is what they tried to do with DB2 which is to not ship it
with the core product but make it an optional, risk associated, non supported
download until it's ready. The problem with what they did with DB2 is they
made it almost impossible to find and download and actively discouraged use by
making it sound like a closed program. T
Since naming clearly isn't my forte I'll leave it to someone else to come up
with a catchy name for an "Optional, Risk Associated, Non Supported Downlaod"!