X
Business

December doldrums, and ad-supported software

Responses to some objections to the notion of ad-supported software by other bloggers and ZDNet Talkback participants
Written by John Carroll, Contributor

Winter brings many things: Christmas, snow (well, not in Los Angeles), skiing, goofy sweaters grandma knitted for you, company parties. Usually it brings a slowdown in work, too, though that hasn't been the case for me. I've been experiencing what its like to sit in room filled with people with their heads on fire. Besides the smell, it's a heck of a lot of work to calm everyone down.

But, I could program my way out of a jail cell sunk 50 miles below the surface of the moon, so everything worked out in the end. The bravado of the tired, that's what that is.

Anyway, I said I was going to respond to Phil Wainewright's response to points made in past blogs on the subject of ad-supported software, and I never got around to doing it. I also promised No_Ax_to_Grind (a regular participant in the Talkbacks) that I would respond to some of his objections. Now seems as good a time as any, killing two birds with one stone, which is an odd bit of phraseology, as I've never tried to throw rocks at birds and kill them.

From Phil's post:

Sorry, John, did you say 'software'? I was not aware that MSNBC, CNN and ZDNet were software publishers. Surely what you meant to say was 'ad-funded content,' not 'ad-funded software'? I find it simply incredible that otherwise highly intelligent people seem suddenly to be unable to tell the difference between content and applications when they're discussing the Web.

Granted, and as I noted in my brief response to the blog, good point. However, it doesn't logically follow that the model used to earn revenue from free content is not applicable to software. It just means that there is something different about the software market that marketers must understand if they are to properly earn money from it using advertisements.

Consider Google's search engine. I wouldn't consider Google to be a "content provider." They serve more of a function comparable to the lawyer's "Lexus Nexus" of old, and they are CLEARLY an application, albeit one that is web based. A more obvious example is online mapping software, such as Google maps or Mapquest. I think it would be a stretch to call a map "content." Online email sites run by Microsoft, Yahoo and Google are also applications, all of which are supported by advertisements.

And as I said, Paltalk is a desktop chat tool that uses advertisements to enable support for free accounts. They try to incentivize free accounts to upgrade to the ad-free version (a version that has full support for video). Still, Paltalk is NOT a content provider, and yet most of their customers are non-paying users the revenue for whom is derived from advertisements.

So, Phil, you are right, content companies don't make a slam dunk case for ad-based software. It doesn't mean, however, that the revenue model is inexorably tied to content, and the previously enumerated examples prove that. Is it EASIER to make ad revenue with sale of content? Perhaps, but it doesn't mean ad revenue is beyond the pale for standalone software, particularly if it enables revenue to be generated from segments of the market from which software companies already make no money (software pirates, or people who can't afford the software).

No_Ax_to_Grind also objected to the notion of ad-supported software, and gave five reasons for his opposition:

Reason 1. How many times have you heard people complain about MSN, Yahoo, whatever and the response is, "what do you expect for free"?

Granted, but I never said there wouldn't be an incentive to pay for the ad-free version. Ad-supported versions of the software are targeted at people who otherwise wouldn't pay. That group doesn't just include students, but most computer users in China (as an example), a country where some studies claim piracy levels surpass 90%.

I use Yahoo all the time for my online email needs. It is good enough for me, because I would have no interest in paying for an email account.

Reason 2. Everything I've seen about ad-based revenue leads to a decline in moral business practice and soon adds are pushed, then comes the pop ups, then comes spyware, then, well you get the idea. I have no mis-conception about Microsoft being able to resist the temptation any better than others have.

That's not a necessity, and there are hazards associated with such moral decline. Remember Gator? Gator gave ad-supported software such a bad name that they probably set the model back by a decade.

Companies want to grow to be LARGE companies. They don't reach that point, though, if they regularly have bad press explaining their numerous privacy violations. Think of Sony's black eye from its recent rootkit DRM protections on music CDs. It's gotten so bad that many in the Talkbacks whose anti-Microsoft tendencies led them to root for Sony's success in the game console market swore never to buy another Sony product - including the Playstation 3. I mean, that's like the pope becoming a Hare Krishna.

Reason 3. Development work on the product will drop, after all functionality is not the issue, selling ads is. When push comes to shove to get something done and out the door, you can bet all efforts will shift to making certain the ads work, even if the app doesn't.

I don't think that will be the case, as Microsoft will STILL need to update things on a somewhat cyclical basis in order to convince paying customers to upgrade. I don't expect many enterprises to opt for the ad-supported version of Office, as an example.

Ad-support may enable more frequent incremental updates, but that's not necessarily a bad thing. Instead of having to wait 2-3 years for some grand project to complete, you get your changes as they roll off the development presses. Of course, Microsoft would have to make those frequent updates easy to acquire, but as I mentioned in my AJAX post, Windows Vista applications are supposed to have some form of auto-update capability (at least, that's an option).

Reason 4. Microsoft's niche on the desktop is that their products have more features, are easy to use, and in the users minds outperform the competition. They have "value". When you give it away in exchange for ad revenue you "cheapen" its perception. It becomes another one of "those" applications. I do not believe this is a market perception Microsoft would want to encourage.

I think the "cheapening" would come from how they implement their ad system. One surefire way to avoid cheapening is NOT to engage in spyware activities, but that one's obvious. Another thing would be to make ads truly useful. I talked about targeted marketing opportunities in my first blog post on the subject, enabling ads that target you instead of taking the billboard on the side of the highway approach. It can get even more personal, though, by using some information provided by the application. For instance, if you are writing a letter, why not see ads for stationary companies? If you are mentioning corporations on the NYSE, why not provide links to ad-supported stock quotes?

Would this violate privacy? Not if the people who choose to use this software understand what they are getting into. Google Mail plans to target ads based on the contents of emails. Google mail, however, has a growing user base.

Privacy comes down to what you consider it necessary to keep private. If someone feels a version of Word that uses what they are typing to provide context-sensitive ads is an infringement, then they won't use the software. Others, however, might not feel that way.

Reason 5. Someone (an advertiser) WILL break the rules, hack the security, learn and play the system to an unfair advantage, and at some point harm Microsoft customers. As they will never be able to track the right person down, Microsoft will be blamed. (Look at who is blamed for bad device drivers.)

Granted, though the same risk exists for Google Maps, Mapquest, Yahoo Mail, Hotmail, etc. Clearly, ads streamed to a desktop application would have to be "sandboxed" in some fashion, but strong sandboxing already exists in the form of HTML rendering components, or even Java and .NET. In other words, I wouldn't exaggerate the risks.

Editorial standards