Developer's Toolkit

Blog archive

How Do Software Companies Make Money?

Seems like an odd question, doesn't it? Especially when your strategic vendors seem to be draining you dry on support contracts. That may in fact be the case, but we've seen a dramatic shift in the business models of development tools vendors over the last five years.

Many of the companies that I deal with on a regular basis have launched open source strategies over the last year or so. For the most part, they have offered similar software under both an open source and a commercial license. What's the difference? Well, the open source software is largely provided as is (yes, I know that commercial software also uses that as a licensing term), with not support, patches, or upgrades. The commercial license is often includes professionally prepared documentation, comprehensive support, and patches and upgrades. In some cases, it also includes indemnification from patent suits.

Even if it is not strictly an open source strategy, it is often a free (as in no cost, not freedom) software strategy. Cross-compilation vendor Mainsoft gives away a version that does virtually everything that its commercial product does.

One company we talked to quite a bit about this was Terracotta, a provider of Java clustering solutions. I had an interesting statement from Terracotta CEO Amit Pandey recently. It's not possible to make money off developers. Instead, the company seeks to let developers easily acquire and use its technology, and charge only for deployment licenses.

I'm of two minds about this trend. One of the biggest problems that both development tools vendors and the developers themselves have is with shelfware. Shelfware is, of course, software that is purchased but for one reason or another is never used. Developers either have it forced on them by management, or never quite figure out how to integrate it into their normal processes.

The idea is to make developer tools more accessible to try out and use, with no strings attached. This effectively solves the problem of shelfware. If developers don't use the software, the vendor makes no money. If developers use the software, the vendor collects its money through runtime licenses. It is a fair deal for developers, and a validation of the value of the software for the vendor.

One other item of note is that cost of sales goes down substantially; in some cases, it is close to zero. In traditional commercial software companies, the cost of sales can make up as much as 50 percent of the cost of software. A lower cost of sales means that companies can still make money by selling their software less expensively, or by selling fewer copies.

However, giving away tools to developers only works for tools that have a runtime component in production. When I worked at development tools vendor Compuware Corporation, one of the more nagging headaches with our debugging tools was that developers would get evaluation copies, or even bring in a sales engineer for a proof of concept, find and fix all of the problems in their software, and send us on our way.

Now, I understand that there are several messages in that story. Clearly developer tools vendors provide value, but that value is realized at a specific time in the application development lifecycle, rather than throughout the entire process. It is true that developers and their employers seem to have a problem with paying for that value, but that may be at least in part because the vendors haven't yet figured out how to successfully monetize that value.

Suffice it to say that this arrangement may be innovative and the wave of the future, but it is also broken in some cases. It behooves all of us to find a way to fix it, else we may find ourselves missing some of the development tools we now take for granted. And for free.

Posted by Peter Varhol on 12/19/2006

comments powered by Disqus


Subscribe on YouTube