What Is Vaporware?

Software exists as patterns of electrons on the hardware - and when it is erased or destroyed, it turns into vapor or smoke, as if it never existed. Hence the name "vaporware".
Software exists as patterns of electrons on the hardware - and when it is erased or destroyed, it turns into vapor or smoke, as if it never existed. Hence the name "vaporware". | Source

What Is Vaporware?

The term vaporware refers to Information Technology products like hardware, software and operating systems that are announced but never reach market. They may only be concepts or announcements of something never made. Or the vaporware exists in a demo version or single prototype but never moves beyond the trial version.

The term vaporware or vapor-ware is attributed to Ann Winblad. The term has been kept in the public lexicon through Wired Magazine’s annual “Vaporware Award”, listing the top product failures that were promised but not delivered or were fell flat upon arrival.

How Do We Get Vaporware?

Vaporware products may start as demonstration products that bomb when revealed to the public, so they are never reach the production floor. Or vaporware products are developed but found to be so complex or buggy that users are not interested in buying it.

Beta versions of vaporware may not elicit interest from users, so a final version is never released. Companies may announce a product that they are developing but fail to deliver from lack of funding, whether from bankruptcy or lack of sales of their major product lines to fund new product development. At that point, the products they may have promised or even demonstrated will become vaporware, because they won't hit the commercial market.

Vapor ware also occurs when a small company is bought out by a competitor who halts the product's development. Buying up potential competitor and then killing it may be cheaper or simpler than competing with it. When a start-up promises a revolutionary new product but folds up instead, its product can be considered vapor-ware.

Vaporware also refers to software that was created by quickly removed from a cloud server or removed in mass after a failed roll out.

How Can You Prevent Your Product From Becoming Vaporware?

There are several things you can do and avoid doing to prevent your software release from failing before it has a chance to succeed.

  • Study your market as you develop the product. Never develop a hardware or software product that doesn't fit your user's needs and has been well received by user groups who have reviewed the concept or tried out beta versions.
  • Work on beta versions until they are relatively bug-free before releasing them to your key users. Buggy versions of beta products will cause your most ardent supports to sour on the product, and they are the root of the grapevine and word of mouth advertising network. To release something that is buggy or fails to include critical features risks the release of “shovel-ware”, software that is dead on arrival and ready for burial.
  • Avoid announcing conceptual products that management may not approve for production.
  • Wait until the release date is relatively firm before making it official. When you move the release date, your customers may be disappointed by the delay and seek other, related products. Continually slipping on a promised delivery date causes consumers to question the quality of the product and discourage them from buying anything else from the vendor.
  • Announcing products as a joke or gimmick may get your company attention, but it erodes customer trust in the brand and can undermine the enthusiasm of users when you announce another product. Using announcements of products that do not exist to stay in the limelight may cause your next, real product to become vaporware because no one listens to the advertising or adopts it.
  • While the waterfall development model promises to accelerate the development of new products and software, mistakes at the initial requirements phase become too costly to correct if realized mid-stream. Collect detailed requirements from the user community before you start coding or designing hardware. Do not drop critical requirements from the design with the hope of shoe-horning them into the design later with patches or in later product versions.
  • Wait until a new product has been well received in the market before starting on its next generation. If too many resources are consumed in creating a bigger or better version of the product, the initial version may fall flat – killing both the first edition and any subsequent versions in the process.

More by this Author


Comments 2 comments

Simone Smith profile image

Simone Smith 4 years ago from San Francisco

Hahaa, I remember the first time I heard the term. I thought it was for some sort of EXTRA SPECIAL and FANCY product! I felt pretty foolish after hearing the real meaning.

Thanks for the excellent explanation!


Davesworld profile image

Davesworld 4 years ago from Cottage Grove, MN 55016

Let me give you a real-life example of vaporware:

For most of my working life I was a software developer for a variety of mainframe software companies. I attempted to cross the boundary between the mainframe and the desktop and had a couple small successes to my credit. I always tried to keep myself abreast of change, as best I could, with developments in both the mainframe and the PC world. One day I ran into something called Eclipse and a light bulb went off.

The software company I worked for had a variety of mainframe products that were showing their age with user interfaces that needed to be brought into the 21st century. A half and hour or so of research showed that Eclipse could be the platform for that and I got excited. Eclipse is written in JAVA and will work on just about any desktop machine. So all I had to do was create s single program on the PC and I would be able to run on a MAC, any release of Windows and LINUX - a software developers wet dream.

So I dug into Eclipse in more depth. Realizing that management was a bit on the stodgy side, I decided to create a "proof of concept" program using one of the simpler mainframe products as my base. It also served as a learning experience for both JAVA and the Eclipse platform itself. When I had a rudimentary system working, I showed it off to the rest of the company. That ended up being a mistake.

Middle management got all excited, looked at what I had and decided, over my strenuous objections, that we would demonstrate the product at an upcoming trade conference two months away. They told me that they had set up the demonstration sessions at the same time they asked for a demonstration system. What I had at the time was held together by band aids and chewing gum, and now I was on a two month deadline - less than that since I had to also train the demonstrators on how things worked. Seven 60+ hour weeks later I had something that was reasonably stable but nowhere near as slick as it could or should be.

Response at the trade show was great with many potential customers expressing interest in the final product. Management promised beta release in six months. Far freaking out but all I had at the time was a cobbled together patch job and with nothing that resembled polish and a whole lot of unanswered questions. Plus a bunch of requirements since the mainframe side of things needed new interfaces for the PC code to work properly.

Cutting to the chase, in the next few months the project grew in size and scope. I couldn't get company support for the needed mainframe additions. Some of my assumptions proved to be incorrect and the net cost to the user got higher and higher as it became apparent that 3rd party software would also be needed.

Six months came and went with no product to show for it, just an ever increasing list of things that needed to be done. Not only did management fail to support me on the mainframe changes, they failed to understand why many of them were necessary (I said they were a stodgy bunch). Eventually I ran into too many brick walls and I gave up on the whole idea.

In this case, vaporware happened. Not intentionally on my part, but nevertheless nothing ever came of the idea. A couple years later competitors managed to pull it off. That developer must have had more enlightened management.

(Sorry about the length of this thing, but I have wanted to tell this story for quite some time.)

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.


    Click to Rate This Article
    working