Why Apple Doesn't Blog - Vaporware

DECS writes "If anyone is still wondering why Apple does not encourage its internal developers to maintain blogs, Roughly Drafted is carrying an example of how the good intentions behind sharing information can result in unpleasant, unintended consequences." From the article: "As customers, we all want to know what's going to happen in the future, but we will also turn around and beat developers with the very information they share with us. One of the terms we hit them with is, of course, vaporware. The other thing about blogs is that written text fails to capture the full range of rich human communication. It's easy to take more offense than is necessary to the wrong choice of words. Minor and casual criticism can quickly ferment into a difficult stink, and attempts to burry it can often just make it worse. Blog entries are like emails that cc: to the entire world."

A hint

[Anonymous Coward]

As customers, we all want to know what's going to happen in the future, but we will also turn around and beat developers with the very information they share with us. One of the terms we hit them with is, of course, vaporware.

Or, more to the point, Apple doesn't want their customers waiting for the new versions that may have the features that their customers really want. Apple wants their customers buying every release; not just the realeases that have the features that the customers want.

Apple, the World's greatest marketer run by the World's greatest salesman: Steve jobs.

"Tell us what you're going to do. Then do it"

[dpbsmith]

At the 1996 Apple Worldwide Developer Conference, the newly-appointed head of developer relations--details of the painful 1996 WWDC are mercifully fading and her name escapes me--said that she had been talking to developers and one thing had emerged as the most important single issue in developer relations.

Developers, she said, had been begging Apple for one thing: "Tell us what you're going to do. Then do it."

Avoiding all talk of the future is a seemingly risk-averse strategy, but it carries risks of its own. If a company wants developers to be ready consistently on day one of new-product introductions, they need to have a reliable roadmap.

Accusations of vaporware are a real problem, but I at least suspect that one of the reaons why companies hate discussions of futures by technical people is that it provides a public record of changes in internal direction, inconsistent decisions by executives, etc. which can be embarrassing to the company.

Pre-announcing would kill the buzz

[macurmudgeon]

Apple gets too much attention from their current way of doing things to want to change. They probably get more blog attention from outsiders guessing what is coming out at the next conference than they would letting employees blog or pre-announcing products. Apple's policy of secrecy and Job's showmanship have been a winning combination.

vaporware distinctions

[Ancient_Hacker]

Perhaps we need to clarify the various flavors of vaporware, distinguished by intents and causes: (1) Deceit-o-ware: Marketing announces a "product" in order to discourage competitors, stake out mindshare, commit the partners and developers, and other dishonorable reasons. ( Taligent, others ) (2) Wish-o-ware: Developers promise to enhance a product, not realizing the current code isnt extendable. ( Copeland ) (3) Bloat-o-ware: Soo many promised features, the resulting code is too embarrasingly complex or slow to ever be released. ( Cairo, SQL file system, .NET code in the OS ) Now #1 is totally indefensible, but #2 and 3 are more likely unintended consequences of good intentions.