The Software Business Has Changed
Or perhaps it is just me that has changed over time. That part is certainly true. In addition to hair color trending gradually toward gray, I have just been fitted with my first pair of progressive eyeglasses.
But I've always been interested in the business of software, for at least three reasons:
- We, as an industry, build products that we know have defects and limitations, and sell them with a license claiming they have no value for anything.
- As we continue maturing the products through subsequent versions, they become increasingly fragile rather than increasingly stable.
- We have little understanding of the market in which the software is sold, and sell without understanding the customer's business of the problems we need to solve.
Let me focus on the last of the three. In the latter half of the 1990s, this didn't seem to matter so much. Users of the software development productivity tools I helped purvey were encouraged by the promise of improvements in the quality or quantity of their custom-built software.
But there was a problem. In many cases, it didn't happen. Software became what is commonly called "shelfware," remaining in the box on the shelf, rather than installed and working on developers' systems. There are any number of reasons why this was so. In some cases, development groups lacked the discipline or methodology to incorporate tools beyond an IDE into their daily activities. It may have been incumbent upon us as the developers to devise solutions that made our customers successful, through either better usability or better training. Either way, much of the software sold to developers remained unused or little used.
But today shelfware has become a thing of the past. If you can't immediately put it to productive use, you can't buy the software. This means that vendors have to do more than deliver a high-quality product. They have to understand what developers need that product for, and how they will use it.
This is especially difficult for the software tools business, because of the strange equation surrounding tools. Tools to aid in developing and testing software have in effect no value 95 percent of the time. This is because they are not used. This statement is true of even such basic tools as debuggers. Granted, a debugger tends to get more use than other tools, but it is only used when it is needed.
There was once a time, not that long ago, when developers were willing to pay sometimes a significant amount, for access to these tools 100 percent of the time, in order to actually use them for the five percent when they were really needed. Occasionally we had the odd developer who would request an evaluation copy of the tools, three or four or five times a year. What those developers were doing is getting free use of the products, only when they were needed. We tolerated these developers, because we didn't have any way to refuse the evaluation or make them buy.
Well, money is scarcer today, and paying for occasional use doesn't make a lot of sense. It turns out that those who requested evaluation software only when they needed that capability had the right idea after all. The value was nothing most of the time. During the brief times when the value was high, we were willing to give away the software, at least for brief periods. It turns out that for many developers, those brief periods are all that is needed.
So is it possible to make money from building and selling software quality and productivity tools to developers? That's a good question. If you have any thoughts on the issue, please let me know.
But I won't follow up right away. I'll be leaving on vacation in a couple of days, so I'll be back on these pages in a couple of weeks. See you inHawaii.
Posted by Peter Varhol on 05/19/2005