Making Money With Software, or Because of It?

Three years ago, Doc Searls discussed the idea that “it’s far more important (and interesting) to make money because of our blogs, rather than with them.” The elephant in the room for that particular conversation was advertising, the implicit question being should the blog be a profit in and of itself, or merely a means to enable profit.

While the issues therein are of great interest to those, like me, that blog on at least a semi-professional basis, its ultimate resonance is limited by its self-selection of an audience. What I’m beginning to wonder, however, is whether there isn’t a lesson therein for those authoring software rather than blogs.

More specifically, is it advisable to make money because of software rather than with software? The question is largely rhetorical, because for every arguments for, there’s one against.

That said, it is self-evident to me that software houses will increasingly seek network revenue streams to augment or even replace the traditional software income derived from licensing, support, and maintenance. I make this argument based on the following:

• Customer Conversion:
  The difficulty that open source software vendors have had in the monetization of their wares is well known and understood; roughly 1 in 1000 MySQL users, for example, becomes a paying customer. What’s less acknowledged is that closed source vendors suffer from exactly the same problem. Whether their software is pirated or users simply switch to freely available alternatives, the software market has never been more competitive – and thus difficult to convert customers in – than it is today. Augmenting traditional offerings with network based complementary or stand-alone services potentially offers the ability to convert a higher percentage of would-be customers into actual customers.
• Customer Demand:
  When Microsoft feels compelled to introduce software that over the longer term potentially impacts the sales of one of its two licenses to print money, it’s a good bet that there’s demand behind it. Because even strictly client products are increasingly competing with online counterparts, it’s necessary to add online or network components to the offering to remain relevant to customers from a demand perspective.
• Lower Barriers to Entry:
  Tim Bray, as is so often the case, says it best:

  The reason the Web worked so well is that nobody had to ask anybody’s permission to build a browser or a crawler or a search engine or an auction site or a dating service. Anything in the system that requires central authority, that’s something that holds you back.

  While the friction involved in the usage of network applications and services varies widely – compare, say, Amazon’s new SimpleDB service to something like Gmail – the lesson of the web is that the ubiquity of network access and availability trumps client installation in many if not most cases. Ergo, introducing additional functionality and exposing it via a network interface is an obvious win.

• Higher Retention Rates:
  Under appreciated at this point is the potential of value add network services to help retain current customers. Consider an offering like Canonical’s Landscape; while I might, at some point, be incented to defect to RHEL or SuSE or another distribution for cost, compatibility or other reasons, those distributions would have to replicate the functionality currently available to me in Canonical’s offering. While it can be done, it requires effort and disincents me from switching.
• Network Effect:
  Most important, perhaps, are the implications of the network effect. Enterprise software in particular massively underleverages the value of the network effect, but it’s a failing common to software generally. For example, Splunk’s Splunkbase adds significant value over the the pure client, harnessing as it does the collective intelligence of the software’s users. While efforts to incorporate this and other user telemetry are merely in their infancy, it seems clear that over time this will become standard practice rather than a differentiator. As Google proves with its “did you mean” function, even the most basic pattern matching can produce useful functionality: such is the power of the network effect.

Beyond the direct monetization of network services, it’s also likely that we’ll see additional creative models emerge that subsidize the cost of the software via other means. Spiceworks, for example, is able to provide its systems management software application to SMBs at no cost, monetizing it via advertising. Much as Google does with search.

It would be the height of folly to predict the end of traditional software revenue streams, of course, but it seems equally illogical to contend that network revenue will be anything but an important part of software economics going forward. Particularly in cases where direct monetization is a challenge, vendors should consider making money because of software rather than with it.

Disclosure: Canonical, Microsoft, MySQL, Spiceworks and Splunk are RedMonk clients, while Amazon and Google are not.